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.

Yes. That's the exact purpose of the GPL/LPGL.

> 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.

Worrying about the reuse of the code is a good thing. But imho when we
move code around, most of the time it's our own code and we can always
move our code around. And if it's not our code, I think it's nicer to
discuss this before moving it.

And please stop using "infecting" and word like that. Word matter and
by choosing them unwisely you are encouraging troll and flamewar, not
discussion.

> 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).

Yes, you can't move code from a LGPL library into a BSD licenced
application. In fact, if you want to move code from a LGPL library to
an application you should "enable" section 3 and this application
should be GPL, but that's the exact purpose of the LGPL. LGPL give the
freedom to link with the library whatever the licence of your app is,
but you can't copy code from it in your app. Yes, that's the purpose
of the LGPL.

And in fact, most of the time, we should not copy code, but merge it
and share it in a common place, a library. That's always a good
software practice, but this argument is general and doesn't reflect
any particular case. Perhaps you have in mind an example of a copy of
code that could be usefull.

> 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."

I think that Sun lawyer are not completely dumb and they did choose
the licence carefully. And it will be LGPLv3 for next release, see
http://www.openoffice.org/license.html.

> 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.

Yes, that's the historic reason.

> 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.

Their is a condition in the LGPL that you missed, in section 5, you
can include header from the library with small inline, if that's what
you want.

And I am in favor of switching the core EFL to LGPL, not E and I
perhaps missunderstood others on this, but we are speaking about the
core library (eet,embryo,evas,ecore and edje).

> So yes, even the LGPL can "infect" other code.  Just not as badly.

No, that's just wrong. The way I understand your reasoning is that we
will pick code from one of the core library put it in E. Then switch E
to GPL. Then you will take code from E and EWL will become GPL too.
This will not happen. That's not the plan. Their is much more chance
that we move code from E to new external library, than the
hypothetical case we put code from the core library inside E.

> If all we care about is linking, then LGPL is just as fine as BSD.
> But is that all we care about?

The way I feel about this, is that this community is growing as a user
of the EFL. This user don't copy our code, they use our library. And
this is currently not increansing the mass of people/company
committing work into the core EFL. I care about this community, and I
think due to my little experience, that the license is a way to take
care of this community. And yes, their is more point to adress than
the licence, but that's the one we discuss here.

--
Cedric BAIL

-------------------------------------------------------------------------
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

Reply via email to