[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITP:Bug#460591 - Falcon P.L. license

Francesco Poli wrote:
> On Wed, 19 Mar 2008 19:59:33 +0100 Giancarlo Niccolai wrote:
> I assume you mean that you would like to have your license "analyzed" or
"revised" by debian-legal.
Yes, sorry, the word was eaten while editing :-/

>> The license is tightly based on Apache 2, with extra clarifications and
> If I read the license correctly, your description does not seem to be
accurate.  Your license is more *restrictive* than the Apache License
> The reason is that you impose conditions on "Embedding Works" and
"Scripts", while the Apache License v2.0 does not.
> [...]
>> I am going through this because, after searching for a license
>> providing those guarantees to language users, I have found none.
> Frankly speaking, I cannot understand what you are trying to achieve.
You are trying to create a license which is more restrictive than the
Apache License v2.0, and you are calling those extra restrictions
"guarantees to language users"...  This is quite confusing, IMHO. I'm
Extra restrictions? -- the definition of Embedded works and scripts are
there *exactly* to FREE THEM from the constraints of the license. Using
*SOLELY* Apache2 license, it would be unclear if an embedding work has to
be considered a derived work.

This license (FPLL) was made EXACTLY to state that it does not apply to
embedders and scripters, except for one thing: they have *NOT to hide* the
fact that they are using Falcon. Applying Apache2 -as is-, the point that
embedded works and pre-compiled scripts can be distributed under any terms
(i.e. under the license the writer prefers), may be
questionable; FPLL clears this, and states that you are free to do that.

> If my understanding is indeed correct, then all the clauses where you
grant a conditioned permission to produce and distribute "Scripts" are
superfluous, as nobody will have to comply with your license, in order
to just write and distribute "Scripts"...
Well, as other poster have mentioned, this point is debatable. As it is
debatable, I don't see what can be disturbing in saying "hey, you just
*CAN* do it, don't ever worry about it". As I was "clearing ground", I
couldn't see why I should have avoided clearing the ground also for this.

Also, while the point of script freedom is debatable (but cleared here), I
wanted to pick up the excellent loophole of non-patentability stated by
Apache2 license. Through that, I state that you *can't* patent Falcon code
*as well as* Falcon grammar; just plainly excluding scripts from this
license would have made the patentability of the grammar doubtful. Also,
using this license, other projects can take benefits of this definition
and extends the non-patentability (read, freedom) to their extensions.

Finally, scripters and embedders do not have to complain with the
license (except for stating or *not hiding* the fact they are using
Falcon), but they may *wish* to do that, and have a GPL-like guarantee of
maintaining freedom of derived works.

I hope this clarifies some points, as it seems your reading of the license
was rather shallow. More on the reasons and on the aims of the license are


One more thing. If anyone, here or anywhere else, points out a
ready-made (i.e. not needing exceptions) license that can be generally
applied (i.e. not project/foundation specific) which gives the grants I
want to give to both the project itself and to the language/engine users,
I will gladfully and immediately adopt it. Just, through
extensive searches, I couldn't find one. I really would prefer to spare 
the money and the time I still have to invest in this if there is a  way.

Giancarlo Niccolai.

Reply to: