Approval of the "Falcon Programming Language License 1.1"

[Giancarlo Niccolai]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20090813/8eae7588/attachment.html>
-------------- next part --------------
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.