On Thu, 24 Jul 2008 14:08:03 -0700 Michael Jennings <[EMAIL PROTECTED]> babbled:
> 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. > > 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. i think we asked people to do it - for ease - it is a good thing to do, but, they still are free to license as they see fit - it is their work and their code. > > 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. yes - known. but if you LINK to it - it doesn't matter. if you literally include it verbatim - it infects. so: -lwhateverlib - does not infect #include "whateverlib.c" - does. i'm just caring about linking here. it means you can make a nice clearly defined boundary that is also convenient :) > 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/ <[EMAIL PROTECTED]> > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
