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: ITP:Bug#460591 - Falcon P.L. license
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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP:Bug#460591 - Falcon P.L. license
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, -- 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: 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: ITP:Bug#460591 - Falcon P.L. license
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 * The contents of this file are subject to the Falcon Programming * Language License 1.0 (the FPLL); you may not use this file * except in compliance with the FPLL. You may obtain a copy of the * FPLL at http://www.falconpl.org/?page_id=license * * Software distributed under the FPLL is distributed on an AS IS basis, * WITHOUT WARRANTY OF ANY KIND, either express or implied. See the FPLL * for the specific language governing rights and limitations under the * FPLL. * * Alternatively, the contents of this file may be used under the * terms of the GNU General Public License Version 2 or later (the * GPL), in which case the provisions of the GPL are applicable * instead of those above. If you wish to allow use of your version of * this file only under the terms of the GPL, and not to allow others * to use your version of this file under the terms of the FPLL, * indicate your decision by deleting the provisions above and replace * them with the notice and other provisions required by the GPL. If * you do not delete the provisions above, a recipient may use your * version of this file under the terms of either the FPLL or the GPL. It would also be nice to put a notice at the top level (e.g. in a README) that states that the same thing. Something like Copyright 1989-2001, Giancarlo Niccolai All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of either: a) the Falcon Public Language License which comes with Falcon, or b) the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. Also include a copy of the FPLL and the GPL with the code. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP:Bug#460591 - Falcon P.L. license
On Thu, 20 Mar 2008 10:35:16 +0100 (CET) Giancarlo Niccolai wrote: Francesco Poli wrote: [...] 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. How so? The Apache License v2.0 explicitly states: | 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. and the FPLL v1.0 defines | 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 ... 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. But is this permission *really* required by copyright laws? It seems that the Apache License v2.0 drafters assumed there is no need for this permission (I cannot believe they wanted to forbid such action, so I suppose they assumed there is no need to explicitly allow it!). I hope there is no need for an explicit permission to perform this action. Indeed, if such an action is effectively forbidden for the Apache web server v2.x.y, then I think we have a serious DFSG-freeness issue with some important packages in Debian main! 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). If, on the other hand, an explicit permission is really needed, then we have a serious problem with Apache License v2.0, and I think the right solution is contacting the Apache Software Foundation and persuading them to publish a fixed Apache License v2.x (with x 0). [...] 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. The ground is not completely cleared, because it remains unclear whether one is allowed to hide the use of Falcon... The FPLL says it's not allowed, but, if the conditioned permission was superfluous in the first place, then, it's effectively allowed. Standardized 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 pgponC1CziciU.pgp Description: PGP signature
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: 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, that is
Re: ITP:Bug#460591 - Falcon P.L. license
On Wed, 19 Mar 2008 19:59:33 +0100 Giancarlo Niccolai wrote: Hello, Hi! As suggested by Mr. Paul Wise, I am writing here to have the Falcon Programming Language License by Debian. I assume you mean that you would like to have your license analyzed or revised by debian-legal. 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. Moreover, there are many reasons why you should *not* try to write a new license: a) license proliferation is bad, since it contributes to balkanize the free software community and makes legal and freeness analyses even more unclear to non-expert users and developers b) writing a good license requires legal expertise (you seem to be willing to hire a lawyer, but that will cost you money...) and is often a long and difficult task[1] c) license proliferation is *really* bad d) did I mention that license proliferation is bad? [1] if you followed the GPLv3 revision process, you saw how many people were involved, how long it took and yet, starting from a terrible first draft, they only managed to produce a final text which is unsatisfactory and suboptimal in several respects, IMO... [...] Here follows the text of the license. [...] * 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. 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. For instance, I don't think I need permission from anyone in order to write (original) C++ code and distribute it as I like. 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... What I expressed are my own opinions. 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 pgpfCTzhu8iDo.pgp Description: PGP signature
Re: ITP:Bug#460591 - Falcon P.L. license
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. For instance, I don't think I need permission from anyone in order to write (original) C++ code and distribute it as I like. This is an interesting claim and I think is far from clear cut. If I develop a comprehensive grammar and syntax for a language (programming or otherwise) what elements are required for others to use speak it and to what extent can I protect/restrict the use of those elements? The first obvious answer is that the language is an idea, and thus patentable. I don't think that's a point of contention here, but worth noting that one can certainly restrict the use of a language via a patent. But, if we keep our analysis to just copyright protection, I'm still not sure it's a slam dunk depending on factors. Here I'm thinking of libraries which may be necessary for the script to run... like libc. Sure, I can just write C code, but it's pretty useless without libc... and if I incorporate a version of libc with a restrictive license, then I'm certainly going to have to comply with the copyright restrictions of that license. 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 :) -Sean -- Sean Kellogg e: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP:Bug#460591 - Falcon P.L. license
On Wed, 19 Mar 2008 16:00:31 -0700 Sean Kellogg 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. For instance, I don't think I need permission from anyone in order to write (original) C++ code and distribute it as I like. This is an interesting claim and I think is far from clear cut. If I develop a comprehensive grammar and syntax for a language (programming or otherwise) what elements are required for others to use speak it and to what extent can I protect/restrict the use of those elements? The first obvious answer is that the language is an idea, and thus patentable. I don't think that's a point of contention here, but worth noting that one can certainly restrict the use of a language via a patent. This is only true in those (insane) jurisdictions where ideas are patentable. That is to say, where software patents and the like are valid. Examples of those jurisdictions are, IIUC: the USA (but there are plans to push for a political change in the USA), Japan, Australia, ... Anyway, as you yourself acknowledge, I was talking about copyright laws only. But, if we keep our analysis to just copyright protection, I'm still not sure it's a slam dunk depending on factors. Here I'm thinking of libraries which may be necessary for the script to run... like libc. Sure, I can just write C code, but it's pretty useless without libc... For the sake of clarity, I was talking about writing and distributing (original) C++ source code. I didn't (on purpose) consider the distribution of compiled *and linked* code. It is my understanding that writing source code intended to link with a library, does not, per se, create a derivative work of a specific implementation of that library, as long as you only adhere to an API. In your example, please note that there are many differently-licensed implementations of the C standard library. If I write C code by only adhering to the standard C library API, then I don't think I'm restricted by the license of any libc implementation... and if I incorporate a version of libc with a restrictive license, then I'm certainly going to have to comply with the copyright restrictions of that license. Let's not open the can of worms of static/dynamic linking versus derivative work creation, please! ;-) 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). By reading a book which explains the grammar, syntax, and semantics of the language? The book will probably include examples, but I don't think that copying one line of code from an example (especially when that line is the only good way to use an instruction or to call a library function) creates a derivative work... Hence, in most cases, your code won't be a derivative work of the examples you once studied. Can I create a work that is not derivative of those examples and thus under the preview of copyright law? Is this e-mail message a derivative work of the example texts I once studied on my English grammar and conversation textbooks? I don't think so... Well, at least, I hope it's not! ;-) This would have made a fun topic to write about in law school :) IANAL, nor did I attend law school, hence I can only try to imagine how fun it would have been... My other disclaimers still apply: 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 pgpy9ElkqjkA3.pgp Description: PGP signature
