Subject: Approval of the "Falcon Programming Language License 1.1"
From: Giancarlo Niccolai <gc@falconpl.org>
Date: Thu, 13 Aug 2009 16:41:29 +0200
Thu, 13 Aug 2009 16:41:29 +0200
To the OSI Board,

This is a formal request of Approval for the Falcon Programming Language 
License 1.1.

FPLL is meant to be a general purpose, open source license aiming to protect 
the freedom and the rights of programming language writers and users. It is 
widely based on Apache 2. 

The official text of the license is available here:

http://www.falconpl.org/index.ftd?page id=license 1 1


I add a legal analysis performed by a prominent attorney in my country. I am 
sending a translation in english (approved by the attorney), the original 
document in PDF format and a transcription in .txt format. The analysis is 
centered on comparation with Apache 2 license (as required by the submission 
rules).

Here below I write the rationale of the License.

Thank you in advance for your Kind Attention,
Giancarlo Niccolai




Rationale
======

The Falcon Programming Language License (FPLL) is meant to be a general 
purpose, open source license aiming to protect the freedom and the rights of 
programming language writers and users.

When first releasing the Falcon Programming Language to the public, I searched 
for an open source license that may grant openness of the distributed code, 
prevent abuses as close-source boxing, but yet fully grant the ability to use 
the Falcon scripting engine everywhere, including in commercial applications 
and to do anything, including falcon-based commercial source applications. 
Studying deeply the GPL and LGPL licenses, and participating also to related 
newsgroups and mailing list, I discovered that they were not adequate for such 
a task, as they required any application where such a deep embedding is 
performed to be released under a GPL-compatible license. This would have made 
extremely difficult to integrate a Falcon scripting engine in already existing 
commercial applications, and would have been a deterrent to further adoption 
of Falcon in commercial realities where it was already somewhat used at the 
time.
Further studies confirmed this analysis: up to date, there is NO mainstream 
programming language, embeddable or stand-alone, released under a “pure” GPL 
compatible license.
Python, PHP, Ruby are all licensed under a proprietary license, which makes 
explicit reference to the entities that own the copyright of the original 
software (i.e. the Python foundation). In particular, Ruby license is 
controversial on some aspect regarding some specific key areas of the inner 
code. They are all OSI approved, but being project specific they cannot be used 
in other projects without modifications.
PERL is released under dual licensing, GPL and Artistic license; it is 
embeddable in existing commercial applications due to the latter, while the 
former grants compatibility with GPL based software distributions (i.e. 
GNU/Linux distributions).
SWI Prolog, Common Lisp, and even GCC are licensed under GPL or LGPL with some 
language/usage specific exceptions. In particular, runtime libraries for GCC 
are distributed under the “GCC Runtime Library Exception.”
Lua was licensed under a Lua-specific license (OSI approved, derived from z-
lib) up to version 4.0; version 5.0 and following are licensed under MIT 
license; yet, Lua source code is meant for inclusion and modification directly 
in other applications, rather than for usage as-is (as a ready-to-use engine), 
and as such its common pattern usage is a bit different with respect to the 
other programming languages.

