Re: License for ATI driver documentation
Daniel Leidert [EMAIL PROTECTED] wrote: Hello, I hope you can help with some ideas and also clear a few of my questions. I'm not a lawyer, so I hope, you can give a few hints. I'm writing manpages for the proprietary ATI driver, which are included in the Debian package. You can find the source here: http://cvs.wgdd.de/cgi-bin/cvsweb/fglrx_man/ At the moment the sources miss a license statement. More about the manpages can be found at Flavios fglrx mailing-list. http://www.stanchina.net/~flavio/debian/fglrx-archive/msg00925.html http://www.stanchina.net/~flavio/debian/fglrx-archive/msg01017.html 1) One thing I'm not sure about is, which license I should use, and if I maybe clash with the ATI license. So what do you think about the latter issue? Am I allowed to release the manpages under a free license or do I need permissions from ATI or do I need to give ATI a partial copyright or ...? To write the fglrx(4x) manpage I used information I found in http://www2.ati.com/drivers/firegl/readme0325.txt. Now this file states: /--- Please read the entire contents of this document. Information in this file may not appear in printed documentation or online help. \--- Does it mean, that I'm not allowed to use this information? How do you interpret this phrase? I interpret may not as meaning that the information will not necessarily appear in the printed documentation etc., not that it is not allowed to appear there. Unless we are dealing with someone who has a history of interpreting phrases in a bizarre manner (e.g. U. Washington), you should be fine. However, the end of the file says (c) Copyright 2002,2003 by ATI Technologies Inc. All rights reserved which means that you can't use the text in that file for anything. But if you got your information by synthesizing many different sources, including that file, you should be fine. 2) I want to release them under a free license and therefor I plan to choose a license, which is based on the FreeBSD documentation license. It would read: /--- Copyright (C) Redistribution and use in source (XML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code (XML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of the file unmodified. 2. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright owner(s) nor the name of any contributor may be used to endorse or promote products derived from this documentation without specific prior written permission. THIS DOCUMENTATION IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. \ What do you think about this license? Is it DFSG-compliant? Can I apply it? Would you change parts (and if yes - why?). One thing, I'm not sure about is the phrase as the first lines. Normally the XML source will look like this There are two issues: 1) Someone may want to use a different format for the documentation. For example, they may use LyX's internal format. So I would change source to read preferred form for modification (e.g. XML DocBook). Similarly, I would change compiled form to other forms. 2) The phrase as the first lines is problematic. Someone may use a different format in which putting the list of claims and conditions in the first lines is impossible or silly. With that said, it looks like you just modified the BSD license. I would recommend that you just use the BSD license, with a nonbinding side note mentioning what you view as source and binary. Something like Note: Source is here meant as the preferred form for modification, such as XML DocBook. Cheers, Walter Landry [EMAIL PROTECTED] -- To
Re: OFL license analysis
Mark Rafn [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Debian decides to distribute works containing your font. The original upstream disappears. A bug is discovered in the font, and Debian needs to fix it. On Sun, 29 Jan 2006, Marco d'Itri wrote: Yes, and this is considered a feature. Usually existing documents should not break because a font is changed, even if this fixes a bug. On Sun, 29 Jan 2006, Don Armstrong wrote: The same argument applies equally well to programs. We should be intelligent enough in our fixing of bugs in fonts not to break existing documents, That's plain impossible. A bug in a font could be a wrong kerning. Kerning means the hints in the fonts that indicate that in a particular combination of letters, two adjacent letters need less (or more) space between them than their size would dictate. For example the letters VA must be shifted a little towards each other, otherwise it will look nearly like a whitespace between them. If there is such a bug in a font, changing it implies that the word-wrapping algorithm has a high chance of finding a different solution, and thus change existing documents. There's simply no solution that allows both for stable docments and for bug fixing. The lmodern fonts, for example, are still under development, and they warn the user and reserve themselves the option to change things like the kerning. But if you've got a font that is in wide use and regarded as stable, changing the kerning is a design decision and should in fact change the name under which the font is available to the user and to documents. just like we should be intelligent enough in our fixing of bugs in programs not to break existing scripts. This discussion seems to have gone into the weeds about WHY someone would want to make a change and whether Debian is able to make such changes reasonably. Well, only in part. A font that you can't rely on is mostly useless... Name-change requirements are acceptible (barely) on the package name, but not API identifiers, and that includes filenames that are part of an API. [...] What ever happenened to the LaTex license, by the way? That had the same non-freeness. You seem to have a different opinion on this as the debian-legal people who negotiated with the LaTeX project and together developped the LPPL version 1.3. In this version, the requirement to change file names (or LaTeX package names) was dropped, probably because it was regarded as too non-free, whereas it was decided that any changed version should indicate that it was changed in the version string that is (or to some degree only will be) part of the API. It seems a clear test: if I can't distribute a changed version that can be dropped into a system without changing other software, it ain't free. You can never distribute a bugfixed version of a font with the same name (identifiers, ...) and, without changing other software, get the same system behavior. That's not a question of freeness, it's a technical problem. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Please review: The OFL (Open Font License)
Marco d'Itri wrote: [EMAIL PROTECTED] wrote: Won't this forbid anyone (but the original copyright holder) to fix bugs or misfeatures in the font? Not if they choose a different name. For a font bug-for-bug compatibility may be very important to preserve correct rendering of docuements. You do, of course, mean preserve _incorrect_ rendering of documents ;-) Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please review: The OFL (Open Font License)
On Jan 30, Gervase Markham [EMAIL PROTECTED] wrote: Not if they choose a different name. For a font bug-for-bug compatibility may be very important to preserve correct rendering of docuements. You do, of course, mean preserve _incorrect_ rendering of documents ;-) Yes. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFL license analysis
On Mon, 30 Jan 2006, Frank Küster wrote: On Sun, 29 Jan 2006, Don Armstrong wrote: The same argument applies equally well to programs. We should be intelligent enough in our fixing of bugs in fonts not to break existing documents, That's plain impossible. A bug in a font could be a wrong kerning. [...] There's simply no solution that allows both for stable docments and for bug fixing. There are clearly some classes of bugs which entail breaking compatibility with existing programs or existing documents. To whit: [When we're not, we have the ability to determine which is the proper course of action: breaking compatibility or living with the bug.] [1] if you've got a font that is in wide use and regarded as stable, changing the kerning is a design decision and should in fact change the name under which the font is available to the user and to documents. This exact argument can be made to apply to programs. We as distributors (or our users as users) should be able to make the determination whether it's appropriate to break compatibility to fix the bug, or keep compatibility and live with the bug. A license really has no business forcing technical decisions like that on us or our users. We've allowed a very narrow compromise to require that the name of the work itself (or its version) change, but that's it; a requirement that other parts of the work change beyond its name goes beyond DFSG §4. Don Armstrong 1: [EMAIL PROTECTED] -- Frankly, if ignoring inane opinions and noisy people and not flaming them to crisp is bad behaviour, I have not yet achieved a state of nirvana. -- Manoj Srivastava in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Please review: The OFL (Open Font License)
[EMAIL PROTECTED] (Marco d'Itri) wrote: On Jan 30, Gervase Markham [EMAIL PROTECTED] wrote: Not if they choose a different name. For a font bug-for-bug compatibility may be very important to preserve correct rendering of docuements. You do, of course, mean preserve _incorrect_ rendering of documents ;-) Yes. Well, let's say preserve rendering. A no-longer incorrect letter kerning might, via changes in line wrapping, lead to a completely incorrect page breaking, or figure placement, etc., and in consequence to a much less correct rendering. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: OFL license analysis
Don Armstrong [EMAIL PROTECTED] wrote: This exact argument can be made to apply to programs. We as distributors (or our users as users) should be able to make the determination whether it's appropriate to break compatibility to fix the bug, or keep compatibility and live with the bug. A license really has no business forcing technical decisions like that on us or our users. We've allowed a very narrow compromise to require that the name of the work itself (or its version) change, but that's it; a requirement that other parts of the work change beyond its name goes beyond DFSG §4. Well, in a sense every font file (the standard version, the italic, bold, small caps, etc versions) is a work of its own, and the complete distribution is only an aggregate work. For commercial fonts it is common that you buy each separately. Anyway: would, in your opinion, a restriction be acceptable to change either the version or, as long as there's no technical solution yet that includes this version in the API, the font name? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: License for ATI driver documentation
Am Montag, den 30.01.2006, 00:42 -0800 schrieb Walter Landry: Daniel Leidert [EMAIL PROTECTED] wrote: I hope you can help with some ideas and also clear a few of my questions. I'm not a lawyer, so I hope, you can give a few hints. I'm writing manpages for the proprietary ATI driver, which are included in the Debian package. You can find the source here: http://cvs.wgdd.de/cgi-bin/cvsweb/fglrx_man/ At the moment the sources miss a license statement. More about the manpages can be found at Flavios fglrx mailing-list. http://www.stanchina.net/~flavio/debian/fglrx-archive/msg00925.html http://www.stanchina.net/~flavio/debian/fglrx-archive/msg01017.html 1) One thing I'm not sure about is, which license I should use, and if I maybe clash with the ATI license. So what do you think about the latter issue? Am I allowed to release the manpages under a free license or do I need permissions from ATI or do I need to give ATI a partial copyright or ...? To write the fglrx(4x) manpage I used information I found in http://www2.ati.com/drivers/firegl/readme0325.txt. Now this file states: /--- Please read the entire contents of this document. Information in this file may not appear in printed documentation or online help. \--- Does it mean, that I'm not allowed to use this information? How do you interpret this phrase? I interpret may not as meaning that the information will not necessarily appear in the printed documentation etc., not that it is not allowed to appear there. Unless we are dealing with someone who has a history of interpreting phrases in a bizarre manner (e.g. U. Washington), you should be fine. However, the end of the file says (c) Copyright 2002,2003 by ATI Technologies Inc. All rights reserved which means that you can't use the text in that file for anything. But if you got your information by synthesizing many different sources, including that file, you should be fine. I used a lot of sources, but also this file. Shall I better still ask ATI for permissions to use the contents of this file? 2) I want to release them under a free license and therefor I plan to choose a license, which is based on the FreeBSD documentation license. It would read: /--- Copyright (C) [snip FreeBSD documentation license] \ What do you think about this license? Is it DFSG-compliant? Can I apply it? Would you change parts (and if yes - why?). One thing, I'm not sure about is the phrase as the first lines. Normally the XML source will look like this There are two issues: 1) Someone may want to use a different format for the documentation. For example, they may use LyX's internal format. So I would change source to read preferred form for modification (e.g. XML DocBook). Similarly, I would change compiled form to other forms. Ok. 2) The phrase as the first lines is problematic. Someone may use a different format in which putting the list of claims and conditions in the first lines is impossible or silly. Ok. I will remove this phrase. With that said, it looks like you just modified the BSD license. The FreeBSD documentation license is a modified BSD license. I would recommend that you just use the BSD license, with a nonbinding side note mentioning what you view as source and binary. Maybe you are right. I better use the BSD license and modify it a bit for my own usage. Something like Note: Source is here meant as the preferred form for modification, such as XML DocBook. Ok. Here my suggestion: /-- Copyright (C) All rights reserved. Redistribution and use in source (the preferred form of modification, such as XML DocBook) and other forms (SGML, HTML, PDF, PostScript, RTF, Groff and so forth) with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source (the preferred form of modification, such as XML DocBook) code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in other forms (transformed to other DTDs, converted to PDF, PostScript, RTF, Groff and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright owner nor the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS DOCUMENTATION IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
Re: Adobe open source license -- is this licence free?
On 1/29/06, Don Armstrong [EMAIL PROTECTED] wrote: On Sun, 29 Jan 2006, Raul Miller wrote: You can still claim that the court in question does not have jurisdiction over the parties. You can claim that the moon is cheese too, if you want.[1] The point is that in order for the court to agree that they don't have jurisdiction, you have to get them to agree that the clause is non-binding. [The claiming is a lessser issue; what the court has to do in order to agree with your claims is critical here.] My point was that a harassing case based on this license would be much akin to claiming that the moon is cheese. Only if the case has merit -- only if there's a valid dispute involving the license -- would the CA courts have jurisdiction. Issues of jurisdiction are one of the first things to be determined in most cases, they occur well before the court even begins entertaining issues of merit.[2] For this clause of the license to apply at all, there would need to be a dispute about something related to the license. That means a dispute about Adobe's customer service or warranty support for this software, or a displute about the software being distributed without proper copyright notices or with improper trademark notices. So this aspect -- what is the dispute about -- would have to be resolved as a part of resolving issues about jurisdiction. I was not trying to say that all issues of merit would have to be resolved. -- Raul
Re: Adobe open source license -- is this licence free?
On Sun, 29 Jan 2006 22:17:47 -0800 (PST) Walter Landry wrote: Nathanael Nerode [EMAIL PROTECTED] wrote: [...] Here's the attribution version: http://creativecommons.org/licenses/by/2.5/scotland/legalcode 6.5 This Licence is governed by the law of Scotland and the parties accept the exclusive jurisdiction of the Courts of Scotland to decide any action or claim directed against the Licensor. Doesn't this cause problems when the code is forked? If someone in France forks the code, then they have to travel to Scotland to defend themselves against any frivolous lawsuits. That allows the original licensors a bit more control over the code than might be desired. I am not sure that allowing choice of venue clauses to be overridded is ever a good idea. The law has a number of (imperfect) safety hatches to prevent forum selection abuse. Mmmmh, that seems to be a problem too and one I hadn't thought about before... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpUGnlLisBFW.pgp Description: PGP signature
Re: OFL license analysis
On Mon, 30 Jan 2006 02:25:34 -0800 Don Armstrong wrote: On Mon, 30 Jan 2006, Frank Küster wrote: [...] if you've got a font that is in wide use and regarded as stable, changing the kerning is a design decision and should in fact change the name under which the font is available to the user and to documents. This exact argument can be made to apply to programs. We as distributors (or our users as users) should be able to make the determination whether it's appropriate to break compatibility to fix the bug, or keep compatibility and live with the bug. A license really has no business forcing technical decisions like that on us or our users. We've allowed a very narrow compromise to require that the name of the work itself (or its version) change, but that's it; a requirement that other parts of the work change beyond its name goes beyond DFSG §4. Exactly! Agreed entirely. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpv1K1YwTbhz.pgp Description: PGP signature
Re: OFL license analysis
Mark Rafn [EMAIL PROTECTED] wrote: This discussion seems to have gone into the weeds about WHY someone would want to make a change and whether Debian is able to make such changes reasonably. On Mon, 30 Jan 2006, Frank Küster wrote: Well, only in part. A font that you can't rely on is mostly useless... I assume the you in this sentence is a hapless user of a system whose software she does not control/understand, not the person wishing to make and distribute changes to the font. Correct me if this is an incorrect reading. A license that tries to protect a user from an incompetent developer/distributor/sysadmin is going to be non-free. There's really no way around this. The only way to be free is to allow a true fork of the software, which means a dropin replacement, even if the licensor disapproves. What ever happenened to the LaTex license, by the way? That had the same non-freeness. You seem to have a different opinion on this as the debian-legal people who negotiated with the LaTeX project and together developped the LPPL version 1.3. In this version, the requirement to change file names (or LaTeX package names) was dropped, probably because it was regarded as too non-free, whereas it was decided that any changed version should indicate that it was changed in the version string that is (or to some degree only will be) part of the API. Hmm. I claim that it is a mistake for Debian to consider something free if it requires binary incompatibility to distribute a modified version. Version strings are a funny edge-case, where if they're normally just human-readable information with no programmatic effect I can live with it, but when it becomes common to programmatically read them and behave differently, then it's part of the API and must be modifiable (or not) without restriction. It's possible that Debian made a mistake if that's what LaTeX does with these strings. Wouldn't be the first time. It seems a clear test: if I can't distribute a changed version that can be dropped into a system without changing other software, it ain't free. You can never distribute a bugfixed version of a font with the same name (identifiers, ...) and, without changing other software, get the same system behavior. That's not a question of freeness, it's a technical problem. No, the intent is to get DIFFERENT system behavior by changing the free component, without changing other software or documents. That's the freedom I'm worried about here. Though the ability to get the same behavior is there too (perhaps a performance fix or other result-compatible implementation change), it's just a special case of the real freedom to make changes. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: GR proposal: GFDL with no Invariant Sections is free
olive [EMAIL PROTECTED] wrote: I personnaly think that Debian would do better to defend free software if there were in accordance to the FSF. I personally think that the FSF would do much, much better at defending free software if they operated in accordance with Debian. Debian-legal has proved better at guaranteeing the FSF's 'four freedoms' in practice than RMS, what with the GFDL and all. Let's face it: the FSF didn't create a full free-software system. Debian did. The FSF didn't even create the majority of the GNU project tools. Volunteers did, and many of them *disagree* with the FSF leadership. Discussions of the merits of FSF policy are forbidden on FSF mailing lists, with the exception of a few which appear to go to /dev/null. The FSF is, bizarrely, a top-down autocratic organization, with all the flaws that implies. Debian isn't, with all the benefits and flaws that implies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License for ATI driver documentation
Daniel Leidert [EMAIL PROTECTED] wrote: Am Montag, den 30.01.2006, 00:42 -0800 schrieb Walter Landry: Daniel Leidert [EMAIL PROTECTED] wrote: However, the end of the file says (c) Copyright 2002,2003 by ATI Technologies Inc. All rights reserved which means that you can't use the text in that file for anything. But if you got your information by synthesizing many different sources, including that file, you should be fine. I used a lot of sources, but also this file. Shall I better still ask ATI for permissions to use the contents of this file? Looking at your man page, I don't think you need to bother. It would be nice to ask them in any case, though, since more free documentation is always good. snip Ok. Here my suggestion: /-- Copyright (C) All rights reserved. Redistribution and use in source (the preferred form of modification, such as XML DocBook) and other forms (SGML, HTML, PDF, PostScript, RTF, Groff and so forth) with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source (the preferred form of modification, such as XML DocBook) code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in other forms (transformed to other DTDs, converted to PDF, PostScript, RTF, Groff and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright owner nor the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS DOCUMENTATION IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. \-- I included your suggestions and changed documentation to software in item 3.) of the conditions list. Better? Better. The no-warranty clause should also say software instead of documentation. Otherwise, I think you're good to go. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adobe open source license -- is this licence free?
On Mon, Jan 30, 2006 at 04:39:33PM -0500, Nathanael Nerode wrote: If it's not a copyleft: * the Scotland-venue clause in the original license only applies to claims against the original licensor of the original software * the French forker uses a license without that clause for his own modifications (perhaps with a French court clause). Suits against him, as licensor of the modified version, go to his French court. The result of this taken to the extreme, where lots of contributors from lots of different countries did this, might not become less free as such, but would become an unbearable mess (think 50 countries, with 50 choice of venue clauses, one for each depending on who you want to sue). (The next thought, of course, is replacing French with something like the home-country-or-something of the copyright holder, but that's a whole new ugly bag of worms.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal: GFDL with no Invariant Sections is free
On Mon, 30 Jan 2006 16:34:25 -0500 Nathanael Nerode wrote: olive [EMAIL PROTECTED] wrote: I personnaly think that Debian would do better to defend free software if there were in accordance to the FSF. I personally think that the FSF would do much, much better at defending free software if they operated in accordance with Debian. Debian-legal has proved better at guaranteeing the FSF's 'four freedoms' in practice than RMS, what with the GFDL and all. Let's face it: the FSF didn't create a full free-software system. Debian did. The FSF didn't even create the majority of the GNU project tools. Volunteers did, and many of them *disagree* with the FSF leadership. Discussions of the merits of FSF policy are forbidden on FSF mailing lists, with the exception of a few which appear to go to /dev/null. The FSF is, bizarrely, a top-down autocratic organization, with all the flaws that implies. Debian isn't, with all the benefits and flaws that implies. Agreed entirely. It's sad, but true... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpw6JEj8L7eo.pgp Description: PGP signature
Re: GR proposal: GFDL with no Invariant Sections is free
On 1/31/06, Nathanael Nerode [EMAIL PROTECTED] wrote: olive [EMAIL PROTECTED] wrote: I personnaly think that Debian would do better to defend free software if there were in accordance to the FSF. I personally think that the FSF would do much, much better at defending free software if they operated in accordance with Debian. Debian-legal has proved better at guaranteeing the FSF's 'four freedoms' in practice than RMS, what with the GFDL and all. Let's face it: the FSF didn't create a full free-software system. Debian did. The FSF didn't even create the majority of the GNU project tools. Volunteers did, and many of them *disagree* with the FSF leadership. Discussions of the merits of FSF policy are forbidden on FSF mailing lists, with the exception of a few which appear to go to /dev/null. The FSF is, bizarrely, a top-down autocratic organization, with all the flaws that implies. Debian isn't, with all the benefits and flaws that implies. Let's face it: Debian wouldn't exist without the FSF. -- Andrew Donnellan http://andrewdonnellan.com http://ajdlinux.blogspot.com Jabber - [EMAIL PROTECTED] --- Member of Linux Australia - http://linux.org.au Debian user - http://debian.org Get free rewards - http://ezyrewards.com/?id=23484 OpenNIC user - http://www.opennic.unrated.net
Re: GR proposal: GFDL with no Invariant Sections is free
On Tue, Jan 31, 2006 at 12:52:00PM +1100, Andrew Donnellan wrote: On 1/31/06, Nathanael Nerode [EMAIL PROTECTED] wrote: olive [EMAIL PROTECTED] wrote: I personnaly think that Debian would do better to defend free software if there were in accordance to the FSF. I personally think that the FSF would do much, much better at defending free software if they operated in accordance with Debian. Debian-legal has proved better at guaranteeing the FSF's 'four freedoms' in practice than RMS, what with the GFDL and all. Let's face it: the FSF didn't create a full free-software system. Debian did. The FSF didn't even create the majority of the GNU project tools. Volunteers did, and many of them *disagree* with the FSF leadership. Discussions of the merits of FSF policy are forbidden on FSF mailing lists, with the exception of a few which appear to go to /dev/null. The FSF is, bizarrely, a top-down autocratic organization, with all the flaws that implies. Debian isn't, with all the benefits and flaws that implies. Let's face it: Debian wouldn't exist without the FSF. Maybe not. Neither would a lot of other things. That's a strawman that doesn't change where things are today. The FSF deserves respect for their part in getting us here, but not so much that they're exempt from critical review. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
