Re: Bug#460591: Falcon P.L. license (ITP:Bug#460591)
-----BEGIN PGP SIGNED MESSAGE-----
MJ Ray wrote:
> Giancarlo Niccolai <email@example.com> wrote: [...]
>> The license is tightly based on Apache 2, with extra
>> clarifications and permissions. [...]
> Summary: I believe that any interpreter under this Falcon P.L.
> licence will contaminate other software and so fail DFSG 9.
About this, I would like to fix this if it's so, but in the rest of
your review i can't trace what element of the license would break the
DSFG and which point of DSFG would be broken.
> Also, I think the licence contains lawyerbombs (things relying on
> court rulings which haven't been stated, maybe because they haven't
> occurred yet).
About this, there's nothing I (or anyone) can do now, except get a
legal advice as I am doing.
> In general, I'm disappointed to see this licence proliferation.
I am too.
There isn't any single open source mainstream programming language or
even compiler I know, including clisp, gcc, PHP, python, swi-prolog,
ruby, harbour and xharbour (little known clipper clones OS projects I
worked in), that isn't distributed under either a propetary
non-reapplicable license or under a commonly known license with
exceptions. IMHO, exceptions are much worse than license
proliferation, as they modify a "lawfully certified" text and
unbalance it, and their effect isn't always fully understandable by
the time the exceptions are written.
The only language that doesn't do so that I am aware of is PERL, which
is distributed with double licensing, pure GPL and Artistic, both
All this license proliferation in this area seems to mean that there
isn't a well known certified license that covers even the *basic*
needs of v.m. based languages (nor the needs of libraries of
compiled-linked languages). Among the "ready made" solutions, the one
that was attracting me the most was swi-prolog's but still swi prolog
was not made to be embedded and there isn't any statement about using
swi-prolog as an engine for 3d-party programs, which anyone would
agree that is a bit more and different than what they stated
originally with the term "/if you link this library with other files,
compiled with a Free Software compiler, to produce an executable".
/Also, this would have caused Falcon to be a bit incompatible with
embedding applications made with Visual Studio, and this is definitely
It's because I am absolutely disappointed with license proliferation
that I tried to write one that was covering exactly the needs of this
application category, and decided to make it "open", that is, not
private or special for my language.
Nevertheless, you'll admit that starting a review with such a sentence
does not suggest a constructive critic attitude towards the object of
> Claiming any copyright over Scripts gives me the heebie-jeebies.
> More importantly, that seems like an obvious failure of DFSG 9 by
> contaminating other software.
To me too.
In fact, the FPLL doesn't claim any copyright on scripts. It just
*defines* them to state they are *free* from possible copyright claims
( ... each Contributor hereby grants to You a perpetual, worldwide,
non-exclusive, no-charge, royalty-free, irrevocable copyright license
to reproduce, prepare ...)
This mean, "no one will mess with your scripts, they copyright to
you". I don't know nor care if this is "automatic", or "already so". I
want it to be clear and legally stated.
Anyhow, let's suppose there is another software not distributed under
FPLL that says the thing you produce with it or that you use to make
it work are subject to copyright restrictions. There isn't any single
article of the DFSG which would contrast with that, as not a single
other software would be affected by that. As long as the openness and
freedom of the software is granted, any software may extend copyright
on any functional component it produces or processes, as i.e. Apache2
license does with configuration files, and this alone won't infring DFSG.
More; Apache2 license states the sentence "including but not limited
to...". In legalese, this means "hey, and also everything else, if we
forgot to say it here". Following your reasoning, this would be quite
a massive breaking of DFSG, but it is not.
Said this, if you or anyone here or in future points out the article
of DFSG that is threatened by FPLL, I will immediately make the
offending part to conform. I *WANT* FPLL to stick with our community
principles, which are quite well drawn by both OSI statement and DFSG.
> Also, surely Users is a court-defined term? What is the effect of
> trying to override that here?
If there is any problem, let's change it. To my best knowledge, there
wasn't any problem in using the term "Users" in a legal statement at
the time I wrote FPLL.
> Finally, it contains a homophone error ("weather" instead of
Ops... thanks for pointing it out. Will be fixed.
> 4(d) is very hard to read in wdiff. It appears to be a total
> rewrite. Falcon version:-
> # If the Source form of Scripts is not distributed nor made
> available by any mean to the Users, a prominent notice about the
> fact that the Scripts have been written in the Language must be
> presented in a place which the Users are exposed to.
> A new obnoxious advertising clause. Probably won't break DFSG, but
> I don't like it for practical reasons.
Which practical reason?
As I said, this article was written taking into consideration the
principle that users must know the software they run (and I was
advised in that direction by FSF).
You'll notice that this requirement applies only if the targets are
not distributed in source form. This means that the embedders/scripters:
1) have their own copyright on the things they do; we explicit said
we, nor anyone else but them, has it.
2) They are absolutely free to pick the license and distribution terms
they prefer to distribute their software IN Falcon or USING Falcon.
3) They can even produce and distribute closed source applications,
both IN Falcon and USING Falcon (but not works derived from/extending
the core Falcon system; they must be open source).
4) But in this case, and only in this case, they have to state that
Falcon has been used, and why/where. What I want to say is, "ok, you
can ALSO do closed sources things with Falcon, but at least let your
user know what they are running."
You'll notice (and it's specified in the commentary), that there isn't
any requirement about the visibility of this statement. It may even be
a fineprint on the last leaflet of the manual, or the last of the
lines in an scrolling about box. It's a mu-gram ink cost on them, but
this is a very important freedom on the user side.
I have no practical usage for this article except that defending this
community principle, which I would like to see applied by/to any free
software. I can just cut it away, but IMHO this would give a very
marginal freedom to embedders/scripters at the cost of a great freedom
loss on the users.
If I am wrong, please correct me. I just want this to be the best
thing possible for the community, so if people thinks this principle
is not right, or if they think that this wordings are not useful to
defend this principle, please tell me how to reformulate this article
(or if it's better to remove it).
> On the plus side, we lose the NOTICE's potential for DFSG-busting
> from the Apache 2.0 licence.
> Other than that, it differs from Apache 2.0 in missing the How to
> Apply appendix, which isn't serious, but seems a bit
There is a commentary, which I posted here, that has the same aims of
the "How to apply" appendix, and hopefully clarifies the license
without introducing further ambiguities or hiding clauses.
> Hope that helps,
Yes, absolutely, thanks.
Notice that I will double-license Falcon itself as GPL/FPLL, so the
package can be clean for Debian, yet I really want to provide a
license with the characteristics I have stated here and in other
posts, so I still request help of anyone willing to help me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----