From: Jorge L. Z. M. <jor...@gm...> - 2008-07-24 23:53:18
|
On Thu, Jul 24, 2008 at 11:08 PM, Michael Jennings <e-...@ka...> wrote: > On Friday, 25 July 2008, at 00:41:51 (+1000), > Carsten Haitzler wrote: > >> if this is for code going into an existing application and/or >> library he is right. code is to be the same license as the existing >> tree - if it is to be a different license - it cannot go into the >> tree. this is simply standard practice. if someone wants to create a >> new library, a new app (and by this i would define it as having its >> own configure.in/ac and build tree) then they may choose any license >> they like. if they make is a GPL library - then it will never be >> used by me as a basis for any other apps that are not GPL (as the >> GPL thus infects). if it's LGPL - it's moot as the license does not >> extend beyond the boundaries of that library. if its an app - it >> doesn't matter. > > Assuming no one using another license ever wants to use that code. If > Peter writes a really badass EWL app and LGPL's or GPL's it, that code > could not be used in E or Evas (unless Peter himself relicensed it) > without changing their licenses to LGPL/GPL. I have a question here, where is the authorship then? if i have an app A licensed with L, i guess im free to relicense another (or the same) app with license M right? and if so, being myself the author how can i not put my own code into another app with license N? does the authorship get relegated to the license itself? > > The reason we originally required all items in the repo to be BSD > licensed (and yes, this decision was made a long time ago) was so that > code could be moved seamlessly between projects without having to > worry about relicensing or infecting other projects. > > It sounds like you're rescinding that decision. If so, that's fine, > but everyone needs to understand that code can't just move around at > will any more. But it's your call. > >> as i said - IMHO GPL is not right - it infects beyond the boundaries >> of its container. LGPL is acceptable. > > Unfortunately, so does the LGPL. > > Let's look at LGPLv2.1 first > (http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html). According > to Section 2a, any "work based on the Library" (that is, anything > containing the Library's code, or any portion thereof, even just a > single function or code block cut-and-pasted in) MUST itself be a > LIBRARY. > > Wait, what? Yup, that's right. The LGPL forbids you from snagging a > portion of code from an LGPL library and using it in a program (i.e., > independent executable). In fact, I can't find anything anywhere in > the LGPLv2.1 that allows it to be used for non-libraries. LGPLv3 > doesn't appear to have this limitation, since "Library" is defined as > any work covered by the LGPLv3. But LGPLv2.1 only covers objects you > link with to create executables, not executables. So LGPL code cannot > be used in applications (e.g., E itself). > > Based on the clear language of the license, trying to apply it to a > software program (like OpenOffice.org) doesn't seem to make any sense, > since the legal term Library used throughout the license cannot apply > to something like Writer which you would never "link against to form > executables." > > The only provision in LGPLv2.1 that would allow someone to use LGPL > code in an application is Section 3 which allows the LGPL to be > replaced by the GPL at any time (and at version 2 or any later > version). So in order to cut-paste-and-modify code from an LGPL > library into an application, the application MUST become GPL. > > Obviously this does not include linking, but one of the primary > reasons we picked the license we did was so that our code could be > used in other software under other licenses (Apache, Artistic, > Mozilla, or yes, even the GPL). Because of Sections 2c and 3, any > code coming from an LGPL project which is used in any way other than > linking can only be used in GPL/LGPL software. > > Here's an example of the danger: Let's say EWL is BSD, and the authors > want to borrow a small bit of code from a large LGPL'd library > (without linking to it); EWL would have to be LGPL'd. Worse yet, if > EWL wanted to borrow some code from E, and E were "LGPL'd" (which > really means GPL'd since it's not a library), EWL would have to become > GPL'd. Then all software using EWL would be GPL'd. > > So yes, even the LGPL can "infect" other code. Just not as badly. > > The LGPLv3, unlike the LGPLv2.1, is not a separate license in its own > right. It is a set of addendums to the GPLv3 which provide additional > "permissions" above and beyond those granted by the GPL. Having not > read the GPLv3 myself, I'm not prepared to discuss whether it's better > or worse. The LGPLv3, as I said before, does seem to allow itself to > be applied to applications as well as libraries, so it would really > seem to be the only option for LGPL'ing the programs that link with > the EFL. > > If all we care about is linking, then LGPL is just as fine as BSD. > But is that all we care about? > > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> > Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) > ----------------------------------------------------------------------- > "Kyrie eleison down the road that I must travel. Kyrie eleison > through the darkness of the night. Kyrie eleison; where I'm going, > will you follow?" -- Mr. Mister, "Kyrie" > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |