Josselin Mouette wrote: > On jeu, 2008-03-27 at 18:58 -0700, Sean Kellogg wrote: > >>> No one can patent the grammar that you wrote, so this is completely >>> useless. The only point of these clauses seem to claim the copyright on >>> scripts using the language. >>> >> Huh? Why can't someone patent langauge grammar/syntax? >> > > I should have written “no one *else* can pattent the grammar that you > wrote”. >
Unluckily, this is far from being true. Any patentable idea can be patented by anyone, and the patent is the preferential title to establish authorship rights on the idea. In other words, Mr. A can have a (patentable) idea and start making use of it, Mr. B can patent it and then Mr. A has this options: 1) quit the idea and go fishing for a living. 2) FIRST, act against THE PATENT, trying to invalidate it as it wasn't based on an original idea; it's A that must demonstrate he was right. SECOND, when (if) he wins the trial that will make Mr. B patent to be removed, act against Mr. B and ask for damage refounds. Funny enough, in scenario 2 Mr. B may file another patent on the idea, changing it enough to be recognized as having some novelty content by clerks that usually have just a vague idea of what a novelty in the field may really be. This can go on forever; if you just take some minutes to google a bit, you'd find some interesting cases (some similar scenario are even used as common examples by Mr. Stallman, when he talks about "de-grade", and about the compression algorithms that GNU had to change). A recent U.S. law recognizes to "prior invention" some limited rights (i.e. that of continuing using inventions as if the patent wasn't filed), but it's a quite limited guarantee, and still you'd have to prove the invention was yours while i.e. being suited by the patent filer. Also, U.S. is not the rest of the world, and there are some countries (Italy to say one I am paricularly concerned with) in which if you don't patent first, you're going to have an hard time. The "unpatentability" claim in this licenses can't prevent Mr. B to patent an idea protected by the license, but it has the net effect to make Mr. A able to sue Mr. B for damage directly; the damage would descend from having broken the license terms, which, in case of having patented an idea that can be seen as "the work" or "a derivative work", would be quite easy to prove in a trial. ... Since I am here with mail client open; I would like to redefine the thing I said this night about FPLL being more *restrictive* than LGPL for some (but not all) applications. The reason that made me to start all this was exactly the fact that Falcon engine is quite invasive, and it also allows to be quite "invaded". The most common way an application can use the Falcon engine consist in extending and modifying the Falcon::VMachine class; also, non trivial embedding applications would have to inject code in the engine, and/or in the standard modules that are provided under the same license terms of the engine. Not to talk about 3d party modules, which must include relevant inline code and perform massive integration with the engine. This is the practical reason why all the major scripting languages have a "proprietary license"; I investigated them, but found impossible to apply them as they are usually application (or "foundation") specific. Moreover, Falcon engine requires and allows an higher level of integration than those usually provided by the scripting engines I have analysed. Applying LGPL as-is to Falcon, without complex and carefully suited exceptions, would have the net effect to enforce LGPL to every thing that goes with Falcon: Falcon (script) applications, applications using Falcon as a scripting engine and 3d party extension modules. The fact that LGPL *defines* a "free zone" of applications that need not to comply to it doesn't mean that those applications may exist in practice. In case of Falcon, that "free" area would be an empty set. This is why I wrote the license as such and this is why I claim that FPLL is *less* restrictive than LGPL/Apache2. They define a set of applications where they are not applied, and so, a set of completely free applications (for whose FPLL would require just a notice to be placed somewhere), but after careful studies I realized that in case of software as Falcon engine that area would have been void. Or at least, users may have been rightfully worried about their applications to fall in a covered category, which may have scared away some business developers in some scenario I was willing to include. That wasn't acceptable, as I have already commercial, closed source applications that run the Falcon engine. The fact that every single programming language, when using LGPL or GPL, is forced to provide an exception is a clear sign of the deficiency of LGPL in this area (read, *excessive* strictness), and this even for languages that provide closed (non embeddable) engines or whose engines require a level of integration far less intrusive than Falcon's. That's why I needed FPLL; otherwise, now, we would be discussing of LGPL with very funny exceptions here, and frankly I can't see why that should be considered "better". Tons of exceptions, different from case to case, doesn't make a better legal scenario for the open source community than a small set of better suited licenses. Nevertheless, I am dual licensing Falcon with GPLv3. If you want to get more restrictions, I am not stopping you... :-) Bests, Giancarlo Niccolai. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
