Re: Bug#460591: Falcon P.L. license (ITP:Bug#460591)
MJ Ray wrote: Giancarlo Niccolai [EMAIL PROTECTED] wrote: 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 I buy 100% your point; I understand I misused the term script to intend an application made of Falcon and other things on one side and the grammar that made up the scripts on the other. In the new version of the license I have prepared, this is clarified as the only thing covered by copyright/left are the things that are licensed with FPLL (the engine and the modules we/others want to release that way). The term Applications of the work is now solely the engine in the act of *running* things, and it's made clear that this definition does not include the *things* you run. Sorry for the former wordings that wasn't what I wanted it to be. Moreover, the term publicly perform in the copyleft grants anyone the right to run applications of Falcon the way it likes. So, in accordance to the above statement: 1) Data (scripts) is free from copyright/left. 2) you can run the copylefted thing on any data, any way you like. Please, notice that this is more than what GPL actually allows, as GPL states also that portions of generated code that are coming from the application (i.e. bytecode middle layers) are covered by GPL; that's the reason for exceptions in GNU compilers. FPLL frees them (pre-compiled scripts) too. That was one of the things that required me to write FPLL: some of my target markets are quite sensible to this aspect, and FPLL clears the grey area of compiled scripts. I'll also reshape a bit the commentary to better specify this fact, and make cross link so that they are always accessible together. In the meanwhile we're finishing the setup for dual licensing with GPL in our new version, so it will be clear under every aspect that Lo, this is Free Software! :-) Thank you for your help, Giancarlo Niccolai. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#460591: Falcon P.L. license (ITP:Bug#460591)
Giancarlo Niccolai [EMAIL PROTECTED] wrote: 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#460591: Falcon P.L. license (ITP:Bug#460591)
Giancarlo Niccolai [EMAIL PROTECTED] 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. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#460591: Falcon P.L. license (ITP:Bug#460591)
MJ Ray wrote: Giancarlo Niccolai [EMAIL PROTECTED] 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,
Re: Falcon P.L. license (ITP:Bug#460591)
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”. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Falcon P.L. license (ITP:Bug#460591)
On Friday 28 March 2008 01:04:14 am 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”. Ah, prior invention... gotcha. -- Sean Kellogg e: [EMAIL PROTECTED]
Re: Falcon P.L. license (ITP:Bug#460591)
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
Re: Falcon P.L. license (ITP:Bug#460591)
On ven, 2008-03-21 at 10:09 +0100, Giancarlo Niccolai wrote: This clause makes the license a copyleft one. It is free, but this is a huge restriction compared to the original license. And this turns the license into yet another copyleft license that will be incompatible with other ones. I see; you are talking of comma 4.5 in the specific? I actually added it after some talk with FSF about requiring the derivative work to be distributed copyleft too. In other words, the aim of this comma is to prevent someone from adding a frobotz statement which nitfols the blorbs, and then distribute an xFalcon as a closed source product. Sure, this is the whole point of copyleft and it is a very good thing. But copyleft has its drawbacks, especially when it comes to license compatibility. This is why you should more seriously consider using an existing copyleft license. License proliferation is not a good thing; copyleft license proliferation is destructive. 5. *Distribution of Embedding Works and Scripts*. I don’t think you can claim anything on the copyrights of scripts using your language, but this is definitely something you should ask your lawyer. This license doesn't state there are copyright claims on the scripts; actually it should do the opposite. If there is any point implicitly or explicitly stating it, please point it out and it will be fixed. It does claim the copyright by asking to apply the license to it. If you really want to explicitly tell that you don’t need to follow the license for writing scripts, you should add a notice that this license and your copyright claims don’t apply to the said scripts, and this will be much better. The point is that, as previously noted, the patentability of grammar sets (i.e. artificial languages) has been recently debated. Including the definition of the scripts in this license has the aim to prevent a Big Guy to come in, add a frobotz statement and patent the resulting language (or, as someone has pointed out, just patent the grammar someone else wrote as-is). Or in other words, I did it to maintain freedom of the grammar set this language define (it means, freedom for everyone to use and extend it). 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. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Falcon P.L. license (ITP:Bug#460591)
On sam, 2008-03-22 at 22:33 +0100, Giancarlo Niccolai wrote: Have you considered the GNU LGPL (v2.1)? Yes, but I encountered strong resistance from FSF when proposing a lighter (with exceptions) LGPL version. This is, again, because you are not proposing additional permissions (for which the LGPL with extra additional permissions would be fine) but additional *restrictions*. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Falcon P.L. license (ITP:Bug#460591)
On Thursday 27 March 2008 06:54:36 pm Josselin Mouette wrote: The point is that, as previously noted, the patentability of grammar sets (i.e. artificial languages) has been recently debated. Including the definition of the scripts in this license has the aim to prevent a Big Guy to come in, add a frobotz statement and patent the resulting language (or, as someone has pointed out, just patent the grammar someone else wrote as-is). Or in other words, I did it to maintain freedom of the grammar set this language define (it means, freedom for everyone to use and extend it). 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? Seems to fit pretty well into the patentability definition here in the U.S[1]... you don't even need to accept the idea that software is patentable to see how a language might be pantentable. -Sean [1] http://www.law.cornell.edu/uscode/35/usc_sup_01_35_10_II_20_10.html -- Sean Kellogg e: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Falcon P.L. license (ITP:Bug#460591)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josselin Mouette wrote: On ven, 2008-03-21 at 10:09 +0100, Giancarlo Niccolai wrote: This clause makes the license a copyleft one. It is free, but this is a huge restriction compared to the original license. And this turns the license into yet another copyleft license that will be incompatible with other ones. I see; you are talking of comma 4.5 in the specific? I actually added it after some talk with FSF about requiring the derivative work to be distributed copyleft too. In other words, the aim of this comma is to prevent someone from adding a frobotz statement which nitfols the blorbs, and then distribute an xFalcon as a closed source product. Sure, this is the whole point of copyleft and it is a very good thing. But copyleft has its drawbacks, especially when it comes to license compatibility. This is why you should more seriously consider using an existing copyleft license. License proliferation is not a good thing; copyleft license proliferation is destructive. I am already fixing things to release Falcon with dual license GPLv3 and FPLL. 5. *Distribution of Embedding Works and Scripts*. I don’t think you can claim anything on the copyrights of scripts using your language, but this is definitely something you should ask your lawyer. This license doesn't state there are copyright claims on the scripts; actually it should do the opposite. If there is any point implicitly or explicitly stating it, please point it out and it will be fixed. It does claim the copyright by asking to apply the license to it. Ok, I get the point. I actually wanted to protect scripts but the only fact that they are mentioned may lead to think (also, may bring out the legal question), that scripts were mine in the beginning and I am so kind to set them free. I will remove the script things, and just require that closed source works using FPLL state it. If you really want to explicitly tell that you don’t need to follow the license for writing scripts, you should add a notice that this license and your copyright claims don’t apply to the said scripts, and this will be much better. The point is that, as previously noted, the patentability of grammar sets (i.e. artificial languages) has been recently debated. Including the definition of the scripts in this license has the aim to prevent a Big Guy to come in, add a frobotz statement and patent the resulting language (or, as someone has pointed out, just patent the grammar someone else wrote as-is). Or in other words, I did it to maintain freedom of the grammar set this language define (it means, freedom for everyone to use and extend it). 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. Pitifully, this isn't the case, but I see that using the term scripts is a near-miss to my target here. As I said, scripts will be off. As it is now, it is unclear if you can take your scripts, run them with an interpreter you did and release your scripts and your interpreter without FPLL, and that wasn't my aim. Removing the term script and bounding FPLL to the product to which is applied (in this case, Falcon engine), seems much more reasonable. Thanks for clarification. Giancarlo. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7FRF5nwsoBIDC4YRAuogAJ9OcbD3YbGSfy9dlg/PrvSSrEELTQCeN6Lj Ow49J+edIbkFSHrRN3n0YI0= =eufy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Falcon P.L. license (ITP:Bug#460591)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josselin Mouette wrote: On sam, 2008-03-22 at 22:33 +0100, Giancarlo Niccolai wrote: Have you considered the GNU LGPL (v2.1)? Yes, but I encountered strong resistance from FSF when proposing a lighter (with exceptions) LGPL version. This is, again, because you are not proposing additional permissions (for which the LGPL with extra additional permissions would be fine) but additional *restrictions*. Well, yes, and no. Part of the things that would be covered by LGPL in full (requiring re-application of LGPL and openness) are just required to place a notice somewhere by FPLL, while the things that LGPL would just forget about (totally free) will still require to place the same notice by FPLL. Some of the applications, the most relevant one for our community (in my aims), would be more, not less, free with FPLL. However, you can't burn a theatre with all people even if you'd like the show because there are *restriction* to certain actions. I Understand that the term *restriction* may have a bad ring among coders, but GPL is all about *restricting* people from *harming* other people's freedom. In this sense, FSF was a bit reluctant; not in demanding a bit more of humanity on closed source software, but in removing some of those *restrictions* from that software that would have been more, not less, free with FPLL. In example, a fully scripted application that uses Falcon to run is not linking it; it's damedly using it head over heels and up to the throat, and if Falcon was LGPL without exceptions, the script-based apps would have to be distributed open source and under LGPL or more restrictive terms. Under FPLL, they can be distributed with any term; they can pick any open source license or distribute the code closed-source, in which case they are required to place a notice. The term script may have given room to the doubt that FPLL should have been applied also to Falcon scripts run by non FPLL software (i.e. run with a separately written VM or interpreter); I'll remove this term to avoid this confusion. Bests, Giancarlo Niccolai. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7FnO5nwsoBIDC4YRAgVbAJ4rr09BWup+H6qspNWVULpvJW43ZgCfYLeB Jf6aL4pjtXsm9OKDw2XmFBg= =Ik4a -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Falcon P.L. license (ITP:Bug#460591)
Giancarlo Niccolai [EMAIL PROTECTED] 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. 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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#460591: Falcon P.L. license (ITP:Bug#460591)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 MJ Ray wrote: Giancarlo Niccolai [EMAIL PROTECTED] 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
Re: Falcon P.L. license (ITP:Bug#460591)
On Fri, 21 Mar 2008 10:09:27 +0100 Giancarlo Niccolai wrote: [...] In other words, the aim of this comma is to prevent someone from adding a frobotz statement which nitfols the blorbs, and then distribute an xFalcon as a closed source product. You seem to want a weak copyleft that does not extend to the works merely linking to the original work. Modifying the Apache License v2.0 is not a good strategy, if the goal is the one outlined above. Have you considered the GNU LGPL (v2.1)? Disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/progs/scripts/refresh-pubring.html New! Version 0.6 available! What? See for yourself! . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpnGlzD1emRw.pgp Description: PGP signature
Re: Falcon P.L. license (ITP:Bug#460591)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Francesco Poli wrote: On Fri, 21 Mar 2008 10:09:27 +0100 Giancarlo Niccolai wrote: [...] In other words, the aim of this comma is to prevent someone from adding a frobotz statement which nitfols the blorbs, and then distribute an xFalcon as a closed source product. You seem to want a weak copyleft that does not extend to the works merely linking to the original work. Modifying the Apache License v2.0 is not a good strategy, if the goal is the one outlined above. Have you considered the GNU LGPL (v2.1)? Yes, but I encountered strong resistance from FSF when proposing a lighter (with exceptions) LGPL version. So, I thought that I whould have been better starting from some OSI approved license that was the nearest to my needs, and Apache2 seemed the most fitting. Bests, Giancarlo. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5XsL5nwsoBIDC4YRAiNvAJ4l3HVbMsuLBXfTHST8kFSCLAIdIQCgiipF uD1RlHnVYSuj+121mjp1wHU= =gwGA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Falcon P.L. license (ITP:Bug#460591)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josselin Mouette wrote: On mer, 2008-03-19 at 20:34 +0100, Giancarlo Niccolai wrote: The license is tightly based on Apache 2, with extra clarifications and permissions. This is, well, an interesting claim. 4. *Redistribution of Work and Derivative Works*. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: 5. The Derivative Works are distributed under the terms of this License, or under terms that do not cause infringement of this License. This clause makes the license a copyleft one. It is free, but this is a huge restriction compared to the original license. And this turns the license into yet another copyleft license that will be incompatible with other ones. I see; you are talking of comma 4.5 in the specific? I actually added it after some talk with FSF about requiring the derivative work to be distributed copyleft too. In other words, the aim of this comma is to prevent someone from adding a frobotz statement which nitfols the blorbs, and then distribute an xFalcon as a closed source product. I understand that the other statements in article 4 would anyhow force the distributors of derivative works to provide the original Falcon as is, while their xFalcon may be closed source, yet I sense that this may become a threat to the both community that developed the original Falcon in future and to the users of final products derived from Falcon. Once someone closes its derived Virtual Machine, how can the community be certain it doesn't run malevolent code? Moreover, it is clearly stated that derivative works does not include applications using Falcon as a scripting engine nor modules extending Falcon. I.e. company xyz may write a differently licensed Falcon module to integrate their top secret device driver API. Derivative works are, in this license, only the ones that take a work on which FPLL has been directly applied, change some instructions and recompile. Anyhow, if anyone sense that this 4.5 comma may be a threat to community freedom, instead of a guarantee as I wished it to be, it can be removed, but let's talk about it. 5. *Distribution of Embedding Works and Scripts*. I don’t think you can claim anything on the copyrights of scripts using your language, but this is definitely something you should ask your lawyer. This license doesn't state there are copyright claims on the scripts; actually it should do the opposite. If there is any point implicitly or explicitly stating it, please point it out and it will be fixed. If you really want to explicitly tell that you don’t need to follow the license for writing scripts, you should add a notice that this license and your copyright claims don’t apply to the said scripts, and this will be much better. The point is that, as previously noted, the patentability of grammar sets (i.e. artificial languages) has been recently debated. Including the definition of the scripts in this license has the aim to prevent a Big Guy to come in, add a frobotz statement and patent the resulting language (or, as someone has pointed out, just patent the grammar someone else wrote as-is). Or in other words, I did it to maintain freedom of the grammar set this language define (it means, freedom for everyone to use and extend it). When the license was written (2005), I was very dobutful about using the term script or the more fuzzy grammar ruleset, but time changes; we can talk about that. Finally, using the term script I added a guarantee that I really wanted to be in, both for the project and for the final users. I added the clause that applications written partially or entierly in Falcon must not hide this fact. In other words, the users must know they are running Falcon with their application. There has been long talks about the opportunity of users knowing the software they run, and the OS /FSF communities generally agree it is better to know it. When I wrote this license I had in mind the example of NScript, which is used commercially by many sofwtare houses writing games (mainly in Japan), but which usage is often kept more or less hidden from the final user. Of course, final users are 99% not interested in that, yet having the programmatic ability to remove this knowledge seemed unfair to me. The term *Distribution of scripts* and the related commas are there to prevent distributors to remove this freedom from end-users. I think this aims are widely accepted and even supported by the Open Source community. The thing under debate here is if this license is adequate to protect this freedom and doesn't introudce any hidden restriction I am not aware of. Other than that, if the community thinks that some of those guarantees are actually restrictions, we can discuss about that and
Re: Falcon P.L. license (ITP:Bug#460591)
On mer, 2008-03-19 at 20:34 +0100, Giancarlo Niccolai wrote: The license is tightly based on Apache 2, with extra clarifications and permissions. This is, well, an interesting claim. 4. *Redistribution of Work and Derivative Works*. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: 5. The Derivative Works are distributed under the terms of this License, or under terms that do not cause infringement of this License. This clause makes the license a copyleft one. It is free, but this is a huge restriction compared to the original license. And this turns the license into yet another copyleft license that will be incompatible with other ones. 5. *Distribution of Embedding Works and Scripts*. I don’t think you can claim anything on the copyrights of scripts using your language, but this is definitely something you should ask your lawyer. If you really want to explicitly tell that you don’t need to follow the license for writing scripts, you should add a notice that this license and your copyright claims don’t apply to the said scripts, and this will be much better. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Falcon P.L. license (ITP:Bug#460591)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, As suggested by Mr. Paul Wise, I am writing here to have the Falcon Programming Language License by Debian. The license is tightly based on Apache 2, with extra clarifications and permissions. Rationale behind this license is that of provide a license defining and clarifying limits between embedding applications (that is, an application USING the scripting language) and derived works (that is, re-works of the language). Also the license clears the field from ambiguity about usability and freedom of code generated and run by the Virtual Machine. I am going through this because, after searching for a license providing those guarantees to language users, I have found none. Other licenses in the field are either left ambiguous, or are special purpose language specific license (along OSI guidelines) or are basic licenses with exceptions (i.e. LGPL with embedding exception). I thought that, instead of smuggling in a new license under the disguise of a well knonw one with exceptions, Falcon users and the the community as a whole would have had benefits from a generic, open source license which is aimed to define those applications meant to work symbiotically with other ones, as i.e. scripting languages. In fact, FPLL is not a languge-specific license and may be adopted by all the applications that fall in this class. I am submitting the license to OSI for certification as soon as the lawyer I hired will provide me with a legal advice. In the meanwhile, I have opened an ITP bug, for which Debian Legal clearance is needed. Here follows the text of the license. TIA , Giancarlo Niccolai. == Falcon Programming Language License Version 1.0, February 2005 http://www.falconpl.org/?page_id=license TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. *Definitions*. * License shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. * Licensor shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. * Legal Entity shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, control means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. * You (or Your) shall mean an individual or Legal Entity exercising permissions granted by this License. * Source form shall mean the preferred form for making modifications, including but not limited to software source code and example code. * Object form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. * Work shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). * Derivative Works shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. * 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. * Contribution shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is
