Re: GR Proposal: GFDL statement

2006-01-25 Thread Lars Wirzenius
ke, 2006-01-25 kello 14:54 -0800, Jeff Carr kirjoitti:
 By this argument, the GPL must be removed or authors must allow anyone
 to modify it. Clearly the intent of the Debian community and the DFSG is
 not to require abandonment of the protections of the GPL.

This argument is old, wrong, and has been discussed already in this
thread. License texts themselves are the exception, it's necessary for
them to be allowed to be non-modifiable. Please don't repeat old
arguments, this discussion is unmanageably big already.

-- 
RFC 1437 - yet another MIME specification Microsoft ignores


-- 
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)

2006-01-17 Thread Andreas Metzler
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)

2006-01-15 Thread Andreas Metzler
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)

2006-01-15 Thread Bill Allombert
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)

2006-01-15 Thread Michael Banck
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)

2006-01-15 Thread Debian Project secretary
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: GR Proposal: GFDL statement

2006-01-14 Thread Pierre Habouzit
Le Ven 13 Janvier 2006 04:04, Anthony Towns a écrit :
 On Wed, Jan 11, 2006 at 09:53:43PM +1000, Anthony Towns wrote:
  On Fri, Jan 06, 2006 at 11:37:37AM +1000, Anthony Towns wrote:
   So, I've updated the wiki [0] in response to most of the
   suggestions on the list so far.
 
  Okay, given the lack of further response (except for dato's
  alternate proposal!), I've tweaked the wording one more time, and I
  think this is the final version. Seconds appreciated.

 So, we've had five seconds making this a formal proposal:

 Manoj Srivastava [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]

 Russ Allbery [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]

 Steve Langasek [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]

 Kalle Kivimaa [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]

 Roger Leigh [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]

 Dato's alternate proposal (which for the record I don't accept as an
 replacement of the original, which thus means it will be a separate
 option on the ballot if it receives sufficient seconds) has received
 three so far by my count:

 Christopher Martin [EMAIL PROTECTED]
 Message-Id: [EMAIL PROTECTED]

 Pierre Habouzit [EMAIL PROTECTED]
 Message-Id: [EMAIL PROTECTED]

 Hamish Moffatt [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]

you miss (at least) :

From: Martin Michlmayr [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]

From: Esteban Manchado =?iso-8859-1?Q?Vel=E1zquez?= [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]

From: Christian Perrier [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]

and a couple of others.



-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpRAdVjE8t0f.pgp
Description: PGP signature


Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)

2006-01-13 Thread martin f krafft
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)

2006-01-13 Thread Esteban Manchado Velázquez
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)

2006-01-13 Thread Moritz Muehlenhoff
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)

2006-01-13 Thread MJ Ray
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)

2006-01-13 Thread Matthew Garrett
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)

2006-01-13 Thread Martin Michlmayr
* 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)

2006-01-13 Thread Russ Allbery
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)

2006-01-13 Thread Manoj Srivastava
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: GR Proposal: GFDL statement

2006-01-12 Thread Kalle Kivimaa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Anthony Towns aj@azure.humbug.org.au writes:
 Okay, given the lack of further response (except for dato's alternate
 proposal!), I've tweaked the wording one more time, and I think this
 is the final version. Seconds appreciated.

 I propose the Debian project release the following statement on the GFDL:

Proposal below seconded.

 =

 Why the GNU Free Documentation License is not suitable for Debian main
 --

 Context
 ---

 Within the Debian community there has been a significant amount of concern
 about the GNU Free Documentation License (GFDL), and whether it is, in
 fact, a free license. This document attempts to explain why Debian's
 answer is that it is not free enough for the Debian distribution.

 It should be noted that this does not imply any hostility towards the
 Free Software Foundation, and does not mean that GFDL documentation
 should not be considered free enough by others. Debian itself will
 continue distributing GFDL documentation in its non-free section,
 which does not have such strict requirements.

 This document covers the GFDL version 1.2, which is the most current
 version at the time of writing. Earlier versions of the GFDL have similar,
 related problems.  

 What is the GFDL?
 -

 The GFDL is a license written by the Free Software Foundation, who
 use it as a license for their own documentation and promote it to
 others. Notably, it is also used as Wikipedia's license. The GFDL is a
 copyleft license in that modifications to documentation made under the
 GFDL must in turn be released under the GFDL, not some more restrictive
 license.  

 How does the GFDL fail to meet Debian's standards for Free Software?
 

 The GFDL conflicts with Debian's traditional requirements for free
 software in a variety of ways, some of which are expanded upon below. As
 a copyleft license, one of the consequences of this is that it is not
 possible to include content from GFDL documentation directly into free
 software.

 The major conflicts are:

   Unmodifiable Sections
   -

 The most troublesome conflict concerns the class of unmodifiable sections
 that, once included, may not be modified or removed from the documentation
 in the future. These are Cover Texts, Dedications, Acknowledgements,
 and Invariant Sections. Modifiability is a fundamental requirement of
 the DFSG, which states:

 3. Derived Works

 The license must allow modifications and derived works, and must
 allow them to be distributed under the same terms as the license of
 the original software.

 These components create particular problems in reusing small portions of
 the work (since any invariant sections must be included also, however
 large), and in making sure that documentation remains accurate and
 relevant.  

   Transparent Copies
   --

 The second conflict is related to the GFDL's requirements for transparent
 copies of documentation (that is, a copy of the documentation in a form
 suitable for editing). In particular, Section 3 of the GFDL requires
 that a transparent copy of the documentation be included with every
 opaque copy distributed, or that a transparent copy be made available
 for a year after the opaque copies are no longer being distributed.

 For free software works, Debian expects that simply providing the source
 (or transparent copy) alongside derivative works will be sufficient,
 and that users need not be forced to obtain the source with every copy
 of the binary they download, but this does not satisfy either clause of
 the GFDL's requirements.  

   Digital Rights Management
   -

 The third conflict with the GFDL arises from the measures in Section 2
 that attempt to overcome Digital Rights Management (DRM) technologies. In
 particular, the GFDL states that You may not use technical measures
 to obstruct or control the reading or further copying of the copies you
 make or distribute. This inhibits freedom in three ways: it limits use
 of the documentation as well as distribution, by covering all copies
 made, as well as copies distributed; it rules out distributing copies
 on DRM-protected media, even if done in such a way as to give users
 full access to a transparent copy of the work; and, as written, it also
 potentially disallows encrypting the documentation, or even storing
 it on a system that provides user restrictions or file permissions for
 the documentation.

 Why does documentation need to be Free Software?
 

 The question of Why does software need free documentation? has been
 addressed in the past by the Free Software Foundation in the essay
 _Free Software and Free Manuals_ [0].

 [0] 

Re: GR Proposal: GFDL statement

2006-01-12 Thread Roger Leigh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Anthony Towns aj@azure.humbug.org.au writes:

 On Fri, Jan 06, 2006 at 11:37:37AM +1000, Anthony Towns wrote:
 So, I've updated the wiki [0] in response to most of the suggestions
 on the list so far.

 Okay, given the lack of further response (except for dato's alternate
 proposal!), I've tweaked the wording one more time, and I think this
 is the final version. Seconds appreciated.

Seconded.

 I propose the Debian project release the following statement on the GFDL:

 =

 Why the GNU Free Documentation License is not suitable for Debian main
 --

 Context
 ---

 Within the Debian community there has been a significant amount of concern
 about the GNU Free Documentation License (GFDL), and whether it is, in
 fact, a free license. This document attempts to explain why Debian's
 answer is that it is not free enough for the Debian distribution.

 It should be noted that this does not imply any hostility towards the
 Free Software Foundation, and does not mean that GFDL documentation
 should not be considered free enough by others. Debian itself will
 continue distributing GFDL documentation in its non-free section,
 which does not have such strict requirements.

 This document covers the GFDL version 1.2, which is the most current
 version at the time of writing. Earlier versions of the GFDL have similar,
 related problems.  

 What is the GFDL?
 -

 The GFDL is a license written by the Free Software Foundation, who
 use it as a license for their own documentation and promote it to
 others. Notably, it is also used as Wikipedia's license. The GFDL is a
 copyleft license in that modifications to documentation made under the
 GFDL must in turn be released under the GFDL, not some more restrictive
 license.  

 How does the GFDL fail to meet Debian's standards for Free Software?
 

 The GFDL conflicts with Debian's traditional requirements for free
 software in a variety of ways, some of which are expanded upon below. As
 a copyleft license, one of the consequences of this is that it is not
 possible to include content from GFDL documentation directly into free
 software.

 The major conflicts are:

   Unmodifiable Sections
   -

 The most troublesome conflict concerns the class of unmodifiable sections
 that, once included, may not be modified or removed from the documentation
 in the future. These are Cover Texts, Dedications, Acknowledgements,
 and Invariant Sections. Modifiability is a fundamental requirement of
 the DFSG, which states:

 3. Derived Works

 The license must allow modifications and derived works, and must
 allow them to be distributed under the same terms as the license of
 the original software.

 These components create particular problems in reusing small portions of
 the work (since any invariant sections must be included also, however
 large), and in making sure that documentation remains accurate and
 relevant.  

   Transparent Copies
   --

 The second conflict is related to the GFDL's requirements for transparent
 copies of documentation (that is, a copy of the documentation in a form
 suitable for editing). In particular, Section 3 of the GFDL requires
 that a transparent copy of the documentation be included with every
 opaque copy distributed, or that a transparent copy be made available
 for a year after the opaque copies are no longer being distributed.

 For free software works, Debian expects that simply providing the source
 (or transparent copy) alongside derivative works will be sufficient,
 and that users need not be forced to obtain the source with every copy
 of the binary they download, but this does not satisfy either clause of
 the GFDL's requirements.  

   Digital Rights Management
   -

 The third conflict with the GFDL arises from the measures in Section 2
 that attempt to overcome Digital Rights Management (DRM) technologies. In
 particular, the GFDL states that You may not use technical measures
 to obstruct or control the reading or further copying of the copies you
 make or distribute. This inhibits freedom in three ways: it limits use
 of the documentation as well as distribution, by covering all copies
 made, as well as copies distributed; it rules out distributing copies
 on DRM-protected media, even if done in such a way as to give users
 full access to a transparent copy of the work; and, as written, it also
 potentially disallows encrypting the documentation, or even storing
 it on a system that provides user restrictions or file permissions for
 the documentation.

 Why does documentation need to be Free Software?
 

 The question of Why does software need 

Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)

2006-01-12 Thread Adeodato Simó
* 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: GR Proposal: GFDL statement

2006-01-12 Thread Kalle Kivimaa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kalle Kivimaa [EMAIL PROTECTED] writes:
 Proposal below seconded.

It seems that my Gnus settings do not work correctly for most people
(including devotee), if I try to send out GPG'd ISO-8859-1 emails.
This should be verifiable by all.

