License Committee Report for September 2009

[Giancarlo Niccolai]

Will Robertson wrote:
> On 17/11/2009, at 11:26 AM, Bruce Perens wrote:
>
>>> As the only example I'm familiar with, take the example of LuaTeX, 
>>> in which the pdfTeX engine is opened up and grafted together with 
>>> Lua. (My understanding of the way these embedded languages work 
>>> only:) This is quite significantly more than just linking to a 
>>> shared library -- i.e., it would be completely impossible for a user 
>>> to simply relink a new version of Lua into LuaTeX.
>> No, this is just engineering that you haven't yet been educated about 
>> yet.
>>> - If Falcon has BSD,  then Falcon can be used and abused without 
>>> restriction by the proprietary software.
>>> - If Falcon has LGPL, then the software must be unduly opened up.
>>> - If Falcon has FPLL, then the software can stay closed but must 
>>> reference Falcon.
>> Not valid, for reasons given above.
>
> Okay, thanks for the info.
> Seems to me, then, that the LGPL should be acceptable for Falcon.
>
It seems that LGPL is not acceptable for some of ours "institutional 
users", so we can't simply distribute Falcon solely with a LGPL. We 
simply can't use it "as is" and alone.

We're currently shipping Falcon under dual licensing: GPL for linux 
distro requiring OSI certified licenses and FPLL for the rest of the 
world. It's hard to distribute a toolset (which include command line 
tools) under LGPL....

If FPLL gets OSI certified, we will distribute Falcon solely as FPLL. 
Still, in both cases, you can pick GPL also if you're part of the "rest 
of the world". Or any other license that respects FPLL, which includes LGPL.

Please, notice that the "advertise" clause of FPLL in closed source 
software is implicitly (but effectively) included into GPL/LGPL as well: 
they state that the covered software must be redistributed as source, or 
that it must be indicated where and how a source copy can be obtained; 
which requires all the GPL/LGPL covered software used in a closed source 
project to be advertised to the final users. So, FPLL is effectively 
granting a subset of the guarantees offered by GPL and LGPL, (plus the 
non-patentability clause), with a more precise definition of specific 
software typologies that GPL/LGPL just don't draw.

I think there is enough material now for the OSI committee to decide if 
FPLL is open source and is different enough from GPL/LGPL to constitute 
a new different license, under its criteria.

As a very final notice, let me re-state that I don't really understand 
the anti-license-proliferation crusade, which had the side effect of 
generating a jungle of exceptions whose combined effect is far from 
clear, on an international legal ground (I respectfully point out again 
evil #1, #2, #3 and #4 of exceptions to certified licenses I wrote about 
in my rationale).

Either, a license is conforming to a standard or not; and it grants 
different coverage and has different effects or not. I hope OSI will 
evaluate the question under this two relevant dimensions.

I am still available for queries and further clarifications.

Best regards,
Giancarlo Niccolai.