License Committee Report for September 2009

[Giancarlo Niccolai]

This is to re-open the discussion about the license, as the report for 
November Committee indicated that there wasn't enough discussion to decide 
about the Falcon Programming Language license.

In data mercoledì 02 settembre 2009 17:21:53, Russ Nelson ha scritto:

: > Giancarlo Niccolai writes:
>  > sent with the submission I explained why I thought it is preferable to
>  > stop the "custom license / GPL, but with my own uncontrolled/uncertified
>  > exception" rage, and to offer a standardized license covering this
>  > general need.
> 
> I believe it is wiser to wait until the need is made clear by having
> many adopters of this language.  

Falcon has entered top 50 languages in TIOBE listing in October; in November, 
it scaled up to position 46, and it is currently being listed in front of 
languages as Forth and Smalltalk.

Of course, we all know that TIOBE listing is not accurate regarding real 
adoption of a language, especially past the first 25 positions, but the fact of 
being in that area of a listing considering several thousands languages is 
nevertheless an important indicator.

Also, we're starting communication campaigns (read $ investments) in the next 
two-three months. We expect this effort to widen the adopter basis, and 
interest commercial audience.

The guarantee of an OSI certified license which is disengaged from some GPL 
limitations in this specific software application type is primarily important.

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. Providing non-clashing exceptions  for each of them would 
be a legal effort that's beyond our current abilities. We need a clear cut 
license which can integrate into those applications, and other that will come 
later, and FPLL grants the needed integrability.

> A GPL ... with modifications ... can
> be consider as the GPL unless you particularly care about the extra
> freedom.  Yet Another License needs to be understood in its totality.
> 

I exposed why this exact way of seeing "exceptions" can generate serious legal 
problems, and drive commercial entities away from Open Source, in my 
rationale.

Up to the moment, not a single statement of the #4 reasons I have discussed 
about in my rationale has been neglected by concrete argumentation, and each 
one of them, IMHO, is sufficient to suggest that the community should move away 
from exceptions to certified licenses, especially when those exceptions are not 
re-certified themselves.

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. My personal views on the legal valence and problems 
caused by exceptions to certified licenses are just an incidental question and 
are indicated in the Rationale for the sake of completeness.

Moreover, FPLL license is generic, and immediately adoptable by any project 
with similar characteristics:
- Offering a set of functionalities that can be combined dynamically into a 
third party application (engine model, exp. but not limited to scripting 
engines); and/or
- Offering the ability to write stand-alone programs; this feature is provided 
usually, but not exclusively, by programming language compilers/interpreters. 
For example, CASE solutions, visual workflow builders, and in general anything 
that allows user to compose dynamically the functionalities offered by another 
applications in an unique sequence.

So, the license would cover a need that is felt in the community; I can claim 
it is felt exactly because all the similar software in the Open Source world 
has either 1) developed its own license or 2) applied sever exceptions to 
existing license (whose validity is, IMHO, all to be demonstrated). This is 
another point that I have exposed in my rationale in the other mails, and that 
has been never confuted, or to say it all, even touched, in any discussion we 
have undertaken up to date. 


I may also digress on the specificity of Python and Ruby licenses, and on the 
exception that OSI has granted to the respective entities with respect to the 
OSI rule about non-specificity of licenses. But I'd prefer to avoid entering 
into this detail; I think the arguments I have drawn are strong enough not to 
require this additional theme to be brought in the field of the discussion.

With the hope not to bore this respected audience,
Bests regards
Giancarlo Niccolai