Seconding the proposal below.

 =

 Why the GNU Free Documentation License is not suitable for Debian main
 --

 Context
 ---

 Within the Debian community there has been a significant amount of concern
 about the GNU Free Documentation License (GFDL), and whether it is, in
 fact, a free license. This document attempts to explain why Debian's
 answer is that it is not free enough for the Debian distribution.

 It should be noted that this does not imply any hostility towards the
 Free Software Foundation, and does not mean that GFDL documentation
 should not be considered free enough by others. Debian itself will
 continue distributing GFDL documentation in its non-free section,
 which does not have such strict requirements.

 This document covers the GFDL version 1.2, which is the most current
 version at the time of writing. Earlier versions of the GFDL have similar,
 related problems.  

 What is the GFDL?
 -

 The GFDL is a license written by the Free Software Foundation, who
 use it as a license for their own documentation and promote it to
 others. Notably, it is also used as Wikipedia's license. The GFDL is a
 copyleft license in that modifications to documentation made under the
 GFDL must in turn be released under the GFDL, not some more restrictive
 license.  

 How does the GFDL fail to meet Debian's standards for Free Software?
 

 The GFDL conflicts with Debian's traditional requirements for free
 software in a variety of ways, some of which are expanded upon below. As
 a copyleft license, one of the consequences of this is that it is not
 possible to include content from GFDL documentation directly into free
 software.

 The major conflicts are:

   Unmodifiable Sections
   -

 The most troublesome conflict concerns the class of unmodifiable sections
 that, once included, may not be modified or removed from the documentation
 in the future. These are Cover Texts, Dedications, Acknowledgements,
 and Invariant Sections. Modifiability is a fundamental requirement of
 the DFSG, which states:

 3. Derived Works

 The license must allow modifications and derived works, and must
 allow them to be distributed under the same terms as the license of
 the original software.

 These components create particular problems in reusing small portions of
 the work (since any invariant sections must be included also, however
 large), and in making sure that documentation remains accurate and
 relevant.  

   Transparent Copies
   --

 The second conflict is related to the GFDL's requirements for transparent
 copies of documentation (that is, a copy of the documentation in a form
 suitable for editing). In particular, Section 3 of the GFDL requires
 that a transparent copy of the documentation be included with every
 opaque copy distributed, or that a transparent copy be made available
 for a year after the opaque copies are no longer being distributed.

 For free software works, Debian expects that simply providing the source
 (or transparent copy) alongside derivative works will be sufficient,
 and that users need not be forced to obtain the source with every copy
 of the binary they download, but this does not satisfy either clause of
 the GFDL's requirements.  

   Digital Rights Management
   -

 The third conflict with the GFDL arises from the measures in Section 2
 that attempt to overcome Digital Rights Management (DRM) technologies. In
 particular, the GFDL states that You may not use technical measures
 to obstruct or control the reading or further copying of the copies you
 make or distribute. This inhibits freedom in three ways: it limits use
 of the documentation as well as distribution, by covering all copies
 made, as well as copies distributed; it rules out distributing copies
 on DRM-protected media, even if done in such a way as to give users
 full access to a transparent copy of the work; and, as written, it also
 potentially disallows encrypting the documentation, or even storing
 it on a system that provides user restrictions or file permissions for
 the documentation.

 Why does documentation need to be Free Software?
 

 The question of Why does software need free documentation? has been
 addressed in the past by the Free Software Foundation in the essay
 _Free Software and Free Manuals_ [0].

 [0] http://www.gnu.org/philosophy/free-doc.html

 There are a number 

Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)

2006-01-12 Thread Adeodato Simó
* 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)

2006-01-12 Thread Bernhard R. Link
* 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)

2006-01-12 Thread Roger Leigh
-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: GR Proposal: GFDL statement

2006-01-12 Thread Kevin B. McCarty
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Russ Allbery wrote:

 Well, that's a reason to second an amendment that says that the GFDL *is*
 DFSG-free, so that it's explicitly a choice, and so that a vote for more
 discussion is clearly not a vote for that position.
 
 However, what's kept me from seconding such a proposal for exactly this
 reason is that I keep seeing problems with how to phrase it, since just
 saying it's DFSG-free without addressing the contradictions between it
 and the DFSG isn't really a solution and results in a very unclear
 interpretation.
 
 I wonder if such a statement would essentially have to be a modification
 of the DFSG to add a special case for the GFDL.

In my opinion, as I already mentioned in -private, this is the case.
Otherwise any software, no matter how non-free, could conceivably be
voted into main by a General Resolution that received a simple
majority.  So I think that an amendment to explicitly permit
GFDL-licensed materials in main would require a 3:1 supermajority to
pass, as stated in http://www.debian.org/devel/constitution Section 4.1,
bullet points 5.2 and 5.3.

I guess that the decision of whether to require a 3:1 supermajority or
only a normal majority on such an amendment would be left up to the
secretary?

- --
Kevin B. McCarty [EMAIL PROTECTED]   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDxpsjfYxAIk+Dx1ERAvo8AKCpBr+Z5F4N3cqmJ1iAgZyLQ5XRjQCcDUEI
kq1K44bCaQ4DpSLd+ew+Fq4=
=p95r
-END PGP SIGNATURE-


-- 
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)

2006-01-12 Thread Wouter Verhelst
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)

2006-01-12 Thread Roland Mas
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)

2006-01-12 Thread Christopher Martin
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)

2006-01-12 Thread Michael Banck
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)

2006-01-12 Thread Pierre Habouzit
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)

2006-01-12 Thread martin f krafft
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)

2006-01-12 Thread Luk Claes
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)

2006-01-12 Thread Pierre Habouzit
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)

2006-01-12 Thread Hamish Moffatt
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: GR Proposal: GFDL statement

2006-01-12 Thread Anthony Towns
On Wed, Jan 11, 2006 at 09:53:43PM +1000, Anthony Towns wrote:
 On Fri, Jan 06, 2006 at 11:37:37AM +1000, Anthony Towns wrote:
  So, I've updated the wiki [0] in response to most of the suggestions
  on the list so far.
 Okay, given the lack of further response (except for dato's alternate
 proposal!), I've tweaked the wording one more time, and I think this
 is the final version. Seconds appreciated.

So, we've had five seconds making this a formal proposal:

Manoj Srivastava [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]

Russ Allbery [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]

Steve Langasek [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]

Kalle Kivimaa [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]

Roger Leigh [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]

Dato's alternate proposal (which for the record I don't accept as an replacement
of the original, which thus means it will be a separate option on the ballot if
it receives sufficient seconds) has received three so far by my count:

Christopher Martin [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]

Pierre Habouzit [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]

Hamish Moffatt [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]

Cheers,
aj



signature.asc
Description: Digital signature


Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)

2006-01-12 Thread Anthony Towns
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)

2006-01-12 Thread Wesley J. Landaker
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)

2006-01-11 Thread MJ Ray
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: GR Proposal: GFDL statement

2006-01-11 Thread Anthony Towns
On Fri, Jan 06, 2006 at 11:37:37AM +1000, Anthony Towns wrote:
 So, I've updated the wiki [0] in response to most of the suggestions
 on the list so far.

Okay, given the lack of further response (except for dato's alternate
proposal!), I've tweaked the wording one more time, and I think this
is the final version. Seconds appreciated.

I propose the Debian project release the following statement on the GFDL:

=

Why the GNU Free Documentation License is not suitable for Debian main
--

Context
---

Within the Debian community there has been a significant amount of concern
about the GNU Free Documentation License (GFDL), and whether it is, in
fact, a free license. This document attempts to explain why Debian's
answer is that it is not free enough for the Debian distribution.

It should be noted that this does not imply any hostility towards the
Free Software Foundation, and does not mean that GFDL documentation
should not be considered free enough by others. Debian itself will
continue distributing GFDL documentation in its non-free section,
which does not have such strict requirements.

This document covers the GFDL version 1.2, which is the most current
version at the time of writing. Earlier versions of the GFDL have similar,
related problems.  

What is the GFDL?
-

The GFDL is a license written by the Free Software Foundation, who
use it as a license for their own documentation and promote it to
others. Notably, it is also used as Wikipedia's license. The GFDL is a
copyleft license in that modifications to documentation made under the
GFDL must in turn be released under the GFDL, not some more restrictive
license.  

How does the GFDL fail to meet Debian's standards for Free Software?


The GFDL conflicts with Debian's traditional requirements for free
software in a variety of ways, some of which are expanded upon below. As
a copyleft license, one of the consequences of this is that it is not
possible to include content from GFDL documentation directly into free
software.

The major conflicts are:

  Unmodifiable Sections
  -

The most troublesome conflict concerns the class of unmodifiable sections
that, once included, may not be modified or removed from the documentation
in the future. These are Cover Texts, Dedications, Acknowledgements,
and Invariant Sections. Modifiability is a fundamental requirement of
the DFSG, which states:

3. Derived Works

The license must allow modifications and derived works, and must
allow them to be distributed under the same terms as the license of
the original software.

These components create particular problems in reusing small portions of
the work (since any invariant sections must be included also, however
large), and in making sure that documentation remains accurate and
relevant.  

  Transparent Copies
  --

The second conflict is related to the GFDL's requirements for transparent
copies of documentation (that is, a copy of the documentation in a form
suitable for editing). In particular, Section 3 of the GFDL requires
that a transparent copy of the documentation be included with every
opaque copy distributed, or that a transparent copy be made available
for a year after the opaque copies are no longer being distributed.

For free software works, Debian expects that simply providing the source
(or transparent copy) alongside derivative works will be sufficient,
and that users need not be forced to obtain the source with every copy
of the binary they download, but this does not satisfy either clause of
the GFDL's requirements.  

  Digital Rights Management
  -

The third conflict with the GFDL arises from the measures in Section 2
that attempt to overcome Digital Rights Management (DRM) technologies. In
particular, the GFDL states that You may not use technical measures
to obstruct or control the reading or further copying of the copies you
make or distribute. This inhibits freedom in three ways: it limits use
of the documentation as well as distribution, by covering all copies
made, as well as copies distributed; it rules out distributing copies
on DRM-protected media, even if done in such a way as to give users
full access to a transparent copy of the work; and, as written, it also
potentially disallows encrypting the documentation, or even storing
it on a system that provides user restrictions or file permissions for
the documentation.

Why does documentation need to be Free Software?


The question of Why does software need free documentation? has been
addressed in the past by the Free Software Foundation in the essay
_Free Software and Free Manuals_ [0].

[0] http://www.gnu.org/philosophy/free-doc.html

There 

Re: GR Proposal: GFDL statement

2006-01-11 Thread Russ Allbery
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I second the proposal quoted below.