In short, from this picture it is rather evident that the currently existing 
OSI approved licenses are deficient in covering the licensing needs of open 
source programming languages and scripting engines.
Also, the option of adopting an existing license and modifying it, i.e. 
applying an exception to it, may seem to reduce the problem of license 
proliferation, but it is actually working towards the proliferation of 
potential legal issues. IMHO it's evil #1, evil #2, evil #3 and evil #4.
It's evil #1 because it forces both commercial-oriented and free-oriented 
users into studying separate exceptions for separate products. When legal 
issues become relevant, this force, or should force, both open-source based 
institutions (i.e. GNU/Linux distributors) and commercial entities (i.e. firms 
willing to use my software) into kicking the exception down to the legal 
department and wait for a response before deciding to adopt a software with 
such a modified license. The argument that an exception is easier to analyse  
than a whole new license doesn't hold, as if it's true that the text of 
exceptions are usually (but not necessarily) shorter than the text of a full 
license, it's also true that the legal consequences may have the same width.
It's evil #2 because both who writes the exception and who accepts it may not 
have fully calculated the legal effects of it. At least in theory, it is 
possible to configure legal scenarios that can happen due to an exception and 
that are undesirable for one of the party, or for the general idea of software 
freedom; those legal scenario are exactly what a certification process is meant 
to exclude.
It's evil #3 because, applying such exceptions outside the control of a legal 
entity may generate a legal monster, which sneaks into otherwise legal-proof 
software set. The software base of GNU/Linux distributions, for instance, is 
just too big to account for an endless set of exceptions, and I have 
personally witnessed cases where open source software licensed under GPL with 
an exception had been added to the distribution without any further legal 
analysis of the exception. Similar scenario can be thought of commercial 
entities willing to adopt an open-source software to drive an internal or 
commercial project, could just read and approve the license terms, but it may 
overlook the exception as a minor detail, underestimating its legal 
consequences. This “legal time-bombs” may one day trigger a legal action that 
may 1) be a very unpleasant surprise for distributors, commercial developers 
and general users, and 2) provoke a damage to the image of free software.
It's evil #4 because, both in a commercial reality and in an open-source 
driven institution, it is impossible to account for the effects of all the 
combinations of every exception. The argument that “as long as it sticks with 
the policy (Debian), or with the criteria (OSI), the exception is OK” doesn't 
hold, as it is possible to figure some scenario where an exception may be in 
contrast with others without breaking those rules, or at least, without 
breaking a consistent subset of rules (compatibility with GPL OR (exclusive) 
conformance to OSI criteria OR (exclusive) conformance with the Policy) which 
may justify legally the existence of that exception in some open-source or 
free-software contexts.
In short, considering the inadequacy of existing non-specific licenses to cover 
the needs of an open source programming language interpreter/compiler/embedded 
engine, and considering the fact that exception proliferation is by no mean 
better than license proliferation, I worked towards a general Open Source 
license meant for this kind of software.
As a base, I used the Apache 2.0 license, which was the general purpose open 
source license nearest to the needs of a stand-alone language 
interpreter/compiler. The FPLL 1.0 was just the generalization of the Apache 
2.0 license with the introduction of the definitions of Embedding applications 
(an application using the “work” as an engine to perform some tasks) and of 
Applications of the work (that is “your scripts”, or better, an application 
run through the “work” which interprets it, or through the prominent usage of 
its libraries in case of compiled, machine runnable code). The distinction was 
made so that open source requirements applied only to the derivative works 
(that is, for example, an XFalcon which just extended the Falcon compiler or 
virtual machines with new functionalities), while applications and embedding 
works were required less stringent terms. After a discussion on the Fedora and 
Debian project legal mailing lists, and with the help of an attorney, I worked 
out a new version simplifying some concepts and clearing some ambiguities.
In its current form, FPLL states that:
Derivative works must be distributed under the FPLL license or compatible, and 
thus, 1) they must be made available in source code, 2) the original source 
must be made available or it must be indicated where to get it, 3) the 
modification with respect to the original source must be described.
Open source (i.e. when the source is made available) embedding applications 
and applications of the work (scripts in Falcon USING a FPLL licensed 
interpreter) are free from any restriction. They are positively outside the 
scope of the FPLL license. FPLL do not applies to them, nor can be extended to 
them improperly.
Closed source embedding application and applications of the work (i.e. when 
the source is hidden) must indicate the fact that they are using the FPLL 
engine or are compiled/run through the FPLL compiler/interpreter/virtual 
machine; as an additional requirement, closed source embedding applications 
must also indicate what the FPLL engine is used for.
In other words, FPLL requires derivative works to stay open as the original 
work, while applications written through them or embedding applications can be 
distributed under any license, and in any form, under the condition that if 
they are not open source they must acknowledge the fact that they are using 
the product, and where it is not self-evident, also why.
The rationale of this is that of preventing obfuscation and hiding of the FPLL 
licensed product away from the final user. Users of the FPLL licensed product 
are still able to decide not to publish their source code or not, yet they 
must grant their final users the right to know what underlying engine is 
driving their applications, or what part of the application they're are using 
is driven by FPLL licensed software.

Although the Falcon Programming Language License bear the name of “Falcon”, it 
is totally generic and makes no reference to a specific software; rather, it 
addresses the category of software that can be used to write higher level 
applications and/or to be included (or used) into other applications to 
perform relevant tasks.
In this, as the Apache license, it can be applied to a wide range of open 
source software.

