Re: Unidentified subject!
On Sat, Jan 28, 2006 at 04:21:02PM +0100, Luca Brivio wrote: What do you think about the following License? Is it a free software license? The patent grant is tighter than I'd like; the way I understand it, you get a copyright license for modified works, but not a patent grant. So if there is any patent (held by the Initial Developer or a Contributor) that covers the code, it makes it non-free, as then modification is not permitted. https://biospice.org/visitor/documents/BioCOMPLicense.pdf -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
On Sun, Nov 06, 2005 at 01:28:36AM -0500, Justin Pryzby wrote: I mean the *developer* must comply with both licenses, eg if you d/l under the GPL and MIT, then the developer must still put the written offer for source code and meet all the distribution requirements of the GPL, but anyone else can choose between the GPL and the MIT license. In opened software, We are all developers. I think he meant to say the copyright holder. In free software, we are not all the copyright holder. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
Yes. I meant the copyright holder. Andrew On 11/6/05, Glenn Maynard [EMAIL PROTECTED] wrote: On Sun, Nov 06, 2005 at 01:28:36AM -0500, Justin Pryzby wrote: I mean the *developer* must comply with both licenses, eg if you d/l under the GPL and MIT, then the developer must still put the written offer for source code and meet all the distribution requirements of the GPL, but anyone else can choose between the GPL and the MIT license. In opened software, We are all developers. I think he meant to say the copyright holder. In free software, we are not all the copyright holder. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- This space for rent. Enquire within. Terms and conditions apply. See store for details. Get free domains - http://www.ezyrewards.com/?id=23484
Re: [no subject]
Raul Miller wrote: On 11/4/05, Lewis Jardine [EMAIL PROTECTED] wrote: (Tangentially, could someone please clarify this: to pass on the work dual-licensed, do you need to comply with both licenses, or does the copyright statement attached to the work that you've legitimately distributed under one of the licenses allow your recipient to choose one or the other just like you could? I'm thinking the latter, but I may be wrong.) If you really need to comply with both licenses that's really just one license with the terms from both. Usually when someone says dual license they mean that people have the option of choosing between two licenses. I'll clarify my question: You have in your possession a dual-licensed work (in the conventional sense of dual-licensing; for sake of argument let's say GPL + MPL) for which you aren't the copyright holder. You know you have the option of using it under either the GPL or the MPL, but what you want to do is distribute it so that whoever received it also has the option of choosing GPL or MPL. If you were to pick either GPL or MPL, and not modify the work, does the recipient only have your choice of licence to pick from, or can they still choose either? Does this change if the way you distributed the work is not compatible with the other license? Does this change if you modified the work? -- Lewis Jardine IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [no subject]
Lewis Jardine wrote: what you want to do is distribute it so that whoever received it also has the option of choosing GPL or MPL. If you were to pick either GPL or MPL, and not modify the work, does the recipient only have your choice of licence to pick from, or can they still choose either? I guess it depends on whether your actions complied with both licenses. If you didn't follow a GPL requirement but did everything the MPL demanded, then I would say you implicitly chose the MPL option. The GPL then terminates (because of your noncompliance) and only the MPL then governs the work you distributed. Does this change if the way you distributed the work is not compatible with the other license? Does this change if you modified the work? I think it's more clear in such a situation. For example, I can integrate the software into something else to create what the MPL calls a Larger Work. Such a work might be a work based on the Program in the GPL's terminology. In such a case, the MPL says I can license the Larger Work under my own terms (if I follow the MPL for the originally-MPL parts), but the GPL says I must apply the GPL's terms to the work as a whole. If I now do not release source of the work as a whole, I comply with the MPL but not the GPL. This can only mean one thing: I elected the option to use the work under the MPL. Arnoud -- Arnoud Engelfriet, Dutch European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [no subject]
Scripsit Lewis Jardine [EMAIL PROTECTED] If you were to pick either GPL or MPL, and not modify the work, does the recipient only have your choice of licence to pick from, or can they still choose either? They can still choose either. In the case of both the GPL and the MPL alike, the grant of rights comes directly from the copyright holder to anybody who has the physical means to exercise them (such as having a copy of the work to copy _from_, however obtained). In particular, the grant of rights do not necessarily follow a particular transmission of bits, and somebody who merely passes bits along is in no position to block the grant of right that flows directly from the copyright holder to anybody. Does this change if you modified the work? If you modify the work in a non-trivial way, you obtain a copyright to your modifications, which you can license or not license as you see fit. For example, you can choose not to license your modifications under the GPL. This means that you cannot appeal to the GPL grant you yourself got when you want to argue that you are allowed to distribute the modified work (for the original copyright holder's permission is still necessary to do that). However, if you offer your modifications under the MPL, you get a right to distribute the modified work, because you can choose to exercise the rights you got from the MPL. -- Henning Makholm Jeg har skabt lammeskyer, piskeris, fingerspidsfornemmelser, polarkalotter, loddenhed, vantro, rutenet, skumtoppe, datid, halvdistancer, restoplag, gigt, pligtdanse, græsrødder, afdrift, bataljer, tyrepis, løvfald, sideblikke, hulrum, røjsere, mislyd, loppetjans, øer, synsrande... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
On Sat, Nov 05, 2005 at 06:47:03AM +1100, Andrew Donnellan wrote: On 11/5/05, Justin Pryzby [EMAIL PROTECTED] wrote: On Fri, Nov 04, 2005 at 06:28:02PM +1100, Andrew Donnellan wrote: On 11/4/05, Nathanael Nerode [EMAIL PROTECTED] wrote: Emmanuel Colbus wrote: My main concern about this was that such relicensed copies could have been considered not free, but undistributable, as the GPL is supposed to apply to software, not to documents. Any collection of bits is software. The GPL works very well for any collection of bits. Some people think that it, particularly the requirement for provision of source code and the nature of permission to distribute in forms other than source code, may have problems when applied to dead-tree printed material. This is easily dealt with by dual-licensing under the GPL and a printing-friendly license of your choice. Well actually no it doesn't solve the problem as you have to comply with both licenses when dual-licensing. Thats not what the phrase dual-licensing is typically used to mean. For example, a thing released under dual GPL/MIT license means that that thing is released under the GPL and under the MIT license. So if you want, you can use it under the terms of the MIT license. And, if you prefer, you can use it under the terms of the GPL license. I mean the *developer* must comply with both licenses, eg if you d/l under the GPL and MIT, then the developer must still put the written offer for source code and meet all the distribution requirements of the GPL, but anyone else can choose between the GPL and the MIT license. In opened software, We are all developers. In something like the proposed mozilla trilicensing scheme, the requirements are extremely loose; something to the effect of: You can do whatever you want, in any one of 3 different ways d/l == download? -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [no subject]
Andrew Donnellan wrote: On 11/4/05, Nathanael Nerode [EMAIL PROTECTED] wrote: Any collection of bits is software. The GPL works very well for any collection of bits. Some people think that it, particularly the requirement for provision of source code and the nature of permission to distribute in forms other than source code, may have problems when applied to dead-tree printed material. This is easily dealt with by dual-licensing under the GPL and a printing-friendly license of your choice. Well actually no it doesn't solve the problem as you have to comply with both licenses when dual-licensing. Then you couldn't dual-license two GPL-derivatives; their two 'no further restrictions' requirements would prevent you distributing the work at all. As I understand it, a dual-licensed work contains two conditional grants of rights; fulfilling the conditions for one conditional grant grants all the rights you need. The other conditional grant can't take your rights away, even if you don't fulfil its conditions. I'd say that dual-licensing would solve this problem, as long as you're content with only passing on the work licensed according to the one that doesn't object to it being in dead-tree format. (Tangentially, could someone please clarify this: to pass on the work dual-licensed, do you need to comply with both licenses, or does the copyright statement attached to the work that you've legitimately distributed under one of the licenses allow your recipient to choose one or the other just like you could? I'm thinking the latter, but I may be wrong.) In any case, could the problem with not providing source be solved by exercising GPL 3b? Just stick a note in the copyright that the source code is available. IMO, this is exactly what the GPL is supposed to be doing: preserving the freedom to modify. This would be curtailed if to modify a book you first had to scan and OCR it. -- Lewis Jardine IANAL, IANADD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dual licensing (was: Re: [no subject])
On Fri, Nov 04, 2005 at 06:28:02PM +1100, Andrew Donnellan wrote: On 11/4/05, Nathanael Nerode [EMAIL PROTECTED] wrote: Emmanuel Colbus wrote: My main concern about this was that such relicensed copies could have been considered not free, but undistributable, as the GPL is supposed to apply to software, not to documents. Any collection of bits is software. The GPL works very well for any collection of bits. Some people think that it, particularly the requirement for provision of source code and the nature of permission to distribute in forms other than source code, may have problems when applied to dead-tree printed material. This is easily dealt with by dual-licensing under the GPL and a printing-friendly license of your choice. Well actually no it doesn't solve the problem as you have to comply with both licenses when dual-licensing. Thats not what the phrase dual-licensing is typically used to mean. For example, a thing released under dual GPL/MIT license means that that thing is released under the GPL and under the MIT license. So if you want, you can use it under the terms of the MIT license. And, if you prefer, you can use it under the terms of the GPL license. You get to choose. Its like the gpl version 2 or later clause: at your option. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
On 11/5/05, Justin Pryzby [EMAIL PROTECTED] wrote: On Fri, Nov 04, 2005 at 06:28:02PM +1100, Andrew Donnellan wrote: On 11/4/05, Nathanael Nerode [EMAIL PROTECTED] wrote: Emmanuel Colbus wrote: My main concern about this was that such relicensed copies could have been considered not free, but undistributable, as the GPL is supposed to apply to software, not to documents. Any collection of bits is software. The GPL works very well for any collection of bits. Some people think that it, particularly the requirement for provision of source code and the nature of permission to distribute in forms other than source code, may have problems when applied to dead-tree printed material. This is easily dealt with by dual-licensing under the GPL and a printing-friendly license of your choice. Well actually no it doesn't solve the problem as you have to comply with both licenses when dual-licensing. Thats not what the phrase dual-licensing is typically used to mean. For example, a thing released under dual GPL/MIT license means that that thing is released under the GPL and under the MIT license. So if you want, you can use it under the terms of the MIT license. And, if you prefer, you can use it under the terms of the GPL license. I mean the *developer* must comply with both licenses, eg if you d/l under the GPL and MIT, then the developer must still put the written offer for source code and meet all the distribution requirements of the GPL, but anyone else can choose between the GPL and the MIT license. Andrew -- This space for rent. Enquire within. Terms and conditions apply. See store for details. Get free domains - http://www.ezyrewards.com/?id=23484
Re: dual licensing (was: Re: [no subject])
On Sat, Nov 05, 2005 at 06:47:03AM +1100, Andrew Donnellan wrote: So if you want, you can use it under the terms of the MIT license. And, if you prefer, you can use it under the terms of the GPL license. I mean the *developer* must comply with both licenses, eg if you d/l under the GPL and MIT, then the developer must still put the written offer for source code and meet all the distribution requirements of the GPL, but anyone else can choose between the GPL and the MIT license. This is true for any developer who releases under both licenses, but any developer may release under just one license and then only comply with that one. In the effort for expanding understanding, here's why that is, by looking at the way the GPL works... The GPL has it's legal enforceability from copyright law. GPL'ed software is copyrighted, which restricts all but the most fringe fair uses to the software. No user has the right to use or redistribute the software in most ways under this state of non-license. The GPL, being a license, also serves as a sort of unsigned contract between the two parties. The author, by releasing per software under the GPL, offers in writting to provide certain things to 3rd parties, including source code, which is what prevents deceptive authors from releasing under the GPL but not complying with it themselves. Then the copyright holder provides a license which permits non-exclusive, royalty-free access to the software under certain conditions. We're all probobally very familiar with what the GPL provides, so I'll leave it there. Now, with dual licensing, the copyright holder offers two different licenses. The purpose of any license is to permit activity which the copyright, by itself, will not. It cannot legally restrict beyond what copyright already does. Nothing in the MIT license, using this as an example (there's a number of proprietary licenses used too, see MySQL or ReiserFS for good examples), says you must also comply with the GPL license. Nothing in the GPL license says that you must also comply with the MIT license. Therefore, you have a choice, since both of these licenses independently grant you access to the code. If you, as a developer, user, reseller, etc choose to only use one license, that is your right, as granted by the original copyright holder. When you slap your copyright on your contributions, assuming you're adding or changing it, you may choose to only license your changes under the GPL, or under the MIT, as both permit changes to be added and redistributed. Now, most dual licensed software requires that, in order for your changes to make it back into the main distro, you must license under both licenses. Some also require that you give the copyright of your changes to the original author. See reiserfsprogs/README for an example of this, where you're allowed not only to keep your copyright but, if you dual license for commercial/proprietary sale (ie, company wants to use reiserfs in non-free software) he may cut you a check for non-trivial contributions. None of this is required. You can, in the above example of GPL+MIT, release a fork of the code under the GPL exclusivly (or MIT exclusivly) if the author won't accept your contribution unless it's also dual licensed. That is, if you write a really great new optimized search routine for MySQL but you don't want your additions to be anything but GPL, MySQL won't accept it, but that doesn't mean you can't offer a fork or patchset for others to use. Now, having a single software package where two or more different licenses cover different parts of the code is a different issue, one that was hinted to earlier on the thread. In this case, those licenses apply only to the parts of the package which they cover, and this may or may not be in violation of the GPL depending on how those pieces fit together. If they're ment to be compiled into a single binary, or linked against each other, and the licenses aren't compatable, the maintainer for that package needs to be schooled. It's perfectly fine, however, for a library to be released under a BSD license with an example mini-app which uses the library licensed under the GPL and documentation licensed under the FDL (or CC Attrib-AsIs or any other combo). A GPL'ed application can link against BSD-licensed library and the docs, which are entirely seperate, can be licensed however the author chooses. A similar situation can arise from patent licenses, which are similar but of an animal all their own. If the patent license (a license which grants access to some patented method or procedure) is GPL-incompatable the author must be very careful that whatever software implements it not be linked directly against either the GPL or LGPL, as section 7 of the GPL and section 11 of the LGPL would render such software illegal for 3rd parties to distribute, as enforced by the copyright
Re: dual licensing (was: Re: [no subject])
Just to make myself clear: if you can't determine sourcecode you still can't release under the GPL, even if you dual-license. Andrew On 11/5/05, Arc Riley [EMAIL PROTECTED] wrote: On Sat, Nov 05, 2005 at 06:47:03AM +1100, Andrew Donnellan wrote: So if you want, you can use it under the terms of the MIT license. And, if you prefer, you can use it under the terms of the GPL license. I mean the *developer* must comply with both licenses, eg if you d/l under the GPL and MIT, then the developer must still put the written offer for source code and meet all the distribution requirements of the GPL, but anyone else can choose between the GPL and the MIT license. This is true for any developer who releases under both licenses, but any developer may release under just one license and then only comply with that one. In the effort for expanding understanding, here's why that is, by looking at the way the GPL works... The GPL has it's legal enforceability from copyright law. GPL'ed software is copyrighted, which restricts all but the most fringe fair uses to the software. No user has the right to use or redistribute the software in most ways under this state of non-license. The GPL, being a license, also serves as a sort of unsigned contract between the two parties. The author, by releasing per software under the GPL, offers in writting to provide certain things to 3rd parties, including source code, which is what prevents deceptive authors from releasing under the GPL but not complying with it themselves. Then the copyright holder provides a license which permits non-exclusive, royalty-free access to the software under certain conditions. We're all probobally very familiar with what the GPL provides, so I'll leave it there. Now, with dual licensing, the copyright holder offers two different licenses. The purpose of any license is to permit activity which the copyright, by itself, will not. It cannot legally restrict beyond what copyright already does. Nothing in the MIT license, using this as an example (there's a number of proprietary licenses used too, see MySQL or ReiserFS for good examples), says you must also comply with the GPL license. Nothing in the GPL license says that you must also comply with the MIT license. Therefore, you have a choice, since both of these licenses independently grant you access to the code. If you, as a developer, user, reseller, etc choose to only use one license, that is your right, as granted by the original copyright holder. When you slap your copyright on your contributions, assuming you're adding or changing it, you may choose to only license your changes under the GPL, or under the MIT, as both permit changes to be added and redistributed. Now, most dual licensed software requires that, in order for your changes to make it back into the main distro, you must license under both licenses. Some also require that you give the copyright of your changes to the original author. See reiserfsprogs/README for an example of this, where you're allowed not only to keep your copyright but, if you dual license for commercial/proprietary sale (ie, company wants to use reiserfs in non-free software) he may cut you a check for non-trivial contributions. None of this is required. You can, in the above example of GPL+MIT, release a fork of the code under the GPL exclusivly (or MIT exclusivly) if the author won't accept your contribution unless it's also dual licensed. That is, if you write a really great new optimized search routine for MySQL but you don't want your additions to be anything but GPL, MySQL won't accept it, but that doesn't mean you can't offer a fork or patchset for others to use. Now, having a single software package where two or more different licenses cover different parts of the code is a different issue, one that was hinted to earlier on the thread. In this case, those licenses apply only to the parts of the package which they cover, and this may or may not be in violation of the GPL depending on how those pieces fit together. If they're ment to be compiled into a single binary, or linked against each other, and the licenses aren't compatable, the maintainer for that package needs to be schooled. It's perfectly fine, however, for a library to be released under a BSD license with an example mini-app which uses the library licensed under the GPL and documentation licensed under the FDL (or CC Attrib-AsIs or any other combo). A GPL'ed application can link against BSD-licensed library and the docs, which are entirely seperate, can be licensed however the author chooses. A similar situation can arise from patent licenses, which are similar but of an animal all their own. If the patent license (a license which grants access to some patented method or procedure) is GPL-incompatable the author must be very careful that whatever software
Re: dual licensing (was: Re: [no subject])
Please don't top-post. On Sat, Nov 05, 2005 at 07:42:10AM +1100, Andrew Donnellan wrote: Just to make myself clear: if you can't determine sourcecode you still can't release under the GPL, even if you dual-license. I don't know what you mean by determine sourcecode, but I can take my program, release it under the GPL and not release source if I want. (Nobody else could redistribute it, so it'd be a silly thing to do, but I could do it.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
On Fri, Nov 04, 2005 at 04:08:01PM -0500, Glenn Maynard wrote: I don't know what you mean by determine sourcecode, but I can take my program, release it under the GPL and not release source if I want. (Nobody else could redistribute it, so it'd be a silly thing to do, but I could do it.) I disagree. By licensing software under the GPL, the author has made a written offer to provide the source code, and if they later refuse to provide the source code, it's quite conceivable that a lawyer could force them to in court. After all, a license is a form of a contract, and the GPL grants rights to the source code, so it's pretty clear to even a layman. If you want a more definite answer, email Eben Moglen [EMAIL PROTECTED] -- Diversity is the Fuel of Evolution, Conformity its Starvation. Be Radical. Be New. Be Different. Feed Evolution with Everything You Are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
The GPL is not a contract, but one clause states that there must be source code provided, so while a copyright holder can violate the GPL by releasing under a different license, but the copyright holder can't release under the GPL and at the same time violate the GPL. Andrew On 11/5/05, Arc [EMAIL PROTECTED] wrote: On Fri, Nov 04, 2005 at 04:08:01PM -0500, Glenn Maynard wrote: I don't know what you mean by determine sourcecode, but I can take my program, release it under the GPL and not release source if I want. (Nobody else could redistribute it, so it'd be a silly thing to do, but I could do it.) I disagree. By licensing software under the GPL, the author has made a written offer to provide the source code, and if they later refuse to provide the source code, it's quite conceivable that a lawyer could force them to in court. After all, a license is a form of a contract, and the GPL grants rights to the source code, so it's pretty clear to even a layman. If you want a more definite answer, email Eben Moglen [EMAIL PROTECTED] -- Diversity is the Fuel of Evolution, Conformity its Starvation. Be Radical. Be New. Be Different. Feed Evolution with Everything You Are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- This space for rent. Enquire within. Terms and conditions apply. See store for details. Get free domains - http://www.ezyrewards.com/?id=23484
Re: dual licensing (was: Re: [no subject])
On Sat, Nov 05, 2005 at 08:50:13AM +1100, Andrew Donnellan wrote: The GPL is not a contract, but one clause states that there must be source code provided, so while a copyright holder can violate the GPL by releasing under a different license, but the copyright holder can't release under the GPL and at the same time violate the GPL. The idea is that the copyright holder doesn't need a license to do anything, so they can do whatever they want, including doing something which doesn't allow other people to do anything because of some inconsistency. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
There's no policy requiring real names on Debian lists, but it should be noted that you'll be taken less seriously by many people if you don't. (My impression is he doesn't trust what he says enough to even attach his name to it?.) Just FYI. On Fri, Nov 04, 2005 at 01:38:21PM -0800, Arc wrote: By licensing software under the GPL, the author has made a written offer to provide the source code, and if they later refuse to provide the source code, it's quite conceivable that a lawyer could force them to in court. No, he hasn't. He has said you have permission to do A and B provided you do C; nothing in the GPL says I, the author, will do the same, or even I promise to make it possible for you to do C. For example, the copyright holder of a GPL-licensed work can distribute binaries statically linked against GPL-incompatible libraries, such as BSD-with-OAC, but nobody else can. What you claim might be more plausible if the licensee paid money for his license. It's reasonable that if I agree to let you use my pool for $50, and then put a lock on my fence (you can use it, but you can't get in! Sucker!), you could enforce that contract against me--but you've given me nothing for your license under the GPL. After all, a license is a form of a contract, and the GPL grants rights to the source code, so it's pretty clear to even a layman. Whether the GPL is a contract is a widely debated topic (and I promise that if you open that discussion, it'll subvert the thread entirely), but the GPL makes no promises from the licensor to the licensee--except, perhaps, I won't sue you if you follow these rules. If you want a more definite answer, email Eben Moglen [EMAIL PROTECTED] You're free to invite whoever you wish to the discussion, but please don't ask me to do it for you. (As one of your premeses is that the GPL is a contract, and Eben Moglen's public position, last I heard[1], was that the GPL is not a contract, I doubt he'd agree with your conclusion.) [1] http://www.gnu.org/philosophy/enforcing-gpl.html Licenses are not contracts. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [no subject]
On 11/4/05, Lewis Jardine [EMAIL PROTECTED] wrote: (Tangentially, could someone please clarify this: to pass on the work dual-licensed, do you need to comply with both licenses, or does the copyright statement attached to the work that you've legitimately distributed under one of the licenses allow your recipient to choose one or the other just like you could? I'm thinking the latter, but I may be wrong.) If you really need to comply with both licenses that's really just one license with the terms from both. Usually when someone says dual license they mean that people have the option of choosing between two licenses. -- Raul
Re: dual licensing (was: Re: [no subject])
On Fri, Nov 04, 2005 at 06:21:10PM -0800, Arc Riley wrote: What makes you think Arc isn't my real name? It's a gaelic name that died out after the romans invaded and most of the male gaelic names were replaced by happy christian names. There's a certain amount of cultural sensitivity here, noting the difference between handles and names is important. It's not generally important to be able to tell the difference between an alias and an obscure name. (And, frankly, I don't mind if someone finds it insensitive that I don't recognize names like that, because I find that expectation unreasonable. :) In any case, posting first-name-only is little different than using an alias. (Though, it's better than using an absurd alias--I've seen someone posting to a technical list as Elvis Presley. Right ...) Read the preamble: When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. Sorry, I don't understand the relevance. The preamble explains the FSF's goals in the GPL; it doesn't make promises on behalf of the licensor. If you did manage to convince people that the GPL could be used as a stick against the copyright holders themselves, I'd suspect many people--at least, those paying attention--would quickly run away from it. You'd have uphill convincing to do, though, since common understanding is the opposite of your claim. It'd be interesting to see what Eben Moglen would say on the subject. Feel free to ask him. I'd need to be convinced further before I'd consider taking up his time with this, though. (By the way, I seem to recall that Eben is no longer general counsel for the FSF, and it may be more appropriate to ask the FSF directly.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
On 11/5/05, Glenn Maynard [EMAIL PROTECTED] wrote: Sorry, I don't understand the relevance. The preamble explains the FSF's goals in the GPL; it doesn't make promises on behalf of the licensor. If you did manage to convince people that the GPL could be used as a stick against the copyright holders themselves, I'd suspect many people--at least, those paying attention--would quickly run away from it. You'd have uphill convincing to do, though, since common understanding is the opposite of your claim. It'd be interesting to see what Eben Moglen would say on the subject. Feel free to ask him. I'd need to be convinced further before I'd consider taking up his time with this, though. (By the way, I seem to recall that Eben is no longer general counsel for the FSF, and it may be more appropriate to ask the FSF directly.) Eben is still legal counsel of the FSF. I'm going to contact the FSF and ask them about this. andrew
Re: [no subject]
Emmanuel Colbus wrote: My main concern about this was that such relicensed copies could have been considered not free, but undistributable, as the GPL is supposed to apply to software, not to documents. Any collection of bits is software. The GPL works very well for any collection of bits. Some people think that it, particularly the requirement for provision of source code and the nature of permission to distribute in forms other than source code, may have problems when applied to dead-tree printed material. This is easily dealt with by dual-licensing under the GPL and a printing-friendly license of your choice. -- Nathanael Nerode [EMAIL PROTECTED] This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [no subject]
On 11/4/05, Nathanael Nerode [EMAIL PROTECTED] wrote: Emmanuel Colbus wrote: My main concern about this was that such relicensed copies could have been considered not free, but undistributable, as the GPL is supposed to apply to software, not to documents. Any collection of bits is software. The GPL works very well for any collection of bits. Some people think that it, particularly the requirement for provision of source code and the nature of permission to distribute in forms other than source code, may have problems when applied to dead-tree printed material. This is easily dealt with by dual-licensing under the GPL and a printing-friendly license of your choice. Well actually no it doesn't solve the problem as you have to comply with both licenses when dual-licensing. But for most documents, source code is pretty easy to define: images, your XCF or PSD source (if you happen to use those formats), sound, your editor's project file, text, your word processor or TeX source. Andrew Donnellan -- This space for rent. Enquire within. Terms and conditions apply. See store for details. Get free domains - http://www.ezyrewards.com/?id=23484
Re: Unidentified subject!
On Wed, Oct 01, 2003 at 05:22:25PM -0400, Richard Stallman wrote: I believe there was never a time when only the FSF pushed for free software. I should have said the GNU Project rather than the FSF, since the GNU Project led to FSF and has always been larger. When the GNU Project started, there was no other organized effort to make software free. We were the first to aim to make it possible to use a computer without non-free software. Sounds to me like a set of criteria carefully invented to fit the GNU project. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Unidentified subject!
I believe there was never a time when only the FSF pushed for free software. I should have said the GNU Project rather than the FSF, since the GNU Project led to FSF and has always been larger. When the GNU Project started, there was no other organized effort to make software free. We were the first to aim to make it possible to use a computer without non-free software.
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: I believe there was never a time when only the FSF pushed for free software. I should have said the GNU Project rather than the FSF, since the GNU Project led to FSF and has always been larger. When the GNU Project started, there was no other organized effort to make software free. We were the first to aim to make it possible to use a computer without non-free software. This may be true, but many things happen without an organized effort. There were plenty of people who then, and now, believed in free software and worked for it. They were often happy to align themselves with the GNU Project, which had no small role in the success of that project. It seems to me that a serious problem is that we don't know at all what the opinions of the members of the GNU Project are about these issues, and that a process for finding out would be of great service to the community. Thomas
Re: Unidentified subject!
The Free Software Foundation built the free software community, years before Debian was started, This is at least much of a nasty cheap shot as what I said. And you've done it before. It is not a shot at all. I was defending the FSF from an accusation, not attacking Debian. I apologize if anyone got the wrong impression. The FSF has done wonderful things for the Free Software community, but it is false to claim it had sole responsibility for the community. I didn't say that. I said we built the community, which we did by pushing for free software when nobody else did. Of course, many others have contributed since then.
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: I didn't say that. I said we built the community, which we did by pushing for free software when nobody else did. Of course, many others have contributed since then. I believe there was never a time when only the FSF pushed for free software. Thomas
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: 1) Because the borders between the cases are ambiguous and uncertain. I sent a message a day or two ago (perhaps after you sent this one) which addresses that issue. 2) Because we want to be able to combine works from different sources, As I explained, this desire is usually impossible due to incompatibility of licenses. To reject the GFDL on these grounds and accept some other GPL-incompatible license is a double standard. Wrong, wrong, wrong. We want to be able to combine works. I keep repeating this, you keep saying I understand you, and then you keep proceeding as if I hadn't repeated it. The desire expressed in number two is *not* about the desire to combine any two arbitrary works. We have that desire, but we agree that it isn't currently met, and it doesn't impact freeness. So let's think about *extension* rather than combination. Can I extend work X and have it be a piece of free software? Any free software license must meet that test. The GFDL does not meet that test. There is no double standard, because you have misconstrued the standard. The standard is NOT whether X meets: For all works A, A can be combined with X and still be free. If that were our test, it would be inconsistent to be bothered that the GFDL fails, since of course most free software licenses fail. We are concerned with whether X meets: There exists a work A of free software, such that A can be combined with X and still be free software. It is this test which the GFDL fails, and it fails not because it has terms which happen to be inconsistent with this or that free software license, but rather because it contains terms which are fundamentally inimical to the very concept of free software itself. It might be sensible not to care about this if documentation and programs were radically different things, but they simply are not. Thomas
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: Your casual suggestion to pick whichever seems better leaves out the object: better for whom? For the Free Software community? For the Free Software Foundation, whose goals are quite different? That is a cheap shot, because it reflects only your decision to be nasty. I could make the same kind of cheap shot by saying Better for whom? For the Free Software community? Or for Debian, whose goals are quite different? I choose not to do this, but others do it to me. It's not a cheap shot. It's a serious question: Whose goals are we going to consider? You once told me that you would frequently read only the beginning of email messages, and ignore the rest as soon as you saw something you didn't like. I think you did that here. Brian went on to expalin carefully just what he meant, and to explain why having different interests here was not a bad thing.
Re: Unidentified subject!
On Wed, 2003-09-24 at 20:17, Thomas Bushnell, BSG wrote: Here's the test. I want to write a brand new program. I insist it be free software, but I am otherwise entirely agnostic about which free software license I use. I will use any license. I want to incorporate parts of a GFDL'd manual into this new program. I've read the above several times, and as far as I can tell, it's a very, very, long way of saying the GFDL is not a free software license, and contains no conversion clause to one. signature.asc Description: This is a digitally signed message part
Re: Unidentified subject!
1) Because the borders between the cases are ambiguous and uncertain. I sent a message a day or two ago (perhaps after you sent this one) which addresses that issue. 2) Because we want to be able to combine works from different sources, As I explained, this desire is usually impossible due to incompatibility of licenses. To reject the GFDL on these grounds and accept some other GPL-incompatible license is a double standard. and something covered by the GFDL cannot be combined with ANY program to produce a work of free software. By now you've seen my response to that point.
Re: Unidentified subject!
Your casual suggestion to pick whichever seems better leaves out the object: better for whom? For the Free Software community? For the Free Software Foundation, whose goals are quite different? That is a cheap shot, because it reflects only your decision to be nasty. I could make the same kind of cheap shot by saying Better for whom? For the Free Software community? Or for Debian, whose goals are quite different? I choose not to do this, but others do it to me. (Frankly, I didn't even think about better for whom. I certainly didn't imagine it meant Better for the FSF. In the FSF we avoid these gray areas, so we would never be the ones deciding.) The Free Software Foundation built the free software community, years before Debian was started, using the same policies that you are criticizing now. That doesn't mean you have to agree with our policies, but it makes your cheap shot even cheaper. Cheap shots like this are another reason why I have decided not to discuss the matter further.
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: 1) Because the borders between the cases are ambiguous and uncertain. I sent a message a day or two ago (perhaps after you sent this one) which addresses that issue. By saying everything has ambiguous and uncertain borders. But hey! We don't need a border at all here! We can ENTIRELY AVOID the problem. Why should we accept it then? 2) Because we want to be able to combine works from different sources, As I explained, this desire is usually impossible due to incompatibility of licenses. To reject the GFDL on these grounds and accept some other GPL-incompatible license is a double standard. We reject the GFDL because it is not merely incomptability of licenses. Here's the test. I want to write a brand new program. I insist it be free software, but I am otherwise entirely agnostic about which free software license I use. I will use any license. I want to incorporate parts of a GFDL'd manual into this new program. I am not going to incorporate any other previously written bits from any source. What license should I use for my program? This is not a case of incompatibility.
Re: Unidentified subject!
Thomas Bushnell, BSG wrote: We reject the GFDL because it is not merely incomptability of licenses. Here's the test. I want to write a brand new program. I insist it be free software, but I am otherwise entirely agnostic about which free software license I use. I will use any license. I want to incorporate parts of a GFDL'd manual into this new program. I am not going to incorporate any other previously written bits from any source. For instance, I'm writing a new self-documenting make program (I was actually in the process of doing this at one point, although it's been suspended for a while). It uses very different algorithms from existing 'make's (so doesn't benefit from other 'make's code). But it would benefit greatly from lifting portions of the GNU Make manual for documentation. What license should I use for my program? This is not a case of incompatibility.
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: You've asked me to explain why the criteria for free documentation licenses should be different from free software licenses (or, as you would perhaps put it, free computer program licenses). I would rather ask why they should be the same, since they deal with different situations. A fair question. Some answers: 1) Because the borders between the cases are ambiguous and uncertain. 2) Because we want to be able to combine works from different sources, and something covered by the GFDL cannot be combined with ANY program to produce a work of free software.
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: Your casual suggestion to pick whichever seems better leaves out the object: better for whom? For the Free Software community? For the Free Software Foundation, whose goals are quite different? That is a cheap shot, because it reflects only your decision to be nasty. Excuse me? I've been trying to conduct a polite conversation. I certainly haven't made a decision to be nasty or started taking cheap shots: the FSF's goals are indisputably different from those of the members of the Free Software community. The FSF's goals are its attempt to fulfill the *best interests* of the community -- this is one of the best arguments for the GPL and copyright assignment to the FSF, that it will work towards the long-term interests of Freedom, not for the wants and goals of the current members of the community. I could make the same kind of cheap shot by saying Better for whom? For the Free Software community? Or for Debian, whose goals are quite different? And certainly, Debian's goals are different from those of the FS community: Debian's goals are its users *and* Free Software. I choose not to do this, but others do it to me. You have done this several times in this thread. For example: The Free Software Foundation built the free software community, years before Debian was started, This is at least much of a nasty cheap shot as what I said. And you've done it before. The FSF has done wonderful things for the Free Software community, but it is false to claim it had sole responsibility for the community. (Frankly, I didn't even think about better for whom. I certainly didn't imagine it meant Better for the FSF. In the FSF we avoid these gray areas, so we would never be the ones deciding.) You mean you *ignore* those gray areas. As a reminder, we're talking about gray areas between program and documentation. The emacs manual contains both. TeX is both. The FSF has signed off on both as being Free -- one as documentation alone, the other as software alone. Debian avoids those grey areas by insisting everything be treated as software: it's not a perfect approach, but it gets the abstract philosophy out of the way and gives more time for producing a Free OS. It's the FSF, not Debian, which has chosen to introduce a classification system, separating Software from Documentation. Many of those on this list have asked about your reasons for doing so, and we've never gotten a clear response -- some allusions to convenience for printers, I think, and that's all. But given you've defined this split, and you want Debian to follow your lead in this, it seems only reasonable for you to provide a good guideline... telling us that *we* should pick whichever seems better doesn't help much with that, so your suggestion that Debian permit restrictions on documentation which it would not permit for software is so far unconvincing. Cheap shots like this are another reason why I have decided not to discuss the matter further. Wonderful to hear. Debian's pulled its too-passionate-to-talk-reasonably members off this discussion and sent in cooler heads; who will the FSF be sending to talk to Debian, now that you're too upset to continue? I dare not speak for even all the readers of debian-legal, but I for one am eager to continue discussing this with the FSF. -Brian
Why documentation and programs should be treated alike (was Re: Unidentified subject!)
RMS wote: For the sake of avoiding confusion, please note that I use software in the meaning I believe is standard, referring to computer programs only. This is not what I believe to be the standard meaning or the historically correct meaning, but thanks for avoiding confusion. The main difference between a program and documentation is that a program does something, while documentation is passive; By this argument, source code to a program (of the sort which must be compiled to run) is not a program. And can therefore, in your opinion be encumbered by unlimited numbers of Invariant Sections (presumably in 'mandatory comments') while remaining free, as long as they can be removed from the actual executable binary, I suppose. Correct? Furthermore, a manual in any markup format (LaTeX, HTML, info, texinfo) is not passive: it does something, namely generating the actual manual in the intended-to-read format (printed, visible on screen in 'info' or 'mozilla', etc.) So manuals in any markup format -- including all the GNU manuals -- are thus akin to programs, and should be judged by those criteria. Correct? This is far from a bright-line distinction. It's such a fuzzy distinction that's it's probably not useful at all. Another difference is that distribution of programs on paper is rare, and not an important case to consider, whereas distribution of documentation on paper is a very important case. OK, so this is an actual distinction. I will concede that the clauses which apply *only* to distribution of printed copies may be defensible in this way. Another difference is that the you can see the words of the text in the manual, whereas you cannot see the source code in the executable of a program. LaTeX markup vs. PostScript output? Some stuff in the source code is visible in the 'final' version; other stuff isn't. (Much the same is true with programs.) Not a real difference. For software, the danger is that the source won't be available at all. The same danger *does* exist for manuals. For instance, distributing only the postscript or 'dvi' version of a manual written in TeX. For manuals, there is a real danger that the source will be in a format that free software cannot read, and thus useless. The same danger *does* exist for programs, and happens often: a 'free' program written in an interpreted language with no free interpreter or translator is effectively non-free in exactly the same way. Yet there is no similar clause in the GPL. This is why we designed the requirement for transparent copies. Which is very poorly drafted (it seems to effectively prohibit any source format which is not hand-written in a text editor), but not a fundamental point of disagreement. Another difference is that DRM systems to stop people from accessing documents are a real threat to our freedom, and we need to try to push against them in any way we can. Not a difference. They're being applied to programs too. And from earlier in the message: I would rather ask why they should be the same, since they deal with different situations. I have explained this before, and I will repeat it. Programs and program documentation are inherently linked; transfer between them is essential and basic. Literate programming styles encourage documentation to be extracted directly from program source code, and documentation to be embedded directly in program source code. Even when this is not done, documentation on a computer routinely has source code which is compiled into an 'executable' version, just like programs. Every issue which has come up relating to freeness of programs has turned out to apply to documentation on a computer, and every issue relating to freeness of documentation on a computer has turned out to apply to programs. --Nathanael
Re: Unidentified subject!
RMS wrote: The GNU Project's motive for using invariant sections is not the issue here; that's a GNU Project decision, not a Debian decision. Out of curiosity, where *is* it the issue? As a GNU Project contributor who disapproves of GFDL Invariant Sections, and knowing quite a few other GNU Project contributors and members who feel the same way, where should we attempt to be heard so as to have some influence on the GNU Project as a whole? -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Unidentified subject!
MJ Ray [EMAIL PROTECTED] a tapoté : On 2003-09-21 23:33:41 +0100 Richard Stallman [EMAIL PROTECTED] wrote: Defining all these thing as software is a peculiar way to use the word. Not at all. It is the original and proper meaning, as far as I can tell. It seems to be a neologism created to cover all things stored in the computer, when the WW2-ish phrase stored program was not adequate. The first known use in print is John W Tukey in the January 1958 edition of American Mathematical Monthly, with a short and vague explanation as interpretive routines, compilers, and other aspects, contrasted with hardware. As with any neologism, it may have fuzzed a little, but the contrast with hardware is constant. And do you really think that every software (of your wide definition) you can have on computer is part of the Operating System? The goal of Debian is to provide an Operating System, isn't it? Apparently it's clear that Debian do not consider that his very own logo must be free software -- that's right, you do not need a logo at all to have a complete free operating system. If Debian already recognize that non-program software can be non-free without that being a problem, why refusing to include a documentation that include a non-program software (technical documentation is likely program)? Likewise, in the term Free Software Movement and Free Software Foundation, software refers specifically to computer programs. Our criteria for free software licenses concern licenses for computer programs. I am not familiar with the Free Software Movement organisation and can find no record of it. The Free Software Foundation uses an odd definition of software. Maybe because the software that must be included in a Free Software Operating System is mostly programs and documentation... You've asked me to explain why the criteria for free documentation licenses should be different from free software licenses (or, as you would perhaps put it, free computer program licenses). I would rather ask why they should be the same, since they deal with different situations. Why should they be different? The freedom to adapt other literary works is no less necessary than the freedom to adapt programs. I suspect we have opinions on that, if your views are similar to the other GNU project members who support FDL and have participated on this list. So, you recognize that in fact you want every literary works to be DFSG-compliant, software or not. It totally explains why you need a so broad definition of software. As a matter of fact, you are no longer discussing about an Operating System. -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Unidentified subject!
Mathieu On Mon, Sep 22, 2003 at 08:30:41AM +0200, Mathieu Roy wrote: MJ Ray [EMAIL PROTECTED] a tapoté : And do you really think that every software (of your wide definition) you can have on computer is part of the Operating System? The goal of Debian is to provide an Operating System, isn't it? The Social Contract is about producing the Debian system and other works that provide a useful platform for our users. The Operating System is just part of that work. Apparently it's clear that Debian do not consider that his very own logo must be free software -- that's right, you do not need a logo at all to have a complete free operating system. If Debian already recognize that non-program software can be non-free without that being a problem, why refusing to include a documentation that include a non-program software (technical documentation is likely program)? True, recent e-mails show that this is/was a problem. One that is being fixed by making the Debian logo a trademark. Maybe because the software that must be included in a Free Software Operating System is mostly programs and documentation... Agreed, but just and OS is a very limited beast. One needs applications to make the platform do real work. Thus the Debian system. So, you recognize that in fact you want every literary works to be DFSG-compliant, software or not. It totally explains why you need a so broad definition of software. Yes, wouldn't it be much nicer to live in a world where everything is free. As a matter of fact, you are no longer discussing about an Operating System. At last we agree. Steve -- disbar, n: As distinguished from some other bar. pgp2sF1EifJdn.pgp Description: PGP signature
Re: Unidentified subject!
On 2003-09-22 07:30:41 +0100 Mathieu Roy [EMAIL PROTECTED] wrote: And do you really think that every software (of your wide definition) you can have on computer is part of the Operating System? The goal of Debian is to provide an Operating System, isn't it? See http://www.uk.debian.org/intro/about#what Apparently it's clear that Debian do not consider that his very own logo must be free software Has Debian taken a decision on that? At least some developers think that having a non-DFSG-free logo is a bug, for similar reasons as those that mean having non-DFSG-free manuals is a bug. Maybe because the software that must be included in a Free Software Operating System is mostly programs and documentation... No auxiliary data files at all? Also, FSF do not consider documentation software. So, you recognize that in fact you want every literary works to be DFSG-compliant, software or not. This makes it sound as if this is a sudden admission on my part. It is not. I believe I have been fairly consistent on this point, even from before I was aware of the FSF. It totally explains why you need a so broad definition of software. It is not a broad definition of software, but a correct one. I encourage GNU to research the origins of the word. As a matter of fact, you are no longer discussing about an Operating System. This is hardly my fault. The previous article invited it. Maybe FDL fans should keep more tightly to the problem under discussion, but tangents are always occurring. If you feel we stray too far to be relevant, take it off-list, as I frequently do. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/
Re: Unidentified subject!
Steve Dobson [EMAIL PROTECTED] a tapoté : Mathieu On Mon, Sep 22, 2003 at 08:30:41AM +0200, Mathieu Roy wrote: MJ Ray [EMAIL PROTECTED] a tapoté : And do you really think that every software (of your wide definition) you can have on computer is part of the Operating System? The goal of Debian is to provide an Operating System, isn't it? The Social Contract is about producing the Debian system and other works that provide a useful platform for our users. The Operating System is just part of that work. I see it as the result of that work. So, you recognize that in fact you want every literary works to be DFSG-compliant, software or not. It totally explains why you need a so broad definition of software. Yes, wouldn't it be much nicer to live in a world where everything is free. I agree. But I feel free enough when I can redistribute as I will a political essay from someone else. If I feel a need to edit that essay, I just start writing my own essay, by quoting eventually the original one. And if I must quote almost all the original one, it means that I have no so many things to add and I would just make a commentary about it. I do not see any urgent freedom to protect here, apart the freedom to redistribute a document. Someone can grant anybody to modify his political essays, but I do not think that not giving this right is similar than forbidding anybody to access the code of a program, to modify it and redistribute it. -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Unidentified subject!
On 2003-09-22 10:38:18 +0100 Mathieu Roy [EMAIL PROTECTED] wrote: [...] I feel free enough when I can redistribute as I will a political essay from someone else. If I feel a need to edit that essay, I just start writing my own essay Some people feel the same about software in general. It is barely relevant, unless you want to make the case that Debian should not have any standard of freedom because it will never satisfy everyone.
Re: Unidentified subject!
MJ Ray [EMAIL PROTECTED] a tapoté : On 2003-09-22 10:38:18 +0100 Mathieu Roy [EMAIL PROTECTED] wrote: [...] I feel free enough when I can redistribute as I will a political essay from someone else. If I feel a need to edit that essay, I just start writing my own essay Some people feel the same about software in general. About programs do you mean? Well, when I read a text, I have all the means necessary to understand how the idea works. Not with a program unless I get the source. And rewriting an implementation is not at all likely rephrasing two words. -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Unidentified subject!
Le lun 22/09/2003 à 08:30, Mathieu Roy a écrit : Apparently it's clear that Debian do not consider that his very own logo must be free software -- that's right, you do not need a logo at all to have a complete free operating system. If Debian already recognize that non-program software can be non-free without that being a problem, why refusing to include a documentation that include a non-program software (technical documentation is likely program)? Can you read ? *WE DO NOT SHIP THE OFFICIAL DEBIAN LOGO WITHIN THE DEBIAN OPERATING SYSTEM.* And if you have problems with English: *LE LOGO OFFICIEL DEBIAN NE FAIT PAS PARTIE DU SYSTÈME D'EXPLOITATION DEBIAN.* The open use logo has another issue as its license needs a better wording, but almost everyone on this list will agree that it needs to be clarified. And you should note that while SPI is ready to change its licensing to keep the open use logo in main (AND NOT THE OFFICIAL DEBIAN LOGO WHICH HAS NOTHING TO DO WITH THE DEBIAN OPERATING SYSTEM), the FSF doesn't seem to be willing to do such things. Nobody here is asking the FSF to make the political statements on their website DFSG-free. We are explaining that all parts of the Debian operating system, including documentations (BUT NOT THE OFFICIAL DEBIAN LOGO WHICH IS NOT PART OF THE DEBIAN OPERATING SYSTEM), must be DFSG-free. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Unidentified subject!
Mathieu Roy wrote: Well, when I read a text, I have all the means necessary to understand how the idea works. Not with a program unless I get the source. We consider even trivial software such as Hello world to be worthy of Freeness, even though in this case you have everything necessary to understand how the idea works without the source. But fundamentally, you do not appear to believe that the ability to make derived works from philosophical texts (or various other things) is a necessity - Debian seems to. The sheer number of postings you have made should have made it clear that you are not going to change our opinions, and we are not going to change yours. Further discussion of this seems fairly pointless. Can we just agree to differ? -- Matthew Garrett | [EMAIL PROTECTED]
Re: Unidentified subject!
On Mon, Sep 22, 2003 at 09:10:07AM +0100, MJ Ray wrote: On 2003-09-22 07:30:41 +0100 Mathieu Roy [EMAIL PROTECTED] wrote: And do you really think that every software (of your wide definition) you can have on computer is part of the Operating System? The goal of Debian is to provide an Operating System, isn't it? See http://www.uk.debian.org/intro/about#what Apparently it's clear that Debian do not consider that his very own logo must be free software Has Debian taken a decision on that? Yes. http://www.debian.org/vote/1999/vote_0002 Also see: http://www.debian.org/vote/1999/vote_0005 (Please forgive Darren Benham's inability to spell the word dual.) -- G. Branden Robinson| The more ridiculous a belief Debian GNU/Linux | system, the higher the probability [EMAIL PROTECTED] | of its success. http://people.debian.org/~branden/ | -- Wayne R. Bartz signature.asc Description: Digital signature
Re: Unidentified subject!
None of these differences correctly classifies Hello as both a program and documentation, as far as I can tell. Hello is an example program. It is difficult to deal with such grey areas and I assume that it requires a case-by-case review. I have never found it difficult. When it's hard to decide, neither choice is really wrong, so pick whichever seems better.
Re: Unidentified subject!
On 2003-09-22 18:10:18 +0100 Branden Robinson [EMAIL PROTECTED] wrote: http://www.debian.org/vote/1999/vote_0002 Interesting. Did anyone spot that it seems not to meet DFSG? A casual search with vote;logo;dfsg of vote/legal/devel/user/project/policy returns no matches for the quarter containing April 1999.
Re: Unidentified subject!
Mathieu On Mon, Sep 22, 2003 at 11:38:18AM +0200, Mathieu Roy wrote: Steve Dobson [EMAIL PROTECTED] a tapoté : The Social Contract is about producing the Debian system and other works that provide a useful platform for our users. The Operating System is just part of that work. I see it as the result of that work. But an operating system is defined by the Oxford English Dictionary as the lowest level software that supports a computer's basic functions, such as scheduling tasks and controlling peripherals. Now the Debian System contains more than just low level system software like Apache, TeX, and XFree86. While these packages are important there are not necessary. There for the Debian System is more than an OS. Yes, wouldn't it be much nicer to live in a world where everything is free. I agree. But I feel free enough when I can redistribute as I will a political essay from someone else. If I feel a need to edit that essay, I just start writing my own essay, by quoting eventually the original one. And if I must quote almost all the original one, it means that I have no so many things to add and I would just make a commentary about it. Agreed. I do not see any urgent freedom to protect here, apart the freedom to redistribute a document. Maybe you do not, but others, in different circumstances, may. Someone can grant anybody to modify his political essays, but I do not think that not giving this right is similar than forbidding anybody to access the code of a program, to modify it and redistribute it. I do not claim that both are similar. What I, and others in Debian judging from this list, are saying is that to restrict documentation is this way does not make it 100% free. Being 100% free is a requirement of the Debian Social Contract #4. Steve -- You will wish you hadn't. pgpQ0KN9ugT96.pgp Description: PGP signature
Re: Unidentified subject!
On 2003-09-22 12:34:27 +0100 Mathieu Roy [EMAIL PROTECTED] wrote: Well, when I read a text, I have all the means necessary to understand how the idea works. Not with a program unless I get the source. It depends on the program, but if you have the source, you do not feel that you need to the freedom to modify it? And rewriting an implementation is not at all likely rephrasing two words. It's not that different either.
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: None of these differences correctly classifies Hello as both a program and documentation, as far as I can tell. Hello is an example program. Yes... and thus both program and documentation. It is difficult to deal with such grey areas and I assume that it requires a case-by-case review. I have never found it difficult. When it's hard to decide, neither choice is really wrong, so pick whichever seems better. TeX is both program and documentation, as are essentially all literate programs. Entries to the various Obfuscated Programming Contests are both program and documentation. These are all gray areas... and more importantly, are members of *both* the set of programs and the set of documentation. So *either* choice is wrong. It is more correct to say that all of these are software (i.e. non-hardware), and we should make sure that all software is free. Your casual suggestion to pick whichever seems better leaves out the object: better for whom? For the Free Software community? For the Free Software Foundation, whose goals are quite different? Debian has to answer: For the Debian Users and for Free Software. -Brian
Re: Unidentified subject!
On Sun, 2003-09-21 at 18:33, Richard Stallman wrote: If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, could indeed be read differently than the GPL. I think the FSF was thinking book in a book store here, not FTP site or table at a Linux convention. I'm not sure what the scenario is, or what the perceived problem is. The perceived problem is this: Let's say I want to put a GFDL document on my FTP site, in an opaque form. My FTP site is popular, so it will distribute copies numbering more than 100. I think its reasonable that if I just put a transparent form alongside the PDF, that should be all I have to do. Instead, the GFDL seems to read that I must somehow include a machine-readble Transparent copy (i.e., not allow the opaque form to be downloaded without the tansparent form) or keep the transparent form available for (forgive me if I'm mistaken about the time) one year. Basically, the problem is if the answer to this question from the GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html#HowCanIMakeSureEachDownloadGetsSource applies to the GFDL as well. signature.asc Description: This is a digitally signed message part
Re: Unidentified subject!
On Saturday, Sep 20, 2003, at 01:14 US/Eastern, Brian T. Sniffen wrote: Anthony DeRobertis [EMAIL PROTECTED] writes: I'm curious: Considering the GPL prohibits binary-only distribution under section 3, do you still hold that position? GPL 3b and 3c deal with that quite nicely. Debian, for example, distributes its GPL'd software by offering the source on the same medium. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, could indeed be read differently than the GPL. I think the FSF was thinking book in a book store here, not FTP site or table at a Linux convention. I hope the FSF (RMS cc'd) is willing to make a minor change to this wording to make it clear that if you offer a machine-readable Transparent copy, but your offer is declined, then that's fine.
Re: Unidentified subject!
Manuals, essays, licenses, and logos *encoded as bits on a computer* are software. Defining all these thing as software is a peculiar way to use the word. I don't think that is the best way to interpret the DFSG, because it leads to unnecessary inflexibility. I do not try to tell the Debian developers how to make this decision about interpreting the DFSG. My point is that it is a decision, and that it goes contrary to the words of article 4 of the DFSG, which seems to treat software as equivalent to programs. For the sake of avoiding confusion, please note that I use software in the meaning I believe is standard, referring to computer programs only. A software package, to be useful, needs to come with other things--manuals, licenses, and sometimes essays and scientific papers--but they are not the software. Likewise, in the term Free Software Movement and Free Software Foundation, software refers specifically to computer programs. Our criteria for free software licenses concern licenses for computer programs. You've asked me to explain why the criteria for free documentation licenses should be different from free software licenses (or, as you would perhaps put it, free computer program licenses). I would rather ask why they should be the same, since they deal with different situations. If you reinterpret the DFSG's words by defining software to include manuals, you are forced to treat them alike. In the GNU Project we don't define manuals as software, so we have no a priori reason to treat them alike. The main difference between a program and documentation is that a program does something, while documentation is passive; you look at it. Another difference is that distribution of programs on paper is rare, and not an important case to consider, whereas distribution of documentation on paper is a very important case. Another difference is that the you can see the words of the text in the manual, whereas you cannot see the source code in the executable of a program. For software, the danger is that the source won't be available at all. For manuals, there is a real danger that the source will be in a format that free software cannot read, and thus useless. This is why we designed the requirement for transparent copies. Another difference is that DRM systems to stop people from accessing documents are a real threat to our freedom, and we need to try to push against them in any way we can. Another difference is that DRM
Re: Unidentified subject!
I'm curious: Considering the GPL prohibits binary-only distribution under section 3, do you still hold that position? GPL 3b and 3c deal with that quite nicely. Debian, for example, distributes its GPL'd software by offering the source on the same medium. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, could indeed be read differently than the GPL. I think the FSF was thinking book in a book store here, not FTP site or table at a Linux convention. I hope the FSF (RMS cc'd) is willing to make a minor change to this wording to make it clear that if you offer a machine-readable Transparent copy, but your offer is declined, then that's fine. I'm not sure what the scenario is, or what the perceived problem is.
Re: Unidentified subject!
RMS On Sun, Sep 21, 2003 at 06:33:41PM -0400, Richard Stallman wrote: Manuals, essays, licenses, and logos *encoded as bits on a computer* are software. Defining all these thing as software is a peculiar way to use the word. I don't think that is the best way to interpret the DFSG, because it leads to unnecessary inflexibility. I do not try to tell the Debian developers how to make this decision about interpreting the DFSG. My point is that it is a decision, and that it goes contrary to the words of article 4 of the DFSG, which seems to treat software as equivalent to programs. My New Little Oxford Dictionary defines software as computer programs. Not much help but it is only a pocket dictionary. A quick search on the Net [1] turned up a longer, but basically similar definition form the American Heritage Dictionary. Princeton University's WordNet defines software as written programs or procedures or rules and associated documentation pertaining to the operation of a computer system and that are stored in read/write memory. As a *nix system can mmap(2) the CDROM content into memory then documentation can be software. The Free On-line Dictionary of Computing has much more to say on the subject and while it is not common usage it does allow that documentation (both paper and electronic) is also software. While you may not use the term software in this way the DFSG is _not_ breaking the rules of English by using the wider meaning. Steve [1] http://dictionary.reference.com/search?q=software -- White dwarf seeks red giant for binary relationship. pgpramSlBbX0v.pgp Description: PGP signature
Re: Unidentified subject!
On 2003-09-21 23:33:41 +0100 Richard Stallman [EMAIL PROTECTED] wrote: Defining all these thing as software is a peculiar way to use the word. Not at all. It is the original and proper meaning, as far as I can tell. It seems to be a neologism created to cover all things stored in the computer, when the WW2-ish phrase stored program was not adequate. The first known use in print is John W Tukey in the January 1958 edition of American Mathematical Monthly, with a short and vague explanation as interpretive routines, compilers, and other aspects, contrasted with hardware. As with any neologism, it may have fuzzed a little, but the contrast with hardware is constant. I don't think that is the best way to interpret the DFSG, because it leads to unnecessary inflexibility. That is your opinion and you are entitled to it. Debian does not seem to want to make contradictory decisions on similar cases, so having an unambiguous public policy is desirable. I do not try to tell the Debian developers how to make this decision about interpreting the DFSG. Thank you. Your respect is noted. My point is that it is a decision, and that it goes contrary to the words of article 4 of the DFSG, which seems to treat software as equivalent to programs. There is no article 4 of the DFSG. Maybe you mean DFSG 4? That says Integrity of The Author's Source Code and then has an explanation which uses a program as an example. As you no doubt appreciate, programs are the most obvious example of software compiled from source code and it is only natural to use it in the explanation. For the sake of avoiding confusion, please note that I use software in the meaning I believe is standard, referring to computer programs only. That is your belief but not one shared by many on this list or the authors of the DFSG and Debian Social Contract, as far as we can tell. Likewise, in the term Free Software Movement and Free Software Foundation, software refers specifically to computer programs. Our criteria for free software licenses concern licenses for computer programs. I am not familiar with the Free Software Movement organisation and can find no record of it. The Free Software Foundation uses an odd definition of software. You've asked me to explain why the criteria for free documentation licenses should be different from free software licenses (or, as you would perhaps put it, free computer program licenses). I would rather ask why they should be the same, since they deal with different situations. Why should they be different? The freedom to adapt other literary works is no less necessary than the freedom to adapt programs. I suspect we have opinions on that, if your views are similar to the other GNU project members who support FDL and have participated on this list. If you reinterpret the DFSG's words by defining software to include manuals, you are forced to treat them alike. This is not a reinterpretation. According to the authors who have discussed it, this is the original interpretation. It should not be a surprise to anyone. The main difference between a program and documentation is that a program does something, while documentation is passive; you look at it. Another difference is that distribution of programs on paper is rare, and not an important case to consider, whereas distribution of documentation on paper is a very important case. Another difference is that the you can see the words of the text in the manual, whereas you cannot see the source code in the executable of a program. For software, the danger is that the source won't be available at all. For manuals, there is a real danger that the source will be in a format that free software cannot read, and thus useless. This is why we designed the requirement for transparent copies. Another difference is that DRM systems to stop people from accessing documents are a real threat to our freedom, and we need to try to push against them in any way we can. None of these differences correctly classifies Hello as both a program and documentation, as far as I can tell. I suspect the other edge cases mentioned would also cause problems for this. It is difficult to deal with such grey areas and I assume that it requires a case-by-case review. Fortunately, Debian is spared that by requiring a common standard of freedom for all software in the operating system. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/
Re: Unidentified subject!
Anthony DeRobertis [EMAIL PROTECTED] writes: On Friday, Sep 19, 2003, at 19:43 US/Eastern, Brian T. Sniffen wrote: I, um, think he meant me, given I *did* say there is a violation of DFSG 2, since binary-only distribution is not permitted. Ah! Yeah, that must be what I meant... I'm curious: Considering the GPL prohibits binary-only distribution under section 3, do you still hold that position? GPL 3b and 3c deal with that quite nicely. Debian, for example, distributes its GPL'd software by offering the source on the same medium. -Brian
Re: Unidentified subject!
Richard Stallman wrote: Yes. Debian will remain 100% free software. That's the first line of the Debian Social Contract. This means that everything in Debian must be free *software*. That is one possible interpretation, but since it is based on asserting that manuals, essays, licenses, and logos are software, I think it is not the proper one. We hope to show you the error of your ways. ;-) I think the text was written without regard to the presence of material other than software in the distribution, and it ought to be interpreted in that light. Bruce Perens has clarified that the DFSG was intended to apply to everything on the Debian CD. I don't think you're right about this. It has been made clear *many* times that the interpretation of software generally used here is the part of the computer which is not hardware. This is the original and more accurate meaning of software. Manuals, essays, licenses, and logos *encoded as bits on a computer* are software. A carving of a program on a stone tablet is not software. Accordingly there is nothing in the Debian distribution which is not software. But let us suppose, for the sake of argument, that we accept your interpretation. I still see no reason to believe that documentation should be treated differently from programs with regard to freedom. Several good reasons have been given to treat it exactly the same way, many related to the difficulty of separating documentation entirely from programs, and the desirability of not separating it. If you really have good, specific reasons to treat it differently in such a way that Invariant Sections are OK for documentation and not for programs, do tell; I haven't heard any.
Re: Unidentified subject!
Anthony DeRobertis [EMAIL PROTECTED] wrote: On Thu, 2003-09-18 at 16:05, Walter Landry wrote: The definition of transparent is similar to, but not the same as source. For example, the source for a LyX document is not transparent. I understand that; in fact, I was one of the many people who pointed out that problem. But that's not what Brian said --- he said that there is a violation of DFSG 2 since it does not permit 'distribution in source code as well as compiled form'. That's what I'd like a clarification of. I see what you're saying. Yes, Debian is allowed to distribute the source to GFDL'd licenses, as long as Debian has a transparent version as well. If Debian doesn't have a transparent version, then it can't distribute it at all. So DFSG #2 doesn't really come into play. It is more DFSG #1, because Debian can't distribute it at all, and DFSG #3, because modifications may make the result undistributable. Regards, Walter Landry [EMAIL PROTECTED]
Re: Unidentified subject!
Anthony DeRobertis [EMAIL PROTECTED] writes: On Thursday, Sep 18, 2003, at 11:24 US/Eastern, Brian T. Sniffen wrote: Also, the requirement to distribute a transparent form appears to violate DFSG 2, since it does not permit distribution in source code as well as compiled form. Brian, I'm not sure how that follows. Could you elaborate? AFAICT, the requirement to distribute in transparent, e.g., source, form is quite similar to the requirement from the GPL, version 2, which we all consider free (per DFSG 10, if nothing else). The GPL allows me to distribute *just* a binary, with the requirement that I offer the source as well. It also allows me to offer just source. The GFDL does not allow me to distribute *just* a non-Transparent form. -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Unidentified subject!
On Thu, 2003-09-18 at 12:05, Richard Stallman wrote: That is why I recently asked to hear from Debian developers whether they are still making up their minds about the matter and whether they are interested in what I have to say about it. If this is generally not the case, I will stop discussing the issue here. I am not interested in beating a dead horse. From this can we assume that your position is as follows: 1) You are willing to try and convince Debian that the GFDL is either DFSG free, or that the DFSG need not apply to certain aspects of the GFDL. 2) You are unwilling to modify the GFDL, for example by allowing the removal of Invariant sections if the document title was changed, to ensure the licence is DFSG free in the eyes of Debian. If I've misinterpreted, could you indicate in what ways you would be willing to discuss modification of the GFDL to accommodate those with a strict reading of the DFSG? I'm also somewhat assuming that your position and the FSF's position are the same; if this is not the case, is there anyone else at the FSF who would be willing to join in? Many thanks in advance, Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Unidentified subject!
Anthony DeRobertis writes: I understand that; in fact, I was one of the many people who pointed out that problem. But that's not what Brian said --- he said that there is a violation of DFSG 2 since it does not permit 'distribution in source code as well as compiled form'. That's what I'd like a clarification of. Actually, if you look at my original message again, I was quoting another list member there. I chose to quote him because I wasn't sure I understood what he was talking about either! For further clarification we may have to go back to the original source. (Sounds appropriate given the topic... ;) Brian
Re: Unidentified subject!
Brian W. Carver [EMAIL PROTECTED] writes: Anthony DeRobertis writes: I understand that; in fact, I was one of the many people who pointed out that problem. But that's not what Brian said --- he said that there is a violation of DFSG 2 since it does not permit 'distribution in source code as well as compiled form'. That's what I'd like a clarification of. Actually, if you look at my original message again, I was quoting another list member there. I chose to quote him because I wasn't sure I understood what he was talking about either! For further clarification we may have to go back to the original source. (Sounds appropriate given the topic... ;) Brian -- I, um, think he meant me, given I *did* say there is a violation of DFSG 2, since binary-only distribution is not permitted. -Brian
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: The GNU Project's motive for using invariant sections is not the issue here; that's a GNU Project decision, not a Debian decision. You are arguing that you should have a voice in what Debian does. I have said nothing of the kind. The Debian developers decide what Debian does, and I recognize that. I am only offering arguments to convince them. Why should we listen to your arguments to convince us if you will not listen to our arguments trying to convince you?
Re: Unidentified subject!
On Friday, Sep 19, 2003, at 19:43 US/Eastern, Brian T. Sniffen wrote: I, um, think he meant me, given I *did* say there is a violation of DFSG 2, since binary-only distribution is not permitted. Ah! Yeah, that must be what I meant... I'm curious: Considering the GPL prohibits binary-only distribution under section 3, do you still hold that position?
Re: Unidentified subject!
On 2003-09-17 20:34:13 +0100 Brian W. Carver [EMAIL PROTECTED] wrote: That's good to hear. Of course another related concern is forward-looking. It is a terrible waste of scare resources to have Debian create a DFSG-free manual every time a GFDL-licensed manual is produced for some new piece of software. [...] Analogously, it may be considered a terrible waste of scarce resources to produce free software manuals when proprietary manuals (such as most of the ORA books) exist, but we do it anyway. Debian is committed to providing its users with 100% free software. If authors and publishers wish to produce manuals that are not free software, then we can ask them to reconsider, but ultimately we cannot include them. We do not necessarily have to have Debian produce manuals itself. We need to encourage wider development of free software manuals. Suggestions (probably off-list) on how to do that are welcome. The publisher of a significant number of manuals has apparently decided to produce manuals that are not free software and seems not to want to make them free software, and I don't see that how there will be sufficient common ground to change that basic problem. It's a shame, definitely, but it always was when others did it too. -- MJR/slef My Opinion Only and possibly not of any group I know.
Re: Unidentified subject!
The GNU Project's motive for using invariant sections is not the issue here; that's a GNU Project decision, not a Debian decision. You are arguing that you should have a voice in what Debian does. I have said nothing of the kind. The Debian developers decide what Debian does, and I recognize that. I am only offering arguments to convince them. That is why I recently asked to hear from Debian developers whether they are still making up their minds about the matter and whether they are interested in what I have to say about it. If this is generally not the case, I will stop discussing the issue here. I am not interested in beating a dead horse.
Re: Unidentified subject!
You have mistaken the objection. There is no reason to think it would be a small fractional increase, especially since little parts of manuals--single paragraphs even--are useful reusable bits just in the way that single functions of Lisp are. Reusing a single paragraph is fair use--you don't need to follow the license conditions. This is not true if we are reusing all the paragraphs, by extensive reworking and reassembly. (Say, to manufacture doc strings.) You raised one scenario and I responded to that. Now you're saying my statement doesn't apply to a different scenario. It wasn't meant to. Let's not mix up different issues--that makes a discussion which doesn't treat any issue thoughtfully.
Re: Unidentified subject!
The argument for that is that there are many such manuals and they would be useful to include, and the DFSG can be interpreted to accept it. The arguments appear to be: 1) There are many GFDL manuals. 2) The many GFDL manuals would be useful to include. That's two parts out of the three I mentioned, and the third part is crucial. The DFSG doesn't directly say anything against the requirements of the GFDL. I sent another longer message explaining why.
Re: Unidentified subject!
I couldn't believe that RMS actually wrote that when I read it. You shouldn't have believed I actually wrote that, because he misunderstood what I wrote. He omitted a crucial part of the argument, so that what remained was absurd; then he went on at length pointing out just how absurd it was.
Re: Unidentified subject!
On Thursday 18 September 2003 13:05, Richard Stallman wrote: I am not interested in beating a dead horse. You have been for at least a whole week. Please stop that. Thanks. Mike
Re: Unidentified subject!
The arguments appear to be: 1) There are many GFDL manuals. 2) The many GFDL manuals would be useful to include. That's two parts out of the three I mentioned, and the third part is crucial. But they are an irrelevant two parts. If Joe Blow writes a license for his program or documentation, it should get the same consideration under the DFSG as when the FSF does. The DFSG doesn't directly say anything against the requirements of the GFDL. Section 3 says The license must allow modifications and derived works[...]; if that's ambiguous in any way about everything being modifiable, a note on section 4, talking about patch files, says The Debian group encourages all authors not to restrict any files, source or binary, from being modified.. Given the license discussions over the years, I think it fairly clear that everything must be modifiable -- your seperation of the technical and non-technical material shows up nowhere in the DFSG. The GFDL allows you to make any changes you like in the technical substance of the manual, just as the TeX license allows you to make any changes you like in the technical substance of TeX. The TeX license allows us to make any changes we like in the user-visible version of TeX. The GFDL doesn't. The DFSG says that we must have the right to modify everything, at least by the use of patch files. I cannot find that in the DFSG. That would be section 3, The license must allow modifications[...]. This text [section 4] is specifically about source code for programs, and specifically about licenses that entirely forbid modified versions of the source code. It is extremely specific and narrow. Okay, but section 4 is merely a weakening of section 3. If section 4 doesn't apply, then everything must be modifiable. If the GFDL doesn't fail the DFSG, then neither does a manual license with the technical parts invariant and political parts modifiable; the DFSG simply doesn't make that distinction. -- __ Sign-up for your own personalized E-mail at Mail.com http://www.mail.com/?sr=signup CareerBuilder.com has over 400,000 jobs. Be smarter about your job search http://corp.mail.com/careers
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: The argument for that is that there are many such manuals and they would be useful to include, and the DFSG can be interpreted to accept it. The arguments appear to be: 1) There are many GFDL manuals. 2) The many GFDL manuals would be useful to include. That's two parts out of the three I mentioned, and the third part is crucial. The DFSG doesn't directly say anything against the requirements of the GFDL. I sent another longer message explaining why. As a matter of fact, it does. The DFSG directly forbids Invariant Sections, which violate DFSG 4: the license restricts even source code (the transparent form) from being distributed in modified form. Additionally, because Invariant Sections must be Secondary, the GFDL's implementation violates DFSG 6. There is *no* work of free software which can be created as a derivative work of a GFDL-licensed manual with invariant sections. Also, the requirement to distribute a transparent form appears to violate DFSG 2, since it does not permit distribution in source code as well as compiled form. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: Unidentified subject!
On Thursday, Sep 18, 2003, at 11:24 US/Eastern, Brian T. Sniffen wrote: Also, the requirement to distribute a transparent form appears to violate DFSG 2, since it does not permit distribution in source code as well as compiled form. Brian, I'm not sure how that follows. Could you elaborate? AFAICT, the requirement to distribute in transparent, e.g., source, form is quite similar to the requirement from the GPL, version 2, which we all consider free (per DFSG 10, if nothing else).
Re: Unidentified subject!
Anthony DeRobertis [EMAIL PROTECTED] writes: On Thursday, Sep 18, 2003, at 11:24 US/Eastern, Brian T. Sniffen wrote: Also, the requirement to distribute a transparent form appears to violate DFSG 2, since it does not permit distribution in source code as well as compiled form. Brian, I'm not sure how that follows. Could you elaborate? AFAICT, the requirement to distribute in transparent, e.g., source, form is quite similar to the requirement from the GPL, version 2, which we all consider free (per DFSG 10, if nothing else). The only problem with transparent versions I'm aware of is that they way they're defined there may not be any such thing[1]. Fortunately, the only thing you need a transparent version for (that I saw) is section 3 (distributing in bulk). The other references to transparent versions generally have an if available caveat. So the upshot, I guess, is that you can't always distribute a GFDL'd document in bulk. Clearly enough to make the GFDL non-DFSG-free, but I doubt this is intentional on the FSF's part. [1] For example, if you make substantial modifications using a word processor like lyx or OpenOffice (or ms-word, for that matter) that doesn't have a human-readable save format, there will not be a transparent version of the new document. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Unidentified subject!
Anthony DeRobertis [EMAIL PROTECTED] wrote: On Thursday, Sep 18, 2003, at 11:24 US/Eastern, Brian T. Sniffen wrote: Also, the requirement to distribute a transparent form appears to violate DFSG 2, since it does not permit distribution in source code as well as compiled form. Brian, I'm not sure how that follows. Could you elaborate? AFAICT, the requirement to distribute in transparent, e.g., source, form is quite similar to the requirement from the GPL, version 2, which we all consider free (per DFSG 10, if nothing else). The definition of transparent is similar to, but not the same as source. For example, the source for a LyX document is not transparent. Regards, Walter Landry [EMAIL PROTECTED]
Re: Unidentified subject!
On Thu, 2003-09-18 at 16:05, Walter Landry wrote: The definition of transparent is similar to, but not the same as source. For example, the source for a LyX document is not transparent. I understand that; in fact, I was one of the many people who pointed out that problem. But that's not what Brian said --- he said that there is a violation of DFSG 2 since it does not permit 'distribution in source code as well as compiled form'. That's what I'd like a clarification of. signature.asc Description: This is a digitally signed message part
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: For example, I might use a manual by tearing it into pieces and using the individual pages as confetti for a parade. But I cannot copy GFDL'd manuals and then do this. I congratulate you on your imagination--it never occurred to me to think about this as a use of a manual. As it happens, you are free to do that, because copyright does not cover tearing up a manual. You don't need a license to give you permission to do that. No no, I cannot *copy* the manuals and then distribute them this way. Yes, there are gray areas where it is hard to decide. I had to think for months about whether the TeX license qualified as free, since it makes the whole of the original TeX source code invariant. And I had to think for weeks about a LaTeX license, that required changing the name of any file that you modify. I eventually concluded that LaTeX was free despite this requirement, but only because it has a remapping feature that lets you say Use file myfoo.sty when the document asks for foo.sty. We have come to basically exactly the same conclusion about these cases. The GFDL does not allow for this. Debian has a way of answering that question: but our way, which involves the DFSG, would say that send $1 to the author for permission to make changes is wrong for the same reasons that send $1 to the author for permission to make copies, and is wrong for the same reason that we think that invariant sections are wrong. The DFSG doesn't say anything about invariant sections; you're assuming a very strict interpretation. You're also assuming that the DFSG should be applied to manuals as well as software, and that the interpretation should be the same. The DFSG says that we must have the right to modify everything, at least by the use of patch files.
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: The principal argument in favor of the GFDL seems to be this is the only way we can get our message out. The GNU Project's motive for using invariant sections is not the issue here; that's a GNU Project decision, not a Debian decision. You are arguing that you should have a voice in what Debian does. It seems only fair to allow that Debian should have a voice in what the GNU Project does. Regardless, I am a part of the GNU Project. Shall we take a poll to see whether the GNU Project agrees with your goals here? The question at hand is whether Debian should accept or reject GFDL-covered manuals. The argument for that is that there are many such manuals and they would be useful to include, and the DFSG can be interpreted to accept it. This is the same argument that non-free software producers give us all the time. Thomas
Re: Unidentified subject!
Richard Stallman wrote: The question at hand is whether Debian should accept or reject GFDL-covered manuals. The argument for that is that there are many such manuals and they would be useful to include, and the DFSG can be interpreted to accept it. As one of those more inclined to listen to the rationale behind the GFDL, and as one who still leaves open the possibility that the DFSG might allow for something very much like the GFDL, I certainly hope that you do not intend the above to be an exhaustive list of the arguments in favor of including GFDL-licensed manuals in Debian. The arguments appear to be: 1) There are many GFDL manuals. 2) The many GFDL manuals would be useful to include. Obviously Debian (and the FSF) would not accept such arguments in other contexts. For instance, one would not make much headway in either circle regarding the inclusion of proprietary software by arguing either of: 1) There are many proprietary software programs. 2) The many proprietary software programs would be useful to include. It is obviously a great inconvenience to replace all the GFDL manuals with new manuals licensed in a DFSG-consistent way. I doubt anyone here disputes that. (If they do, they are welcome to write all the replacement manuals and report back when they are done.) But what we must find is an argument that clearly demonstrates why the GFDL should be seen as consistent with the DFSG. Part of such a demonstration might include an explanation of the many tough decisions that the FSF had to make when drafting the GFDL, and the rationales behind each part. With a greater understanding of these tough issues, Debian developers might say, Wow. They're right. That is a tough issue to deal with and we cannot think of any better way to write a license to deal with that problem. Hmmm, perhaps the GFDL is as free as we can get regarding this issue. If instead Debian developers say, No. We don't think that is the best licensing solution to the problem you describe. What if instead the license said XYZ? Then we are now making progress toward drafting an improved version of the GFDL that just might please everyone. Collaborating in such a way is not easy, and I'll admit that few here have demonstrated the will to keep their egos/tempers reigned in long enough to have such a fruitful discussion. Perhaps that is where Bruce Perens' efforts will be helpful. But, I earnestly believe that if you took the parts of the GFDL that list members have pointed out as particularly egregious and described in detail what you were trying to accomplish and why the current version of the GFDL seems/seemed to you the best way to accomplish that, then at least some list readers would have one of the above reactions described and progress toward common ground could begin to be reached. If I remember the list's complaints well enough, some key areas to address would be: 1) Invariant sections (a) Why have them? (b) Why have each part of the license that deals with invariant sections be precisely as it is? Could there be another way of meeting the goals stated in (a) above that would be agreeable to each group? 2) GPL Incompatibility (a) Why make the GFDL incompatible with the GPL? --Assumed a Yes answer to the question: --(i)Does the FSF agree that the GFDL is GPL-incompatible? 3) No DRM One of your previous messages to this list suggested to me that you might not have intended some of these problems and were looking into it. So, (a) What's the status of that? 4) Transparent and Opaque Copies Jeremy Hankins wrote: Under certain circumstances the document may not have a transparent version (for example, after being modified with a proprietary word processor). This would make it impossible to meet the requirements of section 3 (Copying in quantity) of the GFDL. (a) Did the FSF intend this effect? (b) What changes to the license could both remove this problem and still be acceptable to the FSF? I think answers to these questions are critical if progress is to be made. If the FSF simply says, This is our license. Now it is solely up to you to include manuals licensed in this way or not. then I think it is pretty clear that the consensus here will not favor the GFDL. This would be a shame both because of the enormous work it would create in replacing manuals, and because I still believe that with several tweaks to the GFDL many here would find it DFSG-consistent. -- Brian W. Carver -- http://rurnt.com/brian ,''`. Try a free operating system at http://www.debian.org : :' : Support EFF! http://www.eff.org `. `' They're defending YOUR rights online! `-
Re: Unidentified subject!
Brian C [EMAIL PROTECTED] wrote: Richard Stallman wrote: The question at hand is whether Debian should accept or reject GFDL-covered manuals. The argument for that is that there are many such manuals and they would be useful to include, and the DFSG can be interpreted to accept it. As one of those more inclined to listen to the rationale behind the GFDL, and as one who still leaves open the possibility that the DFSG might allow for something very much like the GFDL, I certainly hope that you do not intend the above to be an exhaustive list of the arguments in favor of including GFDL-licensed manuals in Debian. The arguments appear to be: 1) There are many GFDL manuals. 2) The many GFDL manuals would be useful to include. Obviously Debian (and the FSF) would not accept such arguments in other contexts. For instance, one would not make much headway in either circle regarding the inclusion of proprietary software by arguing either of: 1) There are many proprietary software programs. 2) The many proprietary software programs would be useful to include. I couldn't believe that RMS actually wrote that when I read it. Part of such a demonstration might include an explanation of the many tough decisions that the FSF had to make when drafting the GFDL, and the rationales behind each part. With a greater understanding of these tough issues, Debian developers might say, Wow. They're right. That is a tough issue to deal with and we cannot think of any better way to write a license to deal with that problem. Hmmm, perhaps the GFDL is as free as we can get regarding this issue. Which brings us back to: :The principal argument in favor of the GFDL seems to be this is the :only way we can get our message out. This is the only reason we were given so far as to why important freedoms must be given up in the GFDL. I for one don't believe that method of getting the message out to be consistent with the message (of freedom) itself. So I cannot be convinced to give up the freedom and still call the license free. I don't feel we are making _any_ progress. We should simply agree to disagree. Debian appears to believe in stronger freedom than the FSF. Peter
Re: Unidentified subject!
On Tue, Sep 16, 2003 at 07:58:01PM -0700, Brian C wrote: I think answers to these questions are critical if progress is to be made. If the FSF simply says, This is our license. Now it is solely up to you to include manuals licensed in this way or not. then I think it is pretty clear that the consensus here will not favor the GFDL. This would be a shame both because of the enormous work it would create in replacing manuals, and because I still believe that with several tweaks to the GFDL many here would find it DFSG-consistent. Fortunately, it is not as much work as we might fear. At least four GNU Manuals that have recently had Invariant Sections added to them and were relicensed under the GNU FDL were DFSG-free in earlier versions. Search the archives of this list for traditional GNU documentation license. However, important works like the GNU Emacs manual, _Using and Porting GNU CC_, and _The GNU C Library Reference Manual_ have had invariant sections for several years at least. -- G. Branden Robinson| Debian GNU/Linux | Extra territorium jus dicenti [EMAIL PROTECTED] | impune non paretur. http://people.debian.org/~branden/ | pgpwRPyHs4Y1S.pgp Description: PGP signature
Re: Unidentified subject!
Branden Robinson writes: Fortunately, it is not as much work as we might fear. At least four GNU Manuals that have recently had Invariant Sections added to them and were relicensed under the GNU FDL were DFSG-free in earlier versions. Search the archives of this list for traditional GNU documentation license. However, important works like the GNU Emacs manual, _Using and Porting GNU CC_, and _The GNU C Library Reference Manual_ have had invariant sections for several years at least. That's good to hear. Of course another related concern is forward-looking. It is a terrible waste of scare resources to have Debian create a DFSG-free manual every time a GFDL-licensed manual is produced for some new piece of software. Perhaps this situation will be avoided in other ways such as making efforts to encourage dual-licensing. But for now, I think it'd be best to avoid the situation altogether by seeking common ground. Hopefully something can be worked out.
Re: Unidentified subject!
For example, I might use a manual by tearing it into pieces and using the individual pages as confetti for a parade. But I cannot copy GFDL'd manuals and then do this. I congratulate you on your imagination--it never occurred to me to think about this as a use of a manual. As it happens, you are free to do that, because copyright does not cover tearing up a manual. You don't need a license to give you permission to do that. And then, in between the silly ones and the reasonable ones, there are a whole lot more, with some pretty darn ambiguous cases. Yes, there are gray areas where it is hard to decide. I had to think for months about whether the TeX license qualified as free, since it makes the whole of the original TeX source code invariant. And I had to think for weeks about a LaTeX license, that required changing the name of any file that you modify. I eventually concluded that LaTeX was free despite this requirement, but only because it has a remapping feature that lets you say Use file myfoo.sty when the document asks for foo.sty. My previous question is still the right one, I think. How would you go about explaining why send $1 to the author for permission to make changes to this program is not a mere requirement, but actually kills freedom? That question is straightforward: if you have to pay for permission to do something, you do not have permission to do it. Debian has a way of answering that question: but our way, which involves the DFSG, would say that send $1 to the author for permission to make changes is wrong for the same reasons that send $1 to the author for permission to make copies, and is wrong for the same reason that we think that invariant sections are wrong. The DFSG doesn't say anything about invariant sections; you're assuming a very strict interpretation. You're also assuming that the DFSG should be applied to manuals as well as software, and that the interpretation should be the same. I'm arguing for a less strict interpretation of the DFSG.
Re: Unidentified subject!
The principal argument in favor of the GFDL seems to be this is the only way we can get our message out. The GNU Project's motive for using invariant sections is not the issue here; that's a GNU Project decision, not a Debian decision. The question at hand is whether Debian should accept or reject GFDL-covered manuals. The argument for that is that there are many such manuals and they would be useful to include, and the DFSG can be interpreted to accept it.
Re: Unidentified subject!
Richard Stallman [EMAIL PROTECTED] writes: Any free software or free documentation license that has nontrivial requirements can have results like this. For instance, there are cases where people choose not to use a GPL-covered program because the GPL has requirements that they don't want to follow. If you adopt the stance that any license condition that someone might be reluctant to follow is unacceptable, you'd have to reject most free software licenses. Nobody has made that the stance. You *seem* to be saying that any requirement is ok, as long as you can still use the text. But use incorporates many things, and some of them you think are things you want to support, and others you don't care about. For example, I might use a manual by tearing it into pieces and using the individual pages as confetti for a parade. But I cannot copy GFDL'd manuals and then do this. Now that's of course a silly example, but it demonstrates the point: there are cases which are silly uses, and cases which are reasonable uses, and you have decided that you want to preserve the freedom of the reasonable uses and forget the silly ones. And then, in between the silly ones and the reasonable ones, there are a whole lot more, with some pretty darn ambiguous cases. What I have not seen is what you think is the right test to use for whether a requirement has become a freedom-impinging *restriction*. My previous question is still the right one, I think. How would you go about explaining why send $1 to the author for permission to make changes to this program is not a mere requirement, but actually kills freedom? (Indeed, that even send one cent for each hundred copies is a freedom-killing restriction!) Debian has a way of answering that question: but our way, which involves the DFSG, would say that send $1 to the author for permission to make changes is wrong for the same reasons that send $1 to the author for permission to make copies, and is wrong for the same reason that we think that invariant sections are wrong. You are asking us to use a different way of determining the answer, but I have not heard an explanation of what that different way would actually look like. The principal argument in favor of the GFDL seems to be this is the only way we can get our message out. Debian has been pretty successful at getting our message out, without needing invariant sections, that we find this implausible. Thomas
Re: Unidentified subject!
On Tue, 2002-07-16 at 17:26, Boris Veytsman wrote: Then they obviously should remove texinfo and all FSF info system as well, since it is TeX-based. A sad situation of ignorance: Debian people do not realize that they ALREADY use TeX with its LPPL-like reservation of the name TeX. They use it in such a way that divorcing from TeX is not posssible. From /usr/share/doc/tetex-base/copyright: - The teTeX distribution is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. On Debian GNU/Linux systems, the complete text of the GNU General Public License may be found in /usr/share/common-licenses/GPL The individual parts of this distribution often have their own copyright. Please look into the respective files for their copyright. seminar and koma-script have changed their licence recently but there are still files that refer to the old copyright. Both are copyrighted under the LPPL (LaTeX Project Public License) now. You can find the LPPL in /usr/share/doc/tetex-base/lppl.txt.gz -- tetex-nonfree is (as the name says) not freely distributable. Please look into the individual files for the copyrights. - From /usr/share/doc/texinfo/copyright: - This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. - From /usr/share/doc/info/copyright: - This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. - I fail to see the problem. Could you point it out for us? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Old subject: Patents and hardware implementations
On Fri, Dec 14, 2001 at 09:33:53PM +0100, Marcelo E. Magallon wrote: [...] My personal opinion is that this is ok. This does not conflict with the DFSG because this is not software we are talking about and until now I haven't read a convincing argument that is does indeed relate to the fields of endevour clause (DFSG 6). Starting from a very na?ve position, yes, this is saying you cannot use this for X, but the particular case in question makes it hard to come up with a realistic example. At the time of the original discussion, -legal seemed to agree that this is ok (IOW, noone actually said those terms make the license non-free). If an entity who has a patent related to some software includes with that software a statement which indicates that they will not use their patent to convince a government to forcibly prevent others from using the subject of the patent, it can not possibly make the software license non-free. In fact, the software license is no more or less Free than it was to begin with. Agreeing not to enforce a patent is a nice gesture. When that gesture extends equally to all software under a particular set of licenses, it is both compatible with the GNU GPL and our Debian Free Software Guidelines. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Unidentified subject!
On Fri, Aug 24, 2001 at 08:36:16AM +, Jeff Prescot wrote: Marcelo Magallon wrote: It should be emphasized that this is something *newsreaders* use. What the author says using this header is that he doesn't want email copies of Usenet posts, which is similar but not the same as mailing lists. So, I verified myself and, do you know what, I have discovered that each mail that we post to debian-legal, for example, is also posted by Debian to the Usenet News! We did not post to the News, did we? It is Debian that posted it! Bored now. Actually, it isn't. -- Colin Watson [EMAIL PROTECTED]
Re: Unidentified subject!
On Fri, Aug 24, 2001 at 05:42:16PM -0500, Colin Watson wrote: On Fri, Aug 24, 2001 at 08:36:16AM +, Jeff Prescot wrote: So, I verified myself and, do you know what, I have discovered that each mail that we post to debian-legal, for example, is also posted by Debian to the Usenet News! We did not post to the News, did we? It is Debian that posted it! Bored now. Actually, it isn't. Bwa ha ha, I was wrong. He's interning for Sergio Brandano! I missed some choice stuff from this twit. Maybe I should check the list archives. -- G. Branden Robinson| If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ | pgpTa3RcAtvwN.pgp Description: PGP signature