Anthony Towns aj@azure.humbug.org.au writes:

 Why the GNU Free Documentation License is not suitable for Debian main
 --

 Context
 ---

 Within the Debian community there has been a significant amount of concern
 about the GNU Free Documentation License (GFDL), and whether it is, in
 fact, a free license. This document attempts to explain why Debian's
 answer is that it is not free enough for the Debian distribution.

 It should be noted that this does not imply any hostility towards the
 Free Software Foundation, and does not mean that GFDL documentation
 should not be considered free enough by others. Debian itself will
 continue distributing GFDL documentation in its non-free section,
 which does not have such strict requirements.

 This document covers the GFDL version 1.2, which is the most current
 version at the time of writing. Earlier versions of the GFDL have similar,
 related problems.  

 What is the GFDL?
 -

 The GFDL is a license written by the Free Software Foundation, who
 use it as a license for their own documentation and promote it to
 others. Notably, it is also used as Wikipedia's license. The GFDL is a
 copyleft license in that modifications to documentation made under the
 GFDL must in turn be released under the GFDL, not some more restrictive
 license.  

 How does the GFDL fail to meet Debian's standards for Free Software?
 

 The GFDL conflicts with Debian's traditional requirements for free
 software in a variety of ways, some of which are expanded upon below. As
 a copyleft license, one of the consequences of this is that it is not
 possible to include content from GFDL documentation directly into free
 software.

 The major conflicts are:

   Unmodifiable Sections
   -

 The most troublesome conflict concerns the class of unmodifiable sections
 that, once included, may not be modified or removed from the documentation
 in the future. These are Cover Texts, Dedications, Acknowledgements,
 and Invariant Sections. Modifiability is a fundamental requirement of
 the DFSG, which states:

 3. Derived Works

 The license must allow modifications and derived works, and must
 allow them to be distributed under the same terms as the license of
 the original software.

 These components create particular problems in reusing small portions of
 the work (since any invariant sections must be included also, however
 large), and in making sure that documentation remains accurate and
 relevant.  

   Transparent Copies
   --

 The second conflict is related to the GFDL's requirements for transparent
 copies of documentation (that is, a copy of the documentation in a form
 suitable for editing). In particular, Section 3 of the GFDL requires
 that a transparent copy of the documentation be included with every
 opaque copy distributed, or that a transparent copy be made available
 for a year after the opaque copies are no longer being distributed.

 For free software works, Debian expects that simply providing the source
 (or transparent copy) alongside derivative works will be sufficient,
 and that users need not be forced to obtain the source with every copy
 of the binary they download, but this does not satisfy either clause of
 the GFDL's requirements.  

   Digital Rights Management
   -

 The third conflict with the GFDL arises from the measures in Section 2
 that attempt to overcome Digital Rights Management (DRM) technologies. In
 particular, the GFDL states that You may not use technical measures
 to obstruct or control the reading or further copying of the copies you
 make or distribute. This inhibits freedom in three ways: it limits use
 of the documentation as well as distribution, by covering all copies
 made, as well as copies distributed; it rules out distributing copies
 on DRM-protected media, even if done in such a way as to give users
 full access to a transparent copy of the work; and, as written, it also
 potentially disallows encrypting the documentation, or even storing
 it on a system that provides user restrictions or file permissions for
 the documentation.

 Why does documentation need to be Free Software?
 

 The question of Why does software need free documentation? has been
 addressed in the past by the Free Software Foundation in the essay
 _Free Software and Free Manuals_ [0].

 [0] http://www.gnu.org/philosophy/free-doc.html

 There are a number of obvious differences between programs and
 documentation that often inspire people to ask why not simply have
 different standards for the two? For example, books are often written
 by individuals, while programs are written by teams, so proper credit
 for a 

Re: GR Proposal: GFDL statement

2006-01-11 Thread Thomas Bushnell BSG
Anthony Towns aj@azure.humbug.org.au writes:

 Okay, given the lack of further response (except for dato's alternate
 proposal!), I've tweaked the wording one more time, and I think this
 is the final version. Seconds appreciated.

 I propose the Debian project release the following statement on the GFDL:

I agree completely with this statement, and of course if it proceeds
to vote, will vote for it unless something even better comes along
(which I think is unlikely).

However, one thing gives me pause: if this goes to a vote, and the
vote is no, then what?  Some will interpret that as an official
statement by the Project that the GFDL does not violate the DFSG.
Sure, they will be wrong, but that doesn't stop people. :)

Is there another way we can proceed?  We have not in the past felt it
necessary to issue official statements like this about non-DFSG
licenses; why the exception in this particular case?

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-11 Thread Steve Langasek
On Wed, Jan 11, 2006 at 09:53:43PM +1000, Anthony Towns wrote:
 On Fri, Jan 06, 2006 at 11:37:37AM +1000, Anthony Towns wrote:
  So, I've updated the wiki [0] in response to most of the suggestions
  on the list so far.

 Okay, given the lack of further response (except for dato's alternate
 proposal!), I've tweaked the wording one more time, and I think this
 is the final version. Seconds appreciated.

 I propose the Debian project release the following statement on the GFDL:

Seconded.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/

 =
 
 Why the GNU Free Documentation License is not suitable for Debian main
 --
 
 Context
 ---
 
 Within the Debian community there has been a significant amount of concern
 about the GNU Free Documentation License (GFDL), and whether it is, in
 fact, a free license. This document attempts to explain why Debian's
 answer is that it is not free enough for the Debian distribution.
 
 It should be noted that this does not imply any hostility towards the
 Free Software Foundation, and does not mean that GFDL documentation
 should not be considered free enough by others. Debian itself will
 continue distributing GFDL documentation in its non-free section,
 which does not have such strict requirements.
 
 This document covers the GFDL version 1.2, which is the most current
 version at the time of writing. Earlier versions of the GFDL have similar,
 related problems.  
 
 What is the GFDL?
 -
 
 The GFDL is a license written by the Free Software Foundation, who
 use it as a license for their own documentation and promote it to
 others. Notably, it is also used as Wikipedia's license. The GFDL is a
 copyleft license in that modifications to documentation made under the
 GFDL must in turn be released under the GFDL, not some more restrictive
 license.  
 
 How does the GFDL fail to meet Debian's standards for Free Software?
 
 
 The GFDL conflicts with Debian's traditional requirements for free
 software in a variety of ways, some of which are expanded upon below. As
 a copyleft license, one of the consequences of this is that it is not
 possible to include content from GFDL documentation directly into free
 software.
 
 The major conflicts are:
 
   Unmodifiable Sections
   -
 
 The most troublesome conflict concerns the class of unmodifiable sections
 that, once included, may not be modified or removed from the documentation
 in the future. These are Cover Texts, Dedications, Acknowledgements,
 and Invariant Sections. Modifiability is a fundamental requirement of
 the DFSG, which states:
 
 3. Derived Works
 
 The license must allow modifications and derived works, and must
 allow them to be distributed under the same terms as the license of
 the original software.
 
 These components create particular problems in reusing small portions of
 the work (since any invariant sections must be included also, however
 large), and in making sure that documentation remains accurate and
 relevant.  
 
   Transparent Copies
   --
 
 The second conflict is related to the GFDL's requirements for transparent
 copies of documentation (that is, a copy of the documentation in a form
 suitable for editing). In particular, Section 3 of the GFDL requires
 that a transparent copy of the documentation be included with every
 opaque copy distributed, or that a transparent copy be made available
 for a year after the opaque copies are no longer being distributed.
 
 For free software works, Debian expects that simply providing the source
 (or transparent copy) alongside derivative works will be sufficient,
 and that users need not be forced to obtain the source with every copy
 of the binary they download, but this does not satisfy either clause of
 the GFDL's requirements.  
 
   Digital Rights Management
   -
 
 The third conflict with the GFDL arises from the measures in Section 2
 that attempt to overcome Digital Rights Management (DRM) technologies. In
 particular, the GFDL states that You may not use technical measures
 to obstruct or control the reading or further copying of the copies you
 make or distribute. This inhibits freedom in three ways: it limits use
 of the documentation as well as distribution, by covering all copies
 made, as well as copies distributed; it rules out distributing copies
 on DRM-protected media, even if done in such a way as to give users
 full access to a transparent copy of the work; and, as written, it also
 potentially disallows encrypting the documentation, or even storing
 it on 

Re: GR Proposal: GFDL statement

2006-01-11 Thread Russ Allbery
Thomas Bushnell BSG [EMAIL PROTECTED] writes:

 However, one thing gives me pause: if this goes to a vote, and the vote
 is no, then what?  Some will interpret that as an official statement
 by the Project that the GFDL does not violate the DFSG.  Sure, they will
 be wrong, but that doesn't stop people. :)

 Is there another way we can proceed?  We have not in the past felt it
 necessary to issue official statements like this about non-DFSG
 licenses; why the exception in this particular case?

Well, that's a reason to second an amendment that says that the GFDL *is*
DFSG-free, so that it's explicitly a choice, and so that a vote for more
discussion is clearly not a vote for that position.

However, what's kept me from seconding such a proposal for exactly this
reason is that I keep seeing problems with how to phrase it, since just
saying it's DFSG-free without addressing the contradictions between it
and the DFSG isn't really a solution and results in a very unclear
interpretation.

I wonder if such a statement would essentially have to be a modification
of the DFSG to add a special case for the GFDL.

-- 
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: GR Proposal: GFDL statement

2006-01-11 Thread Anthony Towns
On Wed, Jan 11, 2006 at 06:06:42PM -0800, Thomas Bushnell BSG wrote:
 However, one thing gives me pause: if this goes to a vote, and the
 vote is no, then what?  

The vote can't be no; at the moment it can either be The GFDL isn't
suitable for main for these reasons (unmodifiable, transparent, drm)
or Further discussion -- neither of which are no.

 Is there another way we can proceed?  We have not in the past felt it
 necessary to issue official statements like this about non-DFSG
 licenses; why the exception in this particular case?

We have: http://www.debian.org/News/1998/19981008

Why do it especially for this? Becuase licenses from the FSF have a
great deal of respect in the community, so the community deserves an
explanation if we're going to treat one of them as non-free.

Cheers,
aj



signature.asc
Description: Digital signature


Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)

2006-01-10 Thread Adeodato Simó
* 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: GR Proposal: GFDL statement

2006-01-10 Thread Benj. Mako Hill
quote who=Alexander (Sasha) Wait date=Thu, Jan 05, 2006 at 06:15:18PM 
-0500
 That pipeline will almost certainly be GFDL/CC-BY-SA.  It's really sad
 to see blood boil over these licenses.  Since I am talking to people
 at FSF  CC regularly, I would be more than happy to bring Debian
 concerns to both groups in a, hopefuly, productive fashion.If
 there's a desire for that, just get in touch with me.

Thanks for the offer but I don't think the issue is a real lack of
understanding between FSF, CC and Debian. There are officially delegated
and long term conversations between Debian and both CC and FSF.

Regards,
Mako

-- 
Benjamin Mako Hill
[EMAIL PROTECTED]
http://mako.cc/



Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)

2006-01-10 Thread Anthony Towns
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: GR Proposal: GFDL statement

2006-01-10 Thread Alexander (Sasha) Wait
On 1/10/06, Benj. Mako Hill [EMAIL PROTECTED] wrote:
 quote who=Alexander (Sasha) Wait date=Thu, Jan 05, 2006 at 06:15:18PM 
 -0500
  That pipeline will almost certainly be GFDL/CC-BY-SA.  It's really sad
  to see blood boil over these licenses.  Since I am talking to people
  at FSF  CC regularly, I would be more than happy to bring Debian
  concerns to both groups in a, hopefuly, productive fashion.If
  there's a desire for that, just get in touch with me.

 Thanks for the offer but I don't think the issue is a real lack of
 understanding between FSF, CC and Debian. There are officially delegated
 and long term conversations between Debian and both CC and FSF.