Lastly, let me state that I am ready to accept any amendment the OSI council 
may want to bring in the to improve it.


To the OSI Board,


This is a formal request of Approval for the Falcon Programming Language License 1.1.


FPLL is meant to be a general purpose, open source license aiming to protect the freedom and the rights of programming language writers and users. It is widely based on Apache 2.


The official text of the license is available here:


http://www.falconpl.org/index.ftd?page_id=license_1_1



I add a legal analysis performed by a prominent attorney in my country. I am sending a translation in english (approved by the attorney), the original document in PDF format and a transcription in .txt format. The analysis is centered on comparation with Apache 2 license (as required by the submission rules).


Here below I write the rationale of the License.


Thank you in advance for your Kind Attention,
Giancarlo Niccolai





Rationale
======


The Falcon Programming Language License (FPLL) is meant to be a general purpose, open source license aiming to protect the freedom and the rights of programming language writers and users.


When first releasing the Falcon Programming Language to the public, I searched for an open source license that may grant openness of the distributed code, prevent abuses as close-source boxing, but yet fully grant the ability to use the Falcon scripting engine everywhere, including in commercial applications and to do anything, including falcon-based commercial source applications. Studying deeply the GPL and LGPL licenses, and participating also to related newsgroups and mailing list, I discovered that they were not adequate for such a task, as they required any application where such a deep embedding is performed to be released under a GPL-compatible license. This would have made extremely difficult to integrate a Falcon scripting engine in already existing commercial applications, and would have been a deterrent to further adoption of Falcon in commercial realities where it was already somewhat used at the time.
Further studies confirmed this analysis: up to date, there is NO mainstream programming language, embeddable or stand-alone, released under a “pure” GPL compatible license.
Python, PHP, Ruby are all licensed under a proprietary license, which makes explicit reference to the entities that own the copyright of the original software (i.e. the Python foundation). In particular, Ruby license is controversial on some aspect regarding some specific key areas of the inner code. They are all OSI approved, but being project specific they cannot be used in other projects without modifications.
PERL is released under dual licensing, GPL and Artistic license; it is embeddable in existing commercial applications due to the latter, while the former grants compatibility with GPL based software distributions (i.e. GNU/Linux distributions).
SWI Prolog, Common Lisp, and even GCC are licensed under GPL or LGPL with some language/usage specific exceptions. In particular, runtime libraries for GCC are distributed under the “GCC Runtime Library Exception.”
Lua was licensed under a Lua-specific license (OSI approved, derived from z-lib) up to version 4.0; version 5.0 and following are licensed under MIT license; yet, Lua source code is meant for inclusion and modification directly in other applications, rather than for usage as-is (as a ready-to-use engine), and as such its common pattern usage is a bit different with respect to the other programming languages.


