[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [jfw] Re: LGPL

On 13 March 2014 12:00, garyamort <> wrote:
> So how does the above apply to a PHP library?  Well, unless the PHP library
> is distributed as compiled code[for example, the Phalcon PHP Framework],
> none of it applies.  A PHP program is not compiled, it is distributed as
> source code.

The advice we have previously received from the SFLC is that they
consider the issue of licensing in terms of what code is running in
memory regardless of how "it got compiled". They don't make a
distinction between you using GCC to compile a native binary, or an
Apache server module converting it to machine instructions on the fly
for each page load. So my understanding is when the GPL code gets
mixed with the rest of the code stack in memory, it's going to want
every other byte of code to be GPL as well.

If we one day get a legal ruling to say that, for the likes of PHP,
GPL code does not infect the rest of the application our little
Framework is going to be the least of anyone's worries. The fallout of
that decision would be catastrophic to the GPL world view.

For what it's worth my personal view is that dynamic linking is this:

`$bar = new Foo();`

If we are LGPL, anyone can use the `Foo` class natively. If we are
GPL, only a GPL application can use the `Foo` class.

Derivation is considered in the following case:

`class myFoo extends Foo { /* my new code */ }`

If `Foo` is LGPL, `myFoo` must also be LGPL and you must distribute
the code with your application, but the application can be any license
and this removes a huge barrier to adoption.

If `Foo` is GPL, derivation forces `myFoo` to be GPL as well but then
the viral nature of the GPL kicks in again (or perception of it) and
we still have a barrier to adoption even amongst other OSI approved

If `Foo` is MIT, `myFoo` can be any license of your choosing and you
can even relicense it and you don't have to distribute the source.
This, in my opinion, goes too far in terms of the heritage of our
project (but probably a better option of indie authors).

> So why LGPL rather then GPL?  Mainly because of the *perception*.   GPL is
> perceived as being "viral" and LGPL is perceived as being "permissive".

But it's still strongly copyleft, so it's only a little bit
"permissive" when you compare it with MIT or BSD as examples. But you
are right, if our goal is increasing adoption then sticking with a
license that has known "perception" problems is not going to let us
achieve that goal.

> A place the actual license text in a seperate file such as:
> https://github.com/joomla-framework/twitter-api/blob/master/LICENSE
> It is easy to update these things to swap one license for the other.  Just
> change the LICENSE file and the @license lines and your done.

Yes, we need to do that anyway.

Andrew Eddie

Framework source code: https://github.com/joomla/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.