On Thu, Jul 24, 2008 at 11:08 PM, Michael Jennings <[EMAIL PROTECTED]> 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/  <[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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

-------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to