I look forward to seeing compatibility between GFDL and CC-BY-SA.  
It's even better to hear that both of these will be DFSG compliant!

Thanks,
Sasha
--
http://freelogy.org/wiki/User:AlexanderWait  (GnuPG ID 4153C516)



Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)

2006-01-09 Thread Adeodato Simó
* Anthony Towns [Sun, 01 Jan 2006 15:02:04 +1000]:

 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:

 ---
 Why the GNU Free Documentation License is not suitable for Debian main
 ~~

 (0) Summary

 Within the Debian community there has been a significant amount of concern
 about the GNU Free Documentation License (GFDL), and whether it is, in
 fact, a free license. This document attempts to explain why Debian's
 answer is no.

 It should be noted that this does not imply any hostility towards the
 Free Software Foundation, and does not mean that GFDL documentation
 should not be considered free enough by others, and Debian itself will
 continue distributing GFDL documentation in its non-free section.

 (1) What is the GFDL?

 The GFDL is a license written by the Free Software Foundation, who use
 it as a license for their own documentation, and promote it to others. It
 is also used as Wikipedia's license. To quote the GFDL's Preamble:

   The purpose of this License is to make a manual, textbook,
   or other functional and useful document free in the sense of
   freedom: to assure everyone the effective freedom to copy and
   redistribute it, with or without modifying it, either commercially or
   noncommercially. Secondarily, this License preserves for the author
   and publisher a way to get credit for their work, while not being
   considered responsible for modifications made by others.

   This License is a kind of copyleft, which means that derivative
   works of the document must themselves be free in the same sense. It
   complements the GNU General Public License, which is a copyleft license
   designed for free software.

 (2) How does it fail to meet Debian's standards for Free Software?

 The GFDL conflicts with traditional requirements for free software in
 a variety of ways, some of which are expanded upon below. As a copyleft
 license, one of the consequences of this is that it is not possible to
 include content from a documention directly into free software under
 the GFDL.

 The major conflicts are:

 (2.1) Invariant Sections

 The most troublesome conflict concerns the class of invariant sections
 that, once included, may not be modified or removed from the documentation
 in future. Modifiability is, however, a fundamental requirement of the
 DFSG, which states:

 3. Derived Works

 The license must allow modifications and derived works, and
 must allow them to be distributed under the same terms as the
 license of the original software.

 Invariant sections create particular problems in reusing small portions
 of the work (since any invariant sections must be included also,
 however large), and in making sure the documentation remains accurate
 and relevant.

 (2.2) Transparent Copies

 The second conflict is related to the GFDL's requirements for transparent
 copies of documentation (that is, a copy of the documentation in a form
 suitable for editing). In particular, Section 3 of the GFDL requires
 that a transparent copy of the documentation be included with every
 opaque copy distributed, or that a transparent copy is made available
 for a year after the opaque copies are no longer being distributed.

 For free software works, Debian expects that simply providing the source
 (or transparent copy) alongside derivative works will be sufficient,
 but this does not satisfy either clause of the GFDL's requirements.

 (2.3) Digital Rights Management

 The third conflict with the GFDL arises from the measures in Section 2
 that attempt to overcome Digital Rights Management (DRM) technologies. In
 particular, the GFDL states that You may not use technical measures
 to obstruct or control the reading or further copying of the copies you
 make or distribute. This inhibits freedom in three ways: it limits use
 of the documentation as well as distribution, by covering all copies
 made, as well as copies distributed; it rules out distributing copies
 on DRM-protected media, even if done in such a way as to give users
 full access to a transparent copy of the work; and, as written, it also
 potentially disallows encrypting the documentation, or even storing it
 on a filesystem that supports permissions.

 (3) Why does documentation need to be Free Software?

 There are a number of obvious differences between programs and
 documentation that often inspire people to ask why not simply have
 different standards for the two? For example, books are often written
 by individuals, while programs are written by teams, so proper credit
 for a book might be more important than proper credit for a program.

 On the other hand, free software is often 

Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)

2006-01-09 Thread Anthony Towns
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


Re: GR Proposal: GFDL statement

2006-01-07 Thread Andrew Suffield
On Thu, Jan 05, 2006 at 06:15:18PM -0500, Alexander (Sasha) Wait wrote:
 I hate proprietary academic publishing, so, 
 I'd like to see a pipeline from Academic Wikis to Academic Journals
 to Wikipedia.  That pipeline will almost certainly be GFDL/CC-BY-SA. 
 It's really sad to see blood boil over these licenses.  Since I am
 talking to people at FSF  CC regularly, I would be more than happy to
 bring Debian concerns to both groups in a, hopefuly, productive
 fashion.If there's a desire for that, just get in touch with me.

We've already talked to CC and they agreed to fix their licenses; 3.0
and later should be fine, when they're released (2.x never will be).

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- --  |


signature.asc
Description: Digital signature


Re: GR Proposal: GFDL statement

2006-01-07 Thread Alexander (Sasha) Wait
On 1/7/06, Andrew Suffield [EMAIL PROTECTED] wrote:
 We've already talked to CC and they agreed to fix their licenses; 3.0
 and later should be fine, when they're released (2.x never will be).

Well - it's a goal for CC  FSF to permit content to move freely
between CC-BY-SA and GFDL (or possibly simplified GFDL).  I'm happy
to help with that as an academic customer of these licenses that
would like to ensure the final result is usable by Debian.  I see the
relevant people at CC  FSF fairly regularly.

just let me know if I can help...
Sasha
--
http://freelogy.org/wiki/User:AlexanderWait  (GnuPG ID 4153C516)



Re: GR Proposal: GFDL statement

2006-01-05 Thread Stephane Bortzmeyer
On Tue, Jan 03, 2006 at 09:17:24PM -0500,
 Nathanael Nerode [EMAIL PROTECTED] wrote 
 a message of 19 lines which said:

 I think -legal came to a very definite consensus that licensing the
 documentation under the exact same license as the program was always
 the right thing to do.

I agree. In some countries (I checked for France), it is the default
(the documentation of a software is regarded as software).

 It saves *so* much trouble.

But not all documentation is attached to a software. For instance, if
I write a book Software development on Debian, releasing it under
the GFDL is still the reasonable thing to do.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-05 Thread Wouter Verhelst
On Thu, Jan 05, 2006 at 10:34:46AM +0100, Stephane Bortzmeyer wrote:
  It saves *so* much trouble.
 
 But not all documentation is attached to a software. For instance, if
 I write a book Software development on Debian, releasing it under
 the GFDL is still the reasonable thing to do.

Not if you want it to be part of Debian.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-05 Thread Stephane Bortzmeyer
On Thu, Jan 05, 2006 at 12:08:23PM +0100,
 Wouter Verhelst [EMAIL PROTECTED] wrote 
 a message of 15 lines which said:

  I write a book Software development on Debian, releasing it under
  the GFDL is still the reasonable thing to do.
 
 Not if you want it to be part of Debian.

It still works for the rest of the world which is large enough for my
Wikipedia contributions (GFDL) and my lectures (GFDL too).


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-05 Thread MJ Ray
Stephane Bortzmeyer [EMAIL PROTECTED]
 But not all documentation is attached to a software. For instance, if
 I write a book Software development on Debian, releasing it under
 the GFDL is still the reasonable thing to do.

It's reasonable if you want to attach adverts to it and allow others
to do so, while witholding the freedom to edit or remove those adverts.

If one wants to forbid all changes, then releasing under a CC-nd
licence is a reasonable action. Not free software, though, which is
what this list usually likes and a free software operating system
should have free software manuals.

-- 
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: GR Proposal: GFDL statement

2006-01-05 Thread Alexander (Sasha) Wait
On 1/5/06, MJ Ray [EMAIL PROTECTED] wrote:
 Stephane Bortzmeyer [EMAIL PROTECTED]
  But not all documentation is attached to a software. For instance, if
  I write a book Software development on Debian, releasing it under
  the GFDL is still the reasonable thing to do.

 It's reasonable if you want to attach adverts to it and allow others
 to do so, while witholding the freedom to edit or remove those adverts.

 If one wants to forbid all changes, then releasing under a CC-nd
 licence is. a reasonable action. Not free software, though, which is
 what this list usually likes and a free software operating system
 should have free software manuals.

I've been a Debian user for eight years.  I can count on one hand the
number of times I've used proprietary software in all of that time; 
well, unless you count helping people out by answering their (MS
Windows or MAC OS) questions or looking over their shoulder.   I'm
also working with Wikipedia, CC,  FSF on licensing issues.  I'm an
academic scientist.   I run a 70 processor cluster (Debian stable 
OpenSSI.) I do synthetic biology.  I work on Personal Genomics; my
mentor's article about the work is the cover story for January's
Scientific American.   I hate proprietary academic publishing, so, 
I'd like to see a pipeline from Academic Wikis to Academic Journals
to Wikipedia.  That pipeline will almost certainly be GFDL/CC-BY-SA. 
It's really sad to see blood boil over these licenses.  Since I am
talking to people at FSF  CC regularly, I would be more than happy to
bring Debian concerns to both groups in a, hopefuly, productive
fashion.If there's a desire for that, just get in touch with me.

Thanks, and Happy New Year,
Sasha

PS. I'm often on AIM/Google Talk as alexanderwait and or Freenode as
asw or await.
--
http://freelogy.org/wiki/User:AlexanderWait  (GnuPG ID 4153 C516)



Re: GR Proposal: GFDL statement

2006-01-05 Thread Michael Banck
On Thu, Jan 05, 2006 at 06:15:18PM -0500, Alexander (Sasha) Wait wrote:
 It's really sad to see blood boil over these licenses.  Since I am
 talking to people at FSF  CC regularly, I would be more than happy to
 bring Debian concerns to both groups in a, hopefuly, productive
 fashion.If there's a desire for that, just get in touch with me.

Thanks for your offer.  Mako Hill and Don Armstrong have been talking to
the FSF in that matter for some time now, I suggest you contact them
first to discuss whether this is likely to be of good use.


cheers,

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: GR Proposal: GFDL statement

2006-01-05 Thread Anthony Towns
On Tue, Jan 03, 2006 at 09:37:32AM +, MJ Ray wrote:
  [3] http://wiki.debian.org/GFDLPositionStatement
 That page says it is immutable.

You need to log in.

Cheers,
aj


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-05 Thread Anthony Towns
On Sun, Jan 01, 2006 at 03:02:04PM +1000, Anthony Towns wrote:
 It's based on Manoj's draft position statement [2] with some notable
 changes (an explicit why not just say docs != software section, a
 how can this be fixed section, a what is the GFDL? section, and
 reordering the major problems). I've put the above draft on the wiki
 [3] so people can tweak it.

