Re: GFDL GR: Amendment: no significant invariant sections in main
* Osamu Aoki [Sun, 12 Feb 2006 10:22:11 +0900]: Thus, let me propose an amendment to Adeodato Simó's proposal: s/include no invariant sections/don't include any significant contents to prevent our Freedom in invariant sections/ and matching changes to the text. In case it's necessary: sorry, I don't accept this modification into my proposed wording. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Pasión Vega - Lunares signature.asc Description: Digital signature
Re: GFDL GR: Amendment: no significant invariant sections in main
Le Dim 12 Février 2006 02:22, Osamu Aoki a écrit : Hi, I second Adeodato Simó's proposal but at the same time I consider it still leaves some spaces for the absolutism interpretation which tends to plague Debian. I consider we should have reasonable space for judgment for many things in life. Let's consider a documentation written in the SGML and released under GFDL in which invariant section is claimed but its invariant section is in commented-out section which contain nothing but list of author name and their contact e-mail address. This is a really possible case since people consider putting their e-mail addresses in printable contents tends to cause headache with spams. GFDL blah, blah,... Invariant section being following comment section in SGML !-- chapter 1: author1_name [EMAIL PROTECTED] chapter 2: author2_name [EMAIL PROTECTED] -- Under literal rule of Adeodato Simó's proposal, above GFDL documentation can not be in main since author forgot to place removal rule for the content. I consider GFDL documentation with such non-significant contents should receive the same treatment as the invariant-less GFDL documentation. Other possible GFDL invariant section which, I consider, should be permitted is an advertisement clause by the author or publisher. I see no difference from 4 clause BSD license. Thus, let me propose an amendment to Adeodato Simó's proposal: s/include no invariant sections/don't include any significant contents to prevent our Freedom in invariant sections/ and matching changes to the text. So here is my proposal in full text: ---8 --- Debian and the GNU Free Documentation License = This is the position of the 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, since it allows for non-removable, non-modifiable parts to be present in documents licensed under it. Such parts are commonly referred to as invariant sections, and are described in Section 4 of the GFDL. As modifiability is a fundamental requirement of the Debian Free Software Guidelines, this restriction is not acceptable for us, and we cannot accept in our distribution works that include such unmodifiable content. 2. At the same time, we also consider that works licensed under the GNU Free Documentation License that don't include any significant contents to prevent our Freedom in invariant sections do fully meet the requirements of the Debian Free Software Guidelines. This means that works that don't include any significant contents to prevent our Freedom in Invariant Sections, Cover Texts, Acknowledgements, and Dedications (or that do, but permission to remove them is explicitly granted), are suitable for the main component of our distribution. 3. Despite the above, GFDL'd documentation is still not free of trouble, even for works with no invariant sections: 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 the same terms as the software they refer to, or any of the traditional free software licenses like the the GPL or the BSD license. my understanding of this is that it's a minor problem, that upstreams are likely to solve easily. I hope dato won't accept that as a amendment of his proposal, because I think it changes it spirit a lot, and I won't second it. There is no need to draw a blurry line, for problems that a maintainer and upstream are really likely to solve in peace. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpCuJkDEFt5c.pgp Description: PGP signature
Re: GFDL GR: Amendment: no significant invariant sections in main
also sprach Osamu Aoki [EMAIL PROTECTED] [2006.02.12.0222 +0100]: s/include no invariant sections/don't include any significant contents to prevent our Freedom in invariant sections/ and matching changes to the text. I think this sounds incredibly vague and leaves significant up in the air for interpretation. We are possibly asking for more trouble with this, IMHO. Please do not be angry if I do not second it. -- 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! women can keep a secret just as well as men, but it takes more of them to do it. signature.asc Description: Digital signature (GPG/PGP)
GFDL GR: Amendment: no significant invariant sections in main
Hi, I second Adeodato Simó's proposal but at the same time I consider it still leaves some spaces for the absolutism interpretation which tends to plague Debian. I consider we should have reasonable space for judgment for many things in life. Let's consider a documentation written in the SGML and released under GFDL in which invariant section is claimed but its invariant section is in commented-out section which contain nothing but list of author name and their contact e-mail address. This is a really possible case since people consider putting their e-mail addresses in printable contents tends to cause headache with spams. GFDL blah, blah,... Invariant section being following comment section in SGML !-- chapter 1: author1_name [EMAIL PROTECTED] chapter 2: author2_name [EMAIL PROTECTED] -- Under literal rule of Adeodato Simó's proposal, above GFDL documentation can not be in main since author forgot to place removal rule for the content. I consider GFDL documentation with such non-significant contents should receive the same treatment as the invariant-less GFDL documentation. Other possible GFDL invariant section which, I consider, should be permitted is an advertisement clause by the author or publisher. I see no difference from 4 clause BSD license. Thus, let me propose an amendment to Adeodato Simó's proposal: s/include no invariant sections/don't include any significant contents to prevent our Freedom in invariant sections/ and matching changes to the text. So here is my proposal in full text: ---8--- Debian and the GNU Free Documentation License = This is the position of the 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, since it allows for non-removable, non-modifiable parts to be present in documents licensed under it. Such parts are commonly referred to as invariant sections, and are described in Section 4 of the GFDL. As modifiability is a fundamental requirement of the Debian Free Software Guidelines, this restriction is not acceptable for us, and we cannot accept in our distribution works that include such unmodifiable content. 2. At the same time, we also consider that works licensed under the GNU Free Documentation License that don't include any significant contents to prevent our Freedom in invariant sections do fully meet the requirements of the Debian Free Software Guidelines. This means that works that don't include any significant contents to prevent our Freedom in Invariant Sections, Cover Texts, Acknowledgements, and Dedications (or that do, but permission to remove them is explicitly granted), are suitable for the main component of our distribution. 3. Despite the above, GFDL'd documentation is still not free of trouble, even for works with no invariant sections: 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 the same terms as the software they refer to, or any of the traditional free software licenses like the the GPL or the BSD license. ---8--- I understand that this vaguer wording may be considered too lenient by some people when compered with Adeodato Simó's original proposal. I trust that we as a group are able to make rational judgment. This proposal should prevent any GFDL document with invariant section containing code or useful data to be in main. This is not the case with the literal text of Anton Zinoviev's proposal. To me, I could sympathize with some of his argument but the text of his proposal was too permissive since it gives blanket approval to GFDL. Osamu PS: Excuse me for late proposal. -- ~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ + Osamu Aoki [EMAIL PROTECTED] Yokohama Japan, GPG-key: A8061F32 .''`. Debian Reference: post-installation user's guide for non-developers : :' : http://qref.sf.net and http://people.debian.org/~osamu `. `' Our Priorities are Our Users and Free Software --- Social Contract signature.asc Description: Digital signature
Re: GFDL GR: Amendment: no significant invariant sections in main
On Sun, 12 Feb 2006 10:22:11 +0900, Osamu Aoki [EMAIL PROTECTED] said: [...] GFDL blah, blah,... Invariant section being following comment section in SGML !-- chapter 1: author1_name [EMAIL PROTECTED] chapter 2: author2_name [EMAIL PROTECTED] -- [...] This cannot be an invariant section as defined by the GFDL, because the GFDL says that an invariant section must be a secondary section, and a secondary section must be a named appendix. A source comment is not a named appendix. Such a document would have to be licensed under a license other than the GFDL. That said, I understand the motivation of Osamu's proposal, and I would consider invariant comments to be more acceptable than invariant portions of the documentation. (Of course, the line again gets a bit blurred when you consider documentation generated from the comments.) But I don't know whether I would consider it free or not. -- Hubert Chan [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GFDL GR: Amendment: no significant invariant sections in main
On Sat, Feb 11, 2006 at 07:14:22PM -0700, Hubert Chan wrote: On Sun, 12 Feb 2006 10:22:11 +0900, Osamu Aoki [EMAIL PROTECTED] said: [...] GFDL blah, blah,... Invariant section being following comment section in SGML !-- chapter 1: author1_name [EMAIL PROTECTED] chapter 2: author2_name [EMAIL PROTECTED] -- [...] Hmmm... my example may have been confusing. This cannot be an invariant section as defined by the GFDL, because the GFDL says that an invariant section must be a secondary section, and a secondary section must be a named appendix. A source comment is not a named appendix. You are talking Invariant Sections (capitalized) in GFDL. I, also Adeodato Simó I think, use lower case invariant section(s) which is combination of Invariant Sections, Cover Texts, Acknowledgements, and Dedications being invariant sections which suffer restriction in GFDL 4 MODIFICATIONS. Such a document would have to be licensed under a license other than the GFDL. That said, I understand the motivation of Osamu's proposal, and I would consider invariant comments to be more acceptable than invariant portions of the documentation. (Of course, the line again gets a bit blurred when you consider documentation generated from the comments.) That why we need some space for judgement based on each case. But I don't know whether I would consider it free or not. I do not either until I see real case. Osamu signature.asc Description: Digital signature
Re: GFDL GR: Amendment: no significant invariant sections in main
On Sun, Feb 12, 2006 at 11:58:14AM +0900, Osamu Aoki wrote: On Sat, Feb 11, 2006 at 07:14:22PM -0700, Hubert Chan wrote: On Sun, 12 Feb 2006 10:22:11 +0900, Osamu Aoki [EMAIL PROTECTED] said: [...] GFDL blah, blah,... Invariant section being following comment section in SGML !-- chapter 1: author1_name [EMAIL PROTECTED] chapter 2: author2_name [EMAIL PROTECTED] -- [...] Hmmm... my example may have been confusing. This cannot be an invariant section as defined by the GFDL, because the GFDL says that an invariant section must be a secondary section, and a secondary section must be a named appendix. A source comment is not a named appendix. You are talking Invariant Sections (capitalized) in GFDL. I, also Adeodato Simó I think, use lower case invariant section(s) which is combination of Invariant Sections, Cover Texts, Acknowledgements, and Dedications being invariant sections which suffer restriction in GFDL 4 MODIFICATIONS. Mmmm... I meant: You are talking Invariant Sections (capitalized) in GFDL. I, also Adeodato Simó I think, use lower case invariant section(s) which is combination of Invariant Sections, Cover Texts, Acknowledgements, and Dedications. The invariant sections suffer restriction in GFDL 4 MODIFICATIONS. Such a document would have to be licensed under a license other than the GFDL. That said, I understand the motivation of Osamu's proposal, and I would consider invariant comments to be more acceptable than invariant portions of the documentation. (Of course, the line again gets a bit blurred when you consider documentation generated from the comments.) That why we need some space for judgement based on each case. But I don't know whether I would consider it free or not. I do not either until I see real case. Osamu signature.asc Description: Digital signature
