[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] Re: [Maxima] Re: GCL compliance and Bill Schelter
Re: [Axiom-developer] Re: [Maxima] Re: GCL compliance and Bill Schelter
25 Jul 2003 11:33:50 -0400
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Greetings, and thanks for your note!
Bakul Shah <address@hidden> writes:
> > 3) This having been said, it is my opinion that axiom would be better
> > served by a GPL license. It is of course completely up to the
> > axiom developers and any other relevant parties, certainly not me,
> > but I feel that the existing BSD license places all the volunteer
> > work being poured into axiom at risk of being hijacked by a
> > commercial fork of the code.
> Just clarifying something....
> The code base that such a commericial project may start from
> *does not* suddenly become closed. An open source developer
> is perfectly free and able to continue working on the
> non-commercial branch. No volunteer work gets lost. What
> you may not get are *further* changes made by the commercial
> What may happen is that someone other than the volunteers
> makes money. Is that what you are calling "being hijacked"?
1) I think it is important to restate that one is completely free to
sell a GPL'ed program commercially. I'd guess that at present,
more money is made from sales of GPL'ed GNU/Linux (e.g. Redhat,
Suse, IBM, etc.) than from sales of closed source BSD derivatives.
This actual working example speaks louder to me than all other
theoretical speculations. This is not about money, but freedom or
liberty. By all means, sell free software, profit and be happy!
But please, just don't close the source.
2) 'Hijacking' does not necessarily follow from a closed source
proprietary fork of a BSD program, but certainly can, and is
arguably quite plausible, though whether or not it is likely
depends on the circumstances in each particular case. Here is how
it works, at least in my mind.
To flourish, a free software program must have an active,
knowledgeable, and dedicated group of developers, volunteers or
otherwise. To motivate and and provide feedback to these
developers, the program needs as large and as varied a group of
users as possible.
So say this exists for a BSD program, and suddenly someone makes a
closed source proprietary fork, and over the course of some time,
improves the program significantly. There is an enormous pressure
on the user base to stop using the free version and buy and use the
closed version instead. The feedback and motivation for the free
program developers steadily deteriorates, perhaps to the point
where they feel no one cares about the free program any longer, and
it has lost the race against the closed proprietary version. The
developers start to do something else. Over time, people even
forget how the code works. The barrier for someone completely new
to the code to take on the project becomes exceedingly high, as
they are effectively on their own with a steep learning curve. The
program is effectively 'hijacked'.
Now there are cases where BSD code does not follow this path, at
least not yet. One highly successful example is postgresql. Then
there are cases where some diluted form of the above is at play.
In my personal opinion, the great difference in developer mindshare
between the Linux and BSD kernel projects is due in part to the
commercial mindshare drain into projects like BSDI, in part due to
early legal conflicts with commercial entities claiming rights to
the same code, and in part due to the feeling among some would be
contributors that their contributions are not adequately protected
for posterity (e.g. via the mechanism outlined above), all of which
are in part due to the nature of the BSD license. And then there
are some projects where the above scenario appears to dominate the
program's evolution, for example with the early browser Mosaic.
The source to Mosaic was always available, but it was largely
rendered useless for some time by the dominant binary only
distributions of Netscape and then IE, until Netscape again opened
the source and forked Mozilla.
> > The last thing I am is a lawyer, but
> > my understanding of the BSD license is that anyone, including the
> > developers, can, if they so chose, relicense their copy/modified
> > version of the code under the GPL. This does not violate the BSD
> > license, to my understanding, and should require no special
> > permission. After all, one can make a commercial fork of BSD code
> > without permission, so one should certainly be able also to make a
> > GPL fork of said code.
> Commercial forking is allowed and done *with* the permission
> given in the BSD license! But I believe you can not take BSD
> licensed code and put it under GPL due to the following in
> the BSD license:
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> * 1. Redistributions of source code must retain the above copyright
> * notice, this list of conditions and the following disclaimer.
> * 2. Redistributions in binary form must reproduce the above copyright
> * notice, this list of conditions and the following disclaimer in the
> * documentation and/or other materials provided with the distribution.
> As I understand it, by requiring that source be available
> GPL modifies condition 2. above and hence runs afoul of the
> BSD license. But I am not a lawyer!
I am certainly not a lawyer either, but my understanding here is a bit
different. BSD basically says one cannot remove the copyright notice,
disclaimer, etc., and one cannot remove the condition that they not be
removed. The GPL in no way contradicts this, but rather *adds* a
restriction that binary distributions must be accompanied by source to
those who want it. If BSD said something like 'no extra requirements
may be placed on the distribution of this code or its modifications',
then the GPL would not be compatible. It is also my understanding
that nothing in the BSD license explicitly grants permission for
commercial closed source forks as apart from GPL'ed forks.
> But if this is the case and if Lisp & Maxima remain intermingled
> does it mean Maxima can't be used with CMUCL?:-):-(
Precisely. I think if you're interpretation of BSD were correct,
Maxima could not distribute an image compiled with CMUCL. Just to
restate, I don't think this is the case, and believe there is no
problem with Maxima/cmucl.
> Personally I am *glad* there are two competing free licenses
> even if there are headaches such as this one.
I also have nothing against people who want to BSD their code. But I
do contribute to some BSD'ed open source projects, and feel somewhat
uneasy in that my contributions might be commercially 'hijacked'.
Just my feelings/opinions, of course.
> Axiom-developer mailing list
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
[Axiom-developer] Small patches, Camm Maguire, 2003/07/24
[Axiom-developer] RE: GCL compliance and Bill Schelter, Mike Thomas, 2003/07/25
[Axiom-developer] Re: GCL compliance and Bill Schelter, Richard Stallman, 2003/07/25
[Axiom-developer] GCL compliance and Bill Schelter, root, 2003/07/24
- [Axiom-developer] GCL compliance and Bill Schelter, root, 2003/07/24
- [Axiom-developer] Re: [Maxima] GCL compliance and Bill Schelter, C Y, 2003/07/24
- [Axiom-developer] Re: GCL compliance and Bill Schelter, Camm Maguire, 2003/07/24
- Re: [Axiom-developer] Re: GCL compliance and Bill Schelter, Mike Dewar, 2003/07/25
- Re: [Maxima] Re: [Axiom-developer] Re: GCL compliance and Bill Schelter, Camm Maguire, 2003/07/25
- Re: [Maxima] Re: [Axiom-developer] Re: GCL compliance and Bill Schelter, Mike Dewar, 2003/07/29