License Committee Report for September 2009

[Giancarlo Niccolai]

Will Robertson wrote:
> Hi,
>
> On 16/11/2009, at 4:21 AM, Giancarlo Niccolai wrote:
>
>> Finally, we're integrating Falcon into third party products which 
>> are, btw,
>> not fully GPL compatible, as Titanium appdeveloper, Ogre 3d engine 
>> and several
>> commercial products.
>
> I'm a novice in the details of all of these licensing matters, but 
> your original FPLL to me sounded rather similar to the LGPL, with some 
> odd restrictions such as:
>
>> In example, if You use Falcon to drive a web site, and You don't want 
>> Your site visitors to ever see Your scripts, You have to put 
>> somewhere a reading like "Powered with Falcon".
>
Notice that the paragraph also reads that it has not to be done in every 
page, nor it needs to be prominent. It may be just a notice in the faqs, 
in the documentation, or in any place. Also, this doesn't apply if the 
scripts are "visible" (read, open-source or closed source but still 
queryable). Open source web-based products, as web platforms or CMS 
systems, are not required this.

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

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. Also, 
there is the same non-patentability clause retained from Apache license, 
which, combined with the non-hide-ability, means "use this software as 
you want; but don't steal it, nor prevent your user from know what 
they're running, and decide if it's ok for them".

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

Bests,
GN