Re: [E-devel] License questions

[Carsten H. (T. R. <ra...@ra...>]

On Thu, 24 Jul 2008 14:08:03 -0700 Michael Jennings <e-...@ka...> 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/  <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
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...