Bug#460591: Falcon P.L. license (ITP:Bug#460591)
MJ Ray wrote:
> Giancarlo Niccolai <gc@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.
>
There are cases in which analyzing exceptions costs more than analyzing
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.
Reply to: