License Committee Report for September 2009
Giancarlo Niccolai
gc at falconpl.org
Mon Nov 16 11:27:45 UTC 2009
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
More information about the License-review
mailing list