In short, from this picture it is rather evident that the currently existing OSI approved licenses are deficient in covering the licensing needs of open source programming languages and scripting engines.
Also, the option of adopting an existing license and modifying it, i.e. applying an exception to it, may seem to reduce the problem of license proliferation, but it is actually working towards the proliferation of potential legal issues. IMHO it's evil #1, evil #2, evil #3 and evil #4.
It's evil #1 because it forces both commercial-oriented and free-oriented users into studying separate exceptions for separate products. When legal issues become relevant, this force, or should force, both open-source based institutions (i.e. GNU/Linux distributors) and commercial entities (i.e. firms willing to use my software) into kicking the exception down to the legal department and wait for a response before deciding to adopt a software with such a modified license. The argument that an exception is easier to analyse than a whole new license doesn't hold, as if it's true that the text of exceptions are usually (but not necessarily) shorter than the text of a full license, it's also true that the legal consequences may have the same width.
It's evil #2 because both who writes the exception and who accepts it may not have fully calculated the legal effects of it. At least in theory, it is possible to configure legal scenarios that can happen due to an exception and that are undesirable for one of the party, or for the general idea of software freedom; those legal scenario are exactly what a certification process is meant to exclude.
It's evil #3 because, applying such exceptions outside the control of a legal entity may generate a legal monster, which sneaks into otherwise legal-proof software set. The software base of GNU/Linux distributions, for instance, is just too big to account for an endless set of exceptions, and I have personally witnessed cases where open source software licensed under GPL with an exception had been added to the distribution without any further legal analysis of the exception. Similar scenario can be thought of commercial entities willing to adopt an open-source software to drive an internal or commercial project, could just read and approve the license terms, but it may overlook the exception as a minor detail, underestimating its legal consequences. This “legal time-bombs” may one day trigger a legal action that may 1) be a very unpleasant surprise for distributors, commercial developers and general users, and 2) provoke a damage to the image of free software.
It's evil #4 because, both in a commercial reality and in an open-source driven institution, it is impossible to account for the effects of all the combinations of every exception. The argument that “as long as it sticks with the policy (Debian), or with the criteria (OSI), the exception is OK” doesn't hold, as it is possible to figure some scenario where an exception may be in contrast with others without breaking those rules, or at least, without breaking a consistent subset of rules (compatibility with GPL OR (exclusive) conformance to OSI criteria OR (exclusive) conformance with the Policy) which may justify legally the existence of that exception in some open-source or free-software contexts.
In short, considering the inadequacy of existing non-specific licenses to cover the needs of an open source programming language interpreter/compiler/embedded engine, and considering the fact that exception proliferation is by no mean better than license proliferation, I worked towards a general Open Source license meant for this kind of software.
As a base, I used the Apache 2.0 license, which was the general purpose open source license nearest to the needs of a stand-alone language interpreter/compiler. The FPLL 1.0 was just the generalization of the Apache 2.0 license with the introduction of the definitions of Embedding applications (an application using the “work” as an engine to perform some tasks) and of Applications of the work (that is “your scripts”, or better, an application run through the “work” which interprets it, or through the prominent usage of its libraries in case of compiled, machine runnable code). The distinction was made so that open source requirements applied only to the derivative works (that is, for example, an XFalcon which just extended the Falcon compiler or virtual machines with new functionalities), while applications and embedding works were required less stringent terms. After a discussion on the Fedora and Debian project legal mailing lists, and with the help of an attorney, I worked out a new version simplifying some concepts and clearing some ambiguities.
In its current form, FPLL states that:
Derivative works must be distributed under the FPLL license or compatible, and thus, 1) they must be made available in source code, 2) the original source must be made available or it must be indicated where to get it, 3) the modification with respect to the original source must be described.
Open source (i.e. when the source is made available) embedding applications and applications of the work (scripts in Falcon USING a FPLL licensed interpreter) are free from any restriction. They are positively outside the scope of the FPLL license. FPLL do not applies to them, nor can be extended to them improperly.
Closed source embedding application and applications of the work (i.e. when the source is hidden) must indicate the fact that they are using the FPLL engine or are compiled/run through the FPLL compiler/interpreter/virtual machine; as an additional requirement, closed source embedding applications must also indicate what the FPLL engine is used for.
In other words, FPLL requires derivative works to stay open as the original work, while applications written through them or embedding applications can be distributed under any license, and in any form, under the condition that if they are not open source they must acknowledge the fact that they are using the product, and where it is not self-evident, also why.
The rationale of this is that of preventing obfuscation and hiding of the FPLL licensed product away from the final user. Users of the FPLL licensed product are still able to decide not to publish their source code or not, yet they must grant their final users the right to know what underlying engine is driving their applications, or what part of the application they're are using is driven by FPLL licensed software.


Although the Falcon Programming Language License bear the name of “Falcon”, it is totally generic and makes no reference to a specific software; rather, it addresses the category of software that can be used to write higher level applications and/or to be included (or used) into other applications to perform relevant tasks.
In this, as the Apache license, it can be applied to a wide range of open source software.


Lastly, let me state that I am ready to accept any amendment the OSI council may want to bring in the to improve it.


We have been requested a motivated legal analysis regarding the conformance of the software
license “Falcon programming Language” to the parameters indicated by the “Open
Source Definition”, eventually analyzing and comparing it with the “Apache” license,
already approved by the Open Source Initiative (from thereon, “OSI – Approved License”
or “Apache”).
The license for which approvation si required (from thereon, “Falcon”) is identical
to the OSI  - Approved License in the following points:
from the beginning up to the 4th point, included, of the “Definitions” section;
from the 6th up to the 8th point, included, of the “Definitions” section;
the 12th and 14th point of the “Definitions”;
the paragraph “3” (Grant of Patent License);
the paragraph “4” (Redistribution of Work and Derivative works), points 1, 2 and
3;
from paragraph “6” (Submission of Contributions) up to the end of the document.
Principali differenze riscontrate comparando i testi della Falcon e della OSI – Approved
Licence:
A)Considering the 6th point of the “Definitions” of the “OSI – Approved License”
the words  “documentation surce, and configuration files” has been changed into
“example code”;
B)Considering the 8th  point of the “Definitions” of the “OSI Approved License”,
the following two points have been added in the “Falcon” license:
“ Embedding works shall mean any work, whether in Source or Object Form, that links
(or binds by name) to the interface of the work and derivative works.
Application of the work shall mean any work whether in Source or Object form, that is
expressed through the grammar rules which are known by the work and that require the
Work to perform its execution.”
C)Considering the 2nd paragraph (Grant Copyright License) of the “OSI – Approved
License”: immediately after the words “prepare derivative works of” the following
words have been added: “prepare embedding works, prepare application of the work”;
D)The title of the 4th paragraph has been changed from “Redistribution”, as it was
in the OSI – Approved License, into “Redistribution of Work and Derivative Works”
in the Falcon license;
E)The points in the 4th paragraph are numbered in progression as 1, 2, 3, 4, e 5 in
the Falcon license, where it was marked by progressive alphabet letters a,b,c,d in the
OSI – Approved License;
F)In the 4th paragraph, the “C” letter of the OSI – Approved License – has been
changed in to the first point,  and two new numbers (4 and 5) has been added to it:
“4. You must state in the Source Form and in the documentation of any Derivative Work
the fact that such work is a derivation of the Work, and include a copy of the Work
in its Source form or provide directions on how to obtain a copy of the Work in its
Source form; and
5. The Derivative Works are distributed under the terms of this License, or under terms
that do not cause infringement of this License.”
G)The d letter and the final part of the 4th paragraph of the “OSI – Approved License”
have been removed.
H)The 5th paragraph (Submission of Contributions), has been turned as-is into the 6th
, because of the insertion of the following new 5th paragraph in the “Falcon” license:
“Distribution of Embedding Works and Applications of the Work. You may produce and
distribute any Embedding Work or Applications of the Work thereof in any medium, in
Source or Object form, provided You meet the following conditions:
1. The Embedding Works and Applications of the Work are distributed under the term of
this License, or the application of another License is explicitly stated in the documentation
of the Embedding Works and Applications of the Work or included in the Source form of
the Embedding Works and Applications of the Work; and
   2. If the Source form of Embedding Works is not distributed nor made available to
the Users in any form, the Embedding Works carry a prominent notice in their documentation,
or when not applicable, in any place that the Users are exposed to, about the fact that
the Work is embedded, along with a general statement about the task that the Work is
performing in the Embedding Works; and
   3. If the Source form of Applications of the Work is not distributed nor made available
to the Users in any form, the Applications of the Work carry a prominent notice in their
documentation, or when not applicable, in any place that the Users are exposed to, about
the fact that the Work is used by the Application of the Work.”
I)The paragraphs 5, 6, 7, 8, 9, in the “OSI – Approved License (Apache)” have
been copied as-is, but their numbering has been changed into 6, 7, 8, 9 and 10.
* * *
It is now necessary to verify if the “Falcon” license respects and satisfies the
parameters of the “Open Source Definition” specified by the  “OSI – Open Source
Initiative”, so that it may be considered an “Open Source” license, considering
the differences that have been highlighted above.
The parameters that must be respected by a license so that it may be considered “Open
Source” are the following:

1) Free Redistribution . The license shall not restrict any party from selling or giving
away the software as a component of an aggregate software distribution containing programs
from several different sources. The license shall not require a royalty or other fee
for such sale.
    2) Source Code. The program must include source code, and must allow distribution
in source code as well as compiled form. Where some form of a product is not distributed
with source code, there must be a well-publicized means of obtaining the source code
for no more than a reasonable reproduction cost preferably, downloading via the Internet
without charge. The source code must be the preferred form in which a programmer would
modify the program. Deliberately obfuscated source code is not allowed. Intermediate
forms such as the output of a preprocessor or translator are not allowed.
    3) Derived Works. The license must allow modifications and derived works, and must
allow them to be distributed under the same terms as the license of the original software.
    4) Integrity of The Author's Source Code. The license may restrict source-code from
being distributed in modified form only if the license allows the distribution of "patch
files" with the source code for the purpose of modifying the program at build time.
The license must explicitly permit distribution of software built from modified source
code. The license may require derived works to carry a different name or version number
from the original software.
    5) No Discrimination Against Persons or Groups. The license must not discriminate
against any person or group of persons.
    6) No Discrimination Against Fields of Endeavor. The license must not restrict anyone
from making use of the program in a specific field of endeavor. For example, it may
not restrict the program from being used in a business, or from being used for genetic
research.

    7) Distribution of License. The rights attached to the program must apply to all
to whom the program is redistributed without the need for execution of an additional
license by those parties.


    8) License Must Not Be Specific to a Product. The rights attached to the program
must not depend on the program's being part of a particular software distribution. If
the program is extracted from that distribution and used or distributed within the terms
of the program's license, all parties to whom the program is redistributed should have
the same rights as those that are granted in conjunction with the original software
distribution.
    9) License Must Not Restrict Other Software. The license must not place restrictions
on other software that is distributed along with the licensed software. For example,
the license must not insist that all other programs distributed on the same medium must
be open-source software.

Analysis of the differencies that have been noticed in comparing the two texts.
As it is granted that the “OSI – Approved License” (Apache License, Version 2.0.,
January 2004, http://www.apache.org/licenses/) respects the Open Source Definition,
as it has already successfully passed the approval process disposed by the OSI, we'll
analyze thereon the respect of the indicated parameters considering the differences
that have been found in the comparison between the OSI Approved License and the the
Falcon License:
regarding the difference listed in in this document under the letter A), the elimination
of the words “documentation surce, and configuration files” and their replacement
with the words “example code” is simply motivated by the fact that the Falcon License,
contrarily to the OSI – Approved License Apache, is not shipping with configuration
files, as it is not meant to be configured, but programmed. The difference here has
been introduced just to match the text of the license with the characteristics of the
software, and it is by no mean incompatible with the Open Source Definition;
regarding the difference listed in in this document under the letters B) and C) they
introduce the definitions of “Embedding Works” and “Application of the Work”.
Those definitions aren't incompatible with the Open Source Definitions, and are necessary
for the sole fact that the software named Falcon is meant to be included inside other
programs by its very nature, as it is exactly an engine allowing other (possibly already
existing) applications to use an higher level programming language to improve their
suitability to given tasks at runtime;
regarding the difference listed in in this document under the letter D), it has been
introduced to make evident to the reader that the 4th paragraph regulates only the redistribution
of Derivative Works, and not Embedding Works, nor Application of the work, whose concepts
have been introduced in the previous paragraphs, and this is surely conforming with
the Open Source Definition;
regarding the difference listed in in this document under the letter E), it relates
uniquely to the disposition and internal organization of the text, and it is irrelevant
in the scope and for the purpose of this legal analysis;
regarding the difference listed in in this document under the letter F), the 2 newly
introduced points are coherent with the Open Source Definition, as they aim to make
so that Derived Works are distributed under the condition that any subsequent user of
any derived work know this fact, and be able to access to the source code. This is coherent
with the Open Source Definition;
regarding the difference listed in in this document under the letter G), the removal
of the point d) in the 4th paragraph of the OSI Approved License and of the final part
of the same paragraph, which is motivated also by the additions indicated at the F)
letter of this legal analysis, they don't alter the coherence of the Falcon license
with respect to the parameters of the Open Source definition;
regarding the difference listed in in this document under the letter H), as said, the
4th point disciplines the redistribution of the Work and of the Derivative Works, the
 5th point has been introduced to specify the fact that also Embedding Works and Applications
of the work are redistributable, this fully respecting the Open Source Definition;
regarding the difference listed in in this document under the letter I) it concerns
uniquely the disposition of the text, and is irrelevant with respect to the scope and
purpose of this legal analysis.
* * *
   In conclusion, following the deep analysis of the text of the Falcon License, I,
as an attorney,  express a favorable opinion concerning the respect of the Open Source
Definition.

Attorney Gaetano Tasca.