So, I've updated the wiki [0] in response to most of the suggestions
on the list so far. Currently missing are decent explanations why the
non-invariant issues are DFSG problems, rather than just annoying;
and possibly additional text detailing more of the problems caused by
those issues.

I see there's some discussion going on in -private too.

Petter Reinholdtsen added the following note to the wiki in the section
on why documentation should be free:

] This section could use more work, to explain why standard texts, where 
] part of the value of a standard text is that it is not changed outside
] the standard process, and also why the difference between programs
] as stored and operational knowledge and documentation as non-operational
] knowledge (you can not execute a book. :) is not sufficient to treat
] text and programs differently.

Are there many standards under the GFDL (which is about documentation
after all) that this is important to mention? Even if it is, I'm not
sure we want to get into the everything must be DFSG free! side of
things rather than just the standards aren't crucial enough that they
warrant an exception to standards of freedom. Thoughts?

Cheers,
aj

[0] http://wiki.debian.org/GFDLPositionStatement



signature.asc
Description: Digital signature


Re: GR Proposal: GFDL statement

2006-01-04 Thread Brian May
Brian May [EMAIL PROTECTED]
 People tend to ask ... but can I really use a license such as the GPL
 for documentation? I thought GPL was for software only.
 
 Do we need to address this point?

I'm not sure. That's covered in the GPL FAQ and should be clear
from the definition of Program in the GPL.

-- 
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: GR Proposal: GFDL statement

2006-01-03 Thread MJ Ray
I suggest a few wording changes and additions to avoid some arguments
against the statement and to make it a little clearer.

I agree with earlier comments about adding the version number.

Anthony Towns aj@azure.humbug.org.au
 Within the Debian community there has been a significant amount of concern
 about the GNU Free Documentation License (GFDL), and whether it is, in
 fact, a free license. This document attempts to explain why Debian's
 answer is no.

s/free license/free software license acceptable for Debian's main
archive section/

 It should be noted that this does not imply any hostility towards the
 Free Software Foundation, and does not mean that GFDL documentation
 should not be considered free enough by others, and Debian itself will
 continue distributing GFDL documentation in its non-free section.
 
 (1) What is the GFDL?
 
 The GFDL is a license written by the Free Software Foundation, who use
 it as a license for their own documentation, and promote it to others. It
 is also used as Wikipedia's license. To quote the GFDL's Preamble:

I would be happier not to quote so much of the Preamble.
Why promote the FSF view of effective freedom if we disagree?

 (2) How does it fail to meet Debian's standards for Free Software?
 
 The GFDL conflicts with traditional requirements for free software in
 a variety of ways, some of which are expanded upon below. As a copyleft
 license, one of the consequences of this is that it is not possible to
 include content from a documention directly into free software under
 the GFDL.

s/traditional requirements for/the traditional definition of/

s/from a documentation/from documentation/ OR
s/from a documentation/from GFDL-licensed documentation/

s/GFDL/GPL/ ?

 The major conflicts are:
 
 (2.1) Invariant Sections
 
 The most troublesome conflict concerns the class of invariant sections
 that, once included, may not be modified or removed from the documentation
 in future. Modifiability is, however, a fundamental requirement of the
 DFSG, which states:
 
 3. Derived Works
=20
 The license must allow modifications and derived works, and
 must allow them to be distributed under the same terms as the
 license of the original software.
 
 Invariant sections create particular problems in reusing small portions
 of the work (since any invariant sections must be included also,
 however large), and in making sure the documentation remains accurate
 and relevant.

This doesn't cover the Encyclopedia Problem. I suggest adding:

Also, Invariant sections must be Secondary sections and contain
nothing that could fall directly within that overall subject
(FDL section 1).  So, it is possible to prevent reuse of some
documentation in other documentation by including an Invariant
section which covers part of its topic, and the blocking
Invariant section cannot be removed.

[...]
 Unfortunately this alone is not enough, as other clauses of the GFDL
 render all GFDL documentation non-free. As a consequence, other licenses
 should be investigated; generally it is probably simplest to choose
 either the GNU General Public License (for a copyleft license) or the
 BSD or MIT licenses (for a non-copyleft license).

I suggest a small rewording to avoid a GFDL non-free argument
and to suggest manuals are put under the program's own licence:

Unfortunately this alone is not enough, as other clauses of the GFDL
mean that no GFDL'd documentation is free software. So, other licences
should be considered: generally it is probably simplest to choose
the same licence as the program being documented, the GNU
General Public License (for a copyleft license) or a BSD- or
MIT/X11-style license (for a non-copyleft license).

 [...] I've put the above draft on the wiki
 [3] so people can tweak it.
 [3] http://wiki.debian.org/GFDLPositionStatement

That page says it is immutable.

Thanks,
-- 
MJ Ray - personal email, see http://mjr.towers.org.uk/email.html
Work: http://www.ttllp.co.uk/  irc.oftc.net/slef  Jabber/SIP ask


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-03 Thread Ian Jackson
Anthony Towns writes (GR Proposal: GFDL statement):
 Bcc'ed to -project, -legal and -private; followups to -vote please.
 
 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 support this proposal.  But, I don't think we go far enough in
disputing the need for a separate documentation licence:

The GPL-incompatibility of the GFDL is a serious problem.  While we're
making our point about the GFDL being DFSG-non-free, we should also
point out that while if it were made DFSG-free we would (have to)
accept it, we would strongly prefer that it simply be abolished.

So, I think this section:
 (3) Why does documentation need to be Free Software?
needs to be strengthened.  I don't have time right now to write a
suggested text I'm afraid.

Also,
 (4) How can this be fixed?

This section should be clarified and strengthened.  In particular, we
should encourage documentation authors to (at the moment) dual-licence
GDFL/GPL.  And we should tell the FSF that the Debian project would
prefer the FSF to drop the GFDL entirely.

