Proposed statement wrt GNU FDL
Anthony Towns
to be handled, and lots of seconds that aren't willing to actually do
anything. How helpful.)
Debian's stance on the GNU Free Documentation License
...OR NOT (completely unofficial, draft, blahblah)
20th April, 2003
In November 2002, the version 1.2 of the GNU Free Documentation License
(GNU FDL) was released by the Free Software Foundation after a long
period of consultation. Unfortunately, some concerns raised by members
of the Debian Project were not addressed, and as such the GNU FDL can
apply to works that do not pass the Debian Free Software Guidelines (DFSG),
and may thus only be included in the non-free component of the Debian
archive, not the Debian distribution itself.
This document attempts to explain the reasoning behind this conclusion,
and offers some suggestions on how authors of free documentation may
avoid these problems.
The Problem
~~~~~~~~~~~
The GNU FDL includes a number of conditions that apply to all modified
versions that disallow modifications, particularly:
* K. For any section Entitled "Acknowledgements" or "Dedications",
Preserve the Title of the section, and preserve in the section all
the substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
* L. Preserve all the Invariant Sections of the Document, unaltered in
their text and in their titles. Section numbers or the equivalent
are not considered part of the section titles.
However, modifiability is a fundamental requirement of the Debian Free
Software Guidelines, which state:
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.
As such, we cannot accept works that include "Invariant Sections" and
similar unmodifiable components into our distribution, which unfortunately
includes a number of current manuals for GNU software.
The Solution
~~~~~~~~~~~~
There are a number of things that can be done to avoid this problem.
1) Avoid using the various options the GNU FDL allows.
If you do not make use of Invariant Sections, or include an
Acknowledgements or Dedication section, there are no problems with
your GNU FDL licensed document passing the DFSG. However, if someone
modifies your document, and adds an Invariant Section, the new document
will become "tainted" and can no longer be made to pass the DFSG.
2) Use an alternative copyleft license for your document.
Alternative licenses that you should consider for your documentation
include the GNU General Public License, or the Creative Commons
ShareAlike or Attribution-ShareAlike licenses.
3) Use a non-copyleft free license for your document.
Example licenses include the FreeBSD Documentation License, the Creative
Commons ShareAlike license, and common software licenses such as the
X11 license, or the updated BSD license.
4) Update the GNU FDL to allow the removal of unmodifiable sections.
While this does not prevent documents covered by the GNU FDL being
non-free, it allows you to extract the non-free components from the
document, leaving just the juicy DFSG-free goodness.
More Information
~~~~~~~~~~~~~~~~
http://www.gnu.org/licenses/fdl.html
http://www.gnu.org/licenses/fdl-1.2-comments.txt
http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00285.html
http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00287.html
http://www.wikipedia.org/pipermail/wikipedia-l/2002-June/002238.html
http://www.wikipedia.org/pipermail/wikipedia-l/2001-October/000624.html
http://www.debian.org/social_contract.html
http://creativecommons.org/licenses/
Open Questions
~~~~~~~~~~~~~~
We want to do a FAQ as well. Should the "documentation = software" thing
be justified there? How about the practical examples we have? What other
practical examples are there?
Which packages are affected?
What are we going to do about all the documentation with clearly non-free
licenses, or that lack clear licenses? This seems to include things like
the Debian Manifesto, that's part of doc-debian.
Do we really want to recommend Creative Commons Licenses? They've very
long and legalistic -- even the "do what you want, but keep my name"
license is disgustingly complicated, to the point where it's not obviously
DFSG-free.
Are those all that makes the GFDL conflict with the DFSG?
What else needs to be covered?
Cheers,
aj
--
Anthony Towns <a...@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Dear Anthony Towns: [...] Congratulations --
you are now certified as a Red Hat Certified Engineer!''
Richard Braakman
> (Hrm, asking for someone to handle this results in a motion for it
> to be handled, and lots of seconds that aren't willing to actually do
> anything. How helpful.)
That comment was unhelpful, and just discourages people from helping.
Speaking for myself, I was waiting for Branden to conclude that he
had enough seconds. As for the people who said they wouldn't have
time to help -- would you prefer that they hadn't seconded the
proposal either? We could have had a nicely silent majority.
Also, remember that it's Easter. Lots of people are busy with
family stuff.
> Debian's stance on the GNU Free Documentation License
> ...OR NOT (completely unofficial, draft, blahblah)
[...]
> The GNU FDL includes a number of conditions that apply to all modified
> versions that disallow modifications, particularly:
I was confused by the pronouns here. How about this?
The GNU FDL includes a number of conditions, which apply to all modified
versions, that disallow modifications. In particular:
(Section I, 'Preserve the section entitled "History"', is also a candidate
for this list.)
[...]
I also have a list of other problems with the GFDL. They should
probably all be listed together, though we may want to skip some
as being too nitpicky. That is, if this is to be the "comprehensive"
list Branden mentioned.
It's easy to misapply the GNU FDL.
The GNU FDL says that only "Secondary Sections" (a term it defines)
may be marked Invariant, but does not say what should happen if a
section that is not Secondary is listed as an Invariant Section.
The FSF itself has made this mistake several times[1], so we know
it's an easy mistake to make.
[1] I remember two in the GDB manual and one in the Emacs manual.
(Un)fortunately these mistakes have been corrected and I no longer have
the old versions around. Does anyone have references?
Definition of "Transparent copy" is limiting
The GNU FDL defines the words "Transparent" and "Opaque" to
distinguish between source-like and object-like documents
(e.g. comparing LaTeX to PDF). Unfortunately, this definition
focuses on implementation rather than intent. It requires
that every component of a document is either text, or an image,
or a drawing. This leaves out for example sound files, which
can never be distributed as part of a document under the GNU FDL.
([Maybe insert rant about PostScript not being Opaque by definition.
In fact, PostScript is the perfect example for documentation ==
software.])
GNU FDL creates a wall between documentation and code
The GFDL is incompatible with the GPL, and many of its requirements
don't translate well to functional software. This makes it difficult
to embed such documents into a program, for example in order to
present on-line help. In the other direction, many documents contain
example code, sometimes sizeable chunks of it, which will be unusable
by default unless specifically licensed otherwise.
Obnoxious Accumulation of Cover Texts
Every contributor can add up to 5 words of Front-Cover Text and up to
25 words of Back-Cover Text. It won't take long before there is no
space for artwork on the front cover, just a dense list of short
texts.
([Nit: "The front cover must present the full title with all words
of the title equally prominent and visible". So no artistic license
allowed in title arrangement. "Nethack: Journey through the MAZES
of MENACE" is right out, especially if "MENACE" has little goblins
holding up the letters.])
Obnoxious Accumulation of Invariant Sections
If two documents under the GNU FDL are reorganized (producing two
new documents with parts from each), then the Invariant Sections
from each of them have to be duplicated in both, except for sections
that are identical. If they differ (for example, both documents
have a "Distribution" section, but one has the old FSF address and
another has the new one), then both have to be included. This can
become unmanageable as documents evolve.
([This point might be subsumed under "Invariant Sections are bad",
and in any case we might not care because DFSG#4 allows something
similar. Do we care?])
The GNU FDL restricts the presentation of documents
(This is a general point, I'm not sure how to word it. We accept
many limitations in free software licenses, such as changelog
requirements, because they affect the source code but not the
object code. It's still possible to create whatever technical
effect is desired, even if manipulating the source can get a little
awkward. The GFDL, by contrast, makes nearly all of its demands
on the "object" of a document, not its source. For example, its
requirements for Front-Cover Texts are very similar to the Zope
and PHP-Nuke requirements that we have rejected as non-free. This
point is also the root problem of the reference-card scenario.)
Languages other than English are poorly supported
The GNU FDL defines special roles for several kinds of sections
(such as "History" and "Dedications"), but refers to these
sections by their names in English. A document under the GNU FDL
will have to include a section with the title "History", regardless
of the language it's written in.
[...]
> 4) Update the GNU FDL to allow the removal of unmodifiable sections.
This should probably be "Convince the FSF to update ..."? Otherwise
it's strange to include it in a list of things the reader can do.
It took me a while to work out what you meant.
> While this does not prevent documents covered by the GNU FDL being
> non-free, it allows you to extract the non-free components from the
> document, leaving just the juicy DFSG-free goodness.
s/extract/remove/ here. Extract implies that the non-free components
are the ones you keep.
> Open Questions
> ~~~~~~~~~~~~~~
>
> We want to do a FAQ as well. Should the "documentation = software" thing
> be justified there? How about the practical examples we have? What other
> practical examples are there?
I'd say yes and yes. The justification can be done by practical examples.
(For example, the emacs manual being part of the emacs interface,
literate programs, and rendering code embedded in documents and fonts).
Examples I've seen so far:
Wikipedia / FOLDOC controversy
Emacs reference card
> What are we going to do about all the documentation with clearly non-free
> licenses, or that lack clear licenses? This seems to include things like
> the Debian Manifesto, that's part of doc-debian.
Frankly, I wouldn't mind distributing a nonmodifiable GNU Manifesto
(as part of the emacs package or even in doc-debian) as long as it's
not bolted to something useful like the emacs manual.
> Do we really want to recommend Creative Commons Licenses? They've very
> long and legalistic -- even the "do what you want, but keep my name"
> license is disgustingly complicated, to the point where it's not obviously
> DFSG-free.
I don't think we should recommend those, since we don't have any
experience with them yet. I also think that free software licenses
should be comprensible to programmers in order to be useful; by the
same token, free documentation licenses should be comprehensible
to technical writers.
> What else needs to be covered?
Why Invariant Sections Are Bad :)
- The problem of excerpts
- People can hijack documents by modifying them and then adding
Invariant Sections that the original author finds unpalatable.
From that point on, they can use the original author's improvements,
but not the reverse. This creates exactly the kind of one-way
wall that copyleft is supposed to prevent. (If you're happy
with this, you might as well use the MIT license.)
- Invariant Sections can become outdated, and there's no way to
update them. Even adding a note saying they're obsolete is
not allowed.
We also need a point-by-point rebuttal of the FSF's response page
about the GFDL feedback, but that's not something I'm going to
think about today.
Richard Braakman
--
To UNSUBSCRIBE, email to debian-leg...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Branden Robinson
> to be handled, and lots of seconds that aren't willing to actually do
> anything. How helpful.)
Yeesh. I'm so used to getting screamed at when I make proposals, that
one would think people would understand when I give people an
opportunity to object before going forward.
Thanks for your contribution to this effort in question, but I could do
without the sniping about my efforts at building consensus. I was only
engaging in the sort of activity Martin Michlmayr flatly accused me of
being incapable of doing in his DPL platform rebuttal...
(As an aside, I do wonder why we bother with platforms and rebuttals at
all in our DPL election process -- I suspect people make up their minds
about how they'll vote without such documents exerting much in the way
of influence at all.)
--
G. Branden Robinson | Never attribute to malice that
Debian GNU/Linux | which can be adequately explained
bra...@debian.org | by stupidity.
http://people.debian.org/~branden/ |
Branden Robinson
> On Sat, Apr 19, 2003 at 11:29:38PM +1000, Anthony Towns wrote:
> > (Hrm, asking for someone to handle this results in a motion for it
> > to be handled, and lots of seconds that aren't willing to actually do
> > anything. How helpful.)
>
> That comment was unhelpful, and just discourages people from helping.
> Speaking for myself, I was waiting for Branden to conclude that he
> had enough seconds.
Oh, I think Anthony's just trying to make it clear that the fact that he
and I agree about something is the purest accident, and must not be
taken as inductive evidence that he and I have anything else at all in
common. He's got his dignity to protect, you know. :)
Anyway, before going *full* steam ahead I'd like to see if we get any
cries of anguish after my message gets covered in Debian Weekly News
(which gets circulated among the broader community). However, Anthony's
put together an excellent draft to guide us forward, and we can
definitely be honing our arguments and marshaling our facts in the
meantime.
I run a Subversion repository at necrotic.deadbeast.net, and was
considering housing the documents there. However a Project machine
would likely be more appropriate, and since all developers would have
accounts on it, it would be trivial to use the svn:// scheme with SSH
tunneling.
Thoughts?
--
G. Branden Robinson | It just seems to me that you are
Debian GNU/Linux | willfully entering an arse-kicking
bra...@debian.org | contest with a monstrous entity
http://people.debian.org/~branden/ | that has sixteen legs and no arse.
Matthew Palmer
> The Solution
> ~~~~~~~~~~~~
>
> There are a number of things that can be done to avoid this problem.
One which isn't mentioned there is to amend the DFSG to allow the FDL and
similar licences.
Before someone schedules a MOAB test over my home, note that I am not
advocating this course, merely that it should be mentioned and refuted. If
we don't do this, someone, somewhere is going to make the jump, and proceed
to pester the Project to death with questions about why we don't just modify
"that pesky ol' DFSG" and solve the problem that way.
- Matt
Matthew Palmer
> (As an aside, I do wonder why we bother with platforms and rebuttals at
> all in our DPL election process -- I suspect people make up their minds
> about how they'll vote without such documents exerting much in the way
> of influence at all.)
I'll say that platforms and rebuttals form some part of my decision making
process. I do go mostly off personalities, and what I feel about each
candidate. But, since I didn't know who Michael or Moshe were to any great
degree, they did help me get a feel for both candidate.
Anyway, back to flames... <g>
Branden Robinson
> One which isn't mentioned there is to amend the DFSG to allow the FDL and
> similar licences.
>
> Before someone schedules a MOAB test over my home, note that I am not
> advocating this course, merely that it should be mentioned and refuted. If
> we don't do this, someone, somewhere is going to make the jump, and proceed
> to pester the Project to death with questions about why we don't just modify
> "that pesky ol' DFSG" and solve the problem that way.
Sure, it's certainly worth addressing this point in the FAQ. It's a
question that we're likely going to hear time and again: "Why should the
FSF have to change? Why don't *you* change?"
--
G. Branden Robinson | It's not a matter of alienating
Debian GNU/Linux | authors. They have every right to
bra...@debian.org | license their software however we
http://people.debian.org/~branden/ | like. -- Craig Sanders
Anthony Towns
> similar licences.
>
> Before someone schedules a MOAB test over my home, note that I am not
> advocating this course, merely that it should be mentioned and refuted. If
> we don't do this, someone, somewhere is going to make the jump, and proceed
> to pester the Project to death with questions about why we don't just modify
> "that pesky ol' DFSG" and solve the problem that way.
I think "Why are Unmodifiable Sections a Problem?" in the proposed FAQ I just
posted in reply to Richard's message covers this. Could you have a look at it
to see if you agree?
Matthew Palmer
> On Tue, Apr 22, 2003 at 06:59:45PM +1000, Matthew Palmer wrote:
> > One which isn't mentioned there is to amend the DFSG to allow the FDL
> > and similar licences.
>
> I think "Why are Unmodifiable Sections a Problem?" in the proposed FAQ I
> just posted in reply to Richard's message covers this. Could you have a
> look at it to see if you agree?
I agree with what's expressed in the FAQ, but apart from the section on why
we think software and documentation should be treated equally under the DFSG
(quite a good argument there, BTW) there's nothing there about why we can't
as a project, for instance, just relax the rules of the DFSG generally.
After all, we bump up against "non-freeisms" regularly (hence non-free),
people are going to ask "why can't you make an exception in the DFSG for
this". Even if it's just something as simple as:
Why can't the DFSG be modified to accomodate the restrictions imposed by the
FDL? After all, RMS endorses it, so why shouldn't you?
The Debian Free Software Guidelines, combined with the Social Contract, are
the basic tenets by which Debian is guided. The DFSG has stood well with
both Debian Developers and the Free Software community for some time, and is
widely regarded as the canonical statement of what makes free software Free
(the Open Source Definition [I think] was based on the DFSG). As such,
changing the DFSG would be widely seen as a major compromise of the
principles the Debian project was founded on, and continues to be based on
today, as well as a key definition of what it means for software to be Free.
On a more practical note, changing the DFSG requires a General Resolution of
Debian Developers, a large logistical task and not one which should be
undertaken lightly.
---[END]---
OK, so maybe it wasn't quite so simple after all.
I'm not putting that up as the canonical form of the Q&A, but it reinforces
to me why the GFDL needs fixing, and not us.
Brian T. Sniffen
> Why can't the DFSG be modified to accomodate the restrictions imposed by the
> FDL? After all, RMS endorses it, so why shouldn't you?
>
> The Debian Free Software Guidelines, combined with the Social Contract, are
> the basic tenets by which Debian is guided. The DFSG has stood well with
> both Debian Developers and the Free Software community for some time, and is
> widely regarded as the canonical statement of what makes free software Free
> (the Open Source Definition [I think] was based on the DFSG). As such,
> changing the DFSG would be widely seen as a major compromise of the
> principles the Debian project was founded on, and continues to be based on
> today, as well as a key definition of what it means for software to be Free.
>
> On a more practical note, changing the DFSG requires a General Resolution of
> Debian Developers, a large logistical task and not one which should be
> undertaken lightly.
>
> ---[END]---
>
> OK, so maybe it wasn't quite so simple after all.
>
> I'm not putting that up as the canonical form of the Q&A, but it reinforces
> to me why the GFDL needs fixing, and not us.
This says to me "It's hard to change the DFSG, and the DFSG is
respected." Neither of those seems like a good reason for the GFDL to
change. I think your argument could be much stronger if it included a
"because we're right" paragraph.
-Brian
--
Brian T. Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
Anthony Towns
> > > One which isn't mentioned there is to amend the DFSG to allow the FDL
> > > and similar licences.
> > I think "Why are Unmodifiable Sections a Problem?" in the proposed FAQ I
> > just posted in reply to Richard's message covers this. Could you have a
> > look at it to see if you agree?
> I agree with what's expressed in the FAQ, but apart from the section on why
> we think software and documentation should be treated equally under the DFSG
> (quite a good argument there, BTW) there's nothing there about why we can't
> as a project, for instance, just relax the rules of the DFSG generally.
Well, obviously, we can.
The only reason we should is if unmodifiable sections aren't a problem, but
we claim they are.
> Why can't the DFSG be modified to accomodate the restrictions imposed by the
> FDL? After all, RMS endorses it, so why shouldn't you?
Because RMS is wrong -- unmodifiable sections are a problem, for the reasons
listed, probably amongst others.
> I'm not putting that up as the canonical form of the Q&A, but it reinforces
> to me why the GFDL needs fixing, and not us.
Cheers,
John Goerzen
> In particular: for emacs21, ``with the Invariant Sections being "The
> GNU Manifesto", "Distribution" and "GNU GENERAL PUBLIC LICENSE"'', and
> for gdb ``with the Invariant Sections being "A Sample GDB Session" and
> "Free Software"'' and ``with the Invariant Sections being "Stabs Types"
> and "Stabs Sections"''
While in general I must say that I agree with Branden on this issue, I'm not
yet completely convinced, and one reason was brought home to me by the
above: I large majority of our software ships with the file COPYING, which
states "changing it is not allowed". Combined with the requirement in
section 1 that the GPL be given to any recipients of the program, this
strikes me as similar to the invariant section. It leaves me wondering if
we are being a bit hyopcritical about it.
At the same time, I see no value in making cover sections, etc. of manuals
invariant.
Any thoughts on that?
Anthony Towns
> On Thu, Apr 24, 2003 at 05:47:35PM +1000, Anthony Towns wrote:
> > In particular: for emacs21, ``with the Invariant Sections being "The
> > GNU Manifesto", "Distribution" and "GNU GENERAL PUBLIC LICENSE"'', and
> > for gdb ``with the Invariant Sections being "A Sample GDB Session" and
> > "Free Software"'' and ``with the Invariant Sections being "Stabs Types"
> > and "Stabs Sections"''
> While in general I must say that I agree with Branden on this issue, I'm not
> yet completely convinced, and one reason was brought home to me by the
> above: I large majority of our software ships with the file COPYING, which
> states "changing it is not allowed". Combined with the requirement in
> section 1 that the GPL be given to any recipients of the program, this
> strikes me as similar to the invariant section. It leaves me wondering if
> we are being a bit hyopcritical about it.
The FAQ says:
] What About Unmodifiable Software Licenses Like the GNU GPL?
]
] Many software licenses unfortunately disallow the creation ofderivative
] works. The FSF give everyone permission to distribute verbatim
] copies of the GPL, eg, but do not give you permission to take the
] text of the GPL and change section (2(c)) to something you prefer,
] and license your own works under this new GPL-based license. This,
] clearly, does not pass the DFSG.
]
] Debian does not generally apply the DFSG to the text of licenses
] themselves, but rather to the software (programs, documentation,
] artwork) they cover. In the past, Debian has similarly overlooked
] applying the DFSG to documentation, but with the increasing focus on
] providing good free documentation, this no longer seems appropriate.
Which doesn't really answer the question.
The real answer is that:
(a) There's never any point making these things unmodifiable. Deriving
a new license that uses some parts of the GPL doesn't change
the license of old works, and isn't dangerous in any way --
it merely makes it easier to write new license. Likewise for
programs, documentation, and anything else.
(b) We can't require freely modifiable licenses -- too much useful
free software is covered by unmodifiable licenses. But conversely,
this isn't something that can or should be extended: licenses
aren't relevant to most users -- software and documentation is,
and it's the users we're trying to protect here. Likewise, the
line between software licenses, and documentation in general is
much clearer than the line between documentation and software.
Additionally, we're only required to give people a copy of the
license, which is a much weaker requirement than including the
complete text of the license in every binary we distribute.
As such, we're happy to make a special exemption for licenses, that
we're not willing to make for documentation in general.
That might make more sense.
Brian T. Sniffen
> On Sun, Apr 20, 2003 at 05:35:14AM +0300, Richard Braakman wrote:
>> > Debian's stance on the GNU Free Documentation License
>> > ...OR NOT (completely unofficial, draft, blahblah)
>> (Section I, 'Preserve the section entitled "History"', is also a candidate
>> for this list.)
>
> Is it? I couldn't see how it was much different to the GPL's "You must
> cause the modified files to carry prominent notices stating that you
> changed the files". I suppose having a History section like:
>
> 2003-05-01 Title: _GNU Manifesto_ Debian
> (Extracted the GNU Manifesto from the GDB docs)
>
> 2003-04-28 Title: _GDB Documentation_ FSF
> 2003-04-12 Title: _GDB Documentation_ Debian
> 2003-04-11 Title: _GDB Documentation_ FSF
> 2003-04-01 Title: _GDB Documentation_ Debian
> 2003-03-20 Title: _GDB Documentation_ FSF
>
> could get tiresome. Does that make it non-free, though? I can't see any
> reason why it should.
>
> There's been some question whether the front-cover texts are DFSG
> free. Considering we accept the obnoxious advertising clause, I can't
> see any reason for them not to be.
The differences between the GPL's requirements and the GFDL's
requirements are in where the required sections must be placed: the
GPL, as you've noted elsewhere, usually makes special requirements
only of the source, and then requires that the source be available.
The GFDL tends to make requirements of all forms of the document.
More importantly, for both the front cover texts and the history
section, the GPL does not require its changelog be in the source file
itself; it is enough to accompany the work with a separate changelog
file. The GFDL's requirement that the History section be part of the
work itself makes it unusable for a wide class of documents and
formats, including video, audio, and static images.
> In particular: for emacs21, ``with the Invariant Sections being "The
> GNU Manifesto", "Distribution" and "GNU GENERAL PUBLIC LICENSE"'', and
> for gdb ``with the Invariant Sections being "A Sample GDB Session" and
> "Free Software"'' and ``with the Invariant Sections being "Stabs Types"
> and "Stabs Sections"''
How can the sample GDB Session possibly be a Secondary Section? Or is
this just a good example of how confusing the Invariant Section rules
can be, even to the FSF?
-Brian
--
Brian T. Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
Simon Law
> > In particular: for emacs21, ``with the Invariant Sections being "The
> > GNU Manifesto", "Distribution" and "GNU GENERAL PUBLIC LICENSE"'', and
> > for gdb ``with the Invariant Sections being "A Sample GDB Session" and
> > "Free Software"'' and ``with the Invariant Sections being "Stabs Types"
> > and "Stabs Sections"''
>
> While in general I must say that I agree with Branden on this issue, I'm not
> yet completely convinced, and one reason was brought home to me by the
> above: I large majority of our software ships with the file COPYING, which
> states "changing it is not allowed". Combined with the requirement in
> section 1 that the GPL be given to any recipients of the program, this
> strikes me as similar to the invariant section. It leaves me wondering if
> we are being a bit hyopcritical about it.
>
> At the same time, I see no value in making cover sections, etc. of manuals
> invariant.
>
> Any thoughts on that?
It seems that we have an implicit exception that legal
statements about a work about allowed to be non-free. That seems to be
quite reasonable since tampering with copyright statements is not
allowed in many countries, and also since many licenses are also
non-free. I don't mind works where it is manditory to reproduce:
Copyright (C) 2003 J. R. Hacker. This manual is free documentation;
yada yada yada. You should have received a copy of the license
along with this manual; if not, write to Fubar, Inc. 123 Sesame St,
New York, NY 10023, USA.
There is ample precedent for putting these little notices on all
sorts of things, typically in fine print. Look, I even have a serviette
on my desk that says "(C) 2003 DOCTOR'S ASSOCIATES INC. All rights
reserved."
Simon
Simon Law
> More importantly, for both the front cover texts and the history
> section, the GPL does not require its changelog be in the source file
> itself; it is enough to accompany the work with a separate changelog
> file. The GFDL's requirement that the History section be part of the
> work itself makes it unusable for a wide class of documents and
> formats, including video, audio, and static images.
This is interesting to consider.
Is it too onerous if copyright notices are required to be part
of the work itself? For instance, audio tapes and compact discs do not
have their copyright statements embedded in the music. Instead, the
statements are printed on the physical media itself. Is that
sufficient?
Simon
Henning Makholm
> On Sun, Apr 20, 2003 at 05:35:14AM +0300, Richard Braakman wrote:
> > -- would you prefer that they hadn't seconded the
> > proposal either? We could have had a nicely silent majority.
> I don't really see much value in "me too" posts. We build consensus by
> responding to criticism,
Me-too posts are a way of observing consensus. One rant (advocating a
possibly controversial course of action leading straight into major
flamewar territory) followed by complete silence does not establish a
consensus. It merely eastablishes apathy. A rant followed by a handful
of me-toos and still no criticism voiced allows consensus to be
observed.
Of course, a rant followed by constructive discussion about how to
implement the proposal in practise is even better, and once that ball
gets rolling, me-toos are superfluous.
> and there hasn't been *any* internal criticism of this stand since
> last November,
True, we knew we had a consensus that we don't like the GFDL and find
it lacking with respect to the DFSG if any of its options are
exercised. But we didn't previously have a clear consensus on turning
that feeling into action, and when the action is as momentous as that
lurking in horizon, I think Branden was right in not assuming that
consensus of assessment would automatically imply consensus on action.
We seem now to have the latter, which is good.
> There's been some question whether the front-cover texts are DFSG
> free. Considering we accept the obnoxious advertising clause, I can't
> see any reason for them not to be.
Perhaps the O.A.C. ought to be our next target, but let us fight one
battle at a time.
We do not accept the O.A.C. because we like it, but because of the
logistic problems of tracking down the well-meaning but misguided
authors who used it because it was in the template they were
following. That situation is unstable and marginally acceptable only
because there are probably none of those authors who actually care to
enforce it.
On the other hand, we have to assume that the FSF really mean what
they write in a brand new license, the drafts of which whey have
solicited and received extensive responses from the community.
> the hypothetical example of random people who don't have RMS's
> credibility attaching their own manifestos to free software
> documentation as some weird unerasable graffiti are both convincing
> to me. Are they convincing to anyone else?
While we should definitely include the hijacking example, some care
should be exercised in phrasing an explanation of what we think it
proves. In particular it should be very clear that we do not claim
that the possibility of hijacking in itself contributes to
DFSG-nonfreedom. (For example, BSD-licensed software and documention
can be hijacked too). On the other hand, the hijacking scenario does
help explain why we're mystified to see the FSF backing the license as
a "copyleft".
> The Problem
> ~~~~~~~~~~~
> The GNU FDL includes a number of conditions, which apply to all modified
> versions, that disallow modifications. In particular, these are:
[K and]
> * L. Preserve all the Invariant Sections of the Document, unaltered in
> their text and in their titles. Section numbers or the equivalent
> are not considered part of the section titles.
> However, modifiability is a fundamental requirement of the Debian Free
> Software Guidelines, which state:
I think it would be good to emphasize more in the central section that
it is the stickyness rather than the rigidity of Invariant Sections
that bugs us. How about something like this after the DFSG quote:
In particular, the DFSG requires that it must be legal to derive
a new work by the particular modification that consists of removing
one or more Invariant Sections. But this is expressly disallowed by
condition L of the GFDL.
If the rule had, instead been, that Invariant Sections could not
themselves be modified, but could freely be omitted entirely in
derived works, Debian would be able to distribute GDFL'ed
documentation. If necessary, the Debian maintainer could himself
remove the Invariant Sections, but in most cases where the license
were not obviously abused or misapplied, we would still be able
to include the original unmodified documentation based on a
case-by-case review of the relevance and technical importance
of the Invariant Section. (See the attached FAQ, question XYZ
for discussion).
> Given the GNU Projects influence on Debian, shouldn't the GNU Manifesto
> be included in the Debian GNU/Linux Distribution anyway?
I propose expanding this question to:
Why does Debian want to remove (say) the GNU Manifesto from the
manuals? Do you want to suppress Stallman's views and just benefit
from the software he created?
The question is one we often hear, but its phrasing betrays a
misunderstanding. Debian does not want to remove the GNU
Manifesto from the packaged GNU manuals that we distribute. On
the contrary, we take pride in providing the best possible
packing of the software we distribute. This includes making
packages that are as close as possible to the upstream author's
standard versions of the software, to the extent that this goal
does not conflict with the practical utility and technical
coherence of the Debian operating system.
What we do want is for our *users* to be allowed to remove the
GNU Manifesto from the manual if they can think of a reason to do
so. In other questions we describe reasons that we imagine that
users could think of, but even if we couldn't imagine them, we
would not want to restrict our users' freedom by our own
imagination. We promise our users that if they have a reason
that makes sense to *them* then they are always allowed to Make
The Necessary Changes to the software they get for us. That
promise is part of the value Debian adds to the software we
distribute. It may look minor compared to the technical
integration work that the majority of our developers' time is
spent with, but it is actually at least as important for a
significant segment of our users.
If only we could be sure that the license on the manuals would
allow a user who thinks that "because!" is reason enough for him,
to remove the GNU Manifesto, we probably could still distribute
the unmidified manuals with the Invariant Section in it. That
would mean that part of what we distribute (namely the Invariant
Section itself) would not, strictly speaking, be modifyable, but
exceptions can be made for things that are both sufficiently
non-software-like not to need modifyability for technical reasons
and sufficienly relevant not to just constitute a waste of space
in the distribution. Of course both of these limits are
judgement calls, and each particular Invariant-But-Removable
section will have to be considered on a case-by-case basis.
[Hmmm.. so I think at least, but I'm not sure that this is
a clear d-l consensus. -HM]
(For the record, the Debian Project neither officially agrees
with the entirety of the GNU Manifesto nor officially disagrees
with any particular part of it. But most Debian developers
recognize individually that the ideas and ideals it seeks to
express are to a very large degree the same ideas and ideals that
lie at the heart of the project and are embodied in its Social
Contract.)
I suppose there should also be a QA-pair that addresses Georg Greve's
droits-moral argument, but I don't even understand it well enough to
write it down as a FAQ question. At least the Danish concept of droits
moral (which is the one I know) is not one I can see how to bend in
the direction of invariant sections at all.
--
Henning Makholm "Nej, hvor er vi altså heldige! Længe
leve vor Buxgører Sansibar Bastelvel!"
Brian T. Sniffen
> The real answer is that:
>
> (a) There's never any point making these things unmodifiable. Deriving
> a new license that uses some parts of the GPL doesn't change
> the license of old works, and isn't dangerous in any way --
> it merely makes it easier to write new license. Likewise for
> programs, documentation, and anything else.
It is dangerous, as it leads to confusion: a document which looks much
like the GPL, except for one small section, might not be noticed.
However, the legal text of the GPL is reusable (allowing modification
and distribution), as long as you don't include the name GPL, the
Preamble, or the instructions for use. If Debian's going to
eventually remove invariant sections, it's possible that the included
copy of the GPL should have those sections removed as well.
-Brian
--
Brian T. Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
Anthony Towns
> If the rule had, instead been, that Invariant Sections could not
> themselves be modified, but could freely be omitted entirely in
> derived works, Debian would be able to distribute GDFL'ed
> documentation.
We can distribute GNU FDL'ed docs as is -- they simply have to not include
any invariant sections.
I don't think it makes sense to include invariant sections ever -- whether
they can be removed by others or not. We wouldn't accept anything that
is entirely invariant as being DFSG-free -- so it doesn't make sense to
accept books with chapters that're invariant as DFSG-free.
If we are willing to accept invariant chapters in DFSG-free
documentation, I don't see how we could possibly claim the GNU FDL is not
DFSG-free. Merely being able to delete something doesn't make it free --
I can delete MS Office easily enough, eg.
In short, I don't think that's a justifiable position.
> What we do want is for our *users* to be allowed to remove the
> GNU Manifesto from the manual if they can think of a reason to do
> so.
No -- we want our users to be able to take everything we give them, and
be able to build on any part of it they might choose, with few exceptions.
> If only we could be sure that the license on the manuals would
> allow a user who thinks that "because!" is reason enough for him,
> to remove the GNU Manifesto, we probably could still distribute
> the unmidified manuals with the Invariant Section in it. That
> would mean that part of what we distribute (namely the Invariant
> Section itself) would not, strictly speaking, be modifyable, but
> exceptions can be made for things that are both sufficiently
> non-software-like not to need modifyability for technical reasons
> and sufficienly relevant not to just constitute a waste of space
> in the distribution.
Didn't we just say we're not making exceptions for things that are
"sufficiently non-software-like"?
> Of course both of these limits are
> judgement calls, and each particular Invariant-But-Removable
> section will have to be considered on a case-by-case basis.
And further, as a practical matter, it's not reasonable for us to be
making judgement calls on every random piece of documentation that
gets uploaded. Just analysing the random licenses people come up with
is hard enough, trying to work out if some rant is "valuable" while
another isn't isn't sensible.
If we're going to make an exception for the GNU Manifesto -- and I think
we should -- let's be clear and deliberate about how we do it. Let's note
that it's completely non-free, and collect it, and any other defining
documents we might want to make similar exceptions for, and put them
in doc-debian with our own manifest and social contract, rather than
scattered through various manuals. That also forms a good way of judging
whether random rants are valuable enough: if they're important enough
to go in doc-debian, they're important enough to waive the DFSG.
Anthony Towns
> However, the legal text of the GPL is reusable (allowing modification
> and distribution), as long as you don't include the name GPL, the
> Preamble, or the instructions for use.
What makes you think this is the case?
Mark Rafn
> > If the rule had, instead been, that Invariant Sections could not
> > themselves be modified, but could freely be omitted entirely in
> > derived works, Debian would be able to distribute GDFL'ed
> > documentation.
On Fri, 25 Apr 2003, Anthony Towns wrote:
> We can distribute GNU FDL'ed docs as is -- they simply have to not include
> any invariant sections.
>
> I don't think it makes sense to include invariant sections ever -- whether
> they can be removed by others or not. We wouldn't accept anything that
> is entirely invariant as being DFSG-free -- so it doesn't make sense to
> accept books with chapters that're invariant as DFSG-free.
A GFDL document with no unmodifiable portions is free, but can be
hijacked by someone later adding an invariant section.
A GFDL document with non-removable non-modifiable sections is non-free.
A document with non-modifiable removable sections (I don't think the GFDL
has any provision for this, I'm including it just for completeness) is not
free itself, but the portion of the document which is modifiable can be
made free by removing the non-modifiable sections.
The fourth case (modifiable non-removable sections) is irrelevant, as one
possible modification is removal.
> If we are willing to accept invariant chapters in DFSG-free
> documentation, I don't see how we could possibly claim the GNU FDL is not
> DFSG-free. Merely being able to delete something doesn't make it free --
> I can delete MS Office easily enough, eg.
Right. The ability to remove it only preserves the freedom of the
attached work, not the unmodifiable portion itself.
> If we're going to make an exception for the GNU Manifesto -- and I think
> we should -- let's be clear and deliberate about how we do it. Let's note
> that it's completely non-free, and collect it, and any other defining
> documents we might want to make similar exceptions for, and put them
> in doc-debian with our own manifest and social contract, rather than
> scattered through various manuals.
Or better yet, put anything that's not freely modifiable (including the
Social Contract and GNU Manifesto) in non-free, and work toward making
them free.
Claiming that documents which do not allow derived works can still be
part of Debian is arrogant, hypocritical, and simply wrong.
--
Mark Rafn da...@dagon.net <http://www.dagon.net/>
Mark Rafn
not very familiar. They sound like some sort of meta-copyright which an
author cannot assign, and may not be able to grant permission over.
Does anyone have a pointer to some description of these rights that a
layman like myself might understand? I'm particularly interested in how
they relate to the GFDL and why they would apply to documentation and not
to software.
--
Mark Rafn da...@dagon.net <http://www.dagon.net/>
Joe Moore
> Perhaps the O.A.C. ought to be our next target, but let us fight one
> battle at a time.
EXPN O.A.C.?
(snip)
> While we should definitely include the hijacking example, some care
> should be exercised in phrasing an explanation of what we think it
> proves. In particular it should be very clear that we do not claim that
> the possibility of hijacking in itself contributes to
> DFSG-nonfreedom. (For example, BSD-licensed software and documention can
> be hijacked too). On the other hand, the hijacking scenario does help
> explain why we're mystified to see the FSF backing the license as a
> "copyleft".
Giving particular attention to the fact that the hijacking entity can use
the Invariant sections to prevent returning thier improvements to the
commons.
Example: SomeCo writes a user-friendly GNUware manual based in part on
the GNUware Manual (which is GFDL-licensed, so the SomeCo GNUware Manual
must be GFDL also). The SomeCo GNUware Manual has lots of useful
information in it, which the GNUware authors would like to incorporate.
Unfortunately, SomeCo included an invariant section which describes the
company and offers investment opportunities, and also the CEO's rant about
how all software should be proprietary (and licensed from SomeCo). The
original authors can not incorporate SomeCo's improvements without
including the company's advertisement, or appearing to endorse the CEO's
confused views.
--Joe
Brian T. Sniffen
> On Thu, Apr 24, 2003 at 12:22:27PM -0400, Brian T. Sniffen wrote:
>> However, the legal text of the GPL is reusable (allowing modification
>> and distribution), as long as you don't include the name GPL, the
>> Preamble, or the instructions for use.
>
> What makes you think this is the case?
http://www.fsf.org/licenses/gpl-faq.html#ModifyGPL
Can I modify the GPL and make a modified license?
You can use the GPL terms (possibly modified) in another license
provided that you call your license by another name and do not
include the GPL preamble, and provided you modify the
instructions-for-use at the end enough to make it clearly
different in wording and not mention GNU (though the actual
procedure you describe may be similar).
<and more on why not to>
Edmund GRIMLEY EVANS
>
> Can I modify the GPL and make a modified license?
>
> You can use the GPL terms (possibly modified) in another license
> provided that you call your license by another name and do not
> include the GPL preamble, and provided you modify the
> instructions-for-use at the end enough to make it clearly
> different in wording and not mention GNU (though the actual
> procedure you describe may be similar).
I recently came across an example of this, in case anyone's
interested:
http://bushido.imag.fr/papillon/ConsultInformations.po?docid=1427055&docLang=eng
It appears to be a modified version of the LGPL. Clause 3 still refers
to the GPL, so it's GPL-compatible.
Edmund
Thomas Uwe Gruettmueller
On Thursday 24 April 2003 19:37, Mark Rafn wrote:
> A few people have brought up the topic of Moral Rights, with
> which I am not very familiar. They sound like some sort of
> meta-copyright which an author cannot assign, and may not be
> able to grant permission over.
>
> Does anyone have a pointer to some description of these rights
> that a layman like myself might understand? I'm particularly
> interested in how they relate to the GFDL and why they would
> apply to documentation and not to software.
* * * IANAL * * *
The German Authors Rights Law is available at
http://bundesrecht.juris.de/bundesrecht/urhg/index.html
For an English version, use the Google translation tools:
http://translate.google.com/translate?u=http%3A%2F%2Fbundesrecht.juris.de%2Fbundesrecht%2Furhg%2Findex.html&langpair=de%7Cen&hl=de&ie=ISO-8859-1&prev=%2Flanguage_tools
(Although this translation seems to be quite readable, I'm a bit
confused about the translation of the headline, "Copyright law
and used patent rights". Literally, it should translate to "Law
About Authors Rights and Similar Protection Rights". What the
hell are "used patents rights"???)
Relevant passages might be:
| UrhG § 14 distortion of the work
|
| The author has the right to forbid distortion or another
| impairment of its work which is suitable, to endanger its
| entitled mental or personal interests in the work.
and
| UrhG § 42 recall right because of changed conviction
|
| (1) the author can recall a right to use opposite the owner,
| if the work does not correspond to its conviction any longer
| and cannot to it therefore the utilization of the work any
| longer be zugemutet. The legal successor of the author (§ 30)
| can explain the recall only if he prove that the author before
| its death would have been entitled to the recall and from the
| explanation of the recall was prevented or this ordered
| last-willingly.
|
| (2) without the recall right cannot be done in advance. Its
| practice cannot be excluded.
|
| (3) the author has to compensate the owner of the right to use
| appropriately.
This point is interesting. How can anyone ever compensate six
billion licensees approprietely? ;o)
| The remuneration must at least cover the
| expenditures, which the owner of the right to use up to the
| explanation of the recall made; however here expenditures,
| which are allotted to uses already pulled, remain out of
| consideration. The recall becomes only effective if the author
| replaced the expenditures or carried security out for it. The
| owner of the right to use has to communicate within one period
| from three months to explanation of the recall the
| expenditures to the author; if it does not follow this
| obligation, then the recall becomes already effective at the
| end of this term.
|
| (4) if the author wants to again use the work after recall,
| then he is obligated to offer to the former owner of the right
| to use an appropriate right to use for appropriate conditions.
|
| (5) the regulations in § 41 exp. 5 and 7 are to be used
| accordingly.
- - - - -
I can't find any hint why software should be different.
cu,
Thomas
}:o{#
Joey Hess
Anthony Towns wrote:
> In November 2002, version 1.2 of the GNU Free Documentation License (GNU
> FDL) was released by the Free Software Foundation after a long period
> of consultation. Unfortunately, some concerns raised by members of the
> Debian Project were not addressed, and as such the GNU FDL can apply
> to works that do not pass the Debian Free Software Guidelines (DFSG),
> and may thus only be included in the non-free component of the Debian
> archive, not the Debian distribution itself.
Maybe just because I had a headache at the time, but the first time I
read that sentence I thought you were saying the FDL license itself
could only go in non-free. You could eliminate any ambiguity by breaking
the last sentence into two.
> The GNU FDL includes a number of conditions, which apply to all modified
> versions, that disallow modifications. In particular, these are:
Maybe say "modified versions of a work". Also, it's at first confusing
to see the "modifid versions" .. "disallow modifications", maybe
s/disallow modifications/disallow certian modifications/
> This is a very fundamental question. Debian's decision is based
> on some fundamental premises: we are, at our heart, an operating
> system distribution, so we're interested in making a good operating
> system that you can do a lot with far more than distributing every
"lot with far more" is hard to parse, suggest punctuation or something.
> What About Unmodifiable Software Licenses Like the GNU GPL?
>
> Many software licenses unfortunately disallow the creation ofderivative
^^ space
> works. The FSF give everyone permission to distribute verbatim
gives
> copies of the GPL, eg, but do not give you permission to take the
does (unless FSF has a different number
than I think it has)
> It's easy to misapply the GNU FDL.
>
> The GNU FDL says that only "Secondary Sections" (a term it defines)
> may be marked Invariant, but does not say what should happen if a
> section that is not Secondary is listed as an Invariant Section.
> The FSF itself has made this mistake several times[1], so we know
> it's an easy mistake to make.
Your footnote [1] seems to be dangling.
> Given the GNU Projects influence on Debian, shouldn't the GNU Manifesto
's
> Why does this document use various Capitalisation Styles?
>
> Because you haven't edited it yet.
Ok, fine so I think you should re-case the words in the questions of
the FAQ, as follows:
What does it mean that this document is a draft?
It's the Debian Free _Software_ Guidelines, stupid -- why apply them to
documentation?
What about unmodifiable software licenses like the GNU GPL?
Beyond allowing Invariant Sections, why does the GNU FDL suck?
Why are unmodifiable sections a problem?
Given the GNU project's influence on Debian, shouldn't the GNU Manifesto
be included in the Debian GNU/Linux distribution anyway?
Why does this document use various capitalisation styles?
There are also a few "invariant sections" here and there that should be
changed to "Invariant Sections".
--
see shy jo
Joey Hess
> As such, we cannot accept works that include "Invariant Sections" and
> similar unmodifiable components into our distribution, which unfortunately
> includes a number of current manuals for GNU software.
It may be worth noting that GNU manuals are hardly the only thing
effected by the emerging consensus on treatment of document licenses.
The RFC's are moving to non-free already as they cannot be modified,
emacs contains a number of documents in its etc directory (WHY-FREE,
PROJECT, INTERVIEW, CENSORSHIP, etc, etc) that cannot be modified. There
are probably quite a few more examples.
> 2) Use an alternative copyleft license for your document.
>
> The GNU General Public License is a good license for documentation
> as well as software. It requires anyone who would want to do a print
> run of your documentation to either include a CD of the text with the
> book so anyone can modify it, or to include an offer to send copies
> to anyone who asks at cost; and also requires the modifiable copy to
> be in whichever transparent form was used to create the book originally.
>
> 3) Use a non-copyleft free license for your document.
>
> Example licenses include the FreeBSD Documentation License, and common
> software licenses such as the X11 license, or the updated BSD license.
>
> 4) Convince the FSF to change the GNU FDL to allow the removal of
> unmodifiable sections.
>
> While this does not prevent documents covered by the GNU FDL being
> non-free by Debian's definition of the term, it allows us to remove the
> non-free components (that by definition are irrelevant to the document),
> leaving simply the DFSG-free manual itself.
It might be good to point to another license written explicitly with
non-code in mind. What about the license used on the Debian web site?
> What About Unmodifiable Software Licenses Like the GNU GPL?
>
> Many software licenses unfortunately disallow the creation ofderivative
> works. The FSF give everyone permission to distribute verbatim
> copies of the GPL, eg, but do not give you permission to take the
> text of the GPL and change section (2(c)) to something you prefer,
> and license your own works under this new GPL-based license. This,
> clearly, does not pass the DFSG.
Apparently they do allow it, according to Brian T. Sniffen who points out
http://www.fsf.org/licenses/gpl-faq.html#ModifyGPL
If the license portion of the GPL can indeed be reused and modified then it
is a bad example to use here. Or at least the reference to section 2c is
a bad example.
> Debian does not generally apply the DFSG to the text of licenses
> themselves, but rather to the software (programs, documentation,
> artwork) they cover. In the past, Debian has similarly overlooked
> applying the DFSG to documentation, but with the increasing focus on
> providing good free documentation, this no longer seems appropriate.
It might be worth noting that Debian historically did not apply the DFSG
to software either (well, there was no DFSG), and had a large amount of
non-free software in the distribution, and that applying a strict
standard to the software we ship has led to a lot of software becoming
free, and has not hurt the distribution or our users in any way. We hope
applying these standards to documentation will have similar positive
effects. I think this is mostly implicit in your answer, but many people
will not know the history.
> Beyond allowing invariant sections, why does the GNU FDL suck?
A little peice of me wonders if "why does the GNU FDL suck" is politic
even in a FAQ, but whatever.
> Obnoxious Accumulation of Cover Texts
>
> Every contributor can add up to 5 words of Front-Cover Text and up to
> 25 words of Back-Cover Text. It won't take long before there is no
> space for artwork on the front cover, just a dense list of short
> texts.
> ([Nit: "The front cover must present the full title with all words
> of the title equally prominent and visible". So no artistic license
> allowed in title arrangement. "Nethack: Journey through the MAZES
> of MENACE" is right out, especially if "MENACE" has little goblins
> holding up the letters.])
Has anyone figured out what you have to do to print a FDL licensed work
as part of a collection like a magazine? I'm thinking particularly of my
Linux Journals which always seem to arrive with a giant honking mailing
lable right over the title of the two articles I'm most interested in.
It would be very amusing if the placement of a label could violate a
copyright.
> Languages other than English are poorly supported
>
> The GNU FDL defines special roles for several kinds of sections
> (such as "History" and "Dedications"), but refers to these
> sections by their names in English. A document under the GNU FDL
> will have to include a section with the title "History", regardless
> of the language it's written in.
I think if I were an author and was worried about this, I would quickly
add a little rider on my document's license, similar to the GPL + openssl
riders, that allowed sections to be translated.
> Why are Unmodifiable Sections a Problem?
>
> Outdated Invariant sections
>
> Invariant Sections can become outdated, and there's no way to
> update them. Even adding a note saying they're obsolete is
> not allowed.
Unless of course it is put in another invariant section. But of course
that leads to this next point..
> Given the GNU Projects influence on Debian, shouldn't the GNU Manifesto
> be included in the Debian GNU/Linux Distribution anyway?
>
> Probably. Should we have a special DFSG exemption for doc-debian, and
> include things like the GNU Manifesto (and "Why Free Software?" and
> "Free Software needs Free Documentation" and whatever else) in there?
> I think so.
I am deeply ambivilant.
I am very glad (and a little bit suprised) that we're finally close to a
consensus on DFSG for documentation. If this little exception is
required to win that consensus, that's one thing. If this exception is
just being made because we're worried about third-party perceptions of
us, I think the existence of an exception can do more harm than good. It
could weaken our stance, or complicate some future licensing discussion
(much as the excpetion for licenses that cannot be modified complicated
this one), or lead to ill feeling amoung other people whose non-free
manifestoes are not deemed worthy enough to go in.
If we're worried about perceptions, especally by the FSF, then I think
we'd do better to make clear that we are not picking on them or their
license explicitly, and that this is a new general policy on document
licenses that we've decided on.
I hope that everyone who is in agreement about the FDL has no problem
with these same standards being applied to other documents in Debian.
This raises the possibility of another tack -- instead of a document
like this one that warns about and criticises the FDL, perhaps Debian
should issue a more general statement along the lines of: We have
decided documentation in Debian must comply with the DFSG, and this will
entail throwing the following documents out of the distribution, and
certian licenses (FDL etc) are causing problems in this task. Just an
idea and I don't feel like writing it myself, but it might be less
inflammatory.
I'm pretty happy with the proposed statment anway.
--
see shy jo
Thomas Uwe Gruettmueller
On Thursday 24 April 2003 13:21, Matthew Palmer wrote:
> I agree with what's expressed in the FAQ, but apart from the
> section on why we think software and documentation should be
> treated equally under the DFSG (quite a good argument there,
> BTW) there's nothing there about why we can't as a project,
> for instance, just relax the rules of the DFSG generally.
As a Debian user, I am glad that there is this set of rules --
namely the DFSG -- that strictly followed, help keeping Debian
100 % free software. I hope that these rules will not be
softened, so that in the end, Debian becomes a second SuSE.
I am also glad that the Debian project treats all different
sorts of content the same way, as I am very enthusiastic about
the idea of a transition of the principles of free software
towards other areas. The FSF has quite disappointed me in this
regard, as they not only deny the leadership of a general
free-everything-movement, but also discourage people from being
consequent by giving them a bad example. For me, this is another
reason why Debian should keep its rules as they are, and
continue to apply them consequently.
On the other hand, the DFSGly non-free docs that are about to be
thrown out of main are at least as freely distributable as any
other package in main. This is a quality that many packages in
non-free do not share with them. As I don't have non-free in my
apt/sources.list, from my point of view, moving these docs to
the 'non-free' section would practically mean the same thing as
moving them to the trash dump. I guess this step would be far
too radical.
Also, it seems to be more difficult to write and test
documentation than software, as it works on human beings, not
machines. Further, there still is too few good documentation.
This makes me think that trashing freely distributable
documentation would not be wise.
So, now I'm repeating an idea that I alredy mentioned here,
after selfhtml had been kicked:
* Create a section 'distributable' that is between main and
non-free, for stuff that is not free WRT modification,
availability of the source code etc., but at least freely
distributable in any medium, by anybody, for any price.
* Therefore, create a subset of the GFDL (a 'relaxed' GFDL)
which regulates what can go in there and what not, but not as
a replacement of the current GFDL, but rather a different set
of rules for a different purpose.
I think this would be a good compromise for those people who
want non-free docs out of main, and those who don't want them
trown onto the 'non-free' trash dump, and those who want both.
cu,
Thomas
}:o{#
Glenn Maynard
> On the other hand, the DFSGly non-free docs that are about to be
> thrown out of main are at least as freely distributable as any
> other package in main. This is a quality that many packages in
> non-free do not share with them.
There's lots of software in non-free that is freely distributable, but
non-free for other reasons, such as limitations on commercial use. Non-
free things should go in non-free, even if there's a lack of free
equivalents.
> As I don't have non-free in my
> apt/sources.list, from my point of view, moving these docs to
> the 'non-free' section would practically mean the same thing as
> moving them to the trash dump. I guess this step would be far
> too radical.
Requiring you to add a line or two to sources.list isn't "trashing" anything.
If this is a "radical" move, I'd say the earlier one of moving non-free
software to non-free was an order of magnitude more "radical".
> So, now I'm repeating an idea that I alredy mentioned here,
> after selfhtml had been kicked:
>
> * Create a section 'distributable' that is between main and
> non-free, for stuff that is not free WRT modification,
> availability of the source code etc., but at least freely
> distributable in any medium, by anybody, for any price.
Distributors can already do this. I don't think Debian should be expending
time categorizing non-free into "non-free and really non-free"; let people
who would actually use the distinction (distributors) spend the time.
(It'd be a fair bit of time, requiring further analysis of clearly non-free
licenses.)
--
Glenn Maynard
Matthew Palmer
> > I'm not putting that up as the canonical form of the Q&A, but it
> > reinforces to me why the GFDL needs fixing, and not us.
>
> This says to me "It's hard to change the DFSG, and the DFSG is
> respected." Neither of those seems like a good reason for the GFDL to
> change. I think your argument could be much stronger if it included a
> "because we're right" paragraph.
The rest of the FAQ takes care of that part of the argument pretty well, I
think. It details why the GFDL sucks in many and varied ways. My Q&A is
just a defence against another sort of whinger - those who will make the
logical steps:
* Debian wants the FDL to change
* They want it to change because the FDL doesn't fit with their guidelines
* Why not change Debian's guidelines?
My answer only attacks this point. The rest of the FAQ answers the question
"Why does the GFDL suck so badly?".
- Matt
Matthew Palmer
> > Given the GNU Projects influence on Debian, shouldn't the GNU Manifesto
> > be included in the Debian GNU/Linux Distribution anyway?
>
> I propose expanding this question to:
>
> Why does Debian want to remove (say) the GNU Manifesto from the
> manuals? Do you want to suppress Stallman's views and just benefit
> from the software he created?
[Answer snipped]
<fx: resounding applause>
For what it's worth, I think this should go in pretty much unaltered (except
for a typo fix: "Changes to the software they get *from* us", line 8, para
2). It treads the line between "rah, rah, we love Stallman" and "Stallman
sucks" quite well.
--
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16
Anthony Towns
> instead of a document
> like this one that warns about and criticises the FDL, perhaps Debian
> should issue a more general statement along the lines of: We have
> decided documentation in Debian must comply with the DFSG, and this will
> entail throwing the following documents out of the distribution, and
> certian licenses (FDL etc) are causing problems in this task. Just an
> idea and I don't feel like writing it myself, but it might be less
> inflammatory.
I think we probably need this too, but it can't be instead of a thing
about the FDL, since otherwise we'd just get "But the GNU FDL's a free
license -- it says so right in the name -- why're you throwing stuff
licensed under it out?"
Matthew Palmer
> If we are willing to accept invariant chapters in DFSG-free
> documentation, I don't see how we could possibly claim the GNU FDL is not
> DFSG-free. Merely being able to delete something doesn't make it free --
> I can delete MS Office easily enough, eg.
>
> In short, I don't think that's a justifiable position.
The difference between Office and Invariants is (if I understand the licence
correctly) that Invariant sections can't be large chunks of the manual -
only so-called "secondary sections". It's merely just extending the
unmodifiability from the copyright notice itself to other ephemeral parts of
the documentation, while keeping the meat of the document flexible.
I don't think Invariant sections are a good idea because if one small part
of them is out-of-date (for instance the project website in a section on
"Getting the Software") you can't just update the address. Why someone
would make a section "Getting the Software" invariant is beyond me, but it
would probably fit in the definition of a "Secondary Section", so someone
somewhere would probably mark it as invariant through lack of knowledge. At
least being able to remove an invariant section and replacing it with
something equivalent solves that problem. I still don't like them, though.
> > What we do want is for our *users* to be allowed to remove the
> > GNU Manifesto from the manual if they can think of a reason to do
> > so.
>
> No -- we want our users to be able to take everything we give them, and
> be able to build on any part of it they might choose, with few exceptions.
Being able to remove an invariant secondary section wholesale allows the
user to build on the meat of the document without having to put all of the
invariant sections into their derived documentation if it doesn't fit (see
"The Reference Card" example for why this is needed).
> > If only we could be sure that the license on the manuals would
> > allow a user who thinks that "because!" is reason enough for him,
> > to remove the GNU Manifesto, we probably could still distribute
> > the unmidified manuals with the Invariant Section in it. That
> > would mean that part of what we distribute (namely the Invariant
> > Section itself) would not, strictly speaking, be modifyable, but
> > exceptions can be made for things that are both sufficiently
> > non-software-like not to need modifyability for technical reasons
> > and sufficienly relevant not to just constitute a waste of space
> > in the distribution.
>
> Didn't we just say we're not making exceptions for things that are
> "sufficiently non-software-like"?
I didn't read that anywhere (though I may have missed it). Since we're
allowing non-modifyable licence texts (which I think everyone would agree is
a given, and IIRC may be a legal requirement) allowing invariance on other
things which do not affect the "operability" of the documentation/software
doesn't seem like an overly huge problem. Defining "operability" in the
realm of documentation would be the stumbling block.
Anthony Towns
> The difference between Office and Invariants is (if I understand the licence
> correctly) that Invariant sections can't be large chunks of the manual -
> only so-called "secondary sections".
So, if I make a Debian system that includes a single non-free program, the
entire system -- including the non-free program -- is DFSG-free, because the
non-free program can be removed?
Manoj Srivastava
> On the other hand, the DFSGly non-free docs that are about to be
> thrown out of main are at least as freely distributable as any other
> package in main. This is a quality that many packages in non-free do
> not share with them. As I don't have non-free in my
> apt/sources.list, from my point of view, moving these docs to the
> 'non-free' section would practically mean the same thing as moving
> them to the trash dump. I guess this step would be far too radical.
> * Create a section 'distributable' that is between main and
> non-free, for stuff that is not free WRT modification,
> availability of the source code etc., but at least freely
> distributable in any medium, by anybody, for any price.
Why are we special casing invariant sections? There are
packages in main that are freely distributable in any medium, by
anybody, and can be modified, but not for commercial distribution --
arguably, these are as free as anything else, since you can't even
ask for money for them. Yet they are non-free (angband is one such
package, if you are looking for examples).
It seems to me that we have a well established tradition of
deeming so-called freely-distributable-but-not-dfsg-free packages,
and relegating them to non-free, and people like me who like tp play
rogue-like games but prefer free software have to add non-free to our
sources lists for ever.
I am not finding this line of argument compelling.
manoj
--
Many books require no thought from those who read them, for a very
simple reason--they made no such demand upon those who wrote them.
Those works, therefore, are the most valuable that set our thinking
faculties in the fullest operation. -- Colton
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Henning Makholm
> > If only we could be sure that the license on the manuals would
> > allow a user who thinks that "because!" is reason enough for him,
> > to remove the GNU Manifesto, we probably could still distribute
> > the unmidified manuals with the Invariant Section in it.
> Didn't we just say we're not making exceptions for things that are
> "sufficiently non-software-like"?
No, we just said that license text are sufficiently non-software-like
to enjoy an exception.
> > Of course both of these limits are
> > judgement calls, and each particular Invariant-But-Removable
> > section will have to be considered on a case-by-case basis.
> And further, as a practical matter, it's not reasonable for us to be
> making judgement calls on every random piece of documentation that
> gets uploaded.
A packager already has to make a lot of judgement calls when he
packages something. Deciding which parts of the documentation is
relevant and up-to-date to include in the binary package is already
one of them.
--
Henning Makholm "Gå ud i solen eller regnen, smil, køb en ny trøje,
slå en sludder af med købmanden, puds dine støvler. Lev!"
Henning Makholm
> Henning Makholm said:
> > Perhaps the O.A.C. ought to be our next target, but let us fight one
> > battle at a time.
> EXPN O.A.C.?
Obnoxious Advertising Clause.
--
Henning Makholm "However, the fact that the utterance by
Epimenides of that false sentence could imply the
existence of some Cretan who is not a liar is rather unsettling."
Henning Makholm
> Anthony Towns wrote:
> > What About Unmodifiable Software Licenses Like the GNU GPL?
> > Many software licenses unfortunately disallow the creation ofderivative
> > works. The FSF give everyone permission to distribute verbatim
> > copies of the GPL, eg, but do not give you permission to take the
> Apparently they do allow it, according to Brian T. Sniffen who points out
> http://www.fsf.org/licenses/gpl-faq.html#ModifyGPL
> If the license portion of the GPL can indeed be reused and modified then it
> is a bad example to use here.
But the question itself is good, because many people do have the
impression that the "changing it is not allowed" language at the top
of the GPL itself is the final word. This question would be an
excellent place to refer to Brian's discovery.
And one notices that the original reasoning still applies to the
GPL's Preamble, which seems to be explicitly non-reuseable.
> > Beyond allowing invariant sections, why does the GNU FDL suck?
> A little peice of me wonders if "why does the GNU FDL suck" is politic
> even in a FAQ, but whatever.
I think this is covered by the Draft Status Warning at the beginning
of the FAQ. In the production version, let us chage it to "what else
is bad about the GNU FDL?".
--
Henning Makholm "... popping pussies into pies
Wouldn't do in my shop
just the thought of it's enough to make you sick
and I'm telling you them pussy cats is quick ..."
James Miller
メッセージ：
> Hi Mark,
> On Thursday 24 April 2003 19:37, Mark Rafn wrote:
> > A few people have brought up the topic of Moral
> Rights, with
> > which I am not very familiar. They sound like
> some sort of
> > meta-copyright which an author cannot assign, and
> may not be
> > able to grant permission over.
> >
> > Does anyone have a pointer to some description of
> these rights
> > that a layman like myself might understand? I'm
> particularly
> > interested in how they relate to the GFDL and why
> they would
> > apply to documentation and not to software.
>
> * * * IANAL * * *
** This is not legal advice. This is a general statement
of law. **
I've reviewed this issue a couple years ago in an article
format (which is I think approachable to a layman, but it
is a law review piece so no promises.. :)
Whether documentation and software are treated differently
for moral rights will depend on the jurisdiction.
Remember, though, that moral rights is a continental
tradition, that was not recognized in common law
jurisdictions generally. Might be of interest for
example, that the U.S. signed on to Berne finally, and
basically said, "uh, we're already protecting moral
rights... sortof... so we need not change our domestic
law."
Software is generally treated differently though and I
reference a variety of sources that give a country by
country analysis. I focused on Japan, U.S., and others.
In the paper, I advocated an assertion of a moral right in
software for free and open source developers, because of
the strong nexus between the rights sought, eg. right to
attribution and integrity of the work, and the lack of
much nexus between the rights generally afforded under
copyright. I argued that for someone more interested in
"protecting" their work for public interest'y reason,
using a regime based on the moralistic rights of an author
makes better sense than one focused on maximized economic
utility.
The article provides several cites for further research,
but I'd be happy to discuss the topic more here. I should
revisit that article so comments are very welcomed.
http://www.nihonlinks.com/JamesMiller/OpenSourceMoralRights/
http://www.nihonlinks.com/JamesMiller/OpenSourceMoralRights/CurrentDraft.pdf
--
James Miller
jami...@yahoo.co.jp
__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/
Anthony Towns
> Scripsit Anthony Towns <a...@azure.humbug.org.au>
> > > If only we could be sure that the license on the manuals would
> > > allow a user who thinks that "because!" is reason enough for him,
> > > to remove the GNU Manifesto, we probably could still distribute
> > > the unmidified manuals with the Invariant Section in it.
> > Didn't we just say we're not making exceptions for things that are
> > "sufficiently non-software-like"?
> No, we just said that license text are sufficiently non-software-like
> to enjoy an exception.
That's not why we're doing it. We're doing it because we don't have any
choice about it.
If you're seriously arguing that things that merely being "not
software-like" is enough reason not to apply the DFSG to the GNU Manifesto
or the GPL, then you can't apply it to documentation in general. If you
want to draw a distinction between them, you need to draw a clear one,
not handwave about it.
There is a clear distinction between licenses and documentation -- one
goes in /usr/share/doc/<foo>/copyright and is solely concerned about
what you can and can't do with everything else, the other goes anywhere
but in /usr/share/doc/<foo>/copyright.
> > > Of course both of these limits are
> > > judgement calls, and each particular Invariant-But-Removable
> > > section will have to be considered on a case-by-case basis.
> > And further, as a practical matter, it's not reasonable for us to be
> > making judgement calls on every random piece of documentation that
> > gets uploaded.
> A packager already has to make a lot of judgement calls when he
> packages something.
It's not the packager that makes the judgement call as to what's
allowable -- it's ftpmaster and -legal. Packagers simply aren't able to
make reliable judgement calls as to what is and isn't DFSG-free in the
general case.
(And this is why I don't think "me too" posts are particularly relevant
as to establishing "consensus")
Jeremy Hankins
> If only we could be sure that the license on the manuals would
> allow a user who thinks that "because!" is reason enough for
> him, to remove the GNU Manifesto, we probably could still
> distribute the unmidified manuals with the Invariant Section in
> it. That would mean that part of what we distribute (namely the
> Invariant Section itself) would not, strictly speaking, be
> modifyable, but exceptions can be made for things that are both
> sufficiently non-software-like not to need modifyability for
> technical reasons and sufficienly relevant not to just
> constitute a waste of space in the distribution. Of course
> both of these limits are judgement calls, and each particular
> Invariant-But-Removable section will have to be considered on a
> case-by-case basis. [Hmmm.. so I think at least, but I'm not
> sure that this is a clear d-l consensus. -HM]
I think this is definitely not the d-l consensus. On one hand, the
benefits to be gained from a free-software-like approach to purely
artistic/aesthetic (i.e., non-functional) works aren't as obvious.
While one can imagine exceptions, it's not as useful to mix-and-match
bits of a novel into your own novel. You don't see nearly as many
collaborative novels or paintings as programs, and I imagine that an
authors pride in a work is much more associated with the work as a
whole in the case of a novel or painting than in a program.
On the other hand, this is an extremely fuzzy distinction, there are
numerous exceptions, and bits that fall into one category will
sometimes move into another. It seems to me that most of the
pride-in-work issue can be resolved by a license that requires
accurate attribution and changing the name (so as to make the changed
attribution perfectly clear) when modified. Those requirements
(assuming they're done right) are pretty clearly DFSG free, I think.
So I'm sympathetic to someone who says: My work is my personal
communication with the world and it doesn't make sense to put it in a
commons. But I don't see any reason for Debian to distribute these
folks' statements (fictional, rants, or otherwise) unless in some sort
of (semi-)official way Debian actually supports or endorses the
statement.
--
Jeremy Hankins <no...@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Branden Robinson
> But the question itself is good, because many people do have the
> impression that the "changing it is not allowed" language at the top
> of the GPL itself is the final word. This question would be an
> excellent place to refer to Brian's discovery.
/me sniffles dejectedly
But I made the same "discovery" 2 days earlier, on Tue, 22 Apr 2003
12:49:47 -0500 in Message-ID: <2003042217...@deadbeast.net>.
/me pouts :)
--
G. Branden Robinson | I am sorry, but what you have
Debian GNU/Linux | mistaken for malicious intent is
bra...@debian.org | nothing more than sheer
http://people.debian.org/~branden/ | incompetence! -- J. L. Rizzo II
Joe Moore
> Scripsit Anthony Towns <a...@azure.humbug.org.au>
>
>> > If only we could be sure that the license on the manuals would
>> allow a user who thinks that "because!" is reason enough for
>> him, to remove the GNU Manifesto, we probably could still
>> distribute the unmidified manuals with the Invariant Section in
>> it.
>
>> Didn't we just say we're not making exceptions for things that are
>> "sufficiently non-software-like"?
>
> No, we just said that license text are sufficiently non-software-like to
> enjoy an exception.
I think the key reason (that licenses are acceptable invariant texts) is
that the license text is a legal agreement between _you_ and the
_copyright holder_. I can not change the agreement you have with the
copyright holder, only you and she can. If you and she change your
agreement (either by explicitly licensing under an alternative license, or
implicitly by the holder changing the license, and you agreeing to those
terms*) I have no control over that. I can not modify someone else's
agreement.
That is why the license texts must be "invariant".
--Joe
* For example, if the work was originally released under a "non-commercial
use only" license, but is later also released under the GPL, you might
agree to the GPL's terms rather than the "non-commercial use only".
Thomas Uwe Gruettmueller
On Friday 25 April 2003 05:00, Glenn Maynard wrote:
> On Fri, Apr 25, 2003 at 04:57:36AM +0200, Thomas Uwe
Gruettmueller wrote:
> > On the other hand, the DFSGly non-free docs that are about
> > to be thrown out of main are at least as freely
> > distributable as any other package in main. This is a
> > quality that many packages in non-free do not share with
> > them.
>
> There's lots of software in non-free that is freely
> distributable, but non-free for other reasons, such as
> limitations on commercial use. Non- free things should go in
> non-free, even if there's a lack of free equivalents.
I agree that they should not stay in main, but I don't think
that freely distributable documents should be mixed with stuff
which is not allowed to be distributed commercially, or which
according to its license, cannot be exported to Iraq.
If the new section proposed below is considered a subset of
'non-free', then I fully agree with the above.
> > As I don't have non-free in my
> > apt/sources.list, from my point of view, moving these docs
> > to the 'non-free' section would practically mean the same
> > thing as moving them to the trash dump. I guess this step
> > would be far too radical.
>
> Requiring you to add a line or two to sources.list isn't
> "trashing" anything.
I'm not convinced, yet. Can I configure apt-cache that it
produces red '[contrib]' and '[non-free]' warnings like
packages.debian.org?
> If this is a "radical" move, I'd say the earlier one of moving
> non-free software to non-free was an order of magnitude more
> "radical".
Is there any documentation of the history of the 'non-free'
section? Have there been similar discussions?
> > So, now I'm repeating an idea that I alredy mentioned here,
> > after selfhtml had been kicked:
> >
> > * Create a section 'distributable' that is between main and
> > non-free, for stuff that is not free WRT modification,
> > availability of the source code etc., but at least freely
> > distributable in any medium, by anybody, for any price.
>
> Distributors can already do this. I don't think Debian should
> be expending time categorizing non-free into "non-free and
> really non-free"; let people who would actually use the
> distinction (distributors) spend the time. (It'd be a fair bit
> of time, requiring further analysis of clearly non-free
> licenses.)
Right. The suggestion was primarily adressed to those people who
would like to change the DFSG. If they want to have guidelines
for lesser free software, in order to build a lesser free
variant of Debian, they are always free to create them, but
please not by replacing the original DFSG and the original
Debian!
cu,
Thomas
}:o{#
Matthew Palmer
[Disclaimer: if, at any point during the reading of this message, you see a
point which has been raised and covered before, please point me to the
archive message. I couldn't find anything in the d-legal archives back to
Jan-2002 which appeared to deal with this. My apologies if I've rehashed
something done to death before.]
> I think this is definitely not the d-l consensus. On one hand, the
> benefits to be gained from a free-software-like approach to purely
> artistic/aesthetic (i.e., non-functional) works aren't as obvious.
> While one can imagine exceptions, it's not as useful to mix-and-match
> bits of a novel into your own novel. You don't see nearly as many
> collaborative novels or paintings as programs, and I imagine that an
> authors pride in a work is much more associated with the work as a
> whole in the case of a novel or painting than in a program.
I was about to pipe up with "but we don't distribute novels with Debian"
until I realised that we want to distribute a few other novel-like things -
pure documentation not associated with a specific software program (eg the
hoary old chestnut of the RFCs). So, I have to start thinking again about
documentation in a different light to software. Could we produce a
distinction amongst our offerings in the following manner:
* Software. Anything intended to instruct a computational device to perform
some action. Yes, total crap definition, but it gets the idea across.
* Documentation for software. Intended to enlighten humans on the design,
implementation, usage, etc of a specific piece software.
* Other documentation. Standards, DFSG, GNU manifesto, etc.
DFSG applies to software. (duh). DFSG applied to docs for software (for
all the very good reasons given in the draft Debian GFDL FAQ). But for
"other documentation" (and we'd need to have a pretty clear definition of
what that was before going too far forward) there could be a second set of
guidelines for it's inclusion in Debian.
To roast a hoary chestnut, I've not yet seen a good argument why we'd want
the RFCs to be relicensed as DFSG-free, apart from the "so it can go into
Debian main". Modifying an RFC and re-releasing it is not a good thing, but
the DFSG says it is, and we want that right (if we're applying DFSG to
everything that goes into main, that is).
The non-software documentation category seems to fit everything else we're
worried about, too. The DFSG, social contract, GNU Manifesto, software
licences, all of these are non-software documentation which we want to
distribute (OK, maybe not the GM) but which in general we don't *want* to be
DFSG-free.
So, could it be possible to come up with a definition of non-software
documentation, about which we could say "it must be free for verbatim
distribution (with copyright notices attached), translation, and conversion
into other machine-readable formats" but which, apart from that,
normal copyright restrictions could apply?
My first stab at a non-software documentation definition would be something
like:
* It must be intended for final consumption by a human reader.
* It must not be specifically intended to apply to, or to refer to, a
particular piece of software [I'm trying to word this so that the same doc
which could be for many softwares, like a licence text, qualifies, but a
README doesn't, because we'd want to modify a readme]
* If distributed with a package of software, modification of the software or
changing circumstance should not require a modification of the
documentation.
Not perfectly clear, and probably with loopholes you could put a jumbo
through, but I think it's enough for the open-minded reader to get an
understanding of.
--
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16
--
Mark Rafn
> I was about to pipe up with "but we don't distribute novels with Debian"
> until I realised that we want to distribute a few other novel-like things -
> pure documentation not associated with a specific software program (eg the
> hoary old chestnut of the RFCs).
And interactive fiction, and screensaver artworks, and actual novels
perhaps.
> So, I have to start thinking again about
> documentation in a different light to software.
I'm still completely unconvinced that there is any useful distinction
between a fractal generator, the generated fractal image (with human input
on parameters, colors, etc), a paper describing what fractals are, a
document describing how to make pretty fractals from the generator, and a
poem inspired by a fractal.
They're all encodable as streams of bits. They all require effort and
creativity to create. They all are useful to a recipient. They all are
free iff a user can modify and copy them.
> Could we produce a distinction amongst our offerings in the following
> manner:
Why do we want to produce a distinction where there is none?
> DFSG applies to software. (duh). DFSG applied to docs for software (for
> all the very good reasons given in the draft Debian GFDL FAQ). But for
> "other documentation" (and we'd need to have a pretty clear definition of
> what that was before going too far forward) there could be a second set of
> guidelines for it's inclusion in Debian.
Why? Why would we call a poem which cannot be modified "free" if we don't
also think a poetry generator which cannot be modified is free?
> To roast a hoary chestnut, I've not yet seen a good argument why we'd want
> the RFCs to be relicensed as DFSG-free, apart from the "so it can go into
> Debian main".
Oh, that's easy. I wish they were free so I could reuse the good bits in
other works, and otherwise improve my world by creating and distributing
derived works.
This is absolutly no different from why you'd want a piece of software to
be licensed freely.
> Modifying an RFC and re-releasing it is not a good thing
It's exactly as good a thing as modifying Apache and re-releasing it.
The modified version is expected to fit someone's needs better than the
original.
> The DFSG, social contract, GNU Manifesto, software
> licences, all of these are non-software documentation which we want to
> distribute (OK, maybe not the GM) but which in general we don't *want* to be
> DFSG-free.
The owners of these documents should be encouraged to make them free, and
if not, they should go in non-free.
License texts themselves are a special case. The actual terms of the
grant of permission cannot be changed, and can only be encoded in the
original wording. That makes perfect sense, and is fundamentally
different from a copyrightable work in a definable way.
--
Mark Rafn da...@dagon.net <http://www.dagon.net/>
Henning Makholm
> On Fri, Apr 25, 2003 at 02:21:24PM +0200, Henning Makholm wrote:
> > excellent place to refer to Brian's discovery.
> /me sniffles dejectedly
> But I made the same "discovery" 2 days earlier, on Tue, 22 Apr 2003
> 12:49:47 -0500 in Message-ID: <2003042217...@deadbeast.net>.
Apologies. I don't keep books on who said what first, just copied
Joey's attibution.
--
Henning Makholm "- Or hast thee (perverted) designs
to attempt (strange, hybrid) procreation
experiments with this (virginal female) self?"
Henning Makholm
> Henning Makholm said:
> > No, we just said that license text are sufficiently non-software-like to
> > enjoy an exception.
> I think the key reason (that licenses are acceptable invariant texts) is
> that the license text is a legal agreement between _you_ and the
> _copyright holder_.
> That is why the license texts must be "invariant".
But as we've found out now, the part of the GPL that is actually
invariant is the preamble, which has no legal content...
--
Henning Makholm "Nemo enim fere saltat sobrius, nisi forte insanit."
Glenn Maynard
> To roast a hoary chestnut, I've not yet seen a good argument why we'd want
> the RFCs to be relicensed as DFSG-free, apart from the "so it can go into
> Debian main". Modifying an RFC and re-releasing it is not a good thing, but
> the DFSG says it is
I suppose this is opportunity to say that this begs the question. :)
Being able to modify an RFC and re-release it is absolutely a good thing.
Why should I have to start from scratch when writing a new spec that
resembles an older one? Why shouldn't I be able to reuse parts of other
RFCs?
The only possible problem is if someone releases a modified RFC and doesn't
mark it appropriately, but that's easily solved (require a name change).
I've yet to see a good argument why RFCs shouldn't be free.
--
Glenn Maynard
Matthew Palmer
> > Could we produce a distinction amongst our offerings in the following
> > manner:
>
> Why do we want to produce a distinction where there is none?
We obviously disagree on whether there is a distinction.
> > To roast a hoary chestnut, I've not yet seen a good argument why we'd want
> > the RFCs to be relicensed as DFSG-free, apart from the "so it can go into
> > Debian main".
>
> Oh, that's easy. I wish they were free so I could reuse the good bits in
> other works, and otherwise improve my world by creating and distributing
> derived works.
I see nothing in the RFC licence which limits you from doing that. Even all
rights reserved doesn't limit you from doing that in practice, since you can
always make a reference to the other work. But the RFC licence allows you
to go further - Section 3 of the general guidelines for copyright of RFCs
(as I've just read it from /usr/share/doc/doc-rfc-std/copyright, doc-std-rfc
version 20010829-1) states that "Copying and distributing portions of an
RFC" is allowed. Proper credit and citations must be provided.
> > Modifying an RFC and re-releasing it is not a good thing
>
> It's exactly as good a thing as modifying Apache and re-releasing it.
> The modified version is expected to fit someone's needs better than the
> original.
Except that it's typically a lot easier to work out where a program has been
incompatibly modified ("oops, compile error, damn, the API changed") than a
standard has been modified. The use of 'diff' notwithstanding.
> License texts themselves are a special case. The actual terms of the
> grant of permission cannot be changed, and can only be encoded in the
> original wording. That makes perfect sense, and is fundamentally
> different from a copyrightable work in a definable way.
I'll agree with that. Should something along those lines go somewhere
definitive so we can point people who say "but you can't change the GPL! So
that's non-free!".
--
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16
--
Matthew Palmer
> > To roast a hoary chestnut, I've not yet seen a good argument why we'd
> > want the RFCs to be relicensed as DFSG-free, apart from the "so it can
> > go into Debian main". Modifying an RFC and re-releasing it is not a
> > good thing, but the DFSG says it is
>
> I suppose this is opportunity to say that this begs the question. :)
>
> Being able to modify an RFC and re-release it is absolutely a good thing.
> Why should I have to start from scratch when writing a new spec that
> resembles an older one? Why shouldn't I be able to reuse parts of other
> RFCs?
RFC authors do it all the time, by issuing updates to existing RFC
documents. They say "Do it like this, except for this, this, and this".
Since software is not written in English, we can't exactly use the same
methodology as an RFC to write new versions of our software (unless we take
this to be the human language equivalent of a patch). Hmm, that suggests
that all documentation which can be redistributed is DFSG free... <grin>
--
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16
--
Glenn Maynard
> RFC authors do it all the time, by issuing updates to existing RFC
> documents. They say "Do it like this, except for this, this, and this".
This argument would suggest that any unmodifiable, freely-distributable
document is free. You can reference *any* document in this way. It's
certainly not similar to software patches. (And I believe many people on
this list consider the "patches" exception to have been an error.)
There's nothing free about being forced to do this.
--
Glenn Maynard
Steve Langasek
> > There's lots of software in non-free that is freely
> > distributable, but non-free for other reasons, such as
> > limitations on commercial use. Non- free things should go in
> > non-free, even if there's a lack of free equivalents.
> I agree that they should not stay in main, but I don't think
> that freely distributable documents should be mixed with stuff
> which is not allowed to be distributed commercially, or which
> according to its license, cannot be exported to Iraq.
Why should Debian distinguish between different shades of non-freeness?
Are you aware that there is much software already in non-free which is
freely redistributable but non-modifiable?
--
Steve Langasek
postmodern programmer
Anthony DeRobertis
> What About Unmodifiable Software Licenses Like the GNU GPL?
Strike that text! It's not true. Noting
<http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL>, let me try:
#### start new answer ####
The Free Software Foundation clarifies what it means by "...but changing
[the GPL] is not allowed" in its GPL FAQ at
<http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL>. In brief, this
says that you may change the GPL provided that:
1) You remove the FSF's endorsement of the license which
is the preamble. The Debian Project has no problem with
this; it is certainly an author's right to refuse to
endorse arbitrary changes.
2) You do not call the license "GPL" and make it clear that it
isn't the GPL. We understand that certain types of software,
require this, and thus our DFSG explicitly permits this,
stating "The license may require derived works to carry a
different name or version number from the original software."
So, the full terms that the GPL is distributed under, as explained on
the FSF website, actually comply with the DFSG.
#### end new answer ####
Anthony DeRobertis
> On one hand, the
> benefits to be gained from a free-software-like approach to purely
> artistic/aesthetic (i.e., non-functional) works aren't as obvious.
A rather ironic statement in a Bazaar-type development of the wording of
a position statement, methinks :-)
Also, I must strongly disagree in general. Take artwork for example.
Suppose you create a (digital) painting of a flower, and you make it
red. I decide that orange would be better, so I change it. Maybe aj
comes along and thinks the leaf would look better if it were a little
rounder.
Or, more pertinently to Debian, I think the icon for a program is ugly,
so I change it. Or I dislike a theme author's choice of fonts, colors,
etc. These are, as much as anything can be, purely aesthetic
considerations, and yet, clearly benefit from being free.
Art also often includes other art into itself. For example, I've got a
neat desktop background which uses the Debian Swirl.
Novels may not benefit much from word-for-word copying from each other,
but copying things like characters, scenes, etc. could sure be useful.
You don't see it much because it's against copyright law. The ones that
are seen are parodies, and are only allowed due to fair use. And they
have to fight it out in court half the time anyway (recent example: _The
Wind Done Gone_)
Many movies have been made from fairy tales, fables, and legends that
are, free due to their public-domain status (go ask Disney about that
hypocracy). Many pieces of music borrow themes, or even the entire tune,
from other, now public-domain music.
I'm not sure where the myth that the benefits of freedom are less for
non-software comes from, but it sure isn't true.
Anthony DeRobertis
> Modifying an RFC and re-releasing it is not a good thing,
And why isn't it? Is it a bad thing if I modify the TCP/IP-related RFCs
to produce a book on TCP/IP? Is it a bad thing if I copy some packet
formats, and their related descriptions, out of an RFC to make a new
protocol? Is it a bad thing if I copy a MIB to make an SNMP-anything?
It's only a bad thing if I modify and RFC and then claim it is still
that RFC. The DFSG already deals with this; it allows a license to
require a name change. I don't think requiring things like removing the
ISC's endorsement from a modified copy would be wrong, either,
especially since the law already requires it.
Back in June of last year Branden proposed a Debian Free Content License
which had some great ideas about endorsements. I'm not sure if he even
finished writing a draft; I can't seem to find one. However, the
conversation (hundreds of messages...) is in the debian-legal archives.
Anthony DeRobertis
> Except that it's typically a lot easier to work out where a program has been
> incompatibly modified ("oops, compile error, damn, the API changed") than a
> standard has been modified. The use of 'diff' notwithstanding.
Well, when you modify a program enough to cause a compile error, sure
it's easy to spot. It's also easy to spot when someone modifies a
standard by renaming all the sections and changing the terminology.
If you really think that its a lot easier to note where a program has
been incompatibly modified, please find all the places where NCSA Mosiac
has been incompatibly (with the relevant standards) been modified to
produce Internet Exploder. Or, if you content that source must be
available, please confirm that GCC-3.2 -> GCC-3.3 won't cause any
regressions in compatibility with the C++ standard, the various
microprocessor standards, etc. The FSF, I'm sure, will be most grateful
for that work.
It's not easy to find program modifications that don't show up as
compile- or link-time errors, even with the use of diff. Programs can be
quite long, and often changes don't change behavior (e.g.,
optimizations). An even larger subset of changes don't break
compatibility.
Glenn Maynard
> 1) You remove the FSF's endorsement of the license which
> is the preamble. The Debian Project has no problem with
> this; it is certainly an author's right to refuse to
> endorse arbitrary changes.
> So, the full terms that the GPL is distributed under, as explained on
> the FSF website, actually comply with the DFSG.
It still contains an invariant section, though it's less severe than the
GFDL type, as it can be removed. I don't believe there's consensus that
invariant sections in general are okay as long as they can be removed,
though.
Anthony DeRobertis
> RFC authors do it all the time, by issuing updates to existing RFC
> documents. They say "Do it like this, except for this, this, and this".
No, that's generally only done for tiny changes: Adding a bit here or
there, etc.
For large changes, the old document is obsoleted and the relevant
portions included into the new one. Any other way would be insane!
Consider that to understand the IPv6 Addressing Architecture, you'd have
to read, in order:
RFC 1884 (December 1995)
RFC 2373 (July 1998)
RFC 3515 (August 2003)
An RFC can either obsolete another RFC (completely replace it) or update
it.
Anthony DeRobertis
> Of course both of these limits are
> judgement calls, and each particular Invariant-But-Removable
> section will have to be considered on a case-by-case basis.
> [Hmmm.. so I think at least, but I'm not sure that this is
> a clear d-l consensus. -HM]
I don't think invariant-but-removable sections are OK; we'd certainly
never accept things like that anywhere else, and I don't think that
compromise would buy anyone much:
If I am the author of a work, why would I want it? The only
reason I'd have to make something invariant would be
something like the manifesto, which contains my beliefs,
arguments, etc. But would it not be a better solution to
require that if its changed, it is clearly changed to show
may not represent my views anymore?
If I am the author, I could _possibly_ use one for an
endorsement of the work, by e.g., making a statement in a
removable invariant section that I endorse the work with a given
MD5sum (calculated assuming the listed md5sum is all 0's, of
course), but upon further reflection I don't need an invariant
section for that: I could use gpg, or I could just include that
statement anywhere in the document. Changing it to state I
endorse a document I do not is already illegal. I don't need
license conditions to make it so.
If I am a distributor, sure, I can rip them all out, but not
having them in the first place is better for me.
I can see the motivation for non-removable invariant sections; they can
be used for things like credits, dedications, odes to my pet anteater,
etc. They just aren't free.
Anthony DeRobertis
> It still contains an invariant section, though it's less severe than the
> GFDL type, as it can be removed. I don't believe there's consensus that
> invariant sections in general are okay as long as they can be removed,
> though.
It's nothing special created by the copyright license. Its the general
rule that you aren't allowed to misrepresent other's beliefs, which is
what carrying the Preamble to your modified license (especially the
first two paragraphs), without the FSF's permission, would be.
Henning Makholm
[GPL preamble]
> > It still contains an invariant section, though it's less severe than the
> > GFDL type, as it can be removed.
> It's nothing special created by the copyright license. Its the general
> rule that you aren't allowed to misrepresent other's beliefs, which is
> what carrying the Preamble to your modified license (especially the
> first two paragraphs), without the FSF's permission, would be.
That could be covered adequately by a you-must-not-misrepresent-me
clause. The current status of the preamble goes much farther than
that. It says that I must not reuse the wordings in the preamble for
composing a text that expresses *my* views on licensing (and makes
clear that they are mine, not the FSF's).
Your argument could be applied to any sort of invariant sections:
Because there is some possible way of modifying this section that
would misrepresent my beliefs, should I not feel morally entitled to
forbid *all* modifications of the section?
--
Henning Makholm "Han råber og skriger, vakler ud på kørebanen og
ind på fortorvet igen, hæver knytnæven mod en bil,
hilser overmådigt venligt på en mor med barn, bryder ud
i sang og stiller sig til sidst op og pisser i en port."
Glenn Maynard
I can change most of that text all I want, and as long as I don't claim the
resulting text is the FSF's beliefs, I'm not misrepresenting anything.
The only thing stopping me from doing that is the FSF's copyright.
Thomas Uwe Gruettmueller
On Friday 25 April 2003 10:54, Manoj Srivastava wrote:
> On Fri, 25 Apr 2003 04:57:36 +0200, Thomas Uwe Gruettmueller
<sloy...@gmx.net> said:
> > * Create a section 'distributable' that is between main and
> > non-free, for stuff that is not free WRT modification,
> > availability of the source code etc., but at least freely
> > distributable in any medium, by anybody, for any price.
>
> Why are we special casing invariant sections? There are
> packages in main that are freely distributable in any medium,
^^^^^^^ Really?
> by anybody, and can be modified, but not for commercial
> distribution --
I don't understand how this relates to the GFDL discussion.
> arguably, these are as free as anything else,
> since you can't even ask for money for them.
I was not talking about beer freedom above.
cu,
Thomas
}:o{#
Thomas Uwe Gruettmueller
On Saturday 26 April 2003 06:15, Steve Langasek wrote:
> On Fri, Apr 25, 2003 at 10:49:26PM +0200, Thomas Uwe
> Gruettmueller wrote:
> > I don't think that freely distributable documents should be
> > mixed with stuff which is not [freely distributable]
> Why should Debian distinguish between different shades of
> non-freeness?
Because I think this would make it easier to throw non-free
things out of main.
> Are you aware that there is much software
> already in non-free which is freely redistributable but
> non-modifiable?
Then leave it there until someone starts complaining about it.
Glenn Maynard
> > Are you aware that there is much software
> > already in non-free which is freely redistributable but
> > non-modifiable?
>
> Then leave it there until someone starts complaining about it.
(and then continue leaving it there)
--
Glenn Maynard
Anthony DeRobertis
> The current status of the preamble goes much farther than
> that. It says that I must not reuse the wordings in the preamble for
> composing a text that expresses *my* views on licensing (and makes
> clear that they are mine, not the FSF's).
That's true. I wonder if the FSF would be willing to change that.
Jeremy Hankins
> On Fri, 2003-04-25 at 11:26, Jeremy Hankins wrote:
>> On one hand, the
>> benefits to be gained from a free-software-like approach to purely
>> artistic/aesthetic (i.e., non-functional) works aren't as obvious.
>
> A rather ironic statement in a Bazaar-type development of the wording of
> a position statement, methinks :-)
>
> Also, I must strongly disagree in general. Take artwork for example.
> Suppose you create a (digital) painting of a flower, and you make it
> red. I decide that orange would be better, so I change it. Maybe aj
> comes along and thinks the leaf would look better if it were a little
> rounder.
I'm not sure we're disagreeing, actually. The bit you quoted was more
a "setting up the problem" bit, which I then argued against in the
rest of the message. I think it is the case that the benefits aren't
as obvious, but that doesn't mean that they aren't there. What's
more, given that restrictive licensing isn't actually necessary to
protect the pride-in-work style interests of authors, there's no
reason for them.
--
Jeremy Hankins <no...@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Stephane Bortzmeyer
Anthony DeRobertis <a...@suespammers.org> wrote
> > RFC authors do it all the time, by issuing updates to existing RFC
> > documents. They say "Do it like this, except for this, this, and this".
>
> No, that's generally only done for tiny changes: Adding a bit here or
> there, etc.
>
> For large changes, the old document is obsoleted and the relevant
> portions included into the new one. Any other way would be insane!
Therefore, the IETF is insane often :-) Take the DNS, for instance,
RFC 1034 and 1035 were never obsoleted (while many parts of them are)
and, to take your example, in order to understand the DNS, you have to
read several RFC, some updating or obsoleting others.
Anthony DeRobertis
> Therefore, the IETF is insane often :-)
No argument there.
Henning Makholm
> It's easy to misapply the GNU FDL.
> The GNU FDL says that only "Secondary Sections" (a term it defines)
> may be marked Invariant, but does not say what should happen if a
> section that is not Secondary is listed as an Invariant Section.
> The FSF itself has made this mistake several times[1], so we know
> it's an easy mistake to make.
Actually, I wonder whether the current application of the GFDL for
GNU manuals is internally consistent at all.
For example, the GNU diffutils manual is licenced with the Front-Cover
Text "A GNU Manual". Say now that I'm a FooBSD user who for some
reason have become dissatisfied with the quality of the documentation
for diff that FooBSD ships with (this is a hypothetical example; I
have access to no *BSD systems and don't know anything about the
actual state of their documentation). So I take the texinfo source for
the GNU diffutils manual and hack upon it so that it describes FooBSD
diff.
Now I have a manual for FooBSD diff whose license says that it needs
to be called "A GNU Manual" on its front cover. That could be somewhat
confusing for users - does this document describe the FooBSD or the
GNU implementation of diff? And is this front-cover text even
compatible with the requirement that I remove all Endorsements?
Worse yet, my FooBSD diff manual must say on its *back* cover: "Copies
published by the Free Software Foundation raise funds for GNU
development" which is rather meaningless as long as the FSF does not
publish copies of the FooBSD version of the manual at all!
--
Henning Makholm "... not one has been remembered from the time
when the author studied freshman physics. Quite the
contrary: he merely remembers that such and such is true, and to
explain it he invents a demonstration at the moment it is needed."
Brian M. Carlson
>
> RFC 1884 (December 1995)
> RFC 2373 (July 1998)
> RFC 3515 (August 2003)
Uhh, I didn't know that the IETF issued RFCs in the future. Perhaps you
meant April 2003?
--
Brian M. Carlson <san...@crustytoothpaste.ath.cx> 0x560553e7
"Let us think the unthinkable, let us do the undoable. Let us prepare
to grapple with the ineffable itself, and see if we may not eff it
after all." --Douglas Adams
Anthony DeRobertis
^^^^^^^^^^^
> Uhh, I didn't know that the IETF issued RFCs in the future. Perhaps you
> meant April 2003?
Might have something to do with <1051541545.31808.105.camel@whosthere>,
or the effect of that on me :-D
Don Armstrong
> But as we've found out now, the part of the GPL that is actually
> invariant is the preamble, which has no legal content...
I've seen this meme popping up in a couple of places.
Can you provide me a reference upon which you are basing this
statement?
Don Armstrong
--
DIE!
-- Maritza Campos http://www.crfh.net/d/20020601.html
http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu
Don Armstrong
> On Sat, 26 Apr 2003, Henning Makholm wrote:
>> But as we've found out now, the part of the GPL that is actually
>> invariant is the preamble, which has no legal content...
>
> statement?
I should remind myself to follow up with all of my unread mail before
asking questions which are easily answered.[1] Although, note the
dissonance between [1] and [2]:
In fact, the GPL is copyrighted, and its license permits only
verbatim copying of the entire GPL.
Wheras [1] in the FAQ says something to the effect of: "If you modify
it, we probably wont take legal action against you" Of course, the
language of the GPL copyright clause itself is prety clear that it
precludes modification. [I guess the FSF just wants it both ways...]
Don Armstrong
1: http://www.gnu.org/licenses/gpl-faq.html#TOCModifyGPL
2: http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble
--
I never until now realized that the primary job of any emoticon is to
say "excuse me, that didn't make any sense." ;-P -- Cory Doctorow
Branden Robinson
> Back in June of last year Branden proposed a Debian Free Content License
> which had some great ideas about endorsements. I'm not sure if he even
> finished writing a draft; I can't seem to find one. However, the
> conversation (hundreds of messages...) is in the debian-legal archives.
I never got very far along on that project, and I have no draft.
--
G. Branden Robinson | Measure with micrometer,
Debian GNU/Linux | mark with chalk,
bra...@debian.org | cut with axe,
http://people.debian.org/~branden/ | hope like hell.
Branden Robinson
Can you gentlemen disambiguate or resolve the tension between the
following statements in the GPL FAQ[1]?
"You can use the GPL terms (possibly modified) in another license
provided that you call your license by another name and do not include
the GPL preamble, and provided you modify the instructions-for-use at
the end enough to make it clearly different in wording and not mention
GNU (though the actual procedure you describe may be similar)."[2]
"In fact, the GPL is copyrighted, and its license permits only verbatim
copying of the entire GPL."[3]
The second statement appears to be slightly misleading given the first.
[1] http://www.gnu.org/licenses/gpl-faq.html
[2] http://www.gnu.org/licenses/gpl-faq.html#TOCModifyGPL
[3] http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble
--
G. Branden Robinson | I must despise the world which does
Debian GNU/Linux | not know that music is a higher
bra...@debian.org | revelation than all wisdom and
http://people.debian.org/~branden/ | philosophy. -- Ludwig van Beethoven
Branden Robinson
> Actually, I wonder whether the current application of the GFDL for
> GNU manuals is internally consistent at all.
>
> For example, the GNU diffutils manual is licenced with the Front-Cover
> Text "A GNU Manual". Say now that I'm a FooBSD user who for some
> reason have become dissatisfied with the quality of the documentation
> for diff that FooBSD ships with (this is a hypothetical example; I
> have access to no *BSD systems and don't know anything about the
> actual state of their documentation). So I take the texinfo source for
> the GNU diffutils manual and hack upon it so that it describes FooBSD
> diff.
>
> Now I have a manual for FooBSD diff whose license says that it needs
> to be called "A GNU Manual" on its front cover. That could be somewhat
> confusing for users - does this document describe the FooBSD or the
> GNU implementation of diff? And is this front-cover text even
> compatible with the requirement that I remove all Endorsements?
>
> Worse yet, my FooBSD diff manual must say on its *back* cover: "Copies
> published by the Free Software Foundation raise funds for GNU
> development" which is rather meaningless as long as the FSF does not
> publish copies of the FooBSD version of the manual at all!
Another good argument against the GNU FDL.
Sorry for the AOL remark, but I'm trying to flag stuff I think should go
in our big FAQ.
--
G. Branden Robinson | "To be is to do" -- Plato
Debian GNU/Linux | "To do is to be" -- Aristotle
bra...@debian.org | "Do be do be do" -- Sinatra
http://people.debian.org/~branden/ |
Branden Robinson
> On Sat, Apr 26, 2003 at 12:24:56AM -0400, Anthony DeRobertis wrote:
> > 1) You remove the FSF's endorsement of the license which
> > is the preamble. The Debian Project has no problem with
> > this; it is certainly an author's right to refuse to
> > endorse arbitrary changes.
>
> > So, the full terms that the GPL is distributed under, as explained on
> > the FSF website, actually comply with the DFSG.
>
> It still contains an invariant section, though it's less severe than the
> GFDL type, as it can be removed. I don't believe there's consensus that
> invariant sections in general are okay as long as they can be removed,
> though.
I think before Debian puts anything in main it should remove any
invariant sections from the work, just as we do with non-free source
code. I once had a big old nasty flamewar with the FTP admins that
was tangentially related to this point, but the FTP admins and I agreed
that having non-free source code in a package's .orig.tar.gz was
unacceptable even if it wasn't "used for anything" and did not appear in
any binary packages.
In other words, invariant sections (small I, small S) are not DFSG-free,
but the removal of invariant sections from a work may be sufficient to
render it DSFG-free.
--
G. Branden Robinson | "There is no gravity in space."
Debian GNU/Linux | "Then how could astronauts walk
bra...@debian.org | around on the Moon?"
http://people.debian.org/~branden/ | "Because they wore heavy boots."
Josselin Mouette
> I think before Debian puts anything in main it should remove any
> invariant sections from the work, just as we do with non-free source
> code. I once had a big old nasty flamewar with the FTP admins that
> was tangentially related to this point, but the FTP admins and I agreed
> that having non-free source code in a package's .orig.tar.gz was
> unacceptable even if it wasn't "used for anything" and did not appear in
> any binary packages.
By removing invariant sections, don't we simply violate the GFDL ?
--
.''`. Josselin Mouette /\./\
: :' : josselin...@ens-lyon.org
`. `' jo...@debian.org
`- Debian GNU/Linux -- The power of freedom
Branden Robinson
> Le mer 07/05/2003 à 08:12, Branden Robinson a écrit :
> > I think before Debian puts anything in main it should remove any
> > invariant sections from the work, just as we do with non-free source
> > code. I once had a big old nasty flamewar with the FTP admins that
> > was tangentially related to this point, but the FTP admins and I agreed
> > that having non-free source code in a package's .orig.tar.gz was
> > unacceptable even if it wasn't "used for anything" and did not appear in
> > any binary packages.
>
> By removing invariant sections, don't we simply violate the GFDL ?
Only if the work is licensed under the GNU FDL in the first place[1].
You appear to have ignored or misunderstood the meaning of my second
paragraph, which you did not quote.
> > In other words, invariant sections (small I, small S) are not DFSG-free,
> > but the removal of invariant sections from a work may be sufficient to
> > render it DSFG-free.
[1] or other terms which forbid the removal of pieces of the work
--
G. Branden Robinson | The National Security Agency is
Debian GNU/Linux | working on the Fourth Amendment
bra...@debian.org | thing.
http://people.debian.org/~branden/ | -- Phil Lago, Deputy XD, CIA
Anthony Towns
> I think before Debian puts anything in main it should remove any
> invariant sections from the work, just as we do with non-free source
> code. I once had a big old nasty flamewar with the FTP admins that
> was tangentially related to this point, but the FTP admins and I agreed
> that having non-free source code in a package's .orig.tar.gz was
> unacceptable even if it wasn't "used for anything" and did not appear in
> any binary packages.
As far as I know, we're happy to accept non-free stuff in pristine
.orig.tar.gz's as long as it's not used. If you don't have a pristine
.orig.tar.gz anyway, then it's silly to include unused non-free stuff,
but it's not cause for a REJECT.
> In other words, invariant sections (small I, small S) are not DFSG-free,
> but the removal of invariant sections from a work may be sufficient to
> render it DSFG-free.
Assuming that's allowed by the license of course. As far as I'm aware, it's
quite okay to do this in either the .diff.gz or debian/rules, though.
Cheers,
aj
--
Anthony Towns <a...@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Dear Anthony Towns: [...] Congratulations --
you are now certified as a Red Hat Certified Engineer!''
Anthony Towns
> As far as I know, we're happy to accept non-free stuff in pristine
> .orig.tar.gz's as long as it's not used.
Okay, so this is wrong. You're not allowed to include non-free stuff in
anything uploaded to main, .deb, .diff.gz or .orig.tar.gz.
Don Armstrong
> As far as I know, we're happy to accept non-free stuff in pristine
> .orig.tar.gz's as long as it's not used.
I'd actually expect apt-get source foo to return sources that are DFSG
free, when foo is in main or contrib.
Granted, you should be checking the licenses of any source that you
use before you use it, but I would assume many of us expect all of the
software and sources in main to be free under the DFSG.
> If you don't have a pristine .orig.tar.gz anyway, then it's silly to
> include unused non-free stuff, but it's not cause for a REJECT.
But it seems strange (to me anyway) that an ftp-master would be
finding this out in a situation where a maintainer didn't already know
about it. Either someone didn't look over the code and licenses when
they were packaging, didn't examine the diff between versions, was
otherwise unaware of what they were uploading, or knew and didn't have
time to do anything abou it.
Don Armstrong
--
Miracles had become relative common-places since the advent of
entheogens; it now took very unusual circumstances to attract public
attention to sightings of supernatural entities. The latest miracle
had raised the ante on the supernatural: the Virgin Mary had
manifested herself to two children, a dog, and a Public Telepresence
Point.
-- Bruce Sterling, _Holy Fire_ p228
Anthony DeRobertis
> Another good argument against the GNU FDL.
Not to mention that publishing known false statements, like claiming it
is a GNU Manual or that the FSF publishes copies, is of dubious
legality.
Branden Robinson
> .orig.tar.gz's as long as it's not used. If you don't have a pristine
> .orig.tar.gz anyway, then it's silly to include unused non-free stuff,
> but it's not cause for a REJECT.
Well, that's weird, because back when we had the xc/util/patch problem
with XFree86, I asked if it was okay if I just let the sleeping dog lie
until the next upstream release, and nobody said "yes".
http://lists.debian.org/debian-ctte/2001/debian-ctte-200108/msg00034.html
Maybe the answer depends on how angry one has made the FTP admins
lately... :)
--
G. Branden Robinson | The last Christian died on the
Debian GNU/Linux | cross.
bra...@debian.org | -- Friedrich Nietzsche
http://people.debian.org/~branden/ |