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 permissions. >> > If I read the license correctly, your description does not seem to be accurate. Your license is more *restrictive* than the Apache License v2.0. > 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 puzzled. > 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 here: http://www.falconpl.org/?page_id=license_comment 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. Bests, Giancarlo Niccolai. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
