Re: Falcon P.L. license (ITP:Bug#460591)
MJ Ray
> 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. Also, I think the
licence contains lawyerbombs (things relying on court rulings which
haven't been stated, maybe because they haven't occurred yet).
In general, I'm disappointed to see this licence proliferation.
I'm only going to look at differences with the Apache licence 2.0.
Terms marked [-...] are in Apache, terms marked {+...} are in Falcon.
I've tried to ignore the extensive punctuation and heading changes.
(Command for rc shell:
wdiff <{curl -s http://www.apache.org/licenses/LICENSE-2.0.txt} <{curl -s 'http://www.falconpl.org/?page_id=license' | dexml}
)
First changes are in the definitions (tightly?). I'm very
uncomfortable with these, as they affect the whole licence.
making modifications, including but not limited
to software source [-code, documentation ]
[-source,] {+code} and [-configuration files. ]
{+example code.}
This change seems OK - documentation is software here - but what
does this mean for configuration files?
New definitions:-
{+"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.} {+"Scripts" shall mean}
{+any work, weather in Source or Object form,}
{+that is expressed through the grammar rules which}
{+are known by the Work.} {+"Users" shall}
{+mean any person that uses, directly or indirectly,}
{+all or any of the Work, the Derivative Works,}
{+the Embedding Works or the Scripts.}
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.
Also, surely Users is a court-defined term? What is the effect of
trying to override that here?
Finally, it contains a homophone error ("weather" instead of "whether").
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.
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 user-unfriendly.
Hope that helps,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
--
To UNSUBSCRIBE, email to debian-leg...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Giancarlo Niccolai
Hash: SHA1
MJ Ray wrote:
> Giancarlo Niccolai <g...@falconpl.org> 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
without exceptions.
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
not acceptable.
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
the review...
//
>
>
> 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
> "whether").
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
> user-unfriendly.
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.
Bests,
Giancarlo Niccolai.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH6VQW5nwsoBIDC4YRAtUbAKCUw1bqte1LrTMCaYTUfN9mihcPbwCfU3Pw
97z+pXea9KDV2svVEhZGny0=
=wr+9
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
MJ Ray
> MJ Ray wrote: [...]
> > 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.
I disagree. Furthermore, there's nothing preventing 'lawful
certification' of a licence with the exceptions. Instead here, if anyone
wants to obtain such certification of Falcon PL, they've got to pay for
a whole new licence to be examined, rather than an increment.
I'm not convinced that the problem being guarded against here is as
big an interference as it's being made out to be. It seems somewhat
orthogonal to the other licence terms, if done right.
[...]
> Nevertheless, you'll admit that starting a review with such a sentence
> does not suggest a constructive critic attitude towards the object of
> the review...
It wasn't /written/ at the start of the review, if that helps. Drafting
is a wonderful process, allowing bits of text to be added at the start
after one has written the body. If the licence had actually brought
some new benefits, instead of drawbacks, I might not be so unhappy that
it's a new one.
[...]
> > 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 ...)
Well, to be *able* to give such a grant and for that to be meaningful
in any way, surely the FPL is asserting it has an applicable copyright
interest on the Scripts? If it wasn't claiming any copyright, its
language about Scripts would be more like the GPL's description that
running the Program needs no permission from the copyright holder.
Did I miss a bit where the licence disclaims copyright interest in the
Scripts?
Anyway, this is the show-stopper. Contaminates other software. DFSG 9.
It's the parts of FPL sections 1, 2 and 5 about Scripts. Clear enough?
[...]
> 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.
No, the Apache 2 licence does not talk about things which are not part
of that software.
[...4d...]
> > A new obnoxious advertising clause. Probably won't break DFSG, but
> > I don't like it for practical reasons.
> Which practical reason?
"When people put many such programs together in an operating system,
the result is a serious problem. Imagine if a software system required
75 different sentences, each one naming a different author or group
of authors. To advertise that, you would need a full-page ad."
"This might seem like extrapolation ad absurdum, but it is actual
fact. NetBSD comes with a long list of different sentences, required
by the various licenses for parts of the system. In a 1997 version of
NetBSD, I counted 75 of these sentences. I would not be surprised if
the list has grown by now."
Source: http://www.gnu.org/philosophy/bsd.html
[...]
> > Other than that, it differs from Apache 2.0 in missing the How to
> > Apply appendix, which isn't serious, but seems a bit
> > user-unfriendly.
> 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.
I didn't see it in the web page http://www.falconpl.org/?page_id=license
but that site has poor accessibility anyway. http://www.w3.org/TR/WCAG1
> Notice that I will double-license Falcon itself as GPL/FPLL, [...]
Great. Thanks.
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Giancarlo Niccolai
> Giancarlo Niccolai <g...@falconpl.org> skribis:
>
>> MJ Ray wrote: [...]
>>
>>> 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.
>>
>
> I disagree. Furthermore, there's nothing preventing 'lawful
> certification' of a licence with the exceptions. Instead here, if anyone
> wants to obtain such certification of Falcon PL, they've got to pay for
> a whole new licence to be examined, rather than an increment.
>
a whole new thing. A programmer should know... ;-)
For one thing, it's a problem for developers of software which
integrates with target applications so deeply.
I would have really loved to have a license that was fitting the needs
for a scripting language, as PHP, Ruby's and Python does, but that are
kept foundation specific. You can't immagine how much time and money is
consuming to search through all those exceptions and finally decide they
are inadequate.
>
> Well, to be *able* to give such a grant and for that to be meaningful
> in any way, surely the FPL is asserting it has an applicable copyright
> interest on the Scripts? If it wasn't claiming any copyright, its
> language about Scripts would be more like the GPL's description that
> running the Program needs no permission from the copyright holder.
>
There is, i think; this is the new formulation of the article, but the
relevant part which I am marking was there also in the previous version:
*2 Grant of Copyright License*. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright
license to reproduce, prepare Derivative Works of, prepare Embedding
Works, prepare Applications of the Work, publicly display, *publicly
perform*, sublicense, and distribute the Work and such Derivative Works
in Source or Object form.
To my best knowledge, *publicly perform* means *run as/where/how you like*.
Now, changed the term "Scripts" in "Applications of the Work", defined as:
"Applications 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.
In other words, "the things (usually scripts, but also pre-compiled
code) run with THE work". There isn't anymore a reference to a specific
programming language. Also, I removed the term script (and didn't
substitute it with the term "Applications of the Work") from the
copyleft claim; so scripts (even the one composing an application of the
work) are not contaminated by the license. It's an application in the
whole, that is, the engine in the act of running scripts, that is
covered; script by themselves are not mentioned directly nor indirectly
on the new version of the license. The spirit is the same, but the
wordings may have lead to confusion; I plainly admit it.
> Anyway, this is the show-stopper. Contaminates other software. DFSG 9.
> It's the parts of FPL sections 1, 2 and 5 about Scripts. Clear enough?
>
Yes, your position is now clear, thanks.
Yet, I can't see why you say it contaminates more software. The license
just applies to software that uses Falcon; scripts (falcon scripts) do
it and embedding applications do it; of course, also derivative work do
it. I can't see why requiring for them to be closed source and putting a
notice or open source with FPLL or with another compatible open source
license (as GPL or LGPL) would be more infringing than i.e. GPL itself.
> [...]
>
>> 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.
>>
>
> No, the Apache 2 licence does not talk about things which are not part
> of that software.
>
>
I see your point. The term "script" was too generic and fuzzy even with
the definition of "scripts" as the things being the ones written IN
Falcon and run WITH Falcon.
That the reason why I changed "Scripts" into "Applications of the Work".
> [...4d...]
>
>>> A new obnoxious advertising clause. Probably won't break DFSG, but
>>> I don't like it for practical reasons.
>>>
>> Which practical reason?
>>
>
> "When people put many such programs together in an operating system,
> the result is a serious problem. Imagine if a software system required
> 75 different sentences, each one naming a different author or group
> of authors. To advertise that, you would need a full-page ad."
>
> "This might seem like extrapolation ad absurdum, but it is actual
> fact. NetBSD comes with a long list of different sentences, required
> by the various licenses for parts of the system. In a 1997 version of
> NetBSD, I counted 75 of these sentences. I would not be surprised if
> the list has grown by now."
>
> Source: http://www.gnu.org/philosophy/bsd.html
>
Then let it grow. Be it 75 or 750 or 7500, they are still 2, 3 or 4
pages in a thousand pages doc. Bibliography of common tech books is even
wider, and no one has ever been fuzzy about it. Also, no one has ever
questioned the need for a complete bibliography to be somewhere in a
technical or educational book.
No claim is done on the visibility of the note; for one thing, no one is
asking you to place the notice in an ads of your products.
Also, the "advertisement" is part of well known and accepted licenses,
as zlib's and pcre's and BSD, which require the people using that lib to
write a notice about their inclusion in the sources. I don't think I am
stating anything new here.
Finally, if your thing is open source you don't need to put any notice
anywhere (I also removed the requirement for a notice in sources in the
last version of the license). You have to state somewhere you're using a
FPLL covered product if your users can't see your sources. In other
words, an FPLL product won't demand any space among those 75[0]* notices
in BSD, unless they go closed source.
> [...]
>
>>> Other than that, it differs from Apache 2.0 in missing the How to
>>> Apply appendix, which isn't serious, but seems a bit
>>> user-unfriendly.
>>>
>> 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.
>>
>
> I didn't see it in the web page http://www.falconpl.org/?page_id=license
> but that site has poor accessibility anyway. http://www.w3.org/TR/WCAG1
>
>
That's because I gave you the direct link to the raw text of the
license. They are always stuck together in distro files and on the pages
from which the license is accessible. Also, I posted the link to the
commentary here.
Anyhow, in the new version of the license I added the appendix "How to
apply" copied from Apache2. Too good that software licenses are
themselves public domain :-)
Thanks for the comments on the site; pitifully, we are short on hands,
and what we have now is all that we can afford in term of effort. A
person with your expertise would surely help.
Thanks for your advices,
Giancarlo Niccolai.
MJ Ray
> MJ Ray wrote:
> > Anyway, this is the show-stopper. Contaminates other software. DFSG 9.
> > It's the parts of FPL sections 1, 2 and 5 about Scripts. Clear enough?
> >
> Yes, your position is now clear, thanks.
>
> Yet, I can't see why you say it contaminates more software. The license
> just applies to software that uses Falcon; scripts (falcon scripts) do
> it and embedding applications do it; of course, also derivative work do
> it. I can't see why requiring for them to be closed source and putting a
> notice or open source with FPLL or with another compatible open source
> license (as GPL or LGPL) would be more infringing than i.e. GPL itself.
The licence for Falcon (this software) is effectively asserting that it
can restrict the scripts (which is some other software). I can't see
why you think that doesn't contaminate other software, the scripts.
To be free software, the licence for Falcon must not apply to software
that uses Falcon *except* when it is embedded into or extending Falcon
in certain ways. I'm not even sure that Falcon's licence *can* restrict
the scripts it loads, because:-
"The interpreted program, to the interpreter, is just data; a free
software license like the GPL, based on copyright law, cannot limit
what data you use the interpreter on. You can run it on any data
(interpreted program), any way you like, and there are no requirements
about licensing that data to anyone."
Source: http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL
So, the GPL doesn't apply to scripts of a GPL'd interpreter, so FPLL is
different in this way.
> > [...4d...]
> >>> A new obnoxious advertising clause. Probably won't break DFSG, but
> >>> I don't like it for practical reasons.
> >>>
[...]
> Also, the "advertisement" is part of well known and accepted licenses,
[...]
Sure. As I wrote: it probably won't break DFSG but is obnoxious to many.
> Finally, if your thing is open source you don't need to put any notice
> anywhere [...]
Well, that's better than many. Thanks!
> > [...]
> > I didn't see it in the web page http://www.falconpl.org/?page_id=license
> > but that site has poor accessibility anyway. http://www.w3.org/TR/WCAG1
> >
> That's because I gave you the direct link to the raw text of the
> license. They are always stuck together in distro files and on the pages
> from which the license is accessible. Also, I posted the link to the
> commentary here.
I suggest linking the FAQ from the Licence and the reverse.
[...]
> Thanks for the comments on the site; pitifully, we are short on hands,
> and what we have now is all that we can afford in term of effort. A
> person with your expertise would surely help.
Sorry. Most of my cooperatives are also short on hands and this has a
pretty tenuous link to my work (I use debian for work and strongly support
free software, so encouraging 100% free software for debian has eventual
benefits) so I can't really spend more time, unless the link becomes more
direct, like one of my cooperatives is commissioned to write a study or
bugfix a website or something.
Regards,
--
MJ Ray (slef)
Webmaster for hire, statistician and online shop builder for a small
worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/
(Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237