FPLL approval - reprise
gc at falconpl.org
Thu Sep 10 08:21:15 UTC 2009
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,
More information about the License-review