License Committee Report for September 2009

[Will Robertson]

On 16/11/2009, at 9:57 PM, Giancarlo Niccolai wrote:

>> Perhaps I'm missing something obvious though; can you outline why  
>> the LGPL doesn't suit your needs?
>
> Yes: when used as a scripting engine, Falcon (or, with this regards,  
> any scripting engine, or in general, any application framework  
> engine) is integrated in the final application so that it makes an  
> unique merge. For example being C++ it has relevant part of the code  
> being verbatim copied into the final application. Also, there are  
> many cases in which the user application is required to extend  
> Falcon classes. The concept of "library linking" cannot be readily  
> applied, and if blindly applied, it may bring to some legal  
> controversy.

There does seem to me to be a legitimate distinction between linking  
to a library as opposed to integrating something within the  
application itself.

So my interpretation of this is that you basically want to provide the  
same sort of system as Lua, say, offers but with a more GPL-style  
licence rather than a "plain" BSD one. And you don't want to use  
Apache licence because malicious/careless people might use the code  
without saying where they got it from?


> Then, the scripts running in the application may be just  
> "decorative" or be more centered on the application core  
> functionalities. In some cases, the application may even just be a  
> shell running certain scripts. LGPL says nothing about those  
> scripts, and saying nothing doesn't automatically means that they  
> are "free" from LGPL, not in legalese, at least.
>
> Combining this two aspects drives commercial (read, non-GPL  
> compatible) users away from an engine-like software. FPLL is  
> designed to state the fact that an FPLL licensed product can be  
> highly integrated, and even extended inside foreign non-FPLL  
> compliant applications (for example, by subclassing, overriding,  
> partial rewriting & so on), WITH THE ONLY CONDITION that this fact  
> must not be hidden away from the users.

(You still have to distribute any changes to Falcon itself as free  
software, right?) So, in simplest terms, if one were modify Falcon  
itself it must be distributed as per a GPL license (basically), but  
one can embed it into a closed-source product.


>> Regardless, if you're creating an all new FPLL then it's probably  
>> worth waiting for that one rather than discussing the old.
>>
> Well, I created an all new FPLL, but as I repeatedly said, if there  
> is a valid alternative I have overlooked, I'd be glad to adopt it.  
> Of course, "certified license + uncertified exception" is a "no"  
> here (and for some relevant user I was poked from). But certified  
> license + certified exception would be ok, if such thing can exist.

Wait, I think we got our wires crossed; in a previous message you said:

> HOWEVER, I don't want to drive the discussion in that direction. I am
> presenting a new license, derived from APACHE2.0, which has some  
> relevant
> differences and a specific application area which was not originally  
> in the area
> covered by APACHE2.0.

I thought when you said this that you meant that the license here is  
going to be replaced by a new one: <http://www.falconpl.org/index.ftd?page_id=license_1_1 
 >

Did I misunderstand?

-- Will