Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Debian Project secretary [EMAIL PROTECTED] wrote: On Sun, 15 Jan 2006 11:40:20 +0100, Andreas Metzler [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] wrote: [[PGP Signed Part:Failed] Signature made Fri Jan 13 02:21:11 2006 CST using DSA key ID 330C4A75 Good signature from Martin F. Krafft [...] [EMAIL PROTECTED] Note: This key has expired! [...] You should refresh your copy of Martin's key from subkeys.pgp.net. Umm, no. I, and devotee, look at the official debian keyrings from keyring.d.o as authoritative for keys and signatures. I see. It seems to be fixed now anyway: [EMAIL PROTECTED]:/tmp$ gpg --keyring /tmp/fooo --keyserver keyring.debian.org --no-default-keyring --recv-keys 330C4A75 gpg: keyring `/tmp/fooo' created gpg: requesting key 330C4A75 from hkp server keyring.debian.org gpg: key 330C4A75: public key Martin F. Krafft [EMAIL PROTECTED] imported [...] [EMAIL PROTECTED]:/tmp$ gpg --keyring /tmp/fooo -v --keyserver keyring.debian.org --no-default-keyring --list-keys 330C4A75 gpg: using classic trust model pub 1024D/330C4A75 2001-06-20 [expires: 2006-06-20] uid Martin F. Krafft [EMAIL PROTECTED] [...] cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Manoj Srivastava [EMAIL PROTECTED] wrote: [[PGP Signed Part:Failed] Signature made Fri Jan 13 02:21:11 2006 CST using DSA key ID 330C4A75 Good signature from Martin F. Krafft [EMAIL PROTECTED] aka Martin F. Krafft (AERAsec GmbH) [EMAIL PROTECTED] aka Martin F. Krafft (Debian) [EMAIL PROTECTED] aka Martin F. Krafft (MB! Sudetia) [EMAIL PROTECTED] aka Martin F. Krafft (Uni Zuerich) [EMAIL PROTECTED] Note: This key has expired! [...] You should refresh your copy of Martin's key from subkeys.pgp.net. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Sim?? wrote: As I expect that at least one of the seconds/proposer will object to this amendment (heh), I'm actively looking for seconds myself now. I personally object to this because I find actually what you call bugs to be much more practical issues that the invariant sections because they affect the Debian CD-ROM as a whole, while you can just ignore non-modifiable documents even if they are in main. I strongly support moving the GFDL document to non-free and provide an extra iso-image with them. Of course, the FSF has the option to release a GFDL 1.3 that address these issue, and then we could take advantage of the upgrade clause. (I would support an amendment hinting the FSF to release a fixed GFDL if someone is smart enough to draft one, because this is clearly the best solution for GFDL documents without non-Invariant Section.) The most grave of these problems are the so-called invariant sections, which are non-removable, non-modifiable parts of the document that the GFDL allows in works under this license. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, so this restriction is not acceptable for us. I disagree that is is the most grave of these problems's. 2. We believe that works licensed under the GFDL that include no such unmodifiable sections do fully meet the spirit of the Debian Free Software Guidelines, and have a place in our distribution despite the other problems (minor, in comparison) that the GFDL has. I don't find them minor at all. Problems of the GFDL I. The DRM Restriction Section 2 (Verbatim Copying) of the GFDL goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to technical measures to obstruct or control reading and copying. This means that: (a) It is not limited to the act of distribution (i.e., it applies to private copies as well). (b) It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time. (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions. Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. This is a serious additional restriction. This affect the distribution of Debian iso images through encrypted channel which is more and more frequent. If the GFDL document where moved to non-free we could provide an extra iso-image with all the GFDL document and only this iso image would be restricted. If that can help settle the issue, I volunteer helping building the extra GFDL iso image. II. Transparent And Opaque Copies Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for download at a publicly accessible location for one year after the last distribution of the opaque form. It is our belief that as long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is required of you. It is up to the user whether to download the transparent form. The requirements for redistributors should be to make sure the users can get the transparent form, not to force users to download the transparent form even if they don't want it. This might be fixable technically, but currently we are in violation of this requirement, so we cannot legally ship GFDL documents anyway, which make this whole GR moot. This requirement is extremly costly for anyone attempting to distribute Sarge either as a mirror or as an ISO image. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Sun, Jan 15, 2006 at 11:30:55PM +0100, Bill Allombert wrote: This requirement is extremly costly for anyone attempting to distribute Sarge either as a mirror or as an ISO image. Can you point to testimony of people actually hindered by this? Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Sun, 15 Jan 2006 11:40:20 +0100, Andreas Metzler [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] wrote: [[PGP Signed Part:Failed] Signature made Fri Jan 13 02:21:11 2006 CST using DSA key ID 330C4A75 Good signature from Martin F. Krafft [EMAIL PROTECTED] aka Martin F. Krafft (AERAsec GmbH) [EMAIL PROTECTED] aka Martin F. Krafft (Debian) [EMAIL PROTECTED] aka Martin F. Krafft (MB! Sudetia) [EMAIL PROTECTED] aka Martin F. Krafft (Uni Zuerich) [EMAIL PROTECTED] Note: This key has expired! [...] You should refresh your copy of Martin's key from subkeys.pgp.net. Umm, no. I, and devotee, look at the official debian keyrings from keyring.d.o as authoritative for keys and signatures. manoj -- Morton's Law: If rats are experimented upon, they will develop cancer. Debian Project secretary [EMAIL PROTECTED] http://vote.debian.org/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Thanks to Luk for setting things straight. I hereby second Dato's proposal, which is included in full below. also sprach Adeodato Simó [EMAIL PROTECTED] [2006.01.10.0455 +0100]: It's been six months since the social contract changes that forbid non-free documentation went into effect [0], and we're still distributing GFDLed stuff in unstable [1]. I think we should get serious about fixing that, and as part of that that we should release the following statement (or one like it) on the GFDL: I propose an amendment to this GR, consisting in replacing the existing text with the one below. I initially tried to follow Anthony's original text as close as possible, and just add a paragraph and reword a couple sentences, but I didn't quite like the result, so I ended up rewriting it; if somebody manages to fit point (2) below in the original text, be my guest. The section Problems of the GFDL comes straight away from Manoj's Draft Position Statement [1]. [1] http://people.debian.org/~srivasta/Position_Statement.html As I expect that at least one of the seconds/proposer will object to this amendment (heh), I'm actively looking for seconds myself now. Thanks. ---8--- Debian and the GNU Free Documentation License = This is the position of Debian Project about the GNU Free Documentation License as published by the Free Software Foundation: 1. We consider that the GNU Free Documentation License version 1.2 conflicts with traditional requirements for free software in a variety of ways, explained in detail in the Problems of the GFDL section below. The most grave of these problems are the so-called invariant sections, which are non-removable, non-modifiable parts of the document that the GFDL allows in works under this license. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, so this restriction is not acceptable for us. 2. We believe that works licensed under the GFDL that include no such unmodifiable sections do fully meet the spirit of the Debian Free Software Guidelines, and have a place in our distribution despite the other problems (minor, in comparison) that the GFDL has. Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. 3. Despite the compromise above, GFDL'd documentation is still not free of trouble: as an example, it is incompatible with the major free software licenses, which means that GFDL'd text can't be incorporated into free programs. For this reason, we encourage documentation authors to license their works (or dual-license, together with the GFDL) under a well known free software license like the the GPL or the BSD license. Problems of the GFDL I. The DRM Restriction Section 2 (Verbatim Copying) of the GFDL goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to technical measures to obstruct or control reading and copying. This means that: (a) It is not limited to the act of distribution (i.e., it applies to private copies as well). (b) It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time. (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions. Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. This is a serious additional restriction. II. Transparent And Opaque Copies Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
I second Adeodato Simó's amendment: On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Simó wrote: I propose an amendment to this GR, consisting in replacing the existing text with the one below. I initially tried to follow Anthony's original text as close as possible, and just add a paragraph and reword a couple sentences, but I didn't quite like the result, so I ended up rewriting it; if somebody manages to fit point (2) below in the original text, be my guest. The section Problems of the GFDL comes straight away from Manoj's Draft Position Statement [1]. [...] ---8--- Debian and the GNU Free Documentation License = This is the position of Debian Project about the GNU Free Documentation License as published by the Free Software Foundation: 1. We consider that the GNU Free Documentation License version 1.2 conflicts with traditional requirements for free software in a variety of ways, explained in detail in the Problems of the GFDL section below. The most grave of these problems are the so-called invariant sections, which are non-removable, non-modifiable parts of the document that the GFDL allows in works under this license. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, so this restriction is not acceptable for us. 2. We believe that works licensed under the GFDL that include no such unmodifiable sections do fully meet the spirit of the Debian Free Software Guidelines, and have a place in our distribution despite the other problems (minor, in comparison) that the GFDL has. Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. 3. Despite the compromise above, GFDL'd documentation is still not free of trouble: as an example, it is incompatible with the major free software licenses, which means that GFDL'd text can't be incorporated into free programs. For this reason, we encourage documentation authors to license their works (or dual-license, together with the GFDL) under a well known free software license like the the GPL or the BSD license. Problems of the GFDL I. The DRM Restriction Section 2 (Verbatim Copying) of the GFDL goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to technical measures to obstruct or control reading and copying. This means that: (a) It is not limited to the act of distribution (i.e., it applies to private copies as well). (b) It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time. (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions. Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. This is a serious additional restriction. II. Transparent And Opaque Copies Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for download at a publicly accessible location for one year after the last distribution of the opaque form. It is our belief that as long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is required of you. It is up to the user whether to download the transparent form. The requirements for redistributors should be to make sure the users can get the transparent form, not to force users to download the transparent form even if they don't want it. III. Invariant Sections
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
In linux.debian.vote Adeodato wrote: I propose an amendment to this GR, consisting in replacing the existing text with the one below. I initially tried to follow Anthony's original text as close as possible, and just add a paragraph and reword a couple sentences, but I didn't quite like the result, so I ended up rewriting it; if somebody manages to fit point (2) below in the original text, be my guest. The section Problems of the GFDL comes straight away from Manoj's Draft Position Statement [1]. [1] http://people.debian.org/~srivasta/Position_Statement.html As I expect that at least one of the seconds/proposer will object to this amendment (heh), I'm actively looking for seconds myself now. I second the proposed amendment quoted fully below. Cheers, Moritz ---8--- Debian and the GNU Free Documentation License =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is the position of Debian Project about the GNU Free Documentation License as published by the Free Software Foundation: 1. We consider that the GNU Free Documentation License version 1.2 conflicts with traditional requirements for free software in a variety of ways, explained in detail in the Problems of the GFDL section below. The most grave of these problems are the so-called invariant sections, which are non-removable, non-modifiable parts of the document that the GFDL allows in works under this license. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, so this restriction is not acceptable for us. 2. We believe that works licensed under the GFDL that include no such unmodifiable sections do fully meet the spirit of the Debian Free Software Guidelines, and have a place in our distribution despite the other problems (minor, in comparison) that the GFDL has. Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. 3. Despite the compromise above, GFDL'd documentation is still not free of trouble: as an example, it is incompatible with the major free software licenses, which means that GFDL'd text can't be incorporated into free programs. For this reason, we encourage documentation authors to license their works (or dual-license, together with the GFDL) under a well known free software license like the the GPL or the BSD license. Problems of the GFDL I. The DRM Restriction Section 2 (Verbatim Copying) of the GFDL goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to technical measures to obstruct or control reading and copying. This means that:=20 =20 (a) It is not limited to the act of distribution (i.e., it applies to private copies as well).=20 (b) It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time.=20 (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions.=20 Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. This is a serious additional restriction.=20 II. Transparent And Opaque Copies Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for download at a publicly accessible location for one year after the last distribution of the opaque form.=20 It is our belief that as long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Adeodato =?utf-8?B?U2ltw7M=?= [EMAIL PROTECTED] Right, FSF stuff goes away. OTOH, I feel utterly ashamed each time I imagine the possibility of the following conversation taking place: =C2=ABHey, fellow free software developer, thanks for writing such a cool program and releasing it under the GPL! I also see that you wrote excellent manual for it, nice! Uhm, I see it's licensed under the GFDL, why? Oh I see, these FSF folks that created the GPL told you that the GFDL is a reasonable license for documentation, and you fscking trusted them?! Bad move, guy. No unmodifiable sections you say? Bah, you know we in Debian care more about legalese than about being fair to the rest of the community. [...] If you explain it that way, you're a bozo and you're unhelpful. This should not be about Trust Debian more than the FSF but should be about free software needs free software manuals. Explain that allowing secured media (when it has no impact on user freedom), distribution without forced source download or long-term archiving and easy copying between program and manual are all useful freedoms. Would ftpmasters and mirror operators be able to either include a machine-readable Transparent copy along with each Opaque copy, or [...] ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public anyway? I thought similar source distribution requirements were a practical problem just now? Blindly following anyone else's opinion has the potential to cause problems for you. FSF are pretty good, but I think their goals for the FDL (to require distribution of the GNU Manifesto and/or manual sponsor's adverts) are significantly different from free software, or what many free software supporters would aim for in a manual. If a similar approach was applied to free software, we could attach an unremovable debian-policy and sponsor adverts to the debian release CD/DVD images. Do you see the problems with that? The security and transparent problems look like bugs more than conflict over the goals, but they are still problematic. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Merle Ray [EMAIL PROTECTED] wrote: Would ftpmasters and mirror operators be able to either include a machine-readable Transparent copy along with each Opaque copy, or [...] ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public anyway? I thought similar source distribution requirements were a practical problem just now? Yes. It just requires a policy stating that each binary package must include a transparent copy. This isn't terribly difficult, it's just irritating. -- Matthew Garrett | [EMAIL PROTECTED] My preferred name is you -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
* Esteban Manchado Velázquez [EMAIL PROTECTED] [2006-01-13 09:26]: I second Adeodato Simó's amendment: I hereby second this proposal as well. On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Simó wrote: I propose an amendment to this GR, consisting in replacing the existing text with the one below. I initially tried to follow Anthony's original text as close as possible, and just add a paragraph and reword a couple sentences, but I didn't quite like the result, so I ended up rewriting it; if somebody manages to fit point (2) below in the original text, be my guest. The section Problems of the GFDL comes straight away from Manoj's Draft Position Statement [1]. [...] ---8--- Debian and the GNU Free Documentation License = This is the position of Debian Project about the GNU Free Documentation License as published by the Free Software Foundation: 1. We consider that the GNU Free Documentation License version 1.2 conflicts with traditional requirements for free software in a variety of ways, explained in detail in the Problems of the GFDL section below. The most grave of these problems are the so-called invariant sections, which are non-removable, non-modifiable parts of the document that the GFDL allows in works under this license. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, so this restriction is not acceptable for us. 2. We believe that works licensed under the GFDL that include no such unmodifiable sections do fully meet the spirit of the Debian Free Software Guidelines, and have a place in our distribution despite the other problems (minor, in comparison) that the GFDL has. Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. 3. Despite the compromise above, GFDL'd documentation is still not free of trouble: as an example, it is incompatible with the major free software licenses, which means that GFDL'd text can't be incorporated into free programs. For this reason, we encourage documentation authors to license their works (or dual-license, together with the GFDL) under a well known free software license like the the GPL or the BSD license. Problems of the GFDL I. The DRM Restriction Section 2 (Verbatim Copying) of the GFDL goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to technical measures to obstruct or control reading and copying. This means that: (a) It is not limited to the act of distribution (i.e., it applies to private copies as well). (b) It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time. (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions. Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. This is a serious additional restriction. II. Transparent And Opaque Copies Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for download at a publicly accessible location for one year after the last distribution of the opaque form. It is our belief that as long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is required of you. It is up to the user whether to download the transparent form. The requirements for
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Matthew Garrett [EMAIL PROTECTED] writes: Merle Ray [EMAIL PROTECTED] wrote: Would ftpmasters and mirror operators be able to either include a machine-readable Transparent copy along with each Opaque copy, or [...] ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public anyway? I thought similar source distribution requirements were a practical problem just now? Yes. It just requires a policy stating that each binary package must include a transparent copy. This isn't terribly difficult, it's just irritating. Given that I expect many people are about to upload non-free packages with GFDL documentation, it would probably be worthwhile to publicize this requirement more widely. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Hi, [[PGP Signed Part:Failed] Signature made Fri Jan 13 02:21:11 2006 CST using DSA key ID 330C4A75 Good signature from Martin F. Krafft [EMAIL PROTECTED] aka Martin F. Krafft (AERAsec GmbH) [EMAIL PROTECTED] aka Martin F. Krafft (Debian) [EMAIL PROTECTED] aka Martin F. Krafft (MB! Sudetia) [EMAIL PROTECTED] aka Martin F. Krafft (Uni Zuerich) [EMAIL PROTECTED] Note: This key has expired! [GNUPG:] KEYEXPIRED 1087729976 [GNUPG:] SIGEXPIRED deprecated-use-keyexpired-instead [GNUPG:] KEYEXPIRED 1087729976 [GNUPG:] SIGEXPIRED deprecated-use-keyexpired-instead [GNUPG:] KEYEXPIRED 1087729976 [GNUPG:] SIGEXPIRED deprecated-use-keyexpired-instead [GNUPG:] KEYEXPIRED 1087729976 [GNUPG:] SIGEXPIRED deprecated-use-keyexpired-instead [GNUPG:] SIG_ID j95dghI+sOZbzZzOznuUH+SEhtg 2006-01-13 1137140471 [GNUPG:] KEYEXPIRED 1087729976 [GNUPG:] SIGEXPIRED deprecated-use-keyexpired-instead [GNUPG:] KEYEXPIRED 1087729976 [GNUPG:] SIGEXPIRED deprecated-use-keyexpired-instead [GNUPG:] KEYEXPIRED 1087729976 [GNUPG:] SIGEXPIRED deprecated-use-keyexpired-instead [GNUPG:] EXPKEYSIG 220BC883330C4A75 Martin F. Krafft [EMAIL PROTECTED] [GNUPG:] VALIDSIG ACF49D3E1E1D5EE2B2035E53220BC883330C4A75 2006-01-13 1137140471 0 3 0 17 2 01 ACF49D3E1E1D5EE2B2035E53220BC883330C4A75 Primary key fingerprint: ACF4 9D3E 1E1D 5EE2 B203 5E53 220B C883 330C 4A75 ] manoj -- A gourmet who thinks of calories is like a tart that looks at her watch. James Beard Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
* MJ Ray [Tue, 10 Jan 2006 13:24:52 +]: Also, this fails to address the security ban and the forced Transparent downloads/availability. 'Cause this amendment is not about trying to engage in legal-type discussion about whether those two can be work-arounded or not. It's: we regard these two issues as bugs/misfunctions in the wording of the license, but they're non-RC for us and hence are willing to waive them for main. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Guy on cell: Yeah, I mean she's not easy to talk to, because, you know, she'll be like, What did you do this weekend? and I'll say, Nothing, but really I was fucking some other girl. -- http://www.overheardinnewyork.com/archives/003179.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
* Anthony Towns [Wed, 11 Jan 2006 14:45:19 +1000]: What documents would this effort actually let us keep, anyway? All the FSF stuff for glibc, gcc, make and so on includes invariant sections anyway, no? Right, FSF stuff goes away. OTOH, I feel utterly ashamed each time I imagine the possibility of the following conversation taking place: «Hey, fellow free software developer, thanks for writing such a cool program and releasing it under the GPL! I also see that you wrote excellent manual for it, nice! Uhm, I see it's licensed under the GFDL, why? Oh I see, these FSF folks that created the GPL told you that the GFDL is a reasonable license for documentation, and you fscking trusted them?! Bad move, guy. No unmodifiable sections you say? Bah, you know we in Debian care more about legalese than about being fair to the rest of the community. Errr, are you suggesting that we dishonor our High Levels Of License And Copyright Compliance and allow invariant-less in main? NO WAY MAN, GO AWAY. You can't relicense because lots of people contributed to it, some of whom have passed away? NOT MY PROBLEM. You'll be recommending Ubuntu instead of Debian from now on? HAH!, AS IF I CARE.» (Or in other words: perhaps it's only me, okay, but I can't help, at all, feel that ripping out of main documentation that their authors intended to be free, and made their best-effort to achieve that, like a form of betrayal. Apologies if this offends somebody, but it's the way I feel it, and can't do anything about it.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A lie can go round the world before the truth has got its boots on. -- Terry Pratchett signature.asc Description: Digital signature
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
* Adeodato Simó [EMAIL PROTECTED] [060112 15:09]: (Or in other words: perhaps it's only me, okay, but I can't help, at all, feel that ripping out of main documentation that their authors intended to be free, and made their best-effort to achieve that, like a form of betrayal. It is a form of betrayal. And this betrayal is on out side. But the betrayal is not that we exclude things out of main someone failed to make free software (we make this with programs most of the time, too), but the betrayal is that we did not inform them before so they could avoid that pitfalls. We (in the form of Debian) knew those problems since short after the GFDL came first up, we did nothing to inform people early due to false hope to get it solved in quiscence easier than confronting. We failed to take the steps early due to our inability to release in a timely manner even without removing/rewriting/relicesing things that slipped in. And in all this time people were trapped into this, partially even with invariant sections or even cover texts, causing real world problems for many. But should we really try to bury that betrayal by betraying our users and our priciples, letting stuff in that we promised not too. Hiding problems our users (and we ourself) will be faced with in the future? Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernhard R. Link [EMAIL PROTECTED] writes: * Adeodato Simó [EMAIL PROTECTED] [060112 15:09]: (Or in other words: perhaps it's only me, okay, but I can't help, at all, feel that ripping out of main documentation that their authors intended to be free, and made their best-effort to achieve that, like a form of betrayal. It is a form of betrayal. And this betrayal is on out side. But the betrayal is not that we exclude things out of main someone failed to make free software (we make this with programs most of the time, too), but the betrayal is that we did not inform them before so they could avoid that pitfalls. We (in the form of Debian) knew those problems since short after the GFDL came first up, we did nothing to inform people early due to false hope to get it solved in quiscence easier than confronting. We did do something about it. About a year before the release of Sarge, I discussed the GFDL issues with all my upstreams using GFDL manuals including Manoj's draft Position Statement, and I was hardly the only one doing this. The problems have been brought to public attention several times since the GFDL came into being, so people using the licence are likely to be at least peripherally aware of the issues. While it's true that we have tried to get it solved quietly, it's not true to say that we collectively did nothing. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDxomgVcFcaSW/uEgRAiasAKC+GqAmZLlt0uEg9coPMw6ITNJ3dQCg3VtG 3rYgVVUU9uAgDT5QSDac4OI= =STVn -END PGP SIGNATURE-
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Thu, Jan 12, 2006 at 03:06:49PM +0100, Adeodato Simó wrote: * Anthony Towns [Wed, 11 Jan 2006 14:45:19 +1000]: What documents would this effort actually let us keep, anyway? All the FSF stuff for glibc, gcc, make and so on includes invariant sections anyway, no? Right, FSF stuff goes away. OTOH, I feel utterly ashamed each time I imagine the possibility of the following conversation taking place: «Hey, fellow free software developer, thanks for writing such a cool program and releasing it under the GPL! I also see that you wrote excellent manual for it, nice! Uhm, I see it's licensed under the GFDL, why? Oh I see, these FSF folks that created the GPL told you that the GFDL is a reasonable license for documentation, and you fscking trusted them?! I would feel bad about that too, and I'd say that. But my next move would be to explain _why_ the GFDL is not free, rather than to laugh at them for thinking it is free. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Adeodato Simó, 2006-01-12 15:10:40 +0100 : [...] (Or in other words: perhaps it's only me, okay, but I can't help, at all, feel that ripping out of main documentation that their authors intended to be free, and made their best-effort to achieve that, like a form of betrayal. Apologies if this offends somebody, but it's the way I feel it, and can't do anything about it.) I tend to have another view. Debian is well-known for its strict adherence to principles of freedom, so distributing something in main carries a message that our users are free to use it under terms which are *at least* as permissive as what the DFSG specifies. Having invariant sections (or any other non-free stuff) in main could be seen as a betrayal of the people who chose the license. Roland. -- Roland Mas Why did the elephant cross the road? Because it was the chicken's day off.
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
I second the proposal quoted below. I'm following debian-vote through the archives, so if you wish to reply or comment to me specifically, CC me. Christopher Martin On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Simó wrote: Debian and the GNU Free Documentation License = This is the position of Debian Project about the GNU Free Documentation License as published by the Free Software Foundation: 1. We consider that the GNU Free Documentation License version 1.2 conflicts with traditional requirements for free software in a variety of ways, explained in detail in the Problems of the GFDL section below. The most grave of these problems are the so-called invariant sections, which are non-removable, non-modifiable parts of the document that the GFDL allows in works under this license. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, so this restriction is not acceptable for us. 2. We believe that works licensed under the GFDL that include no such unmodifiable sections do fully meet the spirit of the Debian Free Software Guidelines, and have a place in our distribution despite the other problems (minor, in comparison) that the GFDL has. Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. 3. Despite the compromise above, GFDL'd documentation is still not free of trouble: as an example, it is incompatible with the major free software licenses, which means that GFDL'd text can't be incorporated into free programs. For this reason, we encourage documentation authors to license their works (or dual-license, together with the GFDL) under a well known free software license like the the GPL or the BSD license. Problems of the GFDL I. The DRM Restriction Section 2 (Verbatim Copying) of the GFDL goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to technical measures to obstruct or control reading and copying. This means that: (a) It is not limited to the act of distribution (i.e., it applies to private copies as well). (b) It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time. (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions. Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. This is a serious additional restriction. II. Transparent And Opaque Copies Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for download at a publicly accessible location for one year after the last distribution of the opaque form. It is our belief that as long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is required of you. It is up to the user whether to download the transparent form. The requirements for redistributors should be to make sure the users can get the transparent form, not to force users to download the transparent form even if they don't want it. III. Invariant Sections This is the most troublesome part of the GFDL. The GNU FDL includes a number of conditions that apply to all modified versions that disallow modifications. Specifically, Section 4 of the GFDL describes the invariant sections that must be unaltered in their text and in their titles in any derived works. These invariant sections must be secondary sections; a secondary section is a named appendix or a front-matter section of the Document
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Thu, Jan 12, 2006 at 08:53:04PM +0100, Roland Mas wrote: Having invariant sections (or any other non-free stuff) in main could be seen as a betrayal of the people who chose the license. This is not about invariant sections. This is about the other bugs in the GFDL the FSF has not fixed (yet?) and ignoring them for one more release. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Le Jeu 12 Janvier 2006 22:28, Christopher Martin a écrit : I second the proposal quoted below. and I do the same. On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Simó wrote: Debian and the GNU Free Documentation License = This is the position of Debian Project about the GNU Free Documentation License as published by the Free Software Foundation: 1. We consider that the GNU Free Documentation License version 1.2 conflicts with traditional requirements for free software in a variety of ways, explained in detail in the Problems of the GFDL section below. The most grave of these problems are the so-called invariant sections, which are non-removable, non-modifiable parts of the document that the GFDL allows in works under this license. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, so this restriction is not acceptable for us. 2. We believe that works licensed under the GFDL that include no such unmodifiable sections do fully meet the spirit of the Debian Free Software Guidelines, and have a place in our distribution despite the other problems (minor, in comparison) that the GFDL has. Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. 3. Despite the compromise above, GFDL'd documentation is still not free of trouble: as an example, it is incompatible with the major free software licenses, which means that GFDL'd text can't be incorporated into free programs. For this reason, we encourage documentation authors to license their works (or dual-license, together with the GFDL) under a well known free software license like the the GPL or the BSD license. Problems of the GFDL I. The DRM Restriction Section 2 (Verbatim Copying) of the GFDL goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to technical measures to obstruct or control reading and copying. This means that: (a) It is not limited to the act of distribution (i.e., it applies to private copies as well). (b) It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time. (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions. Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. This is a serious additional restriction. II. Transparent And Opaque Copies Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for download at a publicly accessible location for one year after the last distribution of the opaque form. It is our belief that as long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is required of you. It is up to the user whether to download the transparent form. The requirements for redistributors should be to make sure the users can get the transparent form, not to force users to download the transparent form even if they don't want it. III. Invariant Sections This is the most troublesome part of the GFDL. The GNU FDL includes a number of conditions that apply to all modified versions that disallow modifications. Specifically, Section 4 of the GFDL describes the invariant sections that must be unaltered in their text and in their titles in any derived works. These invariant sections must be secondary sections; a secondary section is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
also sprach Adeodato Simó [EMAIL PROTECTED] [2006.01.10.0455 +0100]: Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. I'm a late entry to the thread, please excuse. If we kicked all GFDL out of main, how many upstreams would reconsider their choice of licence? None? Few? Some? Many? I am - that short of seconding dato's proposal, but I believe that Debian is also in a position to make the world a better place by asking upstreams to rethink. Or am I being completely naïve here? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! gilmour's guitar sounds good whether you've got a bottle of cider in your hand or a keyboard and a mouse. -- prof. bruce maxwell signature.asc Description: Digital signature (GPG/PGP)
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
martin f krafft wrote: also sprach Adeodato Simó [EMAIL PROTECTED] [2006.01.10.0455 +0100]: Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. I'm a late entry to the thread, please excuse. If we kicked all GFDL out of main, how many upstreams would reconsider their choice of licence? None? Few? Some? Many? I am - that short of seconding dato's proposal, but I believe that Debian is also in a position to make the world a better place by asking upstreams to rethink. Or am I being completely naïve here? You can second a proposal without voting for it if you just want to have it on the ballot! Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Le Ven 13 Janvier 2006 00:09, martin f krafft a écrit : also sprach Adeodato Simó [EMAIL PROTECTED] [2006.01.10.0455 +0100]: Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. I'm a late entry to the thread, please excuse. If we kicked all GFDL out of main, how many upstreams would reconsider their choice of licence? None? Few? Some? Many? The QT-KDE Team has contacted KDE people about the GFDL issue, and the answer has been very polite. I'll quote it here : There are no invariant sections in *any* KDE documentation. There are no Front-Cover texts, and there are no Back-Cover texts. *ALL* our documentation that uses the FDL is licensed under the following terms: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. (as you can see here, as an example, the first doc I come across) http://docs.kde.org/stable/en/kdebase/kxkb/ln-id2481641.html If you can find a specific example where this is not the case, please let me know, and I will sort it out. The FDL, with the above terms, is the only license currently in use in KDE, although there are some legacy documents licensed under the GPL. Before this goes any further, can you please show me where (and why) debian believes the GFDL *with no invariant sections and no front/back cover texts* is a non-free license? For the record, relicensing most of our documentation will be impossible. There are several people with stated objections to using the GPL for documentation, many people we have no way of contacting, and a couple who are no longer alive, which makes them fairly difficult to contact. -- Lauri Watts [EMAIL PROTECTED] (KDE) Of course, we answered to his questions about the issues of GFDL and the possibility to use a BSD-style license for *new* documentation. Though, the last part of his mail is the one that has to be understood fully : relicensing of the KDE documentation is just *not humanly possible*. And since the licensing terms allow us to chose any version of the GFDL = 1.1, I still hope that the transparent and DRM problems could be solved in a later version. I am - that short of seconding dato's proposal, but I believe that Debian is also in a position to make the world a better place by asking upstreams to rethink. Or am I being completely naïve here? Well, it's true that we could make some upstreams rethink, but it's also a fact that KDE, GNOME, or such projects won't be able to do such an effort. And taking that documentation away, may make the world a worse place for users that need that documentation. And please, I don't want to see answers saying that the documentation can be put in non-free, because, due the the debian policy, `kde` meta-package (same is true for gnome) beeing in main, cannot depend upon the non free kde docs (since that would make it live in contrib, which is IMHO not an option). So that means that unaware users won't have the docs installed when the 'apt-get install kde' (or aptitude install gnome, or dselect whatever). Given the fact that I really think that users that would need applications manuals the most, are often the one that are the most unaware of debian packaging considerations, we would just have a lot of users, desperately pushing their [F1] key, without seeing anything coming. While the Invariant parts *is* really problematic, the DRM and transparent copies things are really a small detail, compared to the suffering of the user that desperately try to configure his browser to use the god**m proxy without the doc ``that the debian guru didn't packaged because after all it's on the net''. Of course I'm exaggerating, but really .. what is simpler ? hitting [F1] (or Help - Contents) ? or trying to find the fscking upstream page of a project that have the brilliant idea to be named after an english word, so that google won't be able to help us to find that fscking page before the 23094th result ? you can also read about it in my recent blog post about it [1] [1] http://blog.madism.org/index.php/2006/01/12/48-gfdl-the-license-that-sks -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpcVCDrKowdi.pgp Description: PGP signature
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Simó wrote: I propose an amendment to this GR, consisting in replacing the existing text with the one below. I initially tried to follow Seconded. Hamish ---8--- Debian and the GNU Free Documentation License = This is the position of Debian Project about the GNU Free Documentation License as published by the Free Software Foundation: 1. We consider that the GNU Free Documentation License version 1.2 conflicts with traditional requirements for free software in a variety of ways, explained in detail in the Problems of the GFDL section below. The most grave of these problems are the so-called invariant sections, which are non-removable, non-modifiable parts of the document that the GFDL allows in works under this license. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, so this restriction is not acceptable for us. 2. We believe that works licensed under the GFDL that include no such unmodifiable sections do fully meet the spirit of the Debian Free Software Guidelines, and have a place in our distribution despite the other problems (minor, in comparison) that the GFDL has. Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. 3. Despite the compromise above, GFDL'd documentation is still not free of trouble: as an example, it is incompatible with the major free software licenses, which means that GFDL'd text can't be incorporated into free programs. For this reason, we encourage documentation authors to license their works (or dual-license, together with the GFDL) under a well known free software license like the the GPL or the BSD license. Problems of the GFDL I. The DRM Restriction Section 2 (Verbatim Copying) of the GFDL goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to technical measures to obstruct or control reading and copying. This means that: (a) It is not limited to the act of distribution (i.e., it applies to private copies as well). (b) It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time. (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions. Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. This is a serious additional restriction. II. Transparent And Opaque Copies Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for download at a publicly accessible location for one year after the last distribution of the opaque form. It is our belief that as long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is required of you. It is up to the user whether to download the transparent form. The requirements for redistributors should be to make sure the users can get the transparent form, not to force users to download the transparent form even if they don't want it. III. Invariant Sections This is the most troublesome part of the GFDL. The GNU FDL includes a number of conditions that apply to all modified versions that disallow modifications. Specifically, Section 4 of the GFDL describes the invariant sections that must be unaltered in their text and in their titles in any derived works. These invariant sections must be secondary sections;
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Fri, Jan 13, 2006 at 12:33:36AM +0100, Pierre Habouzit wrote: And please, I don't want to see answers saying that the documentation can be put in non-free, because, due the the debian policy, `kde` meta-package (same is true for gnome) beeing in main, cannot depend upon the non free kde docs (since that would make it live in contrib, which is IMHO not an option). Dependencies aren't the only way of getting things installed; Enhances: fields and Task: fields allow things to be automatically selected only if the user's indicated they're happy to have non-free software installed, eg. We've got just under a year to improve our tools to cope with that properly before our next release, and make sure that: So that means that unaware users won't have the docs installed when the 'apt-get install kde' (or aptitude install gnome, or dselect whatever). ...is not the case. (Note that the Task:-style setup beats the Depends: setup for metapackages because it means that when one of the packages in the grouping breaks, the grouping can continue to function even after the RMs pull the broken package out of testing) Cheers, aj signature.asc Description: Digital signature
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Seconded. On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Simó wrote: Debian and the GNU Free Documentation License = This is the position of Debian Project about the GNU Free Documentation License as published by the Free Software Foundation: 1. We consider that the GNU Free Documentation License version 1.2 conflicts with traditional requirements for free software in a variety of ways, explained in detail in the Problems of the GFDL section below. The most grave of these problems are the so-called invariant sections, which are non-removable, non-modifiable parts of the document that the GFDL allows in works under this license. However, modifiability is a fundamental requirement of the Debian Free Software Guidelines, so this restriction is not acceptable for us. 2. We believe that works licensed under the GFDL that include no such unmodifiable sections do fully meet the spirit of the Debian Free Software Guidelines, and have a place in our distribution despite the other problems (minor, in comparison) that the GFDL has. Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. 3. Despite the compromise above, GFDL'd documentation is still not free of trouble: as an example, it is incompatible with the major free software licenses, which means that GFDL'd text can't be incorporated into free programs. For this reason, we encourage documentation authors to license their works (or dual-license, together with the GFDL) under a well known free software license like the the GPL or the BSD license. Problems of the GFDL I. The DRM Restriction Section 2 (Verbatim Copying) of the GFDL goes beyond the traditional source requirement in copyleft licenses in an important way: according to the GFDL no copy may ever be subject to technical measures to obstruct or control reading and copying. This means that: (a) It is not limited to the act of distribution (i.e., it applies to private copies as well). (b) It rules out the possibility that a version be distributed on some form of DRM media (for technical reasons, perhaps), even while providing source (i.e., a transparent copy) in an unencumbered way at the same time. (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions. Consider that the GFDL currently prohibits distribution on DRM media, as compared to the GPL which requires distribution on non-DRM media. This is a serious additional restriction. II. Transparent And Opaque Copies Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). Instead, the GFDL insists that you must somehow include a machine-readable Transparent copy (i.e., not allow the opaque form to be downloaded without the transparent form) or keep the transparent form available for download at a publicly accessible location for one year after the last distribution of the opaque form. It is our belief that as long as you make the source and binaries available so that the users can see what's available and take what they want, you have done what is required of you. It is up to the user whether to download the transparent form. The requirements for redistributors should be to make sure the users can get the transparent form, not to force users to download the transparent form even if they don't want it. III. Invariant Sections This is the most troublesome part of the GFDL. The GNU FDL includes a number of conditions that apply to all modified versions that disallow modifications. Specifically, Section 4 of the GFDL describes the invariant sections that must be unaltered in their text and in their titles in any derived works. These invariant sections must be secondary sections; a secondary section is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
Adeodato Sim=C3=B3 Formally, the Debian Project will include in the main section of its distribution works licensed under the GNU Free Documentation License that include no Invariant Sections, no Cover Texts, no Acknowledgements, and no Dedications, unless permission to remove them is granted. Section 4 creates other sections which are restricted-modification. Should there be permission to remove those too? Also, this fails to address the security ban and the forced Transparent downloads/availability. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
* Anthony Towns [Tue, 10 Jan 2006 16:24:47 +1000]:
On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Simó wrote:
II. Transparent And Opaque Copies
Section 3 (Copying in Quantity) of the GFDL states that it is not
enough to just put a transparent copy of a document alongside with the
opaque version when you are distributing it (which is all that you
need to do for sources under the GPL, for example).
The way we distribute source and binaries doesn't meet this requirement;
so allowing this seems like it implies a pretty serious change to
how we manage source, one way or another. The way things works at the
moment, we'd have to interpret that as a prohibition (for our purposes)
on distributing compiled GFDL docs, which presumably would (for our
purposes) violate the must allow distribution in ... compiled form
requirement of the DFSG.
Well, this assuming that distributing the source in the same directory
as the compiled form does not satisfy the gfdl's along with (I'm
sure some -legal person will be able to teach me proper English); but
if this is the case, I don't understand why the same distribution
method does magically not infringe the license terms if the section is
non-free as oppsed to main ('cause stuff in non-free has to be at
least legally distributable by us).
IOW, why does this matter for main and not for non-free?
(And if determined that it's not okay, then one can go with the or
state in or with each Opaque copy a [...] location [...] to download
[...] protocols a complete Transparent copy of the Document clause.
I'd say a maintainer is taking take reasonably prudent steps if they
include in debian/copyright (1) the upstream url, (2) the url for
ftp.d.o:/pool/sourcepkg, (3) an url for archive.d.o, (4) an url for
snapshot.d.n.)
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Ana Belén - Puerto viejo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Wed, Jan 11, 2006 at 02:42:00AM +0100, Adeodato Sim?? wrote:
* Anthony Towns [Tue, 10 Jan 2006 16:24:47 +1000]:
II. Transparent And Opaque Copies
The way we distribute source and binaries doesn't meet this requirement;
Well, this assuming that distributing the source in the same directory
as the compiled form does not satisfy the gfdl's along with (I'm
sure some -legal person will be able to teach me proper English);
It's not the along with, it's the include .. with each opaque
copy. Having a separate file on the archive doesn't include the source
with the binaries. Maybe that's ambiguous though, in which case an
indication from an FSF lawyer of the correct interpretation should
be fine.
but
if this is the case, I don't understand why the same distribution
method does magically not infringe the license terms if the section is
non-free as oppsed to main ('cause stuff in non-free has to be at
least legally distributable by us).
Because in non-free, we'll jump through whatever hoops are necessary
-- whether that be getting Debian-specific permission, only letting
some particular authorised maintainers build debs, only distributing
official binaries, not autobuilding, whatever.
(And if determined that it's not okay, then one can go with the or
state in or with each Opaque copy a [...] location [...] to download
[...] protocols a complete Transparent copy of the Document clause.
I'd say a maintainer is taking take reasonably prudent steps if they
include in debian/copyright (1) the upstream url, (2) the url for
ftp.d.o:/pool/sourcepkg, (3) an url for archive.d.o, (4) an url for
snapshot.d.n.)
The upstream url doesn't include any Debian changes, source files in
the pool don't stay around for a week after the debs are gone let alone
a year, and archive.debian.org only includes the last stable release
of software, not stuff that's uploaded to unstable but is removed from
the archive before being released, eg. I don't think snapshot.d.n is
reliable enough to rely on for license terms; for instance it's currently
supposedly missing about a year's worth of data between 2004/02/27 and
2005/03/12.
The morgue on ftp-master, which includes debs and sources going back to
July is about 175G (ie, the size of the archive again), six months of
the 2004 morgue (2004-02 to 2004-07) that happens to only include source
makes up 16G; so a year's archive (the GFDL's term) could be up to 50G,
while three year's source archives (the GPL's term) would probably be up
to 200G. It's probably /possible/ to do that, but it seems like a fair
bit of work to maintain reliably (which would detract from time spent
doing work actually necessary to release), and it seems like we ought to
have that work done first before saying GFDL stuff should just include
a link to /blah/.
What documents would this effort actually let us keep, anyway? All the
FSF stuff for glibc, gcc, make and so on includes invariant sections
anyway, no?
Cheers,
aj
signature.asc
Description: Digital signature
Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)
On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Simó wrote: I propose an amendment to this GR, consisting in replacing the existing text with the one below. (The purpose being to indicate the GFDL only needs to be in non-free due to invariant sections. This would be nice if it were true; it's not clear to me that it is though) Problems of the GFDL It'd seem like a good idea to split it into why the GFDL is non-free and other problems of the GFDL that ought to be fixed, but don't really bother us. I. The DRM Restriction (c) As written, it would outlaw actions like changing the permission of a copy of the document on your machine, storing it on an encrypted file system, distributing a copy over an encrypted link (Obstruct or control the reading is not clarified to apply merely to the recipient), or even storing it on a file-sharing system with non-world-readable permissions. If we're taking this literally, this seems to make it non-free to me by restricting how it can actually be used. I guess I'm not personally opposed to just pretending it doesn't exist, but... II. Transparent And Opaque Copies Section 3 (Copying in Quantity) of the GFDL states that it is not enough to just put a transparent copy of a document alongside with the opaque version when you are distributing it (which is all that you need to do for sources under the GPL, for example). The way we distribute source and binaries doesn't meet this requirement; so allowing this seems like it implies a pretty serious change to how we manage source, one way or another. The way things works at the moment, we'd have to interpret that as a prohibition (for our purposes) on distributing compiled GFDL docs, which presumably would (for our purposes) violate the must allow distribution in ... compiled form requirement of the DFSG. Changing the way things work at the moment isn't necessarily out of the question, but seems a lot of hassle when it won't save the FSF GFDL docs that usually do include invariant sections anyway. Cheers, aj signature.asc Description: Digital signature
