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)
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: ITP:Bug#460591 - Falcon P.L. license
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Landry wrote: Giancarlo Niccolai [EMAIL PROTECTED] wrote: I am working now at this. However, I have a notice in every file stating that the file is released under the terms described in the LICENSE file that must come bound with the sources. I think that changing the content of that file, instead of changing the contents of each source (there are several hundreds) may be enough. Can you confirm this or is putting a more descriptive license statement in each source a requirement? I opened up a random file in the 0.8.8 release, and I found /* FALCON - The Falcon Programming Language FILE: indirect.cpp $Id: indirect.cpp,v 1.6 2007/03/04 17:39:03 jonnymind Exp $ Indirect function calling and symbol access. --- Author: Giancarlo Niccolai Begin: gio apr 13 2006 Last modified because: --- (C) Copyright 2004: the FALCON developers (see list in AUTHORS file) See LICENSE file for licensing details. In order to use this file in its compiled form, this source or part of it you have to read, understand and accept the conditions that are stated in the LICENSE file that comes boundled with this package. */ This is not quite accurate, since you do not have to accept the GPL to use the code. You only have to accept it if you make copies. The current wording makes your intent unclear. If you just had See LICENSE file for licensing details. then that would be fine. If the file ever gets separated from the LICENSE file, it may be difficult to figure out its license. But that is not critical for you. Cheers, Walter Landry [EMAIL PROTECTED] Ok, I understand. It seems that there is the need to touch the header of all the files, so I can't just re-distribute version 0.8.8 changing its license as I wanted. Also, it would be a bit confusing, as other distros are distributing 0.8.8 with the previous licensing scheme. Luckily, we have just completed the review of features that we planned for release 0.8.10; in other words, our official 0.8.10 release is nearly ready, except for stress test, packaging and documentation updates. We may have it shaped up in a week or so. The structure of the package was not planned to change, so it's just a change on the sources, while the packaging (i.e. /debian stuff) can stay the same. As we're releasing, I'll take the occasion to stuff the new license plates in the source headers. We're not writing scripting languages for nothing, after all :-)) So I'll be back with a dual licensed package in a week or so. About the FPLL license, I have a tentative 1.1 version, which my lawyers have been reviewing since today. I have changed the too wide and generic script term into: * 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. So, you can write scripts in the Falcon language, but if you don't run them with a work covered by this license, the license does not extends to them. Also, I have removed references to the old script without changing it in to the new term in the copyright-copyleft statement. In other words, Applications of the work do not appare in the copyleft. Finally, point 5 is simplified and cites explicitly Applications of the Work instead of the generic term Scripts. So, point 5 requiring closed sources scripted apps to carry a notice is to be applied only if those scripts are run with an interpreter covered by the license. Oh, and I copied the how to apply appendix from Apache 2 :-) The complete reviewed text is here: http://www.falconpl.org/?page_id=license_1_1 Thanks to everyone here for the precious reviews and suggestions. If someone has further comments on this new version of the license, they will be welcome. Bests, Giancarlo Niccolai. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH8Uo/5nwsoBIDC4YRAl3cAJ4ycXIJAgIpRdL2jpTSGQBqZZjdVwCfZ1gE 8SR3pEsrjGIw9/t7R0CsiK8= =9T7r -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP:Bug#460591 - Falcon P.L. license
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Landry wrote: Giancarlo Niccolai [EMAIL PROTECTED] wrote: Walter Landry wrote: Giancarlo Niccolai [EMAIL PROTECTED] wrote: In example, I can release Falcon as a Debian package under GPL, and let users pick FPLL if they wish. That would be perfect. Many other programs in Debian are dual-licensed in that manner. Very well, let's go for that then. How that can be accomplished? -- where can I look for samples, and what do I need write? Firefox is one example. In every file, you can write something like I am working now at this. However, I have a notice in every file stating that the file is released under the terms described in the LICENSE file that must come bound with the sources. I think that changing the content of that file, instead of changing the contents of each source (there are several hundreds) may be enough. Can you confirm this or is putting a more descriptive license statement in each source a requirement? Bests, Giancarlo Niccolai. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH72R05nwsoBIDC4YRAvL4AKCJOXl7AIXNOCHYrS4D2E1TxSbykACfUEnK vxJ2J/YW8v78eUvKs4ctAEE= =sMjH -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)
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]
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: ITP:Bug#460591 - Falcon P.L. license
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Walter Landry wrote: Giancarlo Niccolai [EMAIL PROTECTED] wrote: In example, I can release Falcon as a Debian package under GPL, and let users pick FPLL if they wish. That would be perfect. Many other programs in Debian are dual-licensed in that manner. Cheers, Walter Landry [EMAIL PROTECTED] Very well, let's go for that then. How that can be accomplished? -- where can I look for samples, and what do I need write? Thanks, Giancarlo Niccolai. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6UOj5nwsoBIDC4YRAlfnAJ4vMaFGGoPlJ/efFngYiQ2rJoFKwACeM0hI HQgOb7FEAi8c0HtCERWuX2E= =7K2e -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP:Bug#460591 - Falcon P.L. license
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 MJ Ray wrote: Sean Kellogg [EMAIL PROTECTED] wrote: On Wednesday 19 March 2008 03:10:07 pm Francesco Poli wrote: I don't think that copyright laws give you the right to control distribution of Scripts, that is to say, works written in your programming language. [...] There's even the question of how someone goes about learning the language... presumably by example (that's how I've learned most other languages). Can I create a work that is not derivative of those examples and thus under the preview of copyright law? This would have made a fun topic to write about in law school :) Sure. I suspect there's quite a bit of case law about it, including some generated by the loglan/lojban disputes, where 'JCB claimed copyright to the language (any use of Loglan had to be approved by him)' Source: http://arj.nvg.org/lojban/why-i-like.html I'm suspicious of any language where the definer is the first implementer and hasn't renounced all claim to works in that language. They look like lawyerbombs to me because I don't know any better. Is that a good thing to have when trying to promote your new language? Regards, The idea I tried to follow is exactly that to free the language definition from any possible current and future claim (i.e. through non-patentability). Bests, Giancarlo Niccolai. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH6UQn5nwsoBIDC4YRAjUzAJ44bYMgNZt/Mir8cYfP12Vb4XxXXwCgmK2L dmbWqWq3/daujGrXpoDdreQ= =wNKl -END PGP SIGNATURE- -- 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
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: ITP:Bug#460591 - Falcon P.L. license
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Francesco Poli wrote: On Thu, 20 Mar 2008 10:35:16 +0100 (CET) Giancarlo Niccolai wrote: | 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. I think it's pretty clear that what you call Embedding Works are not Derivative Works for the purposes of the Apache License v2.0 ... Unluckily, Apache is C, and Falcon is C++. Much code is inlined, so it is not possible to use the mere link by name criterion as a clear cut between derivative works (that would fall under FPLL) and embedding works and modules (that won't fall under that, but are required to tell they're using Falcon). I agree that we coders know what an inline is, and we can draw a clear equivalence between using inline code and name-linking; just, I was afraid that there could have some illicit extension of the concept of derivative work beyond the limit we, the coders, would consider adequate. Or put down more simply; the name linking criterion proved a bit controversial on the ground. FSF had long talks about that, it can be easily browsed on the net. And anyhow, it may be ok for things as an external service, but when it comes to a scripting engine, which do certain things inside your own application, I thought that a more precise and functional-oriented distinction was needed. What may be less clear is whether I'm allowed to create and distribute a work that merely links to the Apache web server v2.x.y. The Apache License v2.0 does *not* explicitly grant this permission. ... 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. If there's no need for an explicit permission, then your conditioned permission is superfluous (and everybody can perform those actions, even while *hiding* the use of Falcon). Sorry, I can't follow your points anymore. I said that I am ready to change any part of the license, if 1) it restricts freedom of users/coders (more than other widely accepted open source license) rather than defending them; and 2) its wording/structure are inadequate to pursue the declared aims (which are listed in the commentary). Otherwise, I require this license to be accepted by Debian as I am proposing a package under that license. If this is plainly not possible regardless of points 1 and 2, in example, because Debian doesn't accept new licenses unless approved i.e. by OSI and/or FSF, then I am asking for an alternative measure. In example, I can release Falcon as a Debian package under GPL, and let users pick FPLL if they wish. Please, let's concentrate on this topics. Bests, Giancarlo Niccolai. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH5YJp5nwsoBIDC4YRAo6mAJ96NRiwENLlSI4EvK8MTWd+NAhT1wCfbR6p 7rwktDkbwpTagQWTd3xnZiY= =73w+ -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
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 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]
ITP:Bug#460591 - Falcon P.L. license
-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
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
