License Committee Report for September 2009

[Giancarlo Niccolai]

Will Robertson wrote:
> 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. 
Correct. Also, in the case of LUA, it would be quite impractical to ask 
for republications of the modification of LUA code, as LUA code is meant 
to be modified every time it is used in this context.

> And you don't want to use Apache licence because malicious/careless 
> people might use the code without saying where they got it from?
Correct, but not just because of that. (Let me be product specific in 
this exposition, but just for the sake of an example I know well). 
Apache license is not targeting programs RUN THROUGH a certain engine.

When you run a Falcon script with this FPLL product (Falcon command line 
interpreter), you're using a third party product. A  Falcon program, 
WHEN run through FPLL covered interpreter, is just instructing the 
interpreter to do things for it.

FPLL clearly states that despite this fact, the script themselves are 
clear from FPLL, and a separate license can be applied to them EVEN when 
shipped and bundled in one unique final (and possibly even closed) product.

Then, Apache doesn't know about embedding applications, that is, 
applications using the engine to run scripts and interact with part of 
them.

FPLL draws a well-defined and explicit line between what is FPLL (the 
engine) and what is not (your scripts, embedding applications and 
modules), and thus clears the ground from some misunderstanding and 
concerns that get still questioned about by "the bosses" when using an 
open source app in a commercial entity.


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

> 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.
Yes, AND write closed-source product entirely based on it (i.e. 
Falcon-only applications). If you do, you can distribute Falcon in 
binary form, hidden in a bigger exe, bundled in a package format, or 
ANYWAY YOU LIKE. The only requirement is that, if you don't make the 
scripts accessible to the users, then you state somewhere that you're 
using Falcon (or the FPLL licensed 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?
No, I mis-explained. I meant I don't want to drag the discussion into 
the pros and cons of uncertified exceptions.

I presented FPLL as a new license because I don't believe that 
exceptions to certified licenses serve the community and the users well 
enough, but I don't want the discussion to end up into a discussion 
about the validity of this opinion.

So, we're discussing if FPLL is:
- valid under OSI terms (it's open source compliant).
- different enough from the other solutions to be a license on its own.

If not, I am willing to:
- modify it to be OSI compliant and different enough OR
- adopt any other certified solution granting the same guarantees, both 
to developers and to final users, which I may have been unaware of.

Bests,
Giancarlo Niccolai