Re: License Stuff



Why then, should we push Linux (and other free unixes) support for
comertial companies at all? Shouldnt we keep our platfor perfectly
pure? Keep all the propriatary code on a propriatary operating
system? Some people need to code and cant use the gpl, and if they have to
reinvent the wheel every time they need to do something we will get bloat,
things wont get done in the first place, and linux will never get
accepted by the masses. I understand the want to get all apps to be GPLed,
but it wont be posible for a long time due to the fact that managers just
dont get it, and some dont want to get it. If you want your lib to be
accessable to the widest range of coders, lgpl it. If you want to limit
your users gpl it.

On Fri, 20 Oct 2000, Derek A. Neighbors wrote:

> Rodrigo,
> 
> > > The this is _not_ possible now a days is a _false_ statement.  I wont go
> > > into a license holy war.  I will say that if you _MUST_ dirty this
> > > project by doing it as LGPL please dual license as GPL/LGPL to at least
> > > show that you dont devalue the GPL but rather feel some "commercial"
> > > need to be accepted.
> > >
> > 
> > Derek, I understand your concern about GPL/LGPL issues, but what I don't
> > see is why does having LGPL dirty the project? As I said, I'm not an expert
> > on license issues, so I may be missing something....
> 
> It is 'dirty' because now prop programs can use it.  That was probably a
> harsh statement.  So please ignore the negative connotation behind it. 
> It wasnt intended to mean choosing it makes the project unusable or
> anything.
> 
> Here is a link to my stance.  I am going to do some cutting and pasting
> of it with comments, but here it is in its entirety for those wishing
> full context. ( http://www.gnu.org/philosophy/why-not-lgpl.html )
> 
> <snip>
> The GNU Project has two principal licenses to use for libraries. One is
> the GNU Library GPL; the other is the ordinary GNU GPL. The choice of
> license makes a big difference: using the
> Library GPL permits use of the library in proprietary programs; using
> the ordinary GPL for a library makes it available only for free
> programs. 
> </snip>
> 
> That in a nut shell is the difference.
> 
> <snip>
> Which license is best for a given library is a matter of strategy, and
> it depends on the details of the situation. At present, most GNU
> libraries are covered by the Library GPL, and that means
> we are using only one of these two strategies, neglecting the other. So
> we are now seeking more libraries to release under the ordinary GPL. 
> </snip>
> 
> Here is a call to please not use the LGPL unless completely warranted.
> 
> <snip>
> Proprietary software developers have the advantage of money; free
> software developers need to make advantages for each other. Using the
> ordinary GPL for a library gives free software
> developers an advantage over proprietary developers: a library that they
> can use, while proprietary developers cannot use it. 
> </snip>
> 
> Maybe this is a philosphy, but while some people say making LGPL gets it
> in more users hands, is it really good if that means more prop vendors
> hands???  I think the thought is if you have something out there that
> can compete or is unique keep it free... It will force others wishing to
> share in its success to make their stuff free or to go through the pain
> of making their own to stifle others freedoms.
> 
> <snip>
> Using the ordinary GPL is not advantageous for every library. There are
> reasons that can make it better to use the Library GPL in certain cases.
> The most common case is when a free library's
> features are readily available for proprietary software through other
> alternative libraries. In that case, the library cannot give free
> software any particular advantage, so it is better to use the
> Library GPL for that library. 
> 
> This is why we used the Library GPL for the GNU C library. After all,
> there are plenty of other C libraries; using the GPL for ours would have
> driven proprietary software developers to use
> another--no problem for them, only for us. 
> 
> However, when a library provides a significant unique capability, like
> GNU Readline, that's a horse of a different color. The Readline library
> implements input editing and history for interactive
> programs, and that's a facility not generally available elsewhere.
> Releasing it under the GPL and limiting its use to free programs gives
> our community a real boost. At least one application
> program is free software today specifically because that was necessary
> for using Readline. 
> </snip>
> 
> This is the point I have brought up SEVERAL times and no one will
> directly address.  On GNU\Linux where is the non-free competition of
> libGDA/gnome-db that warrants doing LGPL over GPL????  Maybe it exists
> and I am not aware of it.
> 
> <snip>
> If we amass a collection of powerful GPL-covered libraries that have no
> parallel available to proprietary software, they will provide a range of
> useful modules to serve as building blocks in new
> free programs. This will be a significant advantage for further free
> software development, and some projects will decide to make software
> free in order to use these libraries. University projects
> can easily be influenced; nowadays, as companies begin to consider
> making software free, even some commercial projects can be influenced in
> this way. 
> </snip>
> 
> This goes back to the philosphy I was describing above.
> 
> <snip>
> Proprietary software developers, seeking to deny the free competition an
> important advantage, will try to convince authors not to contribute
> libraries to the GPL-covered collection. For
> example, they may appeal to the ego, promising "more users for this
> library" if we let them use the code in proprietary software products.
> Popularity is tempting, and it is easy for a library
> developer to rationalize the idea that boosting the popularity of that
> one library is what the community needs above all. 
> </snip>
> 
> At this time the ONLY reason I have heard this list say to do LGPL is
> because they feel it gives them more users and popularity.  (Even our
> own Reinhard) <-- Time to put you in the time out box. ;)
> 
> <snip>
> But we should not listen to these temptations, because we can achieve
> much more if we stand together. We free software developers should
> support one another. By releasing libraries that are
> limited to free software only, we can help each other's free software
> packages outdo the proprietary alternatives. The whole free software
> movement will have more popularity, because free
> software as a whole will stack up better against the competition. 
> </snip>
> 
> This is VERY true.  One reason we were drawn to libGDA/Gnome-db was that
> it was GPL.  We looked forward to being able to help a "free software"
> brother grow and develop in our journey. 
> 
> <snip>
> Since the name "Library GPL" conveys the wrong idea about this question,
> we are planning to change the name to "Lesser GPL." Actually
> implementing the name change may take some time,
> but you don't have to wait--you can release GPL-covered libraries now. 
> </snip>
> 
> Of course this is a final word that says a lot and as in our talks some
> people have said they call it "lesser" for a reason.
> 
> 
> BTW: Before you flame for the above... I said I did not want a license
> holy war.  Everyone is entitled to their opinion.  I only responded
> because I was asked directly by Rodrigo and was going to just reply to
> him directly rather than fill the list with license debates.  I did not
> as I figured that would not be fair for others to have the ability to
> refute the points and give Rodrigo a full spectrum of views coming from
> people on this project.
> 
> Derek Neighbors
> GNU Enterprise
> http://www.gnue.org
> derek gnue org
> 





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]