FPLL approval - reprise

[Giancarlo Niccolai]

Hello;

I  would like to add new material to the discussion (in the second part, 
I report a fresh direct experience).

Up to date, the only comment on Falcon Programming Language License 
compliance to OSI standard has been "obviously compliant". Then, it has 
been noticed that the community hasn't raised an issue (yet) about 
special concerns in licensing structure that "engine" oriented software 
brings into its users.

I have exposed the fact that there is currently no scripting language, 
and generally no interpreted/bytecode compiled language in the wild that 
uses an OSI approved license as-is, with the exception of LUA, which 
uses BSD licensing, but whose embedding model is widely different from 
the other scripting languages: LUA is positively made to be hacked at 
source code level right into "your application", so the final user is 
nearly always in definite need to create a personalized version of the 
software, where there isn't a precise boundary. In short, LUA adopts a 
"cut & paste me in your code" approach, and BSD is definitely the most 
adequate license. In all the other cases (from SWI prolog to CLisp, to 
Python, to PHP and so on), and extending the concept to serviceable 
engines (i.e. OGRE), direct modify of the engine is discouraged, and 
preferably separated (have a patch? -- don't keep it, send it back to me 
so others can benefit).

I think that the objection that "the community hasn't raised the issue" 
(yet) doesn't really hold. The moral suasion towards getting one of the 
OSI approved license is immense; for example, Falcon would not have been 
shipped with any linux distro otherwise; and also, commercial entities 
interested in the product first question is "won't be your code 
legal-polluting my selling?" (direct experience). So, rather than go to 
a lawyer and have a license reviewed (it took a year or so to shape down 
FPLL and have it approved by my lawyer), even if in NEED of a better 
model, every single member in our small community will be nearly forced 
to stick with an inadequate license and eventually amend it through its 
sole judgment. And again, some amendments may be thoughtfully breaking 
some of our rules (you read my rationale, and evil #1-#4, I assume).

----

On this point, I have a fresh, relevant experience.

Falcon has just been approved in Titanium project; we're starting the 
API integration right now. I accepted to release Falcon under Apace 
license for Titanium (which, actually, is more restrictive than FPLL, so 
I gave away nothing of the rights I reserved with FPLL), as it's an OSI 
approved license and, you know, they didn't want to get in trouble... 
... ...

But Mr. Marshall Culpepper, one of the project leaders, was very 
interested in the FPLL; so he asked me some details, and I explained him 
the mechanics and the aims of the license. He confirmed that "we have 
the same view: let everyone use our software freely, even in closed 
source products", if that "everyone" just respects our work. He asked me 
about the progress of FPLL here. The application stand point is slighly 
different, as Titanium is an application framework using scripting 
engines, so it's not an embeddable engine itself, but it can produce 
even closed source applications; so he was cherishing the possibility to 
add exceptions to Apache license to better suit this aspect. Of course, 
it was discouraged first by the complexity of the task (that is, would 
an exception "such and such" be effective? -- would it be legal? -- 
would it clash with something I didn't read in the legalese of Apache2 
license?) and secondly by the fact that Apache2 + exception wouldn't be 
automatically OSI certified, and that may scare away or make suspicious 
commercial user entities.

In short, he would seriously consider using FPLL if it was approved, and 
he is considering to accept Falcon as FPLL even if not OSI approved.

----

I repeat that I am absolutely and positively interested in making a good 
work out of FPLL, and a work that everyone with our needs may reuse 
directly; this includes VM based languages, embeddable languages and 
application engines, and that, I repeat, is an important and totally 
uncovered area. For this reason, I would be eager to add/change anything 
that the OSI board thinks it may be useful for this cause.
In short, I am offering to cooperate to fill a gap that *IS* perceived 
in our community (the community of open source serviceable 
engines/application framewors/scripting languages, that is, the 
community of service-oriented open source software producers), for how 
small it may be with respect to other communities, and that *IS* 
uncovered, and this *IS* a problem that we *DO* perceive every time we 
need to exchange/integrate our software.

The fact that only foundations and commercial backed institutions have 
been able to produce a product/entity specific license just for 
themselves (and you approved them, despite their specificity), being the 
others forced (yes forced) to stick with nearly inapplicable licenses, 
talks in favor of my arguments.

The problem is not just relevant for the producers of this kind of 
software; it is even more relevant for the users; just consider the 
additional cost of screening the exceptions or the effect of dual 
licensing + distro restrictions on a wide set of suitable software 
BEFORE taking into consideration their technical aspects. But I went in 
the detail of this point in the #4 evil of my rationale.

Thank you in advance for your kind attention,
Giancarlo Niccolai.