Also, the summary needs a lot of work.  The summary should be good
enough that if you only read the summary you get the main points of
the article.  And it should avoid weaselphrases like `there has been a
significant amount of concern' because they just use up space which
would be valuable for putting our position.


I'll try to write something up today or tomorrow.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-03 Thread Manoj Srivastava
On Tue, 03 Jan 2006 09:37:32 +, MJ Ray [EMAIL PROTECTED] said: 

 I suggest a few wording changes and additions to avoid some
 arguments against the statement and to make it a little clearer.

 I agree with earlier comments about adding the version number.

 Anthony Towns aj@azure.humbug.org.au
 Within the Debian community there has been a significant amount of
 concern about the GNU Free Documentation License (GFDL), and
 whether it is, in fact, a free license. This document attempts to
 explain why Debian's answer is no.

 s/free license/free software license acceptable for Debian's
 main archive section/

I think this shall only bring up the distraction or arguments
 of what does one mwna by software. While some of us hold to the
 view that software is all that is cmputer related and not hardware or
 wetware. others hold to the narrower definition that software ==
 software programs.

That discussion is unlikely to be productive.

manoj
-- 
Support Mental Health.  Or I'll kill you.
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: GR Proposal: GFDL statement

2006-01-03 Thread Nathanael Nerode
Ian Jackson wrote:

 Also,
 (4) How can this be fixed?
 
 This section should be clarified and strengthened.  In particular, we
 should encourage documentation authors to (at the moment) dual-licence
 GDFL/GPL.

The recommendation is: License your documentation under the same license
as the program it goes with.  If you need to license under the GFDL for some
reason, dual-licence.

I think -legal came to a very definite consensus that licensing the
documentation under the exact same license as the program was always the
right thing to do.  It saves *so* much trouble.

-- 
ksig --random|


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-03 Thread Nathanael Nerode
Anthony Towns wrote:

 (2.1) Invariant Sections
 
 The most troublesome conflict concerns the class of invariant sections
 that, once included, may not be modified or removed from the documentation
 in future. Modifiability is, however, a fundamental requirement of the
 DFSG, which states:
 
 3. Derived Works
 
 The license must allow modifications and derived works, and
 must allow them to be distributed under the same terms as the
 license of the original software.
 
 Invariant sections create particular problems in reusing small portions
 of the work (since any invariant sections must be included also,
 however large), and in making sure the documentation remains accurate
 and relevant.

Please note the following:

Cover Texts create the same problems as Invariant Sections.

-- 
ksig --random|


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-03 Thread Brian May
On Tue, 2006-01-03 at 21:17 -0500, Nathanael Nerode wrote:
 The recommendation is: License your documentation under the same license
 as the program it goes with.  If you need to license under the GFDL for some
 reason, dual-licence.
 
 I think -legal came to a very definite consensus that licensing the
 documentation under the exact same license as the program was always the
 right thing to do.  It saves *so* much trouble.

People tend to ask ... but can I really use a license such as the GPL
for documentation? I thought GPL was for software only.

Do we need to address this point?
-- 
Brian May [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-02 Thread Thomas Bushnell BSG
Florian Weimer [EMAIL PROTECTED] writes:

 This GR effectively overrides decisions by the DPL and his delegates,
 and should mention this.

Which decisions?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-02 Thread Steve Langasek
On Sun, Jan 01, 2006 at 06:17:57PM -0800, Russ Allbery wrote:
 Manoj Srivastava [EMAIL PROTECTED] writes:

  The release team has spoken, and they decide what goes in a
   release.  If they have decided, under advice from debian-legal, that
   GFDL docs are RC bugs, then that is that.

 I've now also found:

 http://release.debian.org/removing-non-free-documentation

 which is basically the statement that I had been looking for.

 Given that, I'm not sure that a GR is really necessary, although I still
 don't think it could hurt.

I'm in favor of a GR because it gives us the means of measuring the
consensus within the project about *what* makes this a non-free license; the
release team is convinced that it's not a Free Software license, but I'd
rather have broad agreement about what *would* make it a free license before
we start telling people they need to change.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Re: GR Proposal: GFDL statement

2006-01-01 Thread Peter Samuelson

No substantive changes suggested, merely matters of style

[Anthony Towns]
 (0) Summary
 
 Within the Debian community there has been a significant amount of
 concern about the GNU Free Documentation License (GFDL), and whether
 it is, in fact, a free license. This document attempts to explain
 why Debian's answer is no.

As Russ said, it's best to clarify here that you mean the GFDL 1.2.

 license, one of the consequences of this is that it is not possible to
 include content from a documention directly into

a documention?  Perhaps ...from documentation.

 that, once included, may not be modified or removed from the documentation
 in future.

in the future, clearer.

 suitable for editing). In particular, Section 3 of the GFDL requires
 that a transparent copy of the documentation be included with every
 opaque copy distributed, or that a transparent copy is made available

Subjunctive police - copy be made available.  You got it right
earlier in the same sentence. (:

 In practice, then, documentation simply isn't different enough to
 warrant different standards: we still wish to provide source code in

different standards of freedoms we expect for our users - that is, I
think this point is strong enough to be worth stating more forcefully.
This seems to be the one major issue that separates Debian from the
FSF: I believe they already concede that the GFDL is not a free
*software* license.  It also seems to be the point most often contested
in the GFDL debates.  (Well, alongside the perennially popular non-
argument, What?!?  You dare call a FSF license non-free?  Heresy!)

 An easy first step is to not include the optional invariant sections in
 your documentation, since they are not required by the license, but are
 simply an option open to authors.

Probably should enumerate the types of invariant sections here - cover
texts in particular, and maybe dedications too.  (Are those considered
bad? since they are removable.)

 I've put the above draft on the wiki [3] so people can tweak it.
 [3] http://wiki.debian.org/GFDLPositionStatement

Since this has already been seconded as-is here, I thought it best to
comment here instead of making random unauthorised edits to a wiki.

Even so, I'd second this if I were a Debian developer.  Thanks for the
GR, AJ,

Peter


signature.asc
Description: Digital signature


Re: GR Proposal: GFDL statement

2006-01-01 Thread Wouter Verhelst
I'd like to propose a few, uh, editorial amendments ;-)

On Sun, Jan 01, 2006 at 03:02:04PM +1000, Anthony Towns wrote:
 ---
 Why the GNU Free Documentation License is not suitable for Debian main
 ~~
 
 (0) Summary
 
 Within the Debian community there has been a significant amount of concern
 about the GNU Free Documentation License (GFDL), and whether it is, in
 fact, a free license. This document attempts to explain why Debian's
 answer is no.
 
 It should be noted that this does not imply any hostility towards the
 Free Software Foundation, and does not mean that GFDL documentation
 should not be considered free enough by others, and Debian itself will
 continue distributing GFDL documentation in its non-free section.

I think the statement should contain a reference to current version or
version 1.2 and below in the above part. Rationale: even though the
text does mention the fact that these problems can be remedied by the
FSF by updating the GFDL, it is a fact that a long text is something
that not everyone will read head to bottom; those who will read it
diagonally might miss this (very important) bit of information, unless
it's mentioned in a part of the text that they will most likely not
miss, such as the title or a part designated Summary.

Perhaps retitle it to 

Why the current version of the GNU Free Documentation License is
not suitable for Debian main

 (1) What is the GFDL?
 
 The GFDL is a license written by the Free Software Foundation, who use
 it as a license for their own documentation, and promote it to others. It
 is also used as Wikipedia's license. To quote the GFDL's Preamble:
 
   The purpose of this License is to make a manual, textbook,
   or other functional and useful document free in the sense of
   freedom: to assure everyone the effective freedom to copy and
   redistribute it, with or without modifying it, either commercially or
   noncommercially. Secondarily, this License preserves for the author
   and publisher a way to get credit for their work, while not being
   considered responsible for modifications made by others.
 
   This License is a kind of copyleft, which means that derivative
   works of the document must themselves be free in the same sense. It
   complements the GNU General Public License, which is a copyleft license
   designed for free software.
 
 (2) How does it fail to meet Debian's standards for Free Software?
 
 The GFDL conflicts with traditional requirements for free software in
 a variety of ways, some of which are expanded upon below. As a copyleft
 license, one of the consequences of this is that it is not possible to
 include content from a documention directly into free software under

Not sure here (not a native English speaker), but can you say from a
documentation? Shouldn't that be either from documentation or from a
piece of documentation?

 the GFDL.
 
 The major conflicts are:
 
 (2.1) Invariant Sections
 
 The most troublesome conflict concerns the class of invariant sections
 that, once included, may not be modified or removed from the documentation
 in future. Modifiability is, however, a fundamental requirement of the
 DFSG, which states:
 
 3. Derived Works
 
 The license must allow modifications and derived works, and
 must allow them to be distributed under the same terms as the
 license of the original software.
 
 Invariant sections create particular problems in reusing small portions
 of the work (since any invariant sections must be included also,
 however large), and in making sure the documentation remains accurate
 and relevant.
 
 (2.2) Transparent Copies
 
 The second conflict is related to the GFDL's requirements for transparent
 copies of documentation (that is, a copy of the documentation in a form
 suitable for editing). In particular, Section 3 of the GFDL requires
 that a transparent copy of the documentation be included with every
 opaque copy distributed, or that a transparent copy is made available
 for a year after the opaque copies are no longer being distributed.
 
 For free software works, Debian expects that simply providing the source
 (or transparent copy) alongside derivative works will be sufficient,
 but this does not satisfy either clause of the GFDL's requirements.
 
 (2.3) Digital Rights Management
 
 The third conflict with the GFDL arises from the measures in Section 2
 that attempt to overcome Digital Rights Management (DRM) technologies. In
 particular, the GFDL states that You may not use technical measures
 to obstruct or control the reading or further copying of the copies you
 make or distribute. This inhibits freedom in three ways: it limits use
 of the documentation as well as distribution, by covering all copies
 made, as well as copies distributed; it rules out distributing copies
 on DRM-protected media, even if done in such a way as to give users
 full access to a 

Re: GR Proposal: GFDL statement

2006-01-01 Thread Anthony Towns
On Sun, Jan 01, 2006 at 04:25:37AM -0600, Peter Samuelson wrote:
 No substantive changes suggested, merely matters of style

...

 Since this has already been seconded as-is here, I thought it best to
 comment here instead of making random unauthorised edits to a wiki.

On Sun, Jan 01, 2006 at 11:28:16AM +0100, Wouter Verhelst wrote:
 Perhaps retitle it to 
   Why the current version of the GNU Free Documentation License is
   not suitable for Debian main

Why the GNU Free Documentation License 1.2 is not suitable for Debian main
is shorter; adding This document refers to version 1.2 of the GFDL. or similar
in the beginning could work too.

  The GFDL conflicts with traditional requirements for free software in
  a variety of ways, some of which are expanded upon below. As a copyleft
  license, one of the consequences of this is that it is not possible to
  include content from a documention directly into free software under
 
 Not sure here (not a native English speaker), but can you say from a
 documentation? Shouldn't that be either from documentation or from a
 piece of documentation?

Or from documentation or from a document, yeah.

  I've put the above draft on the wiki [3] so people can tweak it.
 I don't think that's a good idea. There's a fairly strict procedure for
 GR proposals, with amendments et al. You shouldn't try to work around
 that.

The wiki doesn't work around it -- all GR stuff has to go via -vote
or it's irrelevant for procedural purposes; it just means other people
can put their changes in directly and the software'll generate pretty
colourised diffs automatically.

I presume more substantive changes (and hence new seconds) will be needed
anyway, fwiw.

Cheers,
aj



signature.asc
Description: Digital signature


Re: GR Proposal: GFDL statement

2006-01-01 Thread Wouter Verhelst
On Sun, Jan 01, 2006 at 09:51:52PM +1000, Anthony Towns wrote:
[...]
 On Sun, Jan 01, 2006 at 11:28:16AM +0100, Wouter Verhelst wrote:
  Perhaps retitle it to 
  Why the current version of the GNU Free Documentation License is
  not suitable for Debian main
 
 Why the GNU Free Documentation License 1.2 is not suitable for Debian main
 is shorter;

Right; I suggested '1.2 or below', but it indeed isn't of any value to
refer to versions that've been declared obsolete by the FSF itself
anyway. Besides, 'current' isn't very helpful if the FSF decides to
bring out another version some time from now.

 adding This document refers to version 1.2 of the GFDL. or similar
 in the beginning could work too.

Agreed, if by in the beginning you mean in the summary (which I
assume you do).

[...]
   I've put the above draft on the wiki [3] so people can tweak it.
  I don't think that's a good idea. There's a fairly strict procedure for
  GR proposals, with amendments et al. You shouldn't try to work around
  that.
 
 The wiki doesn't work around it -- all GR stuff has to go via -vote
 or it's irrelevant for procedural purposes; it just means other people
 can put their changes in directly and the software'll generate pretty
 colourised diffs automatically.

Okay, as long as that's clear..

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-01 Thread Joey Hess
I'm confused. Where does it say that we have to go through the GR
process to issue a position statement for something the project has
already decided on?

-- 
see shy jo


signature.asc
Description: Digital signature


Re: GR Proposal: GFDL statement

2006-01-01 Thread Florian Weimer
* Anthony Towns:

 Bcc'ed to -project, -legal and -private; followups to -vote please.

 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:

This GR effectively overrides decisions by the DPL and his delegates,
and should mention this.

Apart from that, I've mixed feelings about it.  I don't know what's
really going on behind the scenes.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-01 Thread Roger Leigh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Russ Allbery [EMAIL PROTECTED] writes:

 Joey Hess [EMAIL PROTECTED] writes:

 I'm confused. Where does it say that we have to go through the GR
 process to issue a position statement for something the project has
 already decided on?

 How do we know the project has decided on it?

http://www.debian.org/vote/2004/vote_003
http://www.debian.org/vote/2004/vote_004

 Not a flippant question.  That's felt like it's been missing from these
 discussions, and certainly RMS has, in the past, questioned whether the
 project has really decided on it.  debian-legal is not a decision-making
 body.  I agree with your take on the consensus, but I know other people
 certainly have not.

The implication of those two votes is that the Project intends that
the 100% of the Debian system must comply with the DFSG.  Since it has
been proven that the GFDL is not a DFSG-free licence, the consequences
are clear.

If we do hold a GR over this decision, I won't be voting any
differently than I did in either of the above votes; my principles
haven't changed since last time I voted.


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/

iD8DBQFDuE75VcFcaSW/uEgRAifmAKDpfALDCjuoXuOrG4ooL40UrHQ39ACg0598
sUF8CwibbgqYW1Wpdu8UogU=
=4k8S
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2006-01-01 Thread Russ Allbery
Roger Leigh [EMAIL PROTECTED] writes:
 Russ Allbery [EMAIL PROTECTED] writes:
 Joey Hess [EMAIL PROTECTED] writes:

 I'm confused. Where does it say that we have to go through the GR
 process to issue a position statement for something the project has
 already decided on?

 How do we know the project has decided on it?

 http://www.debian.org/vote/2004/vote_003
 http://www.debian.org/vote/2004/vote_004

No, that's not what I'm talking about.

 The implication of those two votes is that the Project intends that
 the 100% of the Debian system must comply with the DFSG.  Since it has
 been proven that the GFDL is not a DFSG-free licence, the consequences
 are clear.

This is what I'm talking about.  Who has proven that the GFDL is not a
DFSG-free license?  Where is the project statement that the GFDL is not a
DFSG-free license?  Again, remember debian-legal is not a decision-making
body.  What about the Debian developers who have argued in debian-devel
that it *is* a DFSG-free license (perhaps under specific circumstances,
such as no invariant section use, or invariant sections used only for
copyright statements)?

I don't disagree with you that it is not a DFSG-free license.  I've been
convinced by the arguments stated (although *if no invariant sections are
used* I think the problems are mistakes in the way the license is phrased
rather than any real intent of the license -- not that that makes any
difference).  But other people clearly have not been, and I think it's
important to arrive at some closure on this with an official statement.

(Please don't respond to this message by reiterating what you feel is the
proof.  One, you'd be preaching to the choir, and two, you're unlikely to
convince anyone at this point since we've been down that path many times
already.)

Also, when communicating with upstream, I think it would be very good to
have an official statement to point them at if they have any questions.
Manoj's current summary is great, but it states pretty clearly that it's a
draft and is not a final statement.

 If we do hold a GR over this decision, I won't be voting any differently
 than I did in either of the above votes; my principles haven't changed
 since last time I voted.

I don't think anyone is asking you to.

-- 
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: GR Proposal: GFDL statement

2006-01-01 Thread Russ Allbery
Joey Hess [EMAIL PROTECTED] writes:

 I'm confused. Where does it say that we have to go through the GR
 process to issue a position statement for something the project has
 already decided on?

How do we know the project has decided on it?

Not a flippant question.  That's felt like it's been missing from these
discussions, and certainly RMS has, in the past, questioned whether the
project has really decided on it.  debian-legal is not a decision-making
body.  I agree with your take on the consensus, but I know other people
certainly have not.

I suppose the DPL delegate who could speak officially for the project here
would be the ftpmasters; is there an official statement about this?  I
believe the release team has decided that GFDL inclusion in main is RC for
the etch release, but I'm not sure where I could find that statement
either.  I suppose that might be sufficient.

-- 
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: GR Proposal: GFDL statement

2006-01-01 Thread Manoj Srivastava
On Sun, 01 Jan 2006 13:30:32 -0800, Russ Allbery [EMAIL PROTECTED] said: 

 Joey Hess [EMAIL PROTECTED] writes:
 I'm confused. Where does it say that we have to go through the GR
 process to issue a position statement for something the project has
 already decided on?

 How do we know the project has decided on it?

 Not a flippant question.  That's felt like it's been missing from
 these discussions, and certainly RMS has, in the past, questioned
 whether the project has really decided on it.  debian-legal is not a
 decision-making body.  I agree with your take on the consensus, but
 I know other people certainly have not.

 I suppose the DPL delegate who could speak officially for the
 project here would be the ftpmasters; is there an official statement
 about this?  I believe the release team has decided that GFDL
 inclusion in main is RC for the etch release, but I'm not sure where
 I could find that statement either.  I suppose that might be
 sufficient.

The release team has spoken, and they decide what goes in a
 release.  If they have decided, under advice from debian-legal, that
 GFDL docs are RC bugs, then that is that.

Personally, I doubt that there is any doubt that the GFDL
 does not satisfy the DFSG.

manoj
-- 
Why should we subsidize intellectual curiosity? -Ronald Reagan
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: GR Proposal: GFDL statement

2006-01-01 Thread Manoj Srivastava
Hi,

I have taken the liberty of re-adding bits to the position
 statement I considered important, and I would be happy to hear
 reasons why they should not be in the position statement we publish. 

manoj

On Sun, 1 Jan 2006 15:02:04 +1000, Anthony Towns aj@azure.humbug.org.au said: 

- --- Why the GNU Free Documentation License is not suitable for
- Debian main
+Why the GNU Free Documentation License 1.2 is not suitable for
+Debian main 
 ~~

 (0) Summary

 Within the Debian community there has been a significant amount of
 concern about the GNU Free Documentation License (GFDL), and whether
 it is, in fact, a free license. This document attempts to explain
 why Debian's answer is no.

 It should be noted that this does not imply any hostility towards
 the Free Software Foundation, and does not mean that GFDL
 documentation should not be considered free enough by others.
- and
+. It merely is meant to clarify that Debian itself does not consider
+ it free. However,
 Debian itself will continue distributing GFDL documentation in its
 non-free section.

 (1) What is the GFDL?

 The GFDL is a license written by the Free Software Foundation, who
 use it as a license for their own documentation, and promote it to
 others. It is also used as Wikipedia's license. To quote the GFDL's
 Preamble:

   The purpose of this License is to make a manual, textbook, or
   other functional and useful document free in the sense of
   freedom: to assure everyone the effective freedom to copy and
   redistribute it, with or without modifying it, either commercially
   or noncommercially. Secondarily, this License preserves for the
   author and publisher a way to get credit for their work, while not
   being considered responsible for modifications made by others.

   This License is a kind of copyleft, which means that derivative
   works of the document must themselves be free in the same
   sense. It complements the GNU General Public License, which is a
   copyleft license designed for free software.

 (2) How does it fail to meet Debian's standards for Free Software?

 The GFDL conflicts with traditional requirements for free software
 in a variety of ways, some of which are expanded upon below. As a
 copyleft license, one of the consequences of this is that it is not
 possible to include content from a documention directly into free
 software under the GFDL.

 The major conflicts are:

 (2.1) Invariant Sections

 The most troublesome conflict concerns the class of invariant
 sections that, once included, may not be modified or removed from
 the documentation in future. Modifiability is, however, a
 fundamental requirement of the DFSG, which states:

 3. Derived Works

 The license must allow modifications and derived works, and must
 allow them to be distributed under the same terms as the license
 of the original software.

 Invariant sections create particular problems in reusing small
 portions of the work (since any invariant sections must be included
 also, however large), and in making sure the documentation remains
 accurate and relevant.

  In addition to the simple restrictions of freedoms imposed by the
 Invariant Sections, they also cause practical problems:

* Incompatibility with the GPL. It's GPL-incompatible in both
  directions. This means that you can't legally extract text from
  a GFDL'ed manual and put it into integrated help strings in a
  GPL'ed program. And you can't extract code or comments from a
  GPL'ed program and put it into a GFDL'ed manual. (Without
  getting explicit permission to relicense from every
  copyright-holding contributor, that is.)
  

* Being forced to retain inaccurate Invariant Sections (or Cover
  Texts, or Dedications).

* Being forced to retain obsolete Invariant Sections (or Cover
  Texts, or Dedications). Dated invariant sections would
  exacerbate this problem.

*  Possibility of obsolescence, via changes in technologies
  (such as the disappearance of printed matter, or the
  particulars of file formats and access restrictions).
  

* Being forced to retain technically inappropriate Invariant
  Sections or Cover Texts, etc.
  

* Being forced to retain Invariant Sections even in extremely
  space-tight environments (such as a rescue disks, reference
  card, PDA's, or embedded devices).
  

* Being forced to retain untranslated Invariant Sections in a
  translation.

* Being unable to use material from the document for a new
  document whose primary topic is that of an Invariant Section
  (because the Invariant Section must be retained, and must be
  Secondary, but would no longer be Secondary). This issue, where
  it can be very difficult or impossible to repurpose chunks (eg
  copy a chapter about regular 

Re: GR Proposal: GFDL statement

2006-01-01 Thread Anthony Towns
 Joey Hess [EMAIL PROTECTED] writes:
  I'm confused. Where does it say that we have to go through the GR
  process to issue a position statement for something the project has
  already decided on?

4. The Developers by way of General Resolution or election
4.1. Together, the Developers may:
  5. Issue, supersede and withdraw nontechnical policy documents and
 statements.

On Sun, Jan 01, 2006 at 01:30:32PM -0800, Russ Allbery wrote:
 I suppose the DPL delegate who could speak officially for the project here
 would be the ftpmasters; is there an official statement about this?

My understanding is that whether ftpmaster is a DPL delegated position
or not is also debatable. As per the security team, I'm trying to avoid
having an opinion. In any event, the DPL doesn't have any particular
right to make statements on behalf of the project anymore, afaics, and
I'm not sure delegates could in any case. Maintainers and delegates
can presumably make statements about their areas of responsibility,
but this is a project wide issue, as it affects things like the wiki
[0] as well as just the archive.

I note ftpmaster already gets accused of imperial rules and having a
fortified post of Project power [1] and other similar garbage, so I'm
disinclined to see the sense in leaving this sort of decision solely
to us. And if the decision's not up to us -- I assume I'm not mistaken
in thinking people would be upset if we decided GFDL docs were A-OK --
I don't see how it makes much sense to expect us alone to explain it.

 I believe the release team has decided that GFDL inclusion in main is RC for
 the etch release, 

The release team had pretty much decided that back in 2003 [2], but the
release team doesn't really get to decide what's appropriate for unstable
or experimental, let alone the wiki, web pages and whatever.

 but I'm not sure where I could find that statement
 either.  I suppose that might be sufficient.

http://lists.debian.org/debian-devel-announce/2005/06/msg00019.html

Note the above is a consequence of the developers' decision to remove
non-free docs by way of changing the social contract; it's (that part of)
that decision that needs the explanation, IMO.

Maybe retitling it to Why we do not consider the GNU Free Documentation
License free or something would work better, though that seems more
likely to push people's buttons.

Cheers,
aj

[0] http://wiki.debian.org/DebianWikiIsNotGFDL
[1] http://lists.debian.org/debian-devel/2005/12/msg00605.html
[2] 
http://web.archive.org/web/20031004172513/http://people.debian.org/~ajt/sarge_rc_policy.txt



signature.asc
Description: Digital signature


Re: GR Proposal: GFDL statement

2006-01-01 Thread Anthony Towns
On Sun, Jan 01, 2006 at 08:53:11PM -0600, Manoj Srivastava wrote:
   In addition to the simple restrictions of freedoms imposed by the
  Invariant Sections, they also cause practical problems: [...]

This is a huge chunk of text for a dcoument that's already a bit
too long to be easily read.

   Analogous to the software program freedoms, we need to
  articulate the freedoms required for the subset of software called
  documentation.

If we're making a position statement, we shouldn't say we need to
articulate things, we should just articulate them. From everything I've
seen, though, I think Debian simply wants to have the same freedoms for
programs and documentation, rather than coming up with a different set;
certainly that's the way the social contract is now written.

Cheers,
aj



signature.asc
Description: Digital signature


Re: GR Proposal: GFDL statement

2005-12-31 Thread Russ Allbery
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Anthony Towns aj@azure.humbug.org.au writes:

 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:

 ---
 Why the GNU Free Documentation License is not suitable for Debian main
 ~~

Seconded.  This has been constantly redebated and rediscussed and we
really should come to a final conclusion about it one way or the other.

One note, which doesn't affect my second:  It may be worthwhile to
explicitly say GNU Free Documentation License 1.2 in that heading and
elsewhere in the text, just in case the FSF fixes at least the DRM and
transparent copy provisions in a new release.  As-is, the versioning is
not mentioned until the how to fix section, which makes sense right now
but which may look strange if read from the perspective of the future.

- -- 
Russ Allbery ([EMAIL PROTECTED])   http://www.eyrie.org/~eagle/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/

iD8DBQFDt2hF+YXjQAr8dHYRAoOXAKDBD3z+VlUqy0Ne7wZYhlecZFquhwCcCOtB
wqX22E1oovvyxil/7HMAH0o=
=FHIn
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: GR Proposal: GFDL statement

2005-12-31 Thread Steve Langasek
On Sun, Jan 01, 2006 at 03:02:04PM +1000, Anthony Towns wrote:
 Why the GNU Free Documentation License is not suitable for Debian main
 ~~
 
 (0) Summary
 
 Within the Debian community there has been a significant amount of concern
 about the GNU Free Documentation License (GFDL), and whether it is, in
 fact, a free license. This document attempts to explain why Debian's
 answer is no.
 
 It should be noted that this does not imply any hostility towards the
 Free Software Foundation, and does not mean that GFDL documentation
 should not be considered free enough by others, and Debian itself will
 continue distributing GFDL documentation in its non-free section.
  
 (1) What is the GFDL?
 
 The GFDL is a license written by the Free Software Foundation, who use
 it as a license for their own documentation, and promote it to others. It
 is also used as Wikipedia's license. To quote the GFDL's Preamble:
 
   The purpose of this License is to make a manual, textbook,
   or other functional and useful document free in the sense of
   freedom: to assure everyone the effective freedom to copy and
   redistribute it, with or without modifying it, either commercially or
   noncommercially. Secondarily, this License preserves for the author
   and publisher a way to get credit for their work, while not being
   considered responsible for modifications made by others.
 
   This License is a kind of copyleft, which means that derivative
   works of the document must themselves be free in the same sense. It
   complements the GNU General Public License, which is a copyleft license
   designed for free software.
 
 (2) How does it fail to meet Debian's standards for Free Software?
 
 The GFDL conflicts with traditional requirements for free software in
 a variety of ways, some of which are expanded upon below. As a copyleft
 license, one of the consequences of this is that it is not possible to
 include content from a documention directly into free software under
 the GFDL.
 
 The major conflicts are:
 
 (2.1) Invariant Sections
 
 The most troublesome conflict concerns the class of invariant sections
 that, once included, may not be modified or removed from the documentation
 in future. Modifiability is, however, a fundamental requirement of the
 DFSG, which states:
 
 3. Derived Works
 
 The license must allow modifications and derived works, and
 must allow them to be distributed under the same terms as the
 license of the original software.
 
 Invariant sections create particular problems in reusing small portions
 of the work (since any invariant sections must be included also,
 however large), and in making sure the documentation remains accurate
 and relevant.
 
 (2.2) Transparent Copies
 
 The second conflict is related to the GFDL's requirements for transparent
 copies of documentation (that is, a copy of the documentation in a form
 suitable for editing). In particular, Section 3 of the GFDL requires
 that a transparent copy of the documentation be included with every
 opaque copy distributed, or that a transparent copy is made available
 for a year after the opaque copies are no longer being distributed.
 
 For free software works, Debian expects that simply providing the source
 (or transparent copy) alongside derivative works will be sufficient,
 but this does not satisfy either clause of the GFDL's requirements.
 
 (2.3) Digital Rights Management
 
 The third conflict with the GFDL arises from the measures in Section 2
 that attempt to overcome Digital Rights Management (DRM) technologies. In
 particular, the GFDL states that You may not use technical measures
 to obstruct or control the reading or further copying of the copies you
 make or distribute. This inhibits freedom in three ways: it limits use
 of the documentation as well as distribution, by covering all copies
 made, as well as copies distributed; it rules out distributing copies
 on DRM-protected media, even if done in such a way as to give users
 full access to a transparent copy of the work; and, as written, it also
 potentially disallows encrypting the documentation, or even storing it
 on a filesystem that supports permissions.
 
 (3) Why does documentation need to be Free Software?
 
 There are a number of obvious differences between programs and
 documentation that often inspire people to ask why not simply have
 different standards for the two? For example, books are often written
 by individuals, while programs are written by teams, so proper credit
 for a book might be more important than proper credit for a program.
 
 On the other hand, free software is often written by a single person,
 and free software documentation is often written by a larger group of
 contributors.  And the line between what is documentation and what is
 a program is not always so clear either, as content from one is often
 needed in the other (to provide online help, to 

Re: GR Proposal: GFDL statement

2005-12-31 Thread Aníbal Monsalve Salazar
On Sun, Jan 01, 2006 at 03:02:04PM +1000, Anthony Towns wrote:
Bcc'ed to -project, -legal and -private; followups to -vote please.

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:

---
Why the GNU Free Documentation License is not suitable for Debian main
~~

(0) Summary

Within the Debian community there has been a significant amount of concern
about the GNU Free Documentation License (GFDL), and whether it is, in
fact, a free license. This document attempts to explain why Debian's
answer is no.

It should be noted that this does not imply any hostility towards the
Free Software Foundation, and does not mean that GFDL documentation
should not be considered free enough by others, and Debian itself will
continue distributing GFDL documentation in its non-free section.
 
(1) What is the GFDL?

The GFDL is a license written by the Free Software Foundation, who use
it as a license for their own documentation, and promote it to others. It
is also used as Wikipedia's license. To quote the GFDL's Preamble:

  The purpose of this License is to make a manual, textbook,
  or other functional and useful document free in the sense of
  freedom: to assure everyone the effective freedom to copy and
  redistribute it, with or without modifying it, either commercially or
  noncommercially. Secondarily, this License preserves for the author
  and publisher a way to get credit for their work, while not being
  considered responsible for modifications made by others.

  This License is a kind of copyleft, which means that derivative
  works of the document must themselves be free in the same sense. It
  complements the GNU General Public License, which is a copyleft license
  designed for free software.

(2) How does it fail to meet Debian's standards for Free Software?

The GFDL conflicts with traditional requirements for free software in
a variety of ways, some of which are expanded upon below. As a copyleft
license, one of the consequences of this is that it is not possible to
include content from a documention directly into free software under
the GFDL.

The major conflicts are:

(2.1) Invariant Sections

The most troublesome conflict concerns the class of invariant sections
that, once included, may not be modified or removed from the documentation
in future. Modifiability is, however, a fundamental requirement of the
DFSG, which states:

3. Derived Works
 
The license must allow modifications and derived works, and
must allow them to be distributed under the same terms as the
license of the original software.

Invariant sections create particular problems in reusing small portions
of the work (since any invariant sections must be included also,
however large), and in making sure the documentation remains accurate
and relevant.

(2.2) Transparent Copies

The second conflict is related to the GFDL's requirements for transparent
copies of documentation (that is, a copy of the documentation in a form
suitable for editing). In particular, Section 3 of the GFDL requires
that a transparent copy of the documentation be included with every
opaque copy distributed, or that a transparent copy is made available
for a year after the opaque copies are no longer being distributed.

For free software works, Debian expects that simply providing the source
(or transparent copy) alongside derivative works will be sufficient,
but this does not satisfy either clause of the GFDL's requirements.

(2.3) Digital Rights Management

The third conflict with the GFDL arises from the measures in Section 2
that attempt to overcome Digital Rights Management (DRM) technologies. In
particular, the GFDL states that You may not use technical measures
to obstruct or control the reading or further copying of the copies you
make or distribute. This inhibits freedom in three ways: it limits use
of the documentation as well as distribution, by covering all copies
made, as well as copies distributed; it rules out distributing copies
on DRM-protected media, even if done in such a way as to give users
full access to a transparent copy of the work; and, as written, it also
potentially disallows encrypting the documentation, or even storing it
on a filesystem that supports permissions.

(3) Why does documentation need to be Free Software?

There are a number of obvious differences between programs and
documentation that often inspire people to ask why not simply have
different standards for the two? For example, books are often written
by individuals, while programs are written by teams, so proper credit
for a book might be more important than proper credit for a program.

On the other hand, free software is 

Re: GR Proposal: GFDL statement

2005-12-31 Thread Mike Hommey
On Sun, Jan 01, 2006 at 03:02:04PM +1000, Anthony Towns 
aj@azure.humbug.org.au wrote:
 Bcc'ed to -project, -legal and -private; followups to -vote please.
 
 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:
 
 ---
 Why the GNU Free Documentation License is not suitable for Debian main
 ~~
 
 (0) Summary
 
 Within the Debian community there has been a significant amount of concern
 about the GNU Free Documentation License (GFDL), and whether it is, in
 fact, a free license. This document attempts to explain why Debian's
 answer is no.
 
 It should be noted that this does not imply any hostility towards the
 Free Software Foundation, and does not mean that GFDL documentation
 should not be considered free enough by others, and Debian itself will
 continue distributing GFDL documentation in its non-free section.
  
 (1) What is the GFDL?
 
 The GFDL is a license written by the Free Software Foundation, who use
 it as a license for their own documentation, and promote it to others. It
 is also used as Wikipedia's license. To quote the GFDL's Preamble:
 
   The purpose of this License is to make a manual, textbook,
   or other functional and useful document free in the sense of
   freedom: to assure everyone the effective freedom to copy and
   redistribute it, with or without modifying it, either commercially or
   noncommercially. Secondarily, this License preserves for the author
   and publisher a way to get credit for their work, while not being
   considered responsible for modifications made by others.
 
   This License is a kind of copyleft, which means that derivative
   works of the document must themselves be free in the same sense. It
   complements the GNU General Public License, which is a copyleft license
   designed for free software.
 
 (2) How does it fail to meet Debian's standards for Free Software?
 
 The GFDL conflicts with traditional requirements for free software in
 a variety of ways, some of which are expanded upon below. As a copyleft
 license, one of the consequences of this is that it is not possible to
 include content from a documention directly into free software under
 the GFDL.
 
 The major conflicts are:
 
 (2.1) Invariant Sections
 
 The most troublesome conflict concerns the class of invariant sections
 that, once included, may not be modified or removed from the documentation
 in future. Modifiability is, however, a fundamental requirement of the
 DFSG, which states:
 
 3. Derived Works
 
 The license must allow modifications and derived works, and
 must allow them to be distributed under the same terms as the
 license of the original software.
 
 Invariant sections create particular problems in reusing small portions
 of the work (since any invariant sections must be included also,
 however large), and in making sure the documentation remains accurate
 and relevant.
 
 (2.2) Transparent Copies
 
 The second conflict is related to the GFDL's requirements for transparent
 copies of documentation (that is, a copy of the documentation in a form
 suitable for editing). In particular, Section 3 of the GFDL requires
 that a transparent copy of the documentation be included with every
 opaque copy distributed, or that a transparent copy is made available
 for a year after the opaque copies are no longer being distributed.
 
 For free software works, Debian expects that simply providing the source
 (or transparent copy) alongside derivative works will be sufficient,
 but this does not satisfy either clause of the GFDL's requirements.
 
 (2.3) Digital Rights Management
 
 The third conflict with the GFDL arises from the measures in Section 2
 that attempt to overcome Digital Rights Management (DRM) technologies. In
 particular, the GFDL states that You may not use technical measures
 to obstruct or control the reading or further copying of the copies you
 make or distribute. This inhibits freedom in three ways: it limits use
 of the documentation as well as distribution, by covering all copies
 made, as well as copies distributed; it rules out distributing copies
 on DRM-protected media, even if done in such a way as to give users
 full access to a transparent copy of the work; and, as written, it also
 potentially disallows encrypting the documentation, or even storing it
 on a filesystem that supports permissions.
 
 (3) Why does documentation need to be Free Software?
 
 There are a number of obvious differences between programs and
 documentation that often inspire people to ask why not simply have
 different standards for the two? For example, books are often written
 by individuals, while programs are written by