Inconsistencies in our approach
John Goerzen
I have for some time been lurking during the discussions of the FDL, RFC
issues, and related matters, and I am getting an increasingly uneasy feeling
about the consensus that appears to be starting to coalesce around them.
You may note that I am a staunch Free Software advocate as you read these
below.
Problem #1: DFSG are Guidelines, not a Definition
This was discussed on -legal a few months back during the discussion with
the OSI folks. At the time, Debian people highlighted that DFSG is meant to
be taken as a document putting forth general guidelines that will be refined
-- and possibly special-cased (read: overridden) by discussion and precedent
within the project. In other words, a starting point, and a place from
which to build. By ontrast, OSD is a definition that is intended to be
completely authoratitive on its own.
As the discussion about FDL and the RFCs continues, I have seen various
people attempt to disect the DFSG, or to redefine "software" in a highly
loose manner, or to question DFSG's applicability to non-software items.
*ALL* of these approaches are wrong. Putting non-software items into the
same box as a very different beast serves only to cloud the issue.
DFSG represents a set of guidelines for software. We should be able to look
at those guidelines, and see how documentation differs from software in
relevant areas, and consider whether we need to apply them differently to
documentation.
Problem #2: Double Standards
We have, and continue to, allow information to be distributed with software
under even more strict terms than the FDL. Examples of these things include
licenses.
All of the arguments being made about freeness of documentation -- that
somebody may want to develop a document based on the original -- would also
apply to licenses (perhaps I wish to develop a license based on the GPL).
Yet we are ignoring the problem with the licenses.
I think this points out to me that a "strict constructionist" approach to
documentation does not serve us well. Speaking in a general sense, rather
than with regard to the particulars of the FDL, it does not prove a
significant problem for people down the line if portions of a document
specifically relating to copyright, licensing, and original authorship
remain immutable, while the "important" parts remain mutable.
Problem #3: Separability of Problems
Concern has rightly been expressed about the ability to modify software
documentation, especially since Free Software is out there to be modified.
Concern has also been expressed about the ability to modify RFCs.
While I share that concern, and agree in principle that they should be
modifyable providing the modified version does not claim to be an RFC, we
need to bear in mind that RFCs serve a quite different purpose than software
documentation.
RFCs are here to provide specifications, and their usefulness is directly
derived from the fact that everyone can point to a single unified source for
a spec. I, therefore, see the attempt to banish RFCs -- which are not
software -- as misguided, but would agree that software documentation under
the same license poses a larger problem. (The question then is whether to
banish that.)
Problem #4: The Big Picture
We have stated that our priorities are our users and Free Software. We need
to be thinking about whether the actions we take are advancing those goals.
I would say that removing FDL-licensed documents from GNU probably neither
helps our users nor Free Software. And I would say that the same holds true
for RFCs.
Consider these things:
1. Would removing the manual for Emacs, libc, or other important GNU
software benefit our users? Would it benefit Free Software?
2. Would removing the specifications around wich large parts of our
system are based benefit our users? Free Software?
Conclusion
----------
I am all for being completely strict regarding what kinds of software
licenses are allowed into Debian. I am also completely in favor of having
excellent documentation accompanying these programs, and making sure that
people can modify that documentation as appropriate. I think that we may be
on the verge of going overboard in that we are saying "but that's not enough
ability to modify for something that's Free!" when it really is.
Thoughts and critiques are welcome. Flames may be sent to
pres...@whitehouse.gov, who deserves a good yelling more than I :-)
-- John
--
To UNSUBSCRIBE, email to debian-leg...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
MJ Ray
> As the discussion about FDL and the RFCs continues, I have seen various
> people attempt to disect the DFSG, or to redefine "software" in a highly
> loose manner, or to question DFSG's applicability to non-software items.
If FDL-covered works are not software, than doesn't the SC mean that they
should not be in Debian?
> *ALL* of these approaches are wrong. Putting non-software items into the
> same box as a very different beast serves only to cloud the issue.
Can someone please offer more evidence for this assertion that we cannot
treat software and other works alike? I can only find evidence for the
contrary view (eg computer programs are specifically classed as literary
works in the current UK copyright law).
Really, I'd like a clear demonstration of how they differ in such a
fundamental way as to make attempts to have a unified decision system
invalid. The best that has been given so far is the opinion that some
writing should be classed as an expression of opinion and not modified
to express other opinions. That's fine as an opinion, but some people
think software should not be modified to aid (say) racist groups.
[...]
> We have, and continue to, allow information to be distributed with software
> under even more strict terms than the FDL. Examples of these things include
> licenses.
We are legally compelled to do so, aren't we? How would you resolve it
in another way? This is a packaging problem, similar in one way to some
of the FDL problem, but different in another.
[...]
> 1. Would removing the manual for Emacs, libc, or other important GNU
> software benefit our users? Would it benefit Free Software?
It would benefit our users by better fulfilling our promises of 100%
free software and it would benefit free software by encouraging more
free documents about free software.
> 2. Would removing the specifications around wich large parts of our
> system are based benefit our users? Free Software?
It would not benefit them, but it may not significantly harm them,
as there are other sources for RFCs and our core stuff like the policy
manual are GPLd.
> [...] I think that we may be
> on the verge of going overboard in that we are saying "but that's not enough
> ability to modify for something that's Free!" when it really is.
I think we have different opinions on "appropriate". How would you
suggest to deal with the specific problems from past FDL summaries?
--
MJR/slef My Opinion Only and possibly not of any group I know.
http://mjr.towers.org.uk/ jabber://sl...@jabber.at
Creative copyleft computing services via http://www.ttllp.co.uk/
Thought: Edwin A Abbott wrote about trouble with Windows in 1884
Don Armstrong
> *ALL* of these approaches are wrong. Putting non-software items into
> the same box as a very different beast serves only to cloud the
> issue.
No one as yet has come forward with a compelling argument as to why we
should consider treating documentation any differently than software.
Most of the arguments that have been presented boil down to:
Removing foo would do harm to our users.
Not packaging Microsoft Word with Debian has negative aspects for our
users. However, we typically agree that the positive aspects of being
able to exercise freedoms granted under the DFSG outweigh the negative
aspects of such a decision.
> We have, and continue to, allow information to be distributed with
> software under even more strict terms than the FDL. Examples of
> these things include licenses.
Not to mention the fact that we can't modify copyright statements...
So are you saying that because we allow software that is licenced
under a license that cannot be modified itself we should accept
documentation that cannot be modified itself?
> Speaking in a general sense, rather than with regard to the
> particulars of the FDL, it does not prove a significant problem for
> people down the line if portions of a document specifically relating
> to copyright, licensing, and original authorship remain immutable,
> while the "important" parts remain mutable.
I'd gather that most of -legal isn't worried about the copyright
statement, license, or author's statement (which is the same thing as
the copyright statement) being immutable. Most of those can't be
modified under the applicable copyright law and construed as the
original anyway.
What we are worried about is the addition of odious requirements for
keeping sections of documents which are not related to the above and
significantly impair the exercise of our freedom to modify and
distribute those modifications.
> While I share that concern, and agree in principle that they should
> be modifyable providing the modified version does not claim to be an
> RFC, we need to bear in mind that RFCs serve a quite different
> purpose than software documentation.
Copying sections from an RFC to generate documentation about such an
RFC or using well engineered portions of an RFC to generate better
RFC's down the line are all relatively reasonable things to do. If
it's present in Debian, one expects to be able to use it just like
they would use the source code present in Debian.
It saddens me that the terms for so much documentation are so
egregious, and I would definetly support installers for said
documentation that downloads the documentation from a canonical site,
but to place it in Debian proper seems to directly conflict with our
stated guidelines and social contract with our users.
If we are to treat documentation any differently than software, we
should first define a ruberic that distinguishes software from
documentation. In all previous discussions, we were unable to do this.
[I cannot do it, but perhaps someone else is able.]
Secondly, someone who advocates the difference between documentation
and software, after distinguishing between the two, should decide what
freedoms are reasonable give up to include documentation. After much
heated discussion, it will probably be GR time.
Until that point, I really don't see us doing much differently than
weighing documentation by the same scales that we weigh software, and
fulfilling our obligations under the social contract.
Don Armstrong
(Earnestly hoping for (and writing) more free documentation.)
--
Debian's not really about the users or the software at all. It's a
large flame-generating engine that the cabal uses to heat their coffee
-- Andrew Suffield (#debian-devel Fri, 14 Feb 2003 14:34 -0500)
http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu
Steve Langasek
> I have for some time been lurking during the discussions of the FDL, RFC
> issues, and related matters, and I am getting an increasingly uneasy feeling
> about the consensus that appears to be starting to coalesce around them.
> You may note that I am a staunch Free Software advocate as you read these
> below.
> Problem #1: DFSG are Guidelines, not a Definition
> This was discussed on -legal a few months back during the discussion with
> the OSI folks. At the time, Debian people highlighted that DFSG is meant to
> be taken as a document putting forth general guidelines that will be refined
> -- and possibly special-cased (read: overridden) by discussion and precedent
> within the project.
On the contrary, I think the point people were making in that discussion
was that compliance with the letter of the DFSG is a necessary but *not*
sufficient condition for a work's inclusion in Debian main. I don't
believe that anyone should have the power to override the DFSG except
through a GR on the part of the developers to amend it. [Insert
US-biased separation-of-powers analogy here]
> As the discussion about FDL and the RFCs continues, I have seen various
> people attempt to disect the DFSG, or to redefine "software" in a highly
> loose manner, or to question DFSG's applicability to non-software items.
> *ALL* of these approaches are wrong. Putting non-software items into the
> same box as a very different beast serves only to cloud the issue.
Indeed! So why would anyone try to put non-software items in the same
box labeled "Debian GNU/Linux"?
> DFSG represents a set of guidelines for software. We should be able to look
> at those guidelines, and see how documentation differs from software in
> relevant areas, and consider whether we need to apply them differently to
> documentation.
Perhaps -- but that makes this a matter of interpretation, and
reasonable beings may disagree on how to interpret the guidelines in
such a case. To remove this ambiguity, a GR would be necessary.
> Problem #2: Double Standards
> We have, and continue to, allow information to be distributed with software
> under even more strict terms than the FDL. Examples of these things include
> licenses.
Are there other examples of these things? Licenses are the only ones I
can think of.
Licenses and copyright notices merit special treatment because they
*are* special: they're the one thing that we include in Debian *not*
because of their content value to users, but because they're necessary
legal incantations required by copyright law. Freedom to modify a
license text does not translate into freedom from distributing the
verbatim text of the license governing the works we distribute; and
while there are parallels here with RFCs (changing the text of the
standard does not change the standard), the key difference is that we
can choose not to distribute the RFCs. Technically we /can/ choose not
to distribute copyright notices and licenses, but as a pragmatic
concession to copyright law, we opt for a non-empty distro instead. ;)
In short, since no one is advocating the distribution of software
licenses as OS components per se, they are not subject to the same
requirements of content modifiability that govern OS components. The
interest in RFCs, and other documentation, clearly lies in their utility
as OS components.
> I think this points out to me that a "strict constructionist" approach to
> documentation does not serve us well. Speaking in a general sense, rather
> than with regard to the particulars of the FDL, it does not prove a
> significant problem for people down the line if portions of a document
> specifically relating to copyright, licensing, and original authorship
> remain immutable, while the "important" parts remain mutable.
Nor does the above prove a significant problem under the DFSG. The
problem is with licenses which impose requirements beyond what you've
listed above.
> While I share that concern, and agree in principle that they should be
> modifyable providing the modified version does not claim to be an RFC, we
> need to bear in mind that RFCs serve a quite different purpose than software
> documentation.
> RFCs are here to provide specifications, and their usefulness is directly
> derived from the fact that everyone can point to a single unified source for
> a spec. I, therefore, see the attempt to banish RFCs -- which are not
> software -- as misguided, but would agree that software documentation under
> the same license poses a larger problem. (The question then is whether to
> banish that.)
As has been discussed here before, there are much better ways to avoid
"identity crises" of works (trademark, libel, slander) that are also
compatible with Free Software.
> 1. Would removing the manual for Emacs, libc, or other important GNU
> software benefit our users? Would it benefit Free Software?
Hasn't the FSF itself taken a long-term view on questions of utility vs.
freedom? Are you arguing that it's beyond the capabilities of the Free
Software community to replace the above documents if they're determined
to be encumbered?
> 2. Would removing the specifications around wich large parts of our
> system are based benefit our users? Free Software?
"Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away." Personally, I find the RFC debate
to be much ado about nothing; as a network administrator and as a
programmer who frequently hacks on network software, I frequently refer
back to RFCs, yet I have never used the RFC packages currently provided
by Debian. Wouldn't our users benefit from efforts to trim down the
distribution by removing unnecessary bloat such as this?
I am playing devil's advocate here; while I don't personally use the RFC
packages, and I do think there's a lot of fat-trimming to be done in the
archive, these packages fare much better than many in the overall
utility analysis. The point is, it's quite difficult to judge what's
best for our users as a whole -- and again, reasonable beings may
disagree. Nevertheless, I do think developers who are balking at the
request to remove RFCs from their individual packages are missing the
more important point, namely, that they're including redundant data in
their packages that's provided elsewhere. If we have copies of common
licenses in our base-files package to cut down on redundancy, why would
we want multiple copies of RFCs that are many times the size of a
typical copyright license?
--
Steve Langasek
postmodern programmer
Andrew Suffield
> documentation does not serve us well. Speaking in a general sense, rather
> than with regard to the particulars of the FDL, it does not prove a
> significant problem for people down the line if portions of a document
> specifically relating to copyright, licensing, and original authorship
> remain immutable, while the "important" parts remain mutable.
It does pose a significant problem for people down the line if the
immutable parts must be included with everything they derive from the
document. Numerous examples have been cited on -legal.
> RFCs are here to provide specifications, and their usefulness is directly
> derived from the fact that everyone can point to a single unified source for
> a spec.
You have not shown this to be relevant to the licensing issue. Please
do not raise this point if you do not have a solid reason why being
able to create modified versions of RFCs would dimish their value as
"standards". Nobody in the RFC discussion was able to do so.
Note that the license can and should stipulate that modified versions
should be clearly labelled as different from the original
document. (Also note that _some_ such restrictions can be non-free,
but it is relatively easy to write in a manner that does not cause a
problem).
> Consider these things:
>
> 1. Would removing the manual for Emacs, libc, or other important GNU
> software benefit our users? Would it benefit Free Software?
Why are we even considering this? It's not like we refuse to include
something just because a non-free implementation exists.
Consider finding a free(er) version of the relevant manual, forking
it, and updating it.
Consider rewriting it. Note that the documentation for most GNU
project is appalling. For emacs and libc, it is merely poor (they're
only really useful as a reference).
Yes, this would benefit free software and our users.
> 2. Would removing the specifications around wich large parts of our
> system are based benefit our users? Free Software?
No. Would it harm them? Not really. Including them, or not, does not
have a significant effect on either.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Joe Moore
> Problem #2: Double Standards
>
> We have, and continue to, allow information to be distributed with
> software under even more strict terms than the FDL.
The entire debate revolves around the question of "will [we]* continue to
allow information to be distributed under non-free terms within Debian"?
> Examples of these
> things include licenses.
>
> All of the arguments being made about freeness of documentation -- that
> somebody may want to develop a document based on the original -- would
> also apply to licenses (perhaps I wish to develop a license based on
> the GPL). Yet we are ignoring the problem with the licenses.
You are free to do so. See the preamble of the GPL for instructions on how.
Basically, just change the name and remove the preamble, and you can change
the license however you want.
It doesn't change the terms under which you can modify and distribute Emacs,
though.
--Joe
* IANADD
Glenn Maynard
> > 2. Would removing the specifications around wich large parts of our
> > system are based benefit our users? Free Software?
>
> No. Would it harm them? Not really. Including them, or not, does not
> have a significant effect on either.
Yes, it would: sticking solidly to our principles benefits users. Putting
non-free items in Debian chips away at our principles and paves the way for
more concessions to non-freeness.
Don't let the Social Contract and the DFSG go the way of the US Constitution.
--
Glenn Maynard
Joey Hess
> John Goerzen <jgoe...@complete.org> wrote:
> > As the discussion about FDL and the RFCs continues, I have seen various
> > people attempt to disect the DFSG, or to redefine "software" in a highly
> > loose manner, or to question DFSG's applicability to non-software items.
>
> If FDL-covered works are not software, than doesn't the SC mean that they
> should not be in Debian?
BZZT. That is exactly the argument John just asked us not to make.
> Can someone please offer more evidence for this assertion that we cannot
> treat software and other works alike? I can only find evidence for the
> contrary view (eg computer programs are specifically classed as literary
> works in the current UK copyright law).
>
> Really, I'd like a clear demonstration of how they differ in such a
> fundamental way as to make attempts to have a unified decision system
> invalid. The best that has been given so far is the opinion that some
> writing should be classed as an expression of opinion and not modified
> to express other opinions. That's fine as an opinion, but some people
> think software should not be modified to aid (say) racist groups.
So's this. And it's been said a hundred times before, so why repeat it
again and waste all of our time?
--
see shy jo
Joey Hess
> All of the arguments being made about freeness of documentation -- that
> somebody may want to develop a document based on the original -- would also
> apply to licenses (perhaps I wish to develop a license based on the GPL).
> Yet we are ignoring the problem with the licenses.
There's a very easy answer to this. We want to promote lots of freely
available documentation, but we would prefer to *limit* the number of
free software licenses, because of licence incompatabily, poor wording
by non-lawyers, and so on.
So we've done with licenses just what you ask for here:
> DFSG represents a set of guidelines for software. We should be able to look
> at those guidelines, and see how documentation differs from software in
> relevant areas, and consider whether we need to apply them differently to
> documentation.
I at least, did not form my current opinion about what freedoms should
apply to documentation in Debian without considering that and weighing
the arguments of RMS and others. But I've found them somewhat lacking.
--
see shy jo
MJ Ray
> BZZT. That is exactly the argument John just asked us not to make.
I think your buzzer is malfunctioning. John seemed to be asking us not
to stretch the DFSG to non-software. Not the same thing.
[Software/Docs distinction]
> So's this. And it's been said a hundred times before, so why repeat it
> again and waste all of our time?
I don't know. I just post it to try to get a response that actually
has some substance. I'd love to hear from someone who actually has a
basis in reality for a distinction, instead of something from their mind.
Does anyone have *NEW DATA* to bring to the discussion? Otherwise,
we can continue hearing the opinions of a few that we should allow
non-free software works into Debian because they like it, regardless of
the problems of distinguishing or justification, and then ignore them
just as happened over other pieces of non-free.
John H. Robinson, IV
>
> Does anyone have *NEW DATA* to bring to the discussion?
as a mostly passive observer at this point, the only data we are missing
is a clear working definition to separate out Software, Data, and
Documentation.
once we do that to our own satisfaction, then we can get on with
defining the free-ness needs of each.
i am afraid i have no such definition to offer.
-john
David B Harris
John Goerzen <jgoe...@complete.org> wrote:
> As the discussion about FDL and the RFCs continues, I have seen various
> people attempt to disect the DFSG, or to redefine "software" in a highly
> loose manner, or to question DFSG's applicability to non-software items.
>
> *ALL* of these approaches are wrong. Putting non-software items into the
> same box as a very different beast serves only to cloud the issue.
>
> DFSG represents a set of guidelines for software. We should be able to look
> at those guidelines, and see how documentation differs from software in
> relevant areas, and consider whether we need to apply them differently to
> documentation.
I will assume that the rest of your argument is not predicated on the
paragraph immediately preceeding this one. If you're going to say "we
aren't allowed to say that the DFSG applies to documentation too", you
can't say in the next breath that it only applies to software.
Speaking of double standards... :)
> Problem #2: Double Standards
>
> We have, and continue to, allow information to be distributed with software
> under even more strict terms than the FDL. Examples of these things include
> licenses.
>
> All of the arguments being made about freeness of documentation -- that
> somebody may want to develop a document based on the original -- would also
> apply to licenses (perhaps I wish to develop a license based on the GPL).
> Yet we are ignoring the problem with the licenses.
I agree wholeheartedly. The project as a whole seems to have decided
that it's okay for license text to be non-Free. That's fine. But don't
assume that because the concensus is that non-Free license texts are
okay that all non-programming text that's non-Free is acceptable.
> I think this points out to me that a "strict constructionist" approach to
> documentation does not serve us well. Speaking in a general sense, rather
> than with regard to the particulars of the FDL, it does not prove a
> significant problem for people down the line if portions of a document
> specifically relating to copyright, licensing, and original authorship
> remain immutable, while the "important" parts remain mutable.
As a "strict constructionist", why is it okay for documentation to be
partially immutable but not okay for parts of software to be immutable?
Consider extremely obnoxious advertisements in software. They're
certainly not important as far as functioning of the program is
concerned, but would you consider the software "Free enough" if such
advertisements legally couldn't be removed?
(Please note that I'm drawing an analogy here, not trying to open up the
debate about whether documentation is software or not.)
> Problem #3: Separability of Problems
>
> Concern has rightly been expressed about the ability to modify software
> documentation, especially since Free Software is out there to be modified.
>
> Concern has also been expressed about the ability to modify RFCs.
I don't believe much serious concern was expressed about the ability to
modify RFCs. In some cases the licenses forbade it, and nobody I know
really had a problem with that. They go into non-free/, but who cares?
They're still there. This is the license they've chosen, and there's
nothing wrong with that.
> RFCs are here to provide specifications, and their usefulness is directly
> derived from the fact that everyone can point to a single unified source for
> a spec. I, therefore, see the attempt to banish RFCs -- which are not
> software -- as misguided, but would agree that software documentation under
> the same license poses a larger problem. (The question then is whether to
> banish that.)
Yes. See above.
> Problem #4: The Big Picture
>
> We have stated that our priorities are our users and Free Software. We need
> to be thinking about whether the actions we take are advancing those goals.
> I would say that removing FDL-licensed documents from GNU probably neither
> helps our users nor Free Software. And I would say that the same holds true
> for RFCs.
>
> Consider these things:
>
> 1. Would removing the manual for Emacs, libc, or other important GNU
> software benefit our users? Would it benefit Free Software?
The "good for our users" point can AND HAS been twisted both ways, so
please refrain from using that approach. It's not constructive.
I will refrain myself, for instance.
> 2. Would removing the specifications around wich large parts of our
> system are based benefit our users? Free Software?
See above.
> Conclusion
> ----------
>
> I am all for being completely strict regarding what kinds of software
> licenses are allowed into Debian. I am also completely in favor of having
> excellent documentation accompanying these programs, and making sure that
> people can modify that documentation as appropriate. I think that we may be
> on the verge of going overboard in that we are saying "but that's not enough
> ability to modify for something that's Free!" when it really is.
>
> Thoughts and critiques are welcome. Flames may be sent to
> pres...@whitehouse.gov, who deserves a good yelling more than I :-)
I'd like to ask you to read the GFDL carefully, especially section 2.
Regardless of whether or not the license is Free, it may very well be
the case that we can't legally distribute anything covered by this
license.
I'm in the process of discussing the issue (and others) with some
lawyers who have volounteered to help with FOSS. When everything's
worked out I will publish an analysis of the GFDL. It will be in two
parts; a short, general overview of the "problems", both ethical and
legal, and a long explanation of the first part.
David B Harris
Brian Nelson <py...@debian.org> wrote:
> I don't think that this is even necessary. Suppose, for example, we
> chose to solve the documentation problem by creating a new archive
> section for documentation. Documentation that meets the DFSG would
> preferably still be included in main; only non-DFSG-compliant
> documentation would have to go in the new section.
>
> The requirements for packages to go in the documentation section would
> probably be something like: must be Arch: all, must not have any files
> with the executable bit set, and must be freely distributable. The
> advantage to doing this over simply placing non-free documentation in
> the non-free archive section is that it could be considered "part of
> Debian", even if not included in main, and would be safe for CD vendors
> to distribute (which is not necessarily true for packages in non-free).
(I would also add to this the obvious "and must be approved by an
ftpmaster" :) That guideline is too broad, all sorts of non-Free crap
could get in under it.)
And most certainly isn't necessarily true for non-Free documentation.
Even the GFDL has been questioned on this point.
I would prefer the "create a new documentation tree" solution over
"include non-Free documentation in main", but chances are CD vendors
will need to treat it like they treat non-Free.
Henning Makholm
> as a mostly passive observer at this point, the only data we are missing
> is a clear working definition to separate out Software, Data, and
> Documentation.
> once we do that to our own satisfaction, then we can get on with
> defining the free-ness needs of each.
I think most regular posters to d-l sees it the other way: As long as
nobody have made any reasoned concrete proposal for how the standards
applied to documentation should differ from the DFSG, it is a waste of
time it to try to hammer out a definition of "documentation".
There seems to be a fairly solid consensus on this list that the
requirements of the DFSG are, in and of themselves, the reasonable
requirements to make of the licensing of documentation - *even* on
the times we have conducted the discusion on the (for some
hypothetical) premise that there is no inherent reason for software
and documentation to be measured with identical standards.
If someone wants to change that consensus, that someone should strive
directly to change the consensus about which demands it is reasonable
to make for documentation. But it seems that the people who, every
once and then, come here to demand that GDFL-licensed manuals should
be included, are content to argue that the standards for documentation
*could* be different. They do not say anything about which way they
want to *change* the standards (expect possibly to make an artificual
exception saying that everything that comes from the FSF is free by
definition).
--
Henning Makholm "De kan rejse hid og did i verden nok så flot
Og er helt fortrolig med alverdens militær"
John Goerzen
I have for some time been lurking during the discussions of the FDL, RFC
issues, and related matters, and I am getting an increasingly uneasy feeling
about the consensus that appears to be starting to coalesce around them.
You may note that I am a staunch Free Software advocate as you read these
below.
Problem #1: DFSG are Guidelines, not a Definition
This was discussed on -legal a few months back during the discussion with
the OSI folks. At the time, Debian people highlighted that DFSG is meant to
be taken as a document putting forth general guidelines that will be refined
-- and possibly special-cased (read: overridden) by discussion and precedent
within the project. In other words, a starting point, and a place from
which to build. By ontrast, OSD is a definition that is intended to be
completely authoratitive on its own.
As the discussion about FDL and the RFCs continues, I have seen various
people attempt to disect the DFSG, or to redefine "software" in a highly
loose manner, or to question DFSG's applicability to non-software items.
*ALL* of these approaches are wrong. Putting non-software items into the
same box as a very different beast serves only to cloud the issue.
DFSG represents a set of guidelines for software. We should be able to look
at those guidelines, and see how documentation differs from software in
relevant areas, and consider whether we need to apply them differently to
documentation.
Problem #2: Double Standards
We have, and continue to, allow information to be distributed with software
under even more strict terms than the FDL. Examples of these things include
licenses.
All of the arguments being made about freeness of documentation -- that
somebody may want to develop a document based on the original -- would also
apply to licenses (perhaps I wish to develop a license based on the GPL).
Yet we are ignoring the problem with the licenses.
I think this points out to me that a "strict constructionist" approach to
documentation does not serve us well. Speaking in a general sense, rather
than with regard to the particulars of the FDL, it does not prove a
significant problem for people down the line if portions of a document
specifically relating to copyright, licensing, and original authorship
remain immutable, while the "important" parts remain mutable.
Problem #3: Separability of Problems
Concern has rightly been expressed about the ability to modify software
documentation, especially since Free Software is out there to be modified.
Concern has also been expressed about the ability to modify RFCs.
While I share that concern, and agree in principle that they should be
modifyable providing the modified version does not claim to be an RFC, we
need to bear in mind that RFCs serve a quite different purpose than software
documentation.
RFCs are here to provide specifications, and their usefulness is directly
derived from the fact that everyone can point to a single unified source for
a spec. I, therefore, see the attempt to banish RFCs -- which are not
software -- as misguided, but would agree that software documentation under
the same license poses a larger problem. (The question then is whether to
banish that.)
Problem #4: The Big Picture
We have stated that our priorities are our users and Free Software. We need
to be thinking about whether the actions we take are advancing those goals.
I would say that removing FDL-licensed documents from GNU probably neither
helps our users nor Free Software. And I would say that the same holds true
for RFCs.
Consider these things:
1. Would removing the manual for Emacs, libc, or other important GNU
software benefit our users? Would it benefit Free Software?
2. Would removing the specifications around wich large parts of our
system are based benefit our users? Free Software?
Conclusion
----------
I am all for being completely strict regarding what kinds of software
licenses are allowed into Debian. I am also completely in favor of having
excellent documentation accompanying these programs, and making sure that
people can modify that documentation as appropriate. I think that we may be
on the verge of going overboard in that we are saying "but that's not enough
ability to modify for something that's Free!" when it really is.
Thoughts and critiques are welcome. Flames may be sent to
pres...@whitehouse.gov, who deserves a good yelling more than I :-)
-- John
Brian T. Sniffen
> Problem #2: Double Standards
>
> We have, and continue to, allow information to be distributed with software
> under even more strict terms than the FDL. Examples of these things include
> licenses.
>
> All of the arguments being made about freeness of documentation -- that
> somebody may want to develop a document based on the original -- would also
> apply to licenses (perhaps I wish to develop a license based on the GPL).
> Yet we are ignoring the problem with the licenses.
I wish to address a very narrow part of this point: because copyright
protects only creative expression of ideas, and because legal
terminology is intended to be strictly denotative and carefully
defined, contracts and similar legal texts (including licenses)
receive very weak copyright protection; often none.
The BSD license, for example, or the usual warranty disclaimer, are
boilerplate: there's no other way to express exactly the same idea, so
the expression receives no copyright protection. As a result, I
suggest you abandon this point of your argument.
> Problem #3: Separability of Problems
>
> Concern has rightly been expressed about the ability to modify software
> documentation, especially since Free Software is out there to be modified.
>
> Concern has also been expressed about the ability to modify RFCs.
>
> While I share that concern, and agree in principle that they should be
> modifyable providing the modified version does not claim to be an RFC, we
> need to bear in mind that RFCs serve a quite different purpose than software
> documentation.
>
> RFCs are here to provide specifications, and their usefulness is directly
> derived from the fact that everyone can point to a single unified source for
> a spec.
Aw, heck. While I'm here, I'll dice the rest too. While you're
correct about a major use of RFCs, it's hardly the only one. My
principal use of the RFCs, for example, has been extracting text for
use in new documents. The new RFCs don't allow me to do that, and are
clearly non-free.
> I, therefore, see the attempt to banish RFCs -- which are not
> software
You really wouldn't want us to insist on shipping the non-software
versions. Apt-get really bogs down when asked to process 20 lb A4.
-Brian
--
Brian T. Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
Manoj Srivastava
> MJ Ray wrote:
>>
>> Does anyone have *NEW DATA* to bring to the discussion?
> as a mostly passive observer at this point, the only data we are
> missing is a clear working definition to separate out Software,
> Data, and Documentation.
> i am afraid i have no such definition to offer.
My feeling is that there may not be any such clear cut
distinction.
manoj
--
Old age is always fifteen years old than I am. Baruch
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
Sergey V. Spiridonov
[snip]
> If we are to treat documentation any differently than software, we
> should first define a ruberic that distinguishes software from
> documentation. In all previous discussions, we were unable to do this.
> [I cannot do it, but perhaps someone else is able.]
[snip]
What about
1. Documentation:
From The Free On-line Dictionary of Computing (09 FEB 02) :
documentation
The multiple kilograms of macerated, pounded, steamed,
bleached, and pressed trees that accompany most modern
software or hardware products (see also tree-killer).
Hackers seldom read paper documentation and (too) often resist
writing it; they prefer theirs to be terse and on-line. A
common comment on this predilection is "You can't grep dead
trees". See drool-proof paper, verbiage, treeware.
From WordNet (r) 1.7 :
documentation
2: program listings or technical manuals describing the
operation and use of programs [syn: software
documentation]
2. Software:
From The Free On-line Dictionary of Computing (09 FEB 02) :
(Or "computer program", "program") The
instructions executed by a computer, as opposed to the
physical device on which they run (the "{hardware").
"{Code" is closely related but not exactly the same.
[snip]
Some claim that documentation (both paper and electronic) is
also software. Others go further and define software to be
programs plus documentation though this does not correspond
with common usage.
--
Best regards, Sergey Spiridonov
Branden Robinson
> I'm in the process of discussing the issue (and others) with some
> lawyers who have volounteered to help with FOSS. When everything's
> worked out I will publish an analysis of the GFDL. It will be in two
> parts; a short, general overview of the "problems", both ethical and
> legal, and a long explanation of the first part.
Kick ass. I am passionately interested in such a document.
For the record[1], I stand with the critics of John Goerzen's message,
and not with the consensus he implicitly claims to represent.
Nevertheless I applaud the calmness with which he expressed his earnest
opinion.
[1] why, yes, I *am* a Debian Developer
--
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
John H. Robinson, IV
> On Thu, 31 Jul 2003 16:38:43 -0700, John H Robinson, IV <jaq...@debian.org> said:
>
> > as a mostly passive observer at this point, the only data we are
> > missing is a clear working definition to separate out Software,
> > Data, and Documentation.
>
> distinction.
i am going to try to take a stab at it:
hardware: physical computing devices
software: logical information stored by hardware devices that can be
used for computation.
this allows us to break software into three (or more) areas:
program: software that provides instructions to hardware
data: input to software
documentation: information about software or data
Drawer 'O': software that does not fit in the above three categories.
this allows us to neatly sidestep the whole issue, because _online_
documentation would fit in one of the above four categories of software.
Debian Will Remain 100% Free Software[0]. so if we never include dead-
tree documentation as part of Debian, then we can easily and safely
apply the DFSG to any bit of program/data/documentation/Drawer 'O' that
is ever uploaded to the archive.
[0] Debian Social Contract, Point 1.
<URL:http://www.debian.org/social_contract>
comments welcome.
credit to Sergey V. Spiridonov for inspiring the above idea.
-john
Manoj Srivastava
> Manoj Srivastava wrote:
>> On Thu, 31 Jul 2003 16:38:43 -0700, John H Robinson, IV
>> <jaq...@debian.org> said:
>>
>> > as a mostly passive observer at this point, the only data we are
>> > missing is a clear working definition to separate out Software,
>> > Data, and Documentation.
>>
>> My feeling is that there may not be any such clear cut distinction.
> i am going to try to take a stab at it:
> hardware: physical computing devices software: logical information
> stored by hardware devices that can be used for computation.
> this allows us to break software into three (or more) areas:
> program: software that provides instructions to hardware
> data: input to software
> documentation: information about software or data
> Drawer 'O': software that does not fit in the above three
> categories.
OK. I have a program (for my day job), where we have pluggable
probes deployed by a sensor program, as and when the sensor deems
fit. Initially, the sensor does not know how many probes have been
installed on the local machine, it goes out and discovers the number
and nature of the probes in an initial resource discovery phase.
Each probe, when installed, installs an XML document that can
be converted into HTML or PDF by applying a sinple xsl transform;
this is where all the documentation oabout the probe lives.
This files is, then documentation, no?
The sensor reads the same file, applies another xsl transform,
and gets to know the capabilities of the probe, and how to classify
it, and publishes the data to a central trading service.
The file is configuration data, no?
Now, when a request for data comes in, a generic probe handler
is deployed, which reads the same file, applies a transform, and is
handed a seris of instructions on how to deploy the probe and
commuunicate with it.
This file is program code, no?
You disambiguate my program for me, and I'll believe there
are rigid classifications of software which are feasible.
manoj
--
The forest is safe because a lion lives therein and the lion is safe
because it lives in a forest. Likewise the friendship of persons
rests on mutual help. Laukikanyay.
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
Joe Wreschnig
> Manoj Srivastava wrote:
> > On Thu, 31 Jul 2003 16:38:43 -0700, John H Robinson, IV <jaq...@debian.org> said:
> >
> > > as a mostly passive observer at this point, the only data we are
> > > missing is a clear working definition to separate out Software,
> > > Data, and Documentation.
> >
> > My feeling is that there may not be any such clear cut
> > distinction.
>
> i am going to try to take a stab at it:
>
> hardware: physical computing devices
> software: logical information stored by hardware devices that can be
> used for computation.
>
> this allows us to break software into three (or more) areas:
>
> program: software that provides instructions to hardware
>
> data: input to software
>
> documentation: information about software or data
>
> Drawer 'O': software that does not fit in the above three categories.
>
> this allows us to neatly sidestep the whole issue, because _online_
> documentation would fit in one of the above four categories of software.
> Debian Will Remain 100% Free Software[0]. so if we never include dead-
> tree documentation as part of Debian, then we can easily and safely
> apply the DFSG to any bit of program/data/documentation/Drawer 'O' that
> is ever uploaded to the archive.
If I have an IA32 binary, running on my home system is clearly a
'program' (if we ignore that some processors do translation of the
"native" instruction set to something else). But if I'm running it on
Bochs on a PPC or SPARC, it's now data to Bochs, a program.
My Perl script is a program, running on a VM. But it's also data to the
Perl interpreter.
CWEB and other literate or semi-literate programming environments allow
you to write documentation and code that are mixed together.
PS, PDF, and LaTeX allow you to write documentation in a Turing-complete
language. HTML/XML is a language for programming a web browser's display
engine, although it's not Turing-complete.
All streams of bits are "Drawer 'O'" software, depending on how you use
it. Please, read the archives.
Then, even if someone does come up with a good delineation between
software and non-software bits, I still haven't seen any convincing
arguments that non-software doesn't need the same kind of freedoms as
software.
--
Joe Wreschnig <pi...@debian.org>
Sergey V. Spiridonov
> Then, even if someone does come up with a good delineation between
> software and non-software bits, I still haven't seen any convincing
> arguments that non-software doesn't need the same kind of freedoms as
> software.
If one does not see the difference between program and documentation, it
is very hard to explain why they do not need the same kind of freedoms.
--
Best regards, Sergey Spiridonov
Nick Phillips
> i am going to try to take a stab at it:
>
> hardware: physical computing devices
> software: logical information stored by hardware devices that can be
> used for computation.
> this allows us to break software into three (or more) areas:
>
> program: software that provides instructions to hardware
>
> data: input to software
>
> documentation: information about software or data
>
> Drawer 'O': software that does not fit in the above three categories.
Pretty good. I would have tried to phrase it slightly differently, but you
have hit the nail on the head.
If it's represented essentially as a sequence of 1s and 0s in a typical
digital computer, and can be modified while the machine is running, and
without moving anything except electrons around, it's software.
Yes, there may be subcategories within "software" which may or may not be
relevant in various situations. In the context of the DFSG, they are not.
I would mention that the question of modifiability of licenses etc. would
to my mind be covered in the definition of "free" rather than in that of
"software".
> this allows us to neatly sidestep the whole issue, because _online_
> documentation would fit in one of the above four categories of software.
It's not a neat sidestep, it's just The Way It Is... people trying to justify
including non-free software (which happens to fall into the "documentation"
subcategory) in Debian are the ones trying to perform the neat sidestep.
Oh, and I agree with Manoj; the boundaries of the subcategories are unclear.
Cheers,
Nick
--
Nick Phillips -- n...@lemon-computing.com
It may or may not be worthwhile, but it still has to be done.
John H. Robinson, IV
> On Fri, Aug 01, 2003 at 09:50:13PM -0700, John H. Robinson, IV wrote:
%< snip of definitions >%
> Pretty good. I would have tried to phrase it slightly differently, but you
> have hit the nail on the head.
>
> If it's represented essentially as a sequence of 1s and 0s in a typical
> digital computer, and can be modified while the machine is running, and
> without moving anything except electrons around, it's software.
thank you. that was the point i was trying to make.
> Yes, there may be subcategories within "software" which may or may not be
> relevant in various situations. In the context of the DFSG, they are not.
i agree fully with the above.
> > this allows us to neatly sidestep the whole issue, because _online_
> > documentation would fit in one of the above four categories of software.
>
> It's not a neat sidestep, it's just The Way It Is... people trying to justify
> including non-free software (which happens to fall into the "documentation"
> subcategory) in Debian are the ones trying to perform the neat sidestep.
perhaps using sidestep was a poor choice of words. the idea is that it
does not matter _what_ the sub-classifications are. the fact is that all
subclassification are under the heading of ``software'' so it simply
does not matter.
> Oh, and I agree with Manoj; the boundaries of the subcategories are unclear.
i also agree. i realised that as i wrote it. take a perl script: is it a
program? is it data? is it documentation? is it all of the above at the
same time?
does it _really_ matter? no. it does not matter. it is still
_software_. the DFSG can apply no matter how you slice the script.
that was the whole point.
in general:
please do not get caught up on th subclassifications. they merely
illustrate the point that they are all software; RFC's in electronic
form included.
-john
Claus Färber
> I'd gather that most of -legal isn't worried about the copyright
> statement, license, or author's statement (which is the same thing as
> the copyright statement) being immutable. Most of those can't be
> modified under the applicable copyright law and construed as the
> original anyway.
> What we are worried about is the addition of odious requirements for
> keeping sections of documents which are not related to the above...
Maybe that's the solution to the GFDL problem: Allow documents that come
under a GFDL licence if the only immutable parts are licence texts or
author statements.
The GFDL is not a full licence, it's a licence template, which has to be
filled with definitions of "invariant sections" and "cover texts" (this
is why I used "GFDL licence" instead of "GFDL"). If the only texts that
are immutable are licence texts, author statements, etc., the GFDL-based
licence can be considered free (similar to software licences that don't
allow to change licence texts either).
Of course, someone can add another invariant section to the manual. But
this is actually a licence change, possibly making the new version of
the manual non-free (although it still uses the GFDL as a template for
its licence). This problem, however, exists in many free software
licences such as the BSD licence, etc.
Claus
--
http://www.faerber.muc.de
Nathanael Nerode
> I'd gather that most of -legal isn't worried about the copyright
> statement, license, or author's statement (which is the same thing as
> the copyright statement) being immutable. Most of those can't be
> modified under the applicable copyright law and construed as the
> original anyway.
Claus Faerber wrote:
>Maybe that's the solution to the GFDL problem: Allow documents that
>come under a GFDL licence if the only immutable parts are licence texts
>or author statements.
Close but not quite right.
We don't mind the copyright statment *for the work* or the license *for
the work*. If the GFDL'ed work contained the GFDL as its only invariant
section, that might conceivably be OK (apart from the other problems
with the GFDL).
But there's no reason to allow a GFDL'ed work to contain, as invariant
sections, other arbitrary licenses (or copyright notices) which don't
apply to the GFDL'ed work. (For instance, many GNU manuals contain
copies of the GPL version 2 as immutable sections. If, for instance,
the GNU Make manual was heavily modified to create a BSD make manual, it
would have to retain such sections, even though BSD make is not licensed
under the GPL...)
Anyway, even if this was the 'solution', we still *must* kick the GCC
and GNU Emacs manuals out of main.
I don't understand why that hasn't been done yet.
Nathanael Nerode
> 1. Would removing the manual for Emacs, libc, or other important GNU
> software benefit our users?
0s and 1s -- so nearly everything Debian distributes except the
physical CDs) in Debian; as a user, I chose Debian at least partly for
the Social Contract, which this violates.
> Would it benefit Free Software?
Yep. It would help promote the movement to have genuninely free manuals
for those pieces of software; manuals which could be integrated into
programs, used as help text, freely lifted from, etc.
I bet you thought you were asking rhetorical questions.
--Nathanael
Joe Wreschnig
> Of course, someone can add another invariant section to the manual. But
> this is actually a licence change, possibly making the new version of
> the manual non-free (although it still uses the GFDL as a template for
> its licence). This problem, however, exists in many free software
> licences such as the BSD licence, etc.
If someone adds proprietary code to BSD-licensed code, however, you can
later extract the free code (assuming you have access to the code of the
now-proprietary program), and use it in something else. Once proprietary
(invariant) sections are added to something under the GFDL, that version
of the document is forever non-free, because they can't ever be removed.
A nice example of a viral license.
--
Joe Wreschnig <pi...@debian.org>
Jakob Bohm
Here is my classification, which handles this better:
A piece of information, whether in analog, digital or other
form, is a program if it is intended to directly control the
actions of a computer, other than by simply holding a pure
description of its other contents.
A piece of information, which is not a program, and whose
contents is not primarily intended for human consumption is just
data.
A piece of information, which is not a program and whose entire
contents is primarily intended for human consumption is either
computer documentation or non-computer literature, depending on
its subject.
Thus if something serves as both program and documentation, the
program classification wins. If something else holds both
information for a humans and information for computers, the data
classification wins. If something is entirely intended for
humans but discusses both computer stuff and non-computer stuff,
the documentation classification wins.
Thus your XML example is a program. Some of the files derived
from it are just data or program documentation, but the file
they come from is a program.
gcc is a program, the output of gcc --help is documentation.
The Debian Social Contract is Literature, as is the GNU
Manifesto.
Most PostScript files are documentation or non-computer
literature, even though PostScript is potentially Turing
Complete and the standard preamble of some of these files may
use programming constructs to describe the format. But there
are PostScript files that are Programs or just data, some of the
files in the GhostScript package are obvious examples.
Most HTML files are documentation too, unless there are scripts
involved.
XML is about as general as plain ASCII, and XML files can end up
in all classifications depending on contents.
Most C files are clearly programs, but there are exceptions: The
keyboard map in the Linux Kernel is data stored in C format. The
classic K&R Hello, World sample is Literature: It does not truly
direct the computer to take actions other than to show itself.
The contents shown is not data, it is not even documentation, it
is just a polite greeting.
Note that this classification is solely for use in evaluation
compliance with requirements for software freedom, such as DFSG,
OSD or RMS's 4 freedoms. For other purposes it may be more
relevant to use entirely different classifications.
Also note that the classification deliberately avoids the
contentious question as to which of the above qualify as
Software.
Jakob
--
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
MJ Ray
> What about
...not cutting out all the definition alternatives that don't support
your position?
Dylan Thurston
> Here is my classification, which handles this better:
>
> A piece of information, whether in analog, digital or other
> form, is a program if it is intended to directly control the
> actions of a computer, other than by simply holding a pure
> description of its other contents.
> A piece of information, which is not a program and whose entire
> contents is primarily intended for human consumption is either
> computer documentation or non-computer literature, depending on
> its subject.
I have no idea how to apply this definition: you use "directly
control" and "primarily intended" in ways that are exceedingly
unclear. The way you use these definitions later makes it seem to me
that any interactive program must be considered primarily intended for
human consumption... What about: Interactive fiction? Screensavers?
Arcade games? Emacs?
Have you looked at the Gallery of CSS Descramblers
<http://www-2.cs.cmu.edu/~dst/DeCSS/Gallery/> and thought about its
consequences?
Peace,
Dylan
Joe Moore
> If someone adds proprietary code to BSD-licensed code, however, you can
> later extract the free code (assuming you have access to the code of
> the now-proprietary program), and use it in something else. Once
> proprietary (invariant) sections are added to something under the GFDL,
> that version of the document is forever non-free, because they can't
> ever be removed.
>
> A nice example of a viral license.
If "proprietary" (invariant) sections are added to something under the GFDL,
you can still fork the (free) version from before those are added. Similar
things have happened with software.
And there are other problems with the GFDL than just invariant texts.
--Joe
Brian T. Sniffen
> Joe Wreschnig said:
>> If someone adds proprietary code to BSD-licensed code, however, you can
>> later extract the free code (assuming you have access to the code of
>> the now-proprietary program), and use it in something else. Once
>> proprietary (invariant) sections are added to something under the GFDL,
>> that version of the document is forever non-free, because they can't
>> ever be removed.
>>
>> A nice example of a viral license.
>
> If "proprietary" (invariant) sections are added to something under the GFDL,
> you can still fork the (free) version from before those are added. Similar
> things have happened with software.
But you have to go and find a copy from before the proprietary section
was added. With a normal combined work, you can just remove the
proprietary code and take the clearly marked (heh) BSD code.
-Brian
--
Brian T. Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
Branden Robinson
> If one does not see the difference between program and documentation, it
> is very hard to explain why they do not need the same kind of freedoms.
If one cannot coherently and usefully *describe* the difference between
programs and documentation, it is difficult for other people to see it.
I continue to suspect that people are indulging an Aristotelian
categorization fetish solely as a means to an end, that end being to
compel the Debian Project to ship their favorite w4r3z in main, heedless
of the negative consequences to the freedoms that our users currently
enjoy.
After all, what utility would this distinction serve beyond providing
one a means of routing around the DFSG's inconvenient restrictions?
--
G. Branden Robinson | What influenced me to atheism was
Debian GNU/Linux | reading the Bible cover to cover.
bra...@debian.org | Twice.
http://people.debian.org/~branden/ | -- J. Michael Straczynski
Branden Robinson
> Anyway, even if this was the 'solution', we still *must* kick the GCC
> and GNU Emacs manuals out of main.
>
> I don't understand why that hasn't been done yet.
Cowardice, and the (apparently) delusional belief that further
negotiation with the FSF on this issue will be fruitful.
I am pretty sure now that the best way to budge the FSF from its
deference to RMS on this subject is to encourage a defection from the
GNU FDL by the contributors to the GNU Project.
In other words, while explusion of the GNU FDL-licensed material from
Debian main may be the only ethical course of action left to us, I don't
think it of itself will be sufficient to get the problems with the GNU
FDL to figure prominently in the FSF's field of view. Morever, I
question whether the FSF holds an institutional belief that the Debian
Project really represents a significant portion of the Free Software
community. They've ignored Debian before and they can do it again.
So, while I encourage the course of action you are proposing, I do not
think it is wise for people to hold the belief that Debian throwing down
the gauntlet will be the straw that breaks the gnu's back on this issue.
People should not support this action because they believe it will lead
to an immediate resolution that will result in a DFSG-free GNU Emacs
manual ending up back in main shortly afterwards. While that's an
outcome to be earnestly hoped for, it's not one to be counted on, in my
opinion.
Furthermore, taking this action with such a goal would be close to take
it to spite the FSF; and since, in my judgment, the onerous clauses of
the GNU FDL primarily exist to spite Tim O'Reilly, it would be
hypocritical for us to act with that motivation.
--
G. Branden Robinson | A celibate clergy is an especially
Debian GNU/Linux | good idea, because it tends to
bra...@debian.org | suppress any hereditary propensity
http://people.debian.org/~branden/ | toward fanaticism. -- Carl Sagan
Lynn Winebarger
> On Sun, Aug 03, 2003 at 02:10:37AM +0200, Sergey V. Spiridonov wrote:
>
>>If one does not see the difference between program and documentation, it
>>is very hard to explain why they do not need the same kind of freedoms.
>
>
> If one cannot coherently and usefully *describe* the difference between
> programs and documentation, it is difficult for other people to see it.
>
> I continue to suspect that people are indulging an Aristotelian
> categorization fetish solely as a means to an end, that end being to
> compel the Debian Project to ship their favorite w4r3z in main, heedless
> of the negative consequences to the freedoms that our users currently
> enjoy.
Meanwhile, others fetishize the notion that the denotation of words
should be a Turing-recognizable set (along with an algorithm to demonstrate
it).
> After all, what utility would this distinction serve beyond providing
> one a means of routing around the DFSG's inconvenient restrictions?
>
This is circular. You are only routing around DFSG's inconvenient
restrictions if those restrictions apply (by virtue of being software).
It can also be turned around - why claim everything is software except
to force DSFG restrictions where they are unnecessary or undeserved?
Lynn
Henning Makholm
> This is circular. You are only routing around DFSG's inconvenient
> restrictions if those restrictions apply (by virtue of being software).
> It can also be turned around - why claim everything is software except
> to force DSFG restrictions where they are unnecessary or undeserved?
Could you please explain which criteria you want to judge
"documentation" licenses by? For the sake of the discussion, you may
assume that we can find a text that everyone agrees is documentation
rather than program.
Do, however, please argue why each of the restrictions you want to
accept for documentation is less important for documentation than for
software.
--
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."
Joe Moore
> "Joe Moore" <joem...@iegrec.org> writes:
>> Joe Wreschnig said:
>>> If someone adds proprietary code to BSD-licensed code, however, you
>>> can later extract the free code (assuming you have access to the code
>>> of the now-proprietary program), and use it in something else. Once
>>> proprietary (invariant) sections are added to something under the
>>> GFDL, that version of the document is forever non-free, because they
>>> can't ever be removed.
>>>
>>> A nice example of a viral license.
>>
>> If "proprietary" (invariant) sections are added to something under the
>> GFDL, you can still fork the (free) version from before those are
>> added. Similar things have happened with software.
>
> But you have to go and find a copy from before the proprietary section
> was added. With a normal combined work, you can just remove the
> proprietary code and take the clearly marked (heh) BSD code.
How is that harder with the FDL "History" section than with the "clearly
marked" BSD code, or the GPL-required changelog?
Besides, you'll be able to find the latest Free version in Debian Main. :)
--Joe
Branden Robinson
[snip]
Well, *someone's* been reading their Derrida...
--
G. Branden Robinson |
Debian GNU/Linux | Yeah, that's what Jesus would do.
bra...@debian.org | Jesus would bomb Afghanistan. Yeah.
http://people.debian.org/~branden/ |
Nathanael Nerode
>It can also be turned around - why claim everything is software except
>to force DSFG restrictions where they are unnecessary or undeserved?
One good definition of software is "the part of a computer that's not
hardware". Another is "Information in a format designed
to be read by a machine". It's hardly artificial to use these
definitions and say that everything Debian distributes, except the
physical CDs, is software.
Anyway, nobody's trying to force DFSG restrictions where they are
'unnecessary'.
The point has already been made that the DFSG requirements *are*
just as necessary for documentation as they are for
programs. (The same motivations apply.)
The point has further been made that the requirements are just
as necessary for standards documents as they are for programs. (The
same motivations apply.)
I have to add a new section to my FDL FAQ. Here's a draft version:
--
It's not about misrepresentation!
A lot of people seem to think that the FDL's "invariant
sections" are there to prevent people from misrepresenting other
people's opinions. This is totally incorrect.
Suppose you (Mr. Foo) write an essay: "Why the BSD license is best, by
Mr. Foo." No matter what copyright license your essay is under -- even
if it's in the public domain -- nobody can modify it to "Why the GPL
license is best, by Mr. Foo." That's fraud (misrepresenting your
opinion). It's quite likely libel in many jurisdictions as well. It's
certainly illegal and unethical. It has absolutely nothing to do with
copyright.
Similarly, if someone modified a copy of "The GNU Manifesto" to say
something else, it would be fraud to distribute the modified copy under
the title "The GNU Manifesto". (It's a distinctive title with a
distinctive meaning.) Actually, GNU used in this fashion is probably a
trademark as well, so it's probably a trademark violation too.
If you want to add a clause to a copyright license which says:
"This license shall not be construed to allow anyone to misrepresent my
opinion, or to commit fraud, or to deliberately mislead anyone,"
that's perfectly free. This is conceptually similar to clauses
requiring modified programs to prominently note that they have been
modified, which many free licenses require. This is *not* the nature
of GFDL "Invariant Sections".
If you want to make *absolutely sure* nobody mistakes the modified
version for your original essay, you can put a clause in the license
like this:
All modified versions must prominently state that they do not
necessarily represent the opinions of Mr. Foo.
This might be a little irritating, but it's certainly free. GFDL
"Invariant Sections" go much further than this.
If your essay is in the public domain, or under a license which allows
free modification, someone else can use your words in the essay "Why the
GPL license is best, by Mr. Bar." Note that you are *not* being
misrepresented. GFDL "invariant sections" prohibit this.
Perhaps you care about being identified as the author of the original
essay. In this case, you probably want to require Mr. Bar to write in
his modified version something like:
This uses some material from 'Why the BSD licence is best', by Mr.
Foo, but does not necessarily represent Mr. Foo's opinions.
It's perfectly reasonable to require this in all modified copies, and
plenty of free licenses have such requirements. The GPL requires
crediting the original author. This is not what GFDL "invariant
sections" are for, either.
GFDL'ed invariant sections prohibit modification. You probably just
want to require that modified versions don't pretend to be your version,
and possibly that they credit you as the author of the original. This
can be accomplished much more easily, with better, freer licenses.
--
Nathanael Nerode <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html
Joe Wreschnig
> How is that harder with the FDL "History" section than with the "clearly
> marked" BSD code, or the GPL-required changelog?
The document trail in "History" may not exist anymore (or may be
inadaquate); you can't just say "Oh, this Invariant Section didn't exist
2 years ago; I'll take it out and pretend I had that version." You need
to actually have a license for that version.
> Besides, you'll be able to find the latest Free version in Debian Main. :)
Besides the caveats above, that doesn't solve the problem that the
majority of GFDL documentation (specifically, the stuff from the FSF) is
clearly non-free.
--
Joe Wreschnig <pi...@debian.org>
Joe Moore
> On Mon, 2003-08-04 at 14:37, Joe Moore wrote:
>> How is that harder with the FDL "History" section than with the
>> "clearly marked" BSD code, or the GPL-required changelog?
>
> The document trail in "History" may not exist anymore (or may be
> inadaquate); you can't just say "Oh, this Invariant Section didn't
> exist 2 years ago; I'll take it out and pretend I had that version."
> You need to actually have a license for that version.
In other words, it is not at all harder with documents under the GFDL, than
it is with source under BSD, or the [L]GPL.
The GFDL is no more "viral" in this respect than any other source license
that allows non-Free derived work.
( Oops, I left out the <humor> tag below. )
>> Besides, you'll be able to find the latest Free version in Debian
>> Main. :)
( </humor> )
>
> Besides the caveats above, that doesn't solve the problem that the
> majority of GFDL documentation (specifically, the stuff from the FSF)
> is clearly non-free.
Then, what needs to be in Debian Main is the last Free version of those
documents, specifically the version that was licensed under the previous GNU
Documentation License, if that's Free, or an empty document, if that is the
last Free document.
--Joe
Joe Wreschnig
> Joe Wreschnig said:
> > On Mon, 2003-08-04 at 14:37, Joe Moore wrote:
> >> How is that harder with the FDL "History" section than with the
> >> "clearly marked" BSD code, or the GPL-required changelog?
> >
> > The document trail in "History" may not exist anymore (or may be
> > inadaquate); you can't just say "Oh, this Invariant Section didn't
> > exist 2 years ago; I'll take it out and pretend I had that version."
> > You need to actually have a license for that version.
>
> In other words, it is not at all harder with documents under the GFDL, than
> it is with source under BSD, or the [L]GPL.
You can extract the BSD-licensed code from the proprietary code, and use
only it. There's no requirement in the BSD-licensed code that you must
distribute proprietary code that it was linked to at one point.
I don't know why you mention the GPL at all. You cannot combine code
under the GPL with proprietary software, nor can you have any kind of
invariant section in GPLd code.
> The GFDL is no more "viral" in this respect than any other source license
I hope this means "free software license" ^^^^^^
> that allows non-Free derived work.
Yes, it is. No other free license requires you keep the previously free
source forever proprietary-linked, once it has become such.
--
Joe Wreschnig <pi...@debian.org>
Joe Wreschnig
> I have to add a new section to my FDL FAQ. Here's a draft version:
Excellent job; you might want to consider adding how the GFDL *is* about
misrepresentation - If someone adds an invariant section contrary to
your beliefs, or a plainly false one, you can't remove it.
--
Joe Wreschnig <pi...@debian.org>
Joey Hess
> Suppose you (Mr. Foo) write an essay: "Why the BSD license is best, by
> Mr. Foo." No matter what copyright license your essay is under -- even
> if it's in the public domain -- nobody can modify it to "Why the GPL
> license is best, by Mr. Foo." That's fraud (misrepresenting your
> opinion). It's quite likely libel in many jurisdictions as well. It's
> certainly illegal and unethical. It has absolutely nothing to do with
> copyright.
>
> Similarly, if someone modified a copy of "The GNU Manifesto" to say
> something else, it would be fraud to distribute the modified copy under
> the title "The GNU Manifesto". (It's a distinctive title with a
> distinctive meaning.)
I've never seen fraud used as you use it here. According to my
dictionaries, its only fraud if you're using untruth to take advantage
of smeone. One could certianly modify the GNU manifesto for other
purposes, like parody.
--
see shy jo
Joe Moore
> On Tue, 2003-08-05 at 05:46, Joe Moore wrote:
>> Joe Wreschnig said:
>> > On Mon, 2003-08-04 at 14:37, Joe Moore wrote:
>> >> How is that harder with the FDL "History" section than with the
>> >> "clearly marked" BSD code, or the GPL-required changelog?
>> >
>> > The document trail in "History" may not exist anymore (or may be
>> > inadaquate); you can't just say "Oh, this Invariant Section didn't
>> > exist 2 years ago; I'll take it out and pretend I had that version."
>> > You need to actually have a license for that version.
>>
>> In other words, it is not at all harder with documents under the GFDL,
>> than it is with source under BSD, or the [L]GPL.
>
> You can extract the BSD-licensed code from the proprietary code, and
> use only it. There's no requirement in the BSD-licensed code that you
> must distribute proprietary code that it was linked to at one point.
And that is exactly the same as what is required by the GFDL.
If you know that paragraph X was in the FooWare manual before EvilCo added
its invariant section, then you can distribute paragraph X without EvilCo's
invariant section. (assuming you fulfill the rest of the requirements of
the GFDL invoked by the FooWare manual from before EvilCo's modification)
The easiest way to be sure that this is the case is to find a copy of the
FooWare manual from before EvilCo's contribution. Or you can try to
interpret EvilCo's "History" section.
If you don't know which paragraphs were added or modified by EvilCo, then
you are taking a risk that you are violating EvilCo's copyright.
Similarly, with BSD'd source:
If you know that function X was in the FooWare product before EvilCo added
its proprietary GUI, then you can distribute function X without EvilCo's
permission. (assuming you fulfull the rest of the requirements of the BSD
license, i.e. preserve copyright notices) The easiest way to be sure that
this is the case is to find a copy of the FooWare product without EvilCo's
proprietary GUI. Or you can review the changelog and back out all changes
from EvilCo.[0]
If you don't know which functions were added or modified by EvilCo, then you
are taking a risk that you are violating EvilCo's copyright.
>
> I don't know why you mention the GPL at all. You cannot combine code
> under the GPL with proprietary software, nor can you have any kind of
> invariant section in GPLd code.
[0] Oh, wait, the BSD license doesn't require a changelog, that must be why
I brought the [L]GPL into the picture... It's a convenient license that
happens to require a changelog. And the LGPL does allow combination with
proprietary software.
>
>> The GFDL is no more "viral" in this respect than any other source
>> license
> I hope this means "free software license" ^^^^^^
>> that allows non-Free derived work.
>
> Yes, it is. No other free license requires you keep the previously free
> source forever proprietary-linked, once it has become such.
The GFDL does not require "you keep the previously free source forever
proprietary-linked, once it has become such." You can continue to develop
and maintain a free version from the last non-proprietary version.
The freedom to fork is one of the key freedoms of Free Software. I can
think of several cases where a Free Software product was continued (from an
earlier version) when a later version was taken proprietary.
If you can't "retroactively" fork from a previous (assumed free) version,
then the license in question fails the "Tentacles of Evil" test. The GFDL
(as I understand the license and the test) passes the "Tentacles of Evil"
test.
Brian T. Sniffen
> Joe Wreschnig said:
>> On Tue, 2003-08-05 at 05:46, Joe Moore wrote:
>>> Joe Wreschnig said:
>>> > On Mon, 2003-08-04 at 14:37, Joe Moore wrote:
>>> >> How is that harder with the FDL "History" section than with the
>>> >> "clearly marked" BSD code, or the GPL-required changelog?
>>> >
>>> > The document trail in "History" may not exist anymore (or may be
>>> > inadaquate); you can't just say "Oh, this Invariant Section didn't
>>> > exist 2 years ago; I'll take it out and pretend I had that version."
>>> > You need to actually have a license for that version.
>>>
>>> In other words, it is not at all harder with documents under the GFDL,
>>> than it is with source under BSD, or the [L]GPL.
>>
>> You can extract the BSD-licensed code from the proprietary code, and
>> use only it. There's no requirement in the BSD-licensed code that you
>> must distribute proprietary code that it was linked to at one point.
>
> And that is exactly the same as what is required by the GFDL.
>
> If you know that paragraph X was in the FooWare manual before EvilCo added
> its invariant section, then you can distribute paragraph X without EvilCo's
> invariant section. (assuming you fulfill the rest of the requirements of
> the GFDL invoked by the FooWare manual from before EvilCo's modification)
That's not true. The BSD license is granted to all third parties, so
if I find a section of some proprietary code I know was written by
UCB, I can just take that section. The GFDL is a license only to the
recipient, so in order to take a free section from an older version,
I'd need to have received that version.
-Brian
--
Brian T. Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
MJ Ray
> I have to add a new section to my FDL FAQ. Here's a draft version:
It may be worth more comment on it not being a free software licence.
Often, that page says it is "non-free" when it means "not free software".
It is even qualified as "not free in the GPL sense" in some places, which
makes me think "not free software" would get your point across better.
Sergey V. Spiridonov
> Sergey V. Spiridonov <se...@hurd.homeunix.org> wrote:
>
>>What about
>
>
> ...not cutting out all the definition alternatives that don't support
> your position?
Definitions do not support me :( ;) I can use another one to express my
position. There is a definition which says that documentation can be a
part of the software, but I failed to find a definition which makes no
difference between software and documentation.
So, if you find a definition which makes no difference between software
and documentation, please send it on this list.
There is a difference, even if someone doesn't want to see it.
--
Best regards, Sergey Spiridonov
Joe Wreschnig
> > You can extract the BSD-licensed code from the proprietary code, and
> > use only it. There's no requirement in the BSD-licensed code that you
> > must distribute proprietary code that it was linked to at one point.
>
> And that is exactly the same as what is required by the GFDL.
>
> If you know that paragraph X was in the FooWare manual before EvilCo added
> its invariant section, then you can distribute paragraph X without EvilCo's
> invariant section.
This is a violation of the license. You received the version of the
document with the invariant section; that's the *only* version you have
a license too.
I would hope that Debian does not endorse copyright violation as a means
to get around the GFDL's shortcomings.
> Similarly, with BSD'd source:
> If you know that function X was in the FooWare product before EvilCo added
> its proprietary GUI, then you can distribute function X without EvilCo's
> permission. (assuming you fulfull the rest of the requirements of the BSD
> license, i.e. preserve copyright notices) The easiest way to be sure that
> this is the case is to find a copy of the FooWare product without EvilCo's
> proprietary GUI. Or you can review the changelog and back out all changes
> from EvilCo.[0]
You received two licenses with FooWare, EvilCo's proprietary one, and
the BSD one. Unless EvilCo's proprietary license forbids you from
extracting the BSD code (in which case I would question its validity),
you are free to extract the BSD one, which is under an entirely separate
copyright license.
> > No other free license requires you keep the previously free
> > source forever proprietary-linked, once it has become such.
>
> The GFDL does not require "you keep the previously free source forever
> proprietary-linked, once it has become such." You can continue to develop
> and maintain a free version from the last non-proprietary version.
If you can find it.
> If you can't "retroactively" fork from a previous (assumed free) version,
> then the license in question fails the "Tentacles of Evil" test. The GFDL
> (as I understand the license and the test) passes the "Tentacles of Evil"
> test.
You can, if you can find it. The trouble may be finding it.
(NB - I'm not discussing any of the other problems in the GFDL, not
because I don't believe they're problems, but because they've been
discussed already. I don't want people to get the opinion that the only
thing in the GFDL I'm objecting to is invariant sections. There's a lot
more, but invariant sections are the most odious to me.)
--
Joe Wreschnig <pi...@debian.org>
Scott James Remnant
> I don't know why you mention the GPL at all. You cannot combine code
> under the GPL with proprietary software, nor can you have any kind of
> invariant section in GPLd code.
>
If you define invariant section as a section of the software that cannot
be varied...
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
~~~~~~~~~~~~~~~~~~~
notices that refer to this License and to the absence of any warranty;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and give any other recipients of the Program a copy of this License
along with the Program.
The COPYING file itself is also invariant.
Scott
Matthew Garrett
>There is a difference, even if someone doesn't want to see it.
Is documentation that is linked into a binary software? If not, how do
you tell which bits are documentation and which bits software? If so,
how is drawing a distinction terribly useful?
--
Matthew Garrett | mjg59-chiark.ma...@srcf.ucam.org
Andrew Suffield
> 1. You may copy and distribute verbatim copies of the Program's
> source code as you receive it, in any medium, provided that you
> conspicuously and appropriately publish on each copy an appropriate
> copyright notice and disclaimer of warranty; keep intact all the
> ~~~~~~~~~~~~~~~~~~~
> notices that refer to this License and to the absence of any warranty;
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> and give any other recipients of the Program a copy of this License
> along with the Program.
This is not an additional stipulation of the license, but rather an
acknowledgement of a restriction imposed by copyright law itself.
[Also included in copyright law is a requirement to maintain
attribution of a work to all its authors, and usually a requirement
not to give false attribution to a citizen who was not an author (this
varies depending on context). No restriction is given on the form of
this attribution.]
> The COPYING file itself is also invariant.
The Berne conventione explicitly makes no statement as to the
copyrightability of legal texts. Their status in many countries is
unclear, but there is no compelling reason to believe that copyright
subsists in such a document.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Joe Moore
>
> That's not true. The BSD license is granted to all third parties, so
> if I find a section of some proprietary code I know was written by UCB,
> I can just take that section. The GFDL is a license only to the
> recipient, so in order to take a free section from an older version,
> I'd need to have received that version.
Ok, that sounds reasonable.
(Except that the GFDL defines "you" as <quote>Any member of the public is a
licensee, and is addressed as "you".</quote> (Section 1, 1st paragraph) so I
was a licensee of the previous version, I just didn't know it)
--Joe
Joe Moore
> On Tue, 2003-08-05 at 12:55, Joe Moore wrote:
>> > You can extract the BSD-licensed code from the proprietary code, and
>> > use only it. There's no requirement in the BSD-licensed code that
>> > you must distribute proprietary code that it was linked to at one
>> > point.
>> added its invariant section, then you can distribute paragraph X
>> without EvilCo's invariant section.
>
> This is a violation of the license. You received the version of the
> document with the invariant section; that's the *only* version you have
> a license too.
According to the GFDL definition section, you were a licensee of the
original version released under the GFDL without the evil invariant section.
Thus, the problem reduces to "finding an old version".
If you are the original author, this should not be a problem.
If you are not the original author, try www.archive.org, old linux
distributions, or whatever. Try contacting the original author, or other
authors listed before EvilCo in the History section.
If it comes down to a lawsuit, request the original version of the document
from EvilCo's lawyers as part of discovery.
If the document was not publicly available from before EvilCo's changes,
then how do you "know" that paragraph X was there before?
>> The GFDL does not require "you keep the previously free source forever
>> proprietary-linked, once it has become such." You can continue to
>> develop and maintain a free version from the last non-proprietary
>> version.
>
> If you can find it.
Yes, if you can find it. And that is exactly the same as extracting any
other subpart from any other combined work under any other license. You
have to be able to prove that you have a license to distribute the extract.
> (NB - I'm not discussing any of the other problems in the GFDL, not
> because I don't believe they're problems, but because they've been
> discussed already. I don't want people to get the opinion that the only
> thing in the GFDL I'm objecting to is invariant sections. There's a lot
> more, but invariant sections are the most odious to me.)
(NB - I'm not defending the GFDL as a particularly "good" license, and
certainly not as a "Free" license. I don't see it as particularly "viral"
either. There are enough real problems with the GFDL that we don't need to
create FUD about its "viral" nature. All that does is fuel the anti-FS
movement -- (see? all their licenses are viral! ban them!) )
Joe Moore
> On Mon, 2003-08-04 at 16:27, Nathanael Nerode wrote:
>> I have to add a new section to my FDL FAQ. Here's a draft version:
>
> Excellent job; you might want to consider adding how the GFDL *is*
> about misrepresentation - If someone adds an invariant section contrary
> to your beliefs, or a plainly false one, you can't remove it.
If you're the original author, (which is what this section talks about) you
can continue to distribute your version, without their invariant section.
You can even add an "Endorsement" saying that this is the only "authorized"
version of this document, and that any other version may not represent the
opinions of the author. Modifiers are obliged to remove all Endorsements.
If your line of reasoning were correct, I can add an "ode to my cat" to the
copy of the GNU Emacs manual I distribute, and the FSF would have to abide
this odious requirement also. (And a large monopolistic software company
could add "Why Software Should Be Proprietary" with the same expectation)
Lynn Winebarger
> Lynn Winebarger <owin...@free-expression.org>
>
>>It can also be turned around - why claim everything is software except
>>to force DSFG restrictions where they are unnecessary or undeserved?
>
>
> One good definition of software is "the part of a computer that's not
> hardware". Another is "Information in a format designed
> to be read by a machine". It's hardly artificial to use these
> definitions and say that everything Debian distributes, except the
> physical CDs, is software.
Oh, but it is artificial. The common usage of software refers only
to programs. While it is true that every program can be viewed as
an interpreter and its input as a program in the language defined by
that interpreter (e.g. every file is a valid program in the "more" language),
and that it is useful to think that way when designing
a program, it is not true that it's useful or honest to use
the term "software" like that in other contexts.
If you want all electronic data in Debian to be free, then you should
slap the title "Debian Free Electronic Data Guidelines" on the
DFSG instead of resorting to a non-standard definition. If this usage
of "software" was not artificial, or if there was no discernible (by
the human eye) difference between documentation and software, then
you wouldn't have these complaints cropping up.
> Anyway, nobody's trying to force DFSG restrictions where they are
> 'unnecessary'.
Apparently some people do think they are unnecessary, or there wouldn't
be (have been) a flap over the GFDL.
> The point has already been made that the DFSG requirements *are*
> just as necessary for documentation as they are for
> programs. (The same motivations apply.)
Then the intellectually honest approach is to say the guidelines are
for both software and documentation, not to say the set of software contains
the set of documentation.
I can only assume that it was easier for the people on debian-legal (at
least) to stretch the definition of software to cover everything they wanted
to be free than to get a vote to officially change the guidelines to reflect
the expansion.
It's fine with me if Debian has its own independent notions of freedom
for documentation and/or all electronic data, BTW.
Lynn
MJ Ray
I don't contribute much to this thread any more.
Lynn Winebarger <owin...@free-expression.org> wrote:
> Oh, but it is artificial. The common usage of software refers only
*Your* common usage. To me, software are the bits in the computer that
aren't hardware... I know the mess media can't tell the difference, but
they can't tell what a hacker is either.
[...]
> I can only assume that it was easier for the people on debian-legal (at
> least) to stretch the definition of software to cover everything they wanted
> to be free than to get a vote to officially change the guidelines to reflect
> the expansion.
Not really. There are some of us who consider all electronically stored
works as software, not just programs. Also, there has not yet been
a robust definition of the two that doesn't allow things to skip from
software to documents and back again to evade exclusions of non-free
software. Finally, if some electronically-held works are not software,
then should Debian distribute them? Currently, the SC suggests not.
--
MJR/slef My Opinion Only and possibly not of any group I know.
http://mjr.towers.org.uk/ jabber://sl...@jabber.at
Creative copyleft computing services via http://www.ttllp.co.uk/
Thought: Edwin A Abbott wrote about trouble with Windows in 1884
John Goerzen
> Lynn Winebarger <owin...@free-expression.org>
> >It can also be turned around - why claim everything is software except
> >to force DSFG restrictions where they are unnecessary or undeserved?
>
> One good definition of software is "the part of a computer that's not
> hardware". Another is "Information in a format designed
> to be read by a machine". It's hardly artificial to use these
> definitions and say that everything Debian distributes, except the
> physical CDs, is software.
Both are really poor. I think that it's very hard to call the King James
Bible software, even if it is encoded in ASCII stored on someone's hard
drive.
> The point has already been made that the DFSG requirements *are*
> just as necessary for documentation as they are for
> programs. (The same motivations apply.)
The same motivations apply, but your argument ignores the fundamental
difference between non-programs and programs. For innstance:
* Where is the executable for the King James Bible?
* How do I make sure I distribute the source code? What IS the source
code? Is it the TIFFs pre-OCR? Is it the OCR'd text? (These first two
points speak to DFSG #2 -- how can you distribute something in source code
and compiled form when it has neither)
> The point has further been made that the requirements are just
> as necessary for standards documents as they are for programs. (The
> same motivations apply.)
The fact that a point has been made does not mean that it is correct. For
instance, once again, where is the source code and executable? Where is our
compelling interest in being able to distribute a modified RFC822?
-- John
John Goerzen
> John Goerzen wrote:
> > 1. Would removing the manual for Emacs, libc, or other important GNU
> > software benefit our users?
> Yep. I'm very unhappy with having non-free software (and software means
> 0s and 1s -- so nearly everything Debian distributes except the
> physical CDs) in Debian; as a user, I chose Debian at least partly for
> the Social Contract, which this violates.
That's an overly-expansive view of software. You would include anything
that is digital in that description -- audio CDs, DVD movies, off-air TV
signals, books on disk, etc. I find it very hard to quantify Beethoven's
Ninth Symphony as software, even if it was recorded digitally, given that
the invention of software postdated its composition by a LONG time -- and
that the invention of software postdated early recordings by a long time as
well.
I see it as fallacious reasoning to conclude that anything that is binary is
software. If I use some sort of binary "Morse code" to send a message
manually, why is it more of software than if I use the real Morse code?
> > Would it benefit Free Software?
> Yep. It would help promote the movement to have genuninely free manuals
> for those pieces of software; manuals which could be integrated into
> programs, used as help text, freely lifted from, etc.
I agree that this is good. But how does it promote Free Software to strip
manuals from Free programs?
> I bet you thought you were asking rhetorical questions.
No, I posed them in my message as things we need to consider. And you have
:-)
John Goerzen
> On Sun, Aug 03, 2003 at 02:10:37AM +0200, Sergey V. Spiridonov wrote:
> > If one does not see the difference between program and documentation, it
> > is very hard to explain why they do not need the same kind of freedoms.
>
> If one cannot coherently and usefully *describe* the difference between
> programs and documentation, it is difficult for other people to see it.
Documentation consists of instructions primarily intended to be
human-readable regarding the operation of something such as a program.
Programs consist of instructions primarily intended to be machine-readable
that either contain machine language binary data or instructions designed to
be interpreted or converted into that at runtime. Programs will always
contain source code or machine language code, and often both.
I will grant that these definitions are imperfect and improbable arguments
could be lodged against them; at the same time, I believe that reasonable
people not engaging in a Jesuit exercise to find logical needles in a
haystack of common sense are able to tell the difference between a manpage
and a C source file.
> I continue to suspect that people are indulging an Aristotelian
> categorization fetish solely as a means to an end, that end being to
> compel the Debian Project to ship their favorite w4r3z in main, heedless
> of the negative consequences to the freedoms that our users currently
> enjoy.
Actually, my goals are the opposite. I see it as intellectually and
logically dishonest to claim certain requirements for some types of
non-program data in Debian, other requirements for other data, and do it all
under the guise that "everything binary is software."
I have a far smaller problem with people designing the Debian Free
Documentation Guidelines or the Debian Free Data Guidelines, and
implementing them fairly even to the exclusion of RFCs and GFDL than the
problem I have with people attempting to contort the Debian Free Software
Guidelines into something that covers non-software, because this attempt is
fraught with confusion and incoherency.
> After all, what utility would this distinction serve beyond providing
> one a means of routing around the DFSG's inconvenient restrictions?
The DFSG's restrictions prove inconvenient to those on your side of the
fence, too. After all, if you claim that all documentation is software,
than you are ignoring the restriction in DFSG #2, which states:
2. Source Code
The program must include source code, and must allow distribution in
source code as well as compiled form.
There is neither source code nor compiled code for my King James Bible in
free-form ASCII text. For we have a definition of source code as:
From The Free On-line Dictionary of Computing (09 FEB 02) [foldoc]:
source code
<language, programming> (Or "source", or rarely "source
language") The form in which a computer program is written by
the programmer. Source code is written in some formal
programming language which can be compiled automatically into
{object code} or {machine code} or executed by an
{interpreter}.
(1995-01-05)
There is no formal programming language that KJV is written in, and nothing
that can compile it or execute it. Moreover, there *never will* be anything
that can do that, because the KJV is not a set of instructions[1]. Other
books, such as works of philosophy or detective novels, similarly are not
instructions, and neither is the Mona Lisa, even if it is saved as a BMP.
The point is that this is not an exercise on my part to let less-than-free
bits into Debian. It is rather an attempt to call a horse a horse, rather
than engage in this business of calling everything software. I think we
have a clear weakness in the DFSG and a clear need for some guidelines for
non-Software components, and I advocate that.
I also advocate equal treatment, both over our entire archive and over time.
(That is, an unmodified copy of something that was free in 2000 should still
be free today unless we have changed our definition to exclude it.)
We distribute the GPL all over on our system, and at the very top, it says:
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Under the DFSG, this would fail. If you call the GPL "software", then you
have declared the entirety of the most important pieces of a Debian system
non-free.
If you do not call the GPL software, then why is documentation software?
Why is it OK to include the GPL in our system but not other bits of
documentation?
John Goerzen
> I wish to address a very narrow part of this point: because copyright
> protects only creative expression of ideas, and because legal
> terminology is intended to be strictly denotative and carefully
> defined, contracts and similar legal texts (including licenses)
> receive very weak copyright protection; often none.
But the GPL itself starts with:
| GNU GENERAL PUBLIC LICENSE
| Version 2, June 1991
|
| Copyright (C) 1989, 1991 Free Software Foundation, Inc.
| 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
| Everyone is permitted to copy and distribute verbatim copies
| of this license document, but changing it is not allowed.
And while you may debate the enforcability of this in the US, it may be
enforcable elsewhere, and our preference has always been to assume licenses
are enforcable as written.
Now, given that a huge portion of our software ships with this, and it is
incorporated in our .debs by reference (and by mandate in the GPL itself),
considering the text of the GPL to be non-free would force the removal of
most of main directly or because of dependencies.
If you then grant the GPL an exception, why do you not do that for RFCs?
Why do you not do that for the Emacs manual? What is special about the GPL?
This is what bothers me the most. We must not play favorites or say "Well,
this non-free file goes in main because it's too important to have in
non-free". Either it is free or not, and popularity has nothing to do with
that.
To put it more concretely: I have not seen any arguments that argue against
the removal of RFCs on the grounds that they are non-free software that do
not also argue against the removal of the GPL. Can someone devise one?
> boilerplate: there's no other way to express exactly the same idea, so
> the expression receives no copyright protection. As a result, I
> suggest you abandon this point of your argument.
But you need only look at the first few lines of the GPL to see what I'm
talking about; the FSF actually asserts copyright over it.
Steve Langasek
> But the GPL itself starts with:
> | GNU GENERAL PUBLIC LICENSE
> | Version 2, June 1991
> |
> | Copyright (C) 1989, 1991 Free Software Foundation, Inc.
> | 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> | Everyone is permitted to copy and distribute verbatim copies
> | of this license document, but changing it is not allowed.
> And while you may debate the enforcability of this in the US, it may be
> enforcable elsewhere, and our preference has always been to assume licenses
> are enforcable as written.
> Now, given that a huge portion of our software ships with this, and it is
> incorporated in our .debs by reference (and by mandate in the GPL itself),
> considering the text of the GPL to be non-free would force the removal of
> most of main directly or because of dependencies.
> If you then grant the GPL an exception, why do you not do that for RFCs?
> Why do you not do that for the Emacs manual? What is special about the GPL?
> To put it more concretely: I have not seen any arguments that argue against
> the removal of RFCs on the grounds that they are non-free software that do
> not also argue against the removal of the GPL. Can someone devise one?
"Licenses and copyright notices merit special treatment because they
*are* special: they're the one thing that we include in Debian *not*
because of their content value to users, but because they're necessary
legal incantations required by copyright law. Freedom to modify a
license text does not translate into freedom from distributing the
verbatim text of the license governing the works we distribute; and
while there are parallels here with RFCs (changing the text of the
standard does not change the standard), the key difference is that we
can choose not to distribute the RFCs. Technically we /can/ choose not
to distribute copyright notices and licenses, but as a pragmatic
concession to copyright law, we opt for a non-empty distro instead. ;)
"In short, since no one is advocating the distribution of software
licenses as OS components per se, they are not subject to the same
requirements of content modifiability that govern OS components. The
interest in RFCs, and other documentation, clearly lies in their utility
as OS components."
Message-ID: <20030731201...@tennyson.netexpress.net>
--
Steve Langasek
postmodern programmer
MJ Ray
> compelling interest in being able to distribute a modified RFC822?
RFC2822, you mean? ;-)
MJ Ray
> [...] I find it very hard to quantify Beethoven's
> Ninth Symphony as software, even if it was recorded digitally, given that
Similarly, do we regard a popular performance of it as a gig, even if
that gig was played in a gig venue? I suspect that a particular form
of a work can be software, even if the original was not.
[...]
> I agree that this is good. But how does it promote Free Software to strip
> manuals from Free programs?
How does it promote free software to strip some accompanying software from
it?
Andrew Suffield
> > I continue to suspect that people are indulging an Aristotelian
> > categorization fetish solely as a means to an end, that end being to
> > compel the Debian Project to ship their favorite w4r3z in main, heedless
> > of the negative consequences to the freedoms that our users currently
> > enjoy.
>
> Actually, my goals are the opposite. I see it as intellectually and
> logically dishonest to claim certain requirements for some types of
> non-program data in Debian, other requirements for other data, and do it all
> under the guise that "everything binary is software."
What requirements, exactly, do you think are being made of some things
and not of others?
> > After all, what utility would this distinction serve beyond providing
> > one a means of routing around the DFSG's inconvenient restrictions?
>
> The DFSG's restrictions prove inconvenient to those on your side of the
> fence, too. After all, if you claim that all documentation is software,
> than you are ignoring the restriction in DFSG #2, which states:
>
> 2. Source Code
>
> The program must include source code, and must allow distribution in
> source code as well as compiled form.
>
> There is neither source code nor compiled code for my King James Bible in
> free-form ASCII text.
This is an example of why they are guidelines, not rules. It is simple
for an intelligent person to interpret this in a sensible manner for
documentation.
> The point is that this is not an exercise on my part to let less-than-free
> bits into Debian. It is rather an attempt to call a horse a horse, rather
> than engage in this business of calling everything software. I think we
> have a clear weakness in the DFSG and a clear need for some guidelines for
> non-Software components, and I advocate that.
So, now we come to the crux of your argument.
What weaknesses, exactly? What actual problems does it cause us?
We have not, to date, had any difficulty in interpreting the DFSG as
applied to documentation, excluding the lunatic fringe who appear,
stick their oar in, and cease to send mail when somebody points out
why their argument is flawed (in every discussion, not just licensing
ones).
In all the FDL debates, there has not once been a solid argument that
it is actually acceptable, which was not immediately rebutted. If
anybody thinks otherwise, they are invited to present their argument
*and then defend it in the face of skilled opposition*.
> Why is it OK to include the GPL in our system but not other bits of
> documentation?
This is virtually a FAQ.
Firstly, even if that statement was not present, the license would
still be unmodifiable and non-removable; that is the nature of
copyright.
Secondly, there is no convincing reason to believe that this statement
is binding in law, because nobody has presented any evidence that
copyright subsists in a license _at all_. Remember, copyright is not a
natural thing, it was invented in the past few decades in order to
improve the profit margins of corporations.
Thirdly, we are distributing software, not licenses. We wouldn't
include them at all if we didn't have to; we only accept them because
forces beyond our control require us to.
Any one of these would be enough on its own. There's probably some
more that I've forgotten.
Matthew Garrett
>Both are really poor. I think that it's very hard to call the King James
>Bible software, even if it is encoded in ASCII stored on someone's hard
>drive.
And (again, sorry to keep whipping a dead horse) what is a copy of the
King James Bible that's linked into a reader application?
> * How do I make sure I distribute the source code? What IS the source
> code? Is it the TIFFs pre-OCR? Is it the OCR'd text? (These first two
> points speak to DFSG #2 -- how can you distribute something in source code
> and compiled form when it has neither)
The preferred form of modification for a textual version of the bible is
plainly the text, and for a graphical version the images. A picture and
a full description of a picture may contain exactly the same
information, but they're plainly different things with different aims
and so in each case would represent the "source".
>The fact that a point has been made does not mean that it is correct. For
>instance, once again, where is the source code and executable? Where is our
>compelling interest in being able to distribute a modified RFC822?
If I modify RFC822 (or 2822, or whatever) to describe an SMTP-based
mechanism for washing machine control and accompany it with an
application that speaks my modified protocol, I think there's a
compelling interest in being able to distribute it.
--
Matthew Garrett | mjg59-chiark.ma...@srcf.ucam.org
Brian T. Sniffen
> On Fri, Aug 01, 2003 at 01:29:12PM -0400, Brian T. Sniffen wrote:
> > I wish to address a very narrow part of this point: because copyright
> > protects only creative expression of ideas, and because legal
> > terminology is intended to be strictly denotative and carefully
> > defined, contracts and similar legal texts (including licenses)
> > receive very weak copyright protection; often none.
>
> But the GPL itself starts with:
>
> | GNU GENERAL PUBLIC LICENSE
> | Version 2, June 1991
> |
> | Copyright (C) 1989, 1991 Free Software Foundation, Inc.
> | 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> | Everyone is permitted to copy and distribute verbatim copies
> | of this license document, but changing it is not allowed.
>
> And while you may debate the enforcability of this in the US, it may be
> enforcable elsewhere, and our preference has always been to assume licenses
> are enforcable as written.
Indeed. And elsewhere, the FSF grants a license to create derivative
works of the GPL: http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL.
It's also been Debian's preference to read all the applicable
licenses. Particularly because it's a license, it's important to
distinguish between changing an instance of it and creating a new
license derivative of the GPL.
> Now, given that a huge portion of our software ships with this, and it is
> incorporated in our .debs by reference (and by mandate in the GPL itself),
> considering the text of the GPL to be non-free would force the removal of
> most of main directly or because of dependencies.
Not quite. I *do* think Debian should remove the GPL's
Invariant-but-removable Preamble, distributing only the legal text.
The FSF says
<http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble>, but since
the requirement for future distribution is only "under the terms of
the GPL," Debian could distribute the "Debian GPL" containing only the
legal terms, and without the invariant Preamble.
> If you then grant the GPL an exception, why do you not do that for RFCs?
> Why do you not do that for the Emacs manual? What is special about the GPL?
>
> This is what bothers me the most. We must not play favorites or say "Well,
> this non-free file goes in main because it's too important to have in
> non-free". Either it is free or not, and popularity has nothing to do with
> that.
Are you constructing straw men? I have seen nobody argue that the GPL
is popular, and so should be retained. Indeed, I've seen proponents
of non-modifiable-RFCs-in-main arguing that they're so popular that it
would un-Social to remove them. Can you cite such a message?
> To put it more concretely: I have not seen any arguments that argue against
> the removal of RFCs on the grounds that they are non-free software that do
> not also argue against the removal of the GPL. Can someone devise one?
Well, there's the easy approach, pointing to
http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL. Look, the terms
of the GPL are free.
But if you'd like a more complicated answer, sure: we are distributing
creative works. Many of them are copyrighted. The law says we must
preserve those copyright notices. So you can't change the line in
YEmacs which says "Copyright 2003 S. Author". We wish to distribute
Free software: we wish to give software to people, and to give them
also legal permission to modify and distribute it. This means that we
must give them a copyright license. We have this Free Software. We'd
like to distribute it in a Free way... so we give the recipients the
license to tell them how they can modify and distribute the software.
It's not part of any program, just infrastructure put alongside the
programs: not distributed for any useful purpose for anybody except
for informing users of their legal rights.
I'd like to point out also that if your goal is to preserve RFCs in
Debian, you would probably do better to argue "I cannot see any
argument for preserving the GPL in Debian which does not also argue
for preserving RFCs in Debian".
> > boilerplate: there's no other way to express exactly the same idea, so
> > the expression receives no copyright protection. As a result, I
> > suggest you abandon this point of your argument.
>
> But you need only look at the first few lines of the GPL to see what I'm
> talking about; the FSF actually asserts copyright over it.
It does. The copyright on the Preamble, and on the combination of the
Preamble and the license text, is strong. The copyright on the
license text itself is probably not defensible. It doesn't matter too
much, given the license to create new documents derivative of the GPL.
-Brian
Sergey V. Spiridonov
> After all, what utility would this distinction serve beyond providing
> one a means of routing around the DFSG's inconvenient restrictions?
Program (code) is not of great value outside computer, except examples
which usually belong to the documentation. I will not buy a book with
printed source code of Linux kernel, even if it will be very cheap :)
Documentation and some other kinds of data can be used without computer.
Documentation can be printed and sold as books. One does not need a
computer to read a printed documentation.
There are kinds of files (documentation, images, sounds) which can be
used outside the cramped computer scope.
There is a whole various world outside the computer!
--
Best regards, Sergey Spiridonov
--
Brian T. Sniffen
> Branden Robinson wrote:
>
>> After all, what utility would this distinction serve beyond providing
>> one a means of routing around the DFSG's inconvenient restrictions?
>
> Program (code) is not of great value outside computer, except examples
> which usually belong to the documentation.
This is not true: source code is intended for human consumption at least
as much as for machines.
> I will not buy a book with
> printed source code of Linux kernel, even if it will be very cheap :)
But you would buy a book like Linux Undercover, with printed man pages?
Would you not buy a book with the source of PGP 2.6? Tens of thousands of
people did so...
> Documentation and some other kinds of data can be used without
> computer. Documentation can be printed and sold as books. One does not
> need a computer to read a printed documentation.
One does not need a computer to read printed source code either -- I do my
best debugging that way, on a desk scattered with papers. And one does
need a computer to read most PDF or MS Word files, no matter whether they
are printed or not: lpr foo.pdf is not a pretty sight.
> There are kinds of files (documentation, images, sounds) which can be
> used outside the cramped computer scope.
Indeed, I believe you are referring to the class "Creative works", which
includes computer programs. Go look at the DeCSS Gallery if you'd like a
slightly stranger, but more artful argument on the same topic.
> There is a whole various world outside the computer!
> --
> Best regards, Sergey Spiridonov
>
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-leg...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listm...@lists.debian.org
--
Brian Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
John Goerzen
> > Actually, my goals are the opposite. I see it as intellectually and
> > logically dishonest to claim certain requirements for some types of
> > non-program data in Debian, other requirements for other data, and do it all
> > under the guise that "everything binary is software."
>
> What requirements, exactly, do you think are being made of some things
> and not of others?
I see us requiring RFCs to be mutable, but ignoring the fact that we
distribute the GPL, which is not. I see this as also being contradictory
with many of the arguments against the FDL.
> > There is neither source code nor compiled code for my King James Bible in
> > free-form ASCII text.
>
> This is an example of why they are guidelines, not rules. It is simple
> for an intelligent person to interpret this in a sensible manner for
> documentation.
If by "interpret" you mean "ignore DFSG #2", which seems to be what happens
in practice, OK. But is that really the kind of thing you want to do? What
would you tell me, as an author, to do to distribute something that can be
compiled into machine code out of my plain text prose?
This has become a problem in practice. I have witnessed attitudes towards
things like the RFC and Emacs manual change within the past few months,
despite the fact that our guidelines have not changed, and neither have
their licenses materially altered the nature of users' freedoms within that
timeframe. Simultaneously, we allow texts like the GPL, which fail if one
applies the same rules to them, into the distribution.
The DFSG should be dynamic with regards to dealing with new licenses and new
software issues. It should not be dynamic regarding applications of
existing principles. Nor should it be so dynamic that people attempt to
make arguments like you do below for discrimination in favor of things that
might otherwise be considered non-free.
> We have not, to date, had any difficulty in interpreting the DFSG as
> applied to documentation, excluding the lunatic fringe who appear,
I think that the persistence and size of this thread provides more than
enough evidennce to debunk that claim.
> In all the FDL debates, there has not once been a solid argument that
My comments are not limited to the FDL debate, but seek to address a more
fundamental question: Do software guidelines serve us well for non-software
items? My answer is no, but obviously it is being discussed.
My mind is open and I remain willing to accept that there may be someone out
there that can come up with equitable guidelines. But I perceive a very
real inequity in the very prominent example I keep citing in the GPL.
> > Why is it OK to include the GPL in our system but not other bits of
> > documentation?
>
> This is virtually a FAQ.
>
> Firstly, even if that statement was not present, the license would
> still be unmodifiable and non-removable; that is the nature of
> copyright.
The license would be unmodifiable and non-removable *solely as it pertains
to the package to which it was affixed*. However, barring protections on
the license itself, I could take the text of the GPL, modify it, and apply
the modified version to my own software -- or just publish the Goerzen
Public License version 2. (Nah, that wouldn't be confusing at all...)
The copyright statement on the GPL prevents me from doing this.
It seems *very* similar to the RFC problem.
> Secondly, there is no convincing reason to believe that this statement
> is binding in law, because nobody has presented any evidence that
> copyright subsists in a license _at all_. Remember, copyright is not a
> natural thing, it was invented in the past few decades in order to
> improve the profit margins of corporations.
In U.S. law, copyright was actually codified in our *constitution* in
section 8, clause 8. That was passed just a we bit more than a few decades
ago.
However, your argument has a lot of problems. First, that which is the case
with U.S. law may not be the case internationally. On this list, we have
always erred on the side of caution, assuming that the requirements in a
license are legally enforceable. Or are you suggesting that we should
special case the GPL?
Secondly, there are pending court cases right now in the U.S. alleging
copyright violations from legal papers filed in court cases.
Thirdly, there is legal precedent for restrictions on the distribution of
licenses (which are just a special case of contracts), though usually from a
trade secret point of view.
> Thirdly, we are distributing software, not licenses. We wouldn't
> include them at all if we didn't have to; we only accept them because
> forces beyond our control require us to.
Are you really saying that we have been violating our own Social Contract
for years because we either lack the power to remove the GPL from our
distribution or the will to switch to non-GPL software?
I find that a rather farfetched notion.
I don't see anybody forcing us to ship the GPL on our hard disks. I do see
us required to put it there *if we distribute GPL'd software*. But that's
the rub, isn't it? We're only required to distribute those invariant
sections if we distribute the manual. So we're back to removing the GPL by
the same argument that removes FDL documents.
--
John Goerzen <jgoe...@complete.org> www.complete.org
Anthony DeRobertis
On Thursday, Aug 7, 2003, at 07:01 US/Eastern, Lynn Winebarger wrote:
> Then the intellectually honest approach is to say the guidelines are
> for both software and documentation, not to say the set of software
> contains
> the set of documentation.
>
> I can only assume that it was easier for the people on debian-legal
> (at
> least) to stretch the definition of software to cover everything they
> wanted
> to be free than to get a vote to officially change the guidelines to
> reflect
> the expansion.
I'd like to know more about this "intellectual honesty" that compels
the word "software" to include documentation when used in the Social
Contract, but not when used a little further down the page[0] in the
guidelines.
Debian Will Remain 100% Free Software
We promise to keep the Debian GNU/Linux Distribution entirely
free software. As there are many definitions of free software,
we include the guidelines we use to determine if software is
"free" below....
[0] http://www.debian.org/social_contract.html
John Goerzen
> standard does not change the standard), the key difference is that we
> can choose not to distribute the RFCs. Technically we /can/ choose not
> to distribute copyright notices and licenses, but as a pragmatic
> concession to copyright law, we opt for a non-empty distro instead. ;)
Can I take this, then, as an admission that we willfully distribute non-free
software in main, and intend to continue doing so, because we perceive a
lack of alternatives? (In the form of, for instance, public domain
software)
John Goerzen
> On Thu, Aug 07, 2003 at 04:52:52PM -0500, Steve Langasek wrote:
> > standard does not change the standard), the key difference is that we
> > can choose not to distribute the RFCs. Technically we /can/ choose not
> > to distribute copyright notices and licenses, but as a pragmatic
> > concession to copyright law, we opt for a non-empty distro instead. ;)
>
> Can I take this, then, as an admission that we willfully distribute non-free
> software in main, and intend to continue doing so, because we perceive a
> lack of alternatives? (In the form of, for instance, public domain
> software)
I should have put "software" in quotes, because I ask the question using the
definition of those that would define software as any bits of data that we
distribute, and thus place all bits of data we distribute, including RFCs
and the GPL, under the auspices of the GPL. I do not ascribe to that view,
but I'm trying to push it to its logical conclusion.
Henning Makholm
> My comments are not limited to the FDL debate, but seek to address a more
> fundamental question: Do software guidelines serve us well for non-software
> items? My answer is no, but obviously it is being discussed.
You have yet not disclosed which guidelines you would like to see for
what you perceive as "non-software". Can you propose specifically how
you would like the guidelines for "non-software" to differ from the
DFSG?
> My mind is open and I remain willing to accept that there may be
> someone out there that can come up with equitable guidelines.
It is you who want different guidelines. Then you should propose some
rather than leaving it to "someone out there".
--
Henning Makholm "The practical reason for continuing our
system is the same as the practical reason
for continuing anything: It works satisfactorily."
John Goerzen
> > And while you may debate the enforcability of this in the US, it may be
> > enforcable elsewhere, and our preference has always been to assume licenses
> > are enforcable as written.
>
> Indeed. And elsewhere, the FSF grants a license to create derivative
> works of the GPL: http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL.
That grant actually has a lot of catches in it; they exclude the entire
preamble and provide restrictions on the instructions for use.
> > incorporated in our .debs by reference (and by mandate in the GPL itself),
> > considering the text of the GPL to be non-free would force the removal of
> > most of main directly or because of dependencies.
>
> Not quite. I *do* think Debian should remove the GPL's
> Invariant-but-removable Preamble, distributing only the legal text.
> The FSF says
> <http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble>, but since
> the requirement for future distribution is only "under the terms of
> the GPL," Debian could distribute the "Debian GPL" containing only the
> legal terms, and without the invariant Preamble.
Nope, that doesn't fly; almost all copyright statements using the GPL say
"under the terms of the GNU General Public License as published by the Free
Software Foundation". The GPLOmitPreamble citation says that the preamble
may not be omitted, which is consistent with the text in the GPL itself.
Therefore, we can't substitute the preamble-less "Debian GPL" alternative
license.
> > this non-free file goes in main because it's too important to have in
> > non-free". Either it is free or not, and popularity has nothing to do with
> > that.
>
> Are you constructing straw men? I have seen nobody argue that the GPL
> is popular, and so should be retained. Indeed, I've seen proponents
> of non-modifiable-RFCs-in-main arguing that they're so popular that it
> would un-Social to remove them. Can you cite such a message?
Steve Langasek cited one for me:
Message-ID: <20030731201...@tennyson.netexpress.net>
It seems that everybody's reasons for allowing the GPL but not the RFCs boil
down to that: GPL'd software is important to us, and we're required to ship
the GPL with that software.
Why else would there be a double standard?
> It's not part of any program, just infrastructure put alongside the
> programs: not distributed for any useful purpose for anybody except
> for informing users of their legal rights.
Couldn't the same be said about RFCs? They're not distributed for any
useful purpose for anybody except for informing developers of
possibly-inaccurate best practices.
> I'd like to point out also that if your goal is to preserve RFCs in
> Debian, you would probably do better to argue "I cannot see any
> argument for preserving the GPL in Debian which does not also argue
> for preserving RFCs in Debian".
While I think RFCs should remain, that is not the point of this, but I
believe I have been advancing just that argument (well, its corollary, but
I'd agree with this one too.)
> It does. The copyright on the Preamble, and on the combination of the
> Preamble and the license text, is strong. The copyright on the
> license text itself is probably not defensible. It doesn't matter too
> much, given the license to create new documents derivative of the GPL.
That still leaves us with a non-free Preamble.
Matthew Garrett
>Documentation and some other kinds of data can be used without computer.
>Documentation can be printed and sold as books. One does not need a
>computer to read a printed documentation.
Is http://www.codon.org.uk/~mjg59/scratch/ifupdown-0.6.4/ifupdown.nw
software or documentation?
--
Matthew Garrett | mjg59-chiark.ma...@srcf.ucam.org
Lynn Winebarger
>
> On Thursday, Aug 7, 2003, at 07:01 US/Eastern, Lynn Winebarger wrote:
>
>> Then the intellectually honest approach is to say the guidelines are
>> for both software and documentation, not to say the set of software
>> contains
>> the set of documentation.
>
> word "software" to include documentation when used in the Social
> Contract, but not when used a little further down the page[0] in the
> guidelines.
Nowhere did I suggest that Debian must or even should distribute
documentation! Indeed it would seem Debian in violation of the 100%
criteria if software is interpreted in the normal manner.
It's interesting that the preamble refers to definitions of "free
software" and then goes on to give the DFSG to define "free" in
relationship to "software", rather than both.
Lynn
John Goerzen
> Scripsit John Goerzen <jgoe...@complete.org>
>
> > My comments are not limited to the FDL debate, but seek to address a more
> > fundamental question: Do software guidelines serve us well for non-software
> > items? My answer is no, but obviously it is being discussed.
>
> You have yet not disclosed which guidelines you would like to see for
> what you perceive as "non-software". Can you propose specifically how
> you would like the guidelines for "non-software" to differ from the
> DFSG?
Fair enough. I will do some thinking on this over the weekend and see if I
can have something substantive to post Monday.
> > My mind is open and I remain willing to accept that there may be
> > someone out there that can come up with equitable guidelines.
>
> It is you who want different guidelines. Then you should propose some
> rather than leaving it to "someone out there".
You omitted some context; I was saying that someone could propose guidelines
for treating documentation as software under the DFSG, which is not what I'm
presently supporting or talking about above.
-- John
John Goerzen
> Sergey V. Spiridonov wrote:
>
> >Documentation and some other kinds of data can be used without computer.
> >Documentation can be printed and sold as books. One does not need a
> >computer to read a printed documentation.
>
> Is http://www.codon.org.uk/~mjg59/scratch/ifupdown-0.6.4/ifupdown.nw
> software or documentation?
I was waiting for that to come up. I would say it's both, and that it must
pass the DFSG and any documentation guidelines we care to draft.
-- John
John Goerzen
> John Goerzen wrote:
>
> >Both are really poor. I think that it's very hard to call the King James
> >Bible software, even if it is encoded in ASCII stored on someone's hard
> >drive.
>
> And (again, sorry to keep whipping a dead horse) what is a copy of the
> King James Bible that's linked into a reader application?
It's just that. You haven't transformed the document into object code;
you've merely surrounded it by object code.
> >The fact that a point has been made does not mean that it is correct. For
> >instance, once again, where is the source code and executable? Where is our
> >compelling interest in being able to distribute a modified RFC822?
>
> If I modify RFC822 (or 2822, or whatever) to describe an SMTP-based
> mechanism for washing machine control and accompany it with an
> application that speaks my modified protocol, I think there's a
> compelling interest in being able to distribute it.
I don't disagree with that; I just don't find it so compelling that it
outweighs the utility of having RFC822 available to start with.
-- John
Lynn Winebarger
> We have not, to date, had any difficulty in interpreting the DFSG as
> applied to documentation, excluding the lunatic fringe who appear,
> stick their oar in, and cease to send mail when somebody points out
> why their argument is flawed (in every discussion, not just licensing
> ones).
>
> In all the FDL debates, there has not once been a solid argument that
> it is actually acceptable, which was not immediately rebutted. If
> anybody thinks otherwise, they are invited to present their argument
> *and then defend it in the face of skilled opposition*.
There are two ways of viewing debate: one is that debate is a
means of persuading others that your point is the correct one, the
other is that debate is a means of deriving truth (or at least
correctness). Thus it's not "lunatic" to offer what seems to be
a plausible argument and then not continue to argue for it when a
convincing refutation is offered.
Lynn
PS. Yes, I know the two views of debate are not orthogonal.
John Goerzen
> I'd like to know more about this "intellectual honesty" that compels
> the word "software" to include documentation when used in the Social
> Contract, but not when used a little further down the page[0] in the
> guidelines.
I don't see the problem. 100% of the software Debian contains is Free.
There may have been some looseness in the original language, but due to the
frequent references to source code and executable code in the DFSG, it is
quite clear to me that the DFSG did not contemplate documentation qualifying
as software.
John Goerzen
> Nowhere did I suggest that Debian must or even should distribute
> documentation! Indeed it would seem Debian in violation of the 100%
> criteria if software is interpreted in the normal manner.
My point here is that redefining "software" does not mean we have really
dealt with the problem.
> It's interesting that the preamble refers to definitions of "free
> software" and then goes on to give the DFSG to define "free" in
> relationship to "software", rather than both.
Matthew Garrett
>On Fri, Aug 08, 2003 at 12:49:28AM +0100, Matthew Garrett wrote:
>> And (again, sorry to keep whipping a dead horse) what is a copy of the
>> King James Bible that's linked into a reader application?
>
>It's just that. You haven't transformed the document into object code;
>you've merely surrounded it by object code.
Is this a reasonable thing to want to do? If so, I need to have the same
set of freedoms as the DSFG would provide me with - producing a piece of
software with an embedded GFDL document would require me to license the
software in such a way that it wouldn't be permitted into Debian. I
could avoid this by separating the reader software and the data, but
performing this sort of hack in order to achieve DSFG freeness seems
like the wrong sort of answer.
>> If I modify RFC822 (or 2822, or whatever) to describe an SMTP-based
>> mechanism for washing machine control and accompany it with an
>> application that speaks my modified protocol, I think there's a
>> compelling interest in being able to distribute it.
>
>I don't disagree with that; I just don't find it so compelling that it
>outweighs the utility of having RFC822 available to start with.
Yet we did (a long time ago) decide that the ability to distribute a
modified Netscape was sufficiently compelling that it outweighed the
utility of having Netscape available to start with. There are valid
technical and practical reasons for us to want modifiable software, and
there are valid technical and practical reasons for us to want
modifiable documentation. RFCs are important - so was Netscape before
Mozilla turned up. A description of why the freedom to distribute
modified documentation is less important than the freedom to distribute
modified software that's based on technical and practical reasoning
would be nice.
(Now, I'm not going to claim that there are no good reasons for
documentation being under licenses that wouldn't pass the DSFG - I
haven't really made up my mind about that. The question is, why do our
users not require the same rights regarding the documentation we
distribute as they do regarding the software we distribute?)
--
Matthew Garrett | mjg59-chiark.ma...@srcf.ucam.org
Steve Langasek
> > standard does not change the standard), the key difference is that we
> > can choose not to distribute the RFCs. Technically we /can/ choose not
> > to distribute copyright notices and licenses, but as a pragmatic
> > concession to copyright law, we opt for a non-empty distro instead. ;)
> Can I take this, then, as an admission that we willfully distribute non-free
> software in main, and intend to continue doing so, because we perceive a
> lack of alternatives? (In the form of, for instance, public domain
> software)
To the extent that licenses should be considered software here, yes. I
do, however, disagree with your characterization of this as a double
standard, and with your claim that these arguments relate to the
importance of GPL software. This is not my argument at all; I'm arguing
that licenses are different because they're not part of the *content* of
the OS, and with the exception of public domain software, it is
*always* mandatory that we distribute them -- unmodified -- with the
software, regardless of the terms of any such meta-license governing the
creation of derivative works of the license text. This means that, if
you really want to take the modifiability requirement to its most absurd
extreme, no software is DFSG-free unless the license *as shipped with
the software* can be freely changed; otherwise, every package that we
distribute under the terms of a software license includes an invariant
section.
But there is a bright line between requiring modifiability of a
package contents, and requiring modifiability of a package's legal
metadata. In contrast, documentation and programs are both package
contents; no one has yet identified the bright line to use for
demarcation of these two categories.
Nathanael Nerode
>> Not quite. I *do* think Debian should remove the GPL's
>> Invariant-but-removable Preamble, distributing only the legal text.
>> The FSF says
>> <http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble>, but since
>> the requirement for future distribution is only "under the terms of
>> the GPL," Debian could distribute the "Debian GPL" containing only the
>> legal terms, and without the invariant Preamble.
John Goerzen wrote:
>Nope, that doesn't fly; almost all copyright statements using the GPL
>say "under the terms of the GNU General Public License as published by
>the Free Software Foundation". The GPLOmitPreamble citation says that
>the preamble may not be omitted, which is consistent with the text in
>the GPL itself. Therefore, we can't substitute the preamble-less
>"Debian GPL" alternative license.
OK, I see the argument here.
Take a work specified to be usable "under the terms of
the GNU General Public License as published by the Free Software
Foundation". The preamble is *not* one of the terms (Brian T. Sniffen's
point). Then we can distribute it under the *terms* of the
GPL, and the license we distribute it under can consist solely of the
*terms* of the GPL. However, the *terms*, specifically term 1, say
that you must "give any other recipients of the program a copy of this
License," where "this license" presumably refers to the GNU GPL
*including* the preamble. This means we have to distribute the GPL with
preamble.
John Goerzen wrote:
>That still leaves us with a non-free Preamble.
OK. How about a GR saying "We will not accept anything non-free in
main, except for the preamble of the GPL. We make this exception
because we feel that the downside of excluding it (i.e. excluding all
GPLed software) far outweighs the cost of having a single short piece of
non-modifiable text in Debian. However, this should not set a
precedent; other non-modifiable text will not be admitted. We do not
want this to be the 'nose in the door' which allows an arbitrary amount
of non-modifiable text into Debian. We would certainly be happier if
the Free Software Foundation eliminated the non-modifiability of this
text."
There. I'd be satisfied. ;-)
--
I bet a lot of people would be satisfied by the following more general
statement as a GR. This seems to correspond to the viewpoint I've seen
taken about license texts.
"License texts, copyright notices, warranty disclaimers, and other
legal notices, are not a particularly desired part of any software
distribution. (Have you ever heard of a user saying "Yes, I want to
download lots of legal notices?") However, they must be distributed
with the software for legal reasons.
"We allow these specific texts to be less free than other software as
a practical decision: there is very limited value in requiring them to
be fully free software; disallowing them would prevent the distribution
of a tremendous amount of otherwise free software; and in many countries,
legal text is freely modifiable and redistributable by law, regardless
of what the authors may claim.
"This only applies to legal texts as they apply to a particular piece
of software; not to legal texts distributed for their own value as
reference works, which must be fully free."
--
Nathanael Nerode <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html
Nathanael Nerode
>Secondly, there are pending court cases right now in the U.S. alleging
>copyright violations from legal papers filed in court cases.
shot out of hand. ;-)
If they actually win, Debian *will* have to be *very* strict about
licensing on licenses.
>I don't see anybody forcing us to ship the GPL on our hard disks. I
>do see us required to put it there *if we distribute GPL'd software*.
>But that's the rub, isn't it? We're only required to distribute those
>invariant sections if we distribute the manual. So we're back to
>removing the GPL by the same argument that removes FDL documents.
Well, there's always my favorite difference: The GPL is one piece of
text. FDL'ed invariant sections are an arbitrary number of pieces of
arbitrary text. (This could be called the 'de minimus' argument.) I
have stated previously that I would have been happy if RMS had imposed
the current conditions on the GCC and GNU Emacs manuals, without
promoting the use of similar conditions for everyone. :-P
This also partly explains why the status of the GNU Emacs manual was
previously accepted and is not anymore. Previously, it was a one-off
special case; now it is part of a herd (hurd?) of unmodifiable
material being pushed, perversely, by the FSF. I have nothing against
special exceptions when they're appropriate, but I do have something
against general exceptions.
How about runnning up a GR to amend the Debian Social Contract to
explicitly allow the GPL? ;-) I bet it would pass. Then anyone who
wants to allow a GFDL'ed document in knows the process; propose an
amendment to the Social Contract, and see if you can get it passed. (-;
--
Nathanael Nerode <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html
Nathanael Nerode
>> Can I take this, then, as an admission that we willfully distribute
>non-free
>> software in main, and intend to continue doing so, because we
>perceive
>a
>> lack of alternatives? (In the form of, for instance, public domain
>> software)
>
>using
>the
>definition of those that would define software as any bits of data that
>we
>distribute, and thus place all bits of data we distribute, including
>RFCs
>and the GPL, under the auspices of the GPL. I do not ascribe to that
>view,
>but I'm trying to push it to its logical conclusion.
I think indeed that Debian is willfully distributing non-free software
in main.
I certainly perceive a lack of alternatives.
I would probably be OK with an amendment saying "Debian will remain
99.99999% free software". ;-) More honest, really. It would still be
better than anyone else.
An amendment saying "Debian will remain free software, except for the
prologue of the GPL, which we wish was free but isn't," would be even better.
(This would be a compromise, much like the patch-requirement clause.)
Or, to be sillier, Debian could drop the GPL from Debian proper, but
require anyone downloading any part of Debian to first download the
non-free GPL text. This could actually be done....
However, I think a lot of this is missing the point. Any bits on
a computer are software. But perhaps not all software requires
the same freedoms to be fully free. Shall I attempt to apply/adapt the
FSF's 'four freedoms' to documentation, and to licenses?
* The freedom to run the program, for any purpose
This should translate to:
* The freedom to read the documentation, for any purpose
GFDL seems OK here.
Or to:
* The freedom to apply the license, for any purpose
GPL is fine there.
* The freedom to study how the program works, and adapt it to your
needs.
This should translate to:
* The freedom to study how the documentation works, and adapt it to your
needs.
"Adapt it to your needs" is violated by the FDL "Invariant Section"
requirements. Notably, the 'embedded' and 'reference card' examples
apply (although RMS espoused a interesting theory involving "multiple
volumes").
It's also very unclear whether it's satsified by embedding the
documentation into a program. (What must you do with the Invariant Section?
What the heck is a 'front-matter section' or 'named appendix' in a
program anyway?)
It's also violated whenever Invariant Sections are inaccurate. It is
then impossible to make a fully accurate manual (which is a very
reasonable need). There is absolutely no legal way to make a derivative
of the technical text in the manual, under the GFDL, without including
the "Invariant Section".
The GFDL clause about 'not using technical measures to obstruct or
control the reading or further copying of copies you make or distribute'
is a very definite violation of this, now that I look at it.
If your needs involve putting a copy on a restricted-access location,
you can't. (The words 'make or' need to be stricken from that clause.)
Of course, you also can't adapt the technical material to use it in a
treatise on the subject of any of the Invariant Sections.
Yes, freedom 1 is definitely the one the GFDL violates big time.
This also translates to:
* The freedom to study how the license works, and adapt it to your
needs.
Yep, you can do that with the GPL. This isn't even violated if the
prologue is inaccurate, because use of the GPL's terms to create a new
license is explicitly allowed.
* The freedom to redistribute copies so you can help your neighbor
Yeah, this is fine everywhere. But oodles of non-free stuff satisfies
*this*.
* The freedom to improve the program, and release your improvements to
the public, so that the whole community benefits
This translates to:
* The freedom to improve the documentation, and release your
improvements to the public, so that the whole community benefits
Well, the GFDL sometimes allows this. But not if the improvement
involves removing inaccurate Invariant Sections and Cover Texts. Or for
that matter irrelevant Invariant Sections (which are at least
somewhat irrelevant by definition!).
This also translates to:
* The freedom to improve the license, and release your
improvements to the public, so that the whole community benefits
The GPL as a license text only partly satisfies this. Specifically, the
prologue can't be improved and released to the public. But at least
it satisfies the rest. :-/ As a *license* at least, it can be improved
and released to the public.
Incidentally, freedom 3 is one which the RFC's verbatim-only
license violates big time:
* The freedom to improve the standard, and release your
improvements to the public, so that the whole community benefits
Matthew Garrett
> On Fri, Aug 08, 2003 at 04:01:59AM +0100, Matthew Garrett wrote:
> > (Now, I'm not going to claim that there are no good reasons for
> > documentation being under licenses that wouldn't pass the DSFG - I
> > haven't really made up my mind about that. The question is, why do our
> > users not require the same rights regarding the documentation we
> > distribute as they do regarding the software we distribute?)
>
You seem to have missed my point.
> When you write a computer program, you're essentially writing a tool
> (games left aside). The purpose of a computer program is not for you to
> read it, but for you to help you performing a task, or to have fun
> playing the game.
I'd somewhat disagree (we don't distribute GNU Hello World in order to
help people perform a task or have fun), but I won't argue too much.
> The same doesn't count for things such as books, standard documents, or
> documentation; they're meant to be written, and may include the opinion
> of the person who wrote the document. That opinion deserves protection,
> whereas the same does not count for a computer program (it's hardly
> possible to state your opinion in a computer program, so protecting it
> is not really necessary).
But I disagree here, on two counts. Firstly, it plainly is possible to
state your opinion in a computer program (see the discussion about the
ReiserFS utilities' output). Secondly, so what? The issue of whether
software is deserving of certain rights has nothing to do with our
decision as to whether we redistribute that or not. We distribute
software if it provides certain freedoms to our *users*. Documentation
may be deserving of a different set of rights, but why do we believe
that our users do not require the same set of freedoms? Answers should
be in the form of practical objections.
--
Matthew Garrett | mj...@srcf.ucam.org
Brian T. Sniffen
> On Sun, Aug 03, 2003 at 05:12:55PM -0400, Nathanael Nerode wrote:
>> John Goerzen wrote:
>> > 1. Would removing the manual for Emacs, libc, or other important GNU
>> > software benefit our users?
>> Yep. I'm very unhappy with having non-free software (and software means
>> 0s and 1s -- so nearly everything Debian distributes except the
>> physical CDs) in Debian; as a user, I chose Debian at least partly for
>> the Social Contract, which this violates.
>
> That's an overly-expansive view of software. You would include anything
> that is digital in that description -- audio CDs, DVD movies, off-air TV
> signals, books on disk, etc. I find it very hard to quantify Beethoven's
> Ninth Symphony as software, even if it was recorded digitally, given that
> the invention of software postdated its composition by a LONG time -- and
> that the invention of software postdated early recordings by a long time as
> well.
Nobody is claiming Beethoven's Ninth Symphony, or the King James
Bible, to be software. Quite a few of us are claiming that this MP3
over here, beethovens_ninth.mp3, is software. So is this file bible.txt.
> I see it as fallacious reasoning to conclude that anything that is binary is
> software. If I use some sort of binary "Morse code" to send a message
> manually, why is it more of software than if I use the real Morse code?
Oh, come on. He was clearly referring to the argument that computers
are hardware which contain software. If you have the message, in
ASCII, binary morse, morse, or Urdu, on a computer, it's either
software or blocking the vents.
> I agree that this is good. But how does it promote Free Software to strip
> manuals from Free programs?
Nobody's suggested stripping manuals: merely replacing them with Free
versions, such as replacing the Emacs 21 manual with an edited Emacs 19 manual.
-Brian
--
Brian T. Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
Andrew Suffield
> Andrew Suffield wrote:
> >We have not, to date, had any difficulty in interpreting the DFSG as
> >applied to documentation, excluding the lunatic fringe who appear,
> >stick their oar in, and cease to send mail when somebody points out
> >why their argument is flawed (in every discussion, not just licensing
> >ones).
> >
> >In all the FDL debates, there has not once been a solid argument that
> >it is actually acceptable, which was not immediately rebutted. If
> >anybody thinks otherwise, they are invited to present their argument
> >*and then defend it in the face of skilled opposition*.
>
> There are two ways of viewing debate: one is that debate is a
> means of persuading others that your point is the correct one, the
> other is that debate is a means of deriving truth (or at least
> correctness).
The second is the relevant one, I would say.
> Thus it's not "lunatic" to offer what seems to be
> a plausible argument and then not continue to argue for it when a
> convincing refutation is offered.
<shrug> Sure, but we also have a few nutcases who perpetually raise
the same points in different subthreads until people get tired of
repeating the same refutations. They're responsible for much of the
perceived "debate" on -devel recently.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Andrew Suffield
> > > There is neither source code nor compiled code for my King James Bible in
> > > free-form ASCII text.
> >
> > This is an example of why they are guidelines, not rules. It is simple
> > for an intelligent person to interpret this in a sensible manner for
> > documentation.
>
> If by "interpret" you mean "ignore DFSG #2", which seems to be what happens
> in practice, OK.
It isn't.
For plain text, the "source code" is fairly obviously the text itself
- there is no binary form.
For latex or docbook sgml, the "source code" should be pretty
obvious. Likewise for manpages.
> But is that really the kind of thing you want to do? What
> would you tell me, as an author, to do to distribute something that can be
> compiled into machine code out of my plain text prose?
Distribute the plain text along with it. That seems pretty clear to me.
> > We have not, to date, had any difficulty in interpreting the DFSG as
> > applied to documentation, excluding the lunatic fringe who appear,
>
> I think that the persistence and size of this thread provides more than
> enough evidennce to debunk that claim.
So you accept the baseless noise-generation of the lunatic fringe as
evidence? Sorry, you won't get any sympathy for that perspective here.
As a general rule, the only thing that you can be sure about when a
thread is large is that there are a number of morons participating in
it. Notably, it does *not* mean that there is significant
disagreement. Making a quick scan of the archives, I can only see less
than a dozen people in recent history who have argued against the
consensus on these issues, none of who presented arguments which were
not refuted.
For both the RFCs and the FDL, numerous arguments (that were not
refuted) have been presented as to why they are non-free.
> My mind is open and I remain willing to accept that there may be someone out
> there that can come up with equitable guidelines. But I perceive a very
> real inequity in the very prominent example I keep citing in the GPL.
I said it's a FAQ, and I meant it. Somebody comes up with this one
about once every month or two. It remains bogus.
> > > Why is it OK to include the GPL in our system but not other bits of
> > > documentation?
> >
> > This is virtually a FAQ.
> >
> > Firstly, even if that statement was not present, the license would
> > still be unmodifiable and non-removable; that is the nature of
> > copyright.
>
> The license would be unmodifiable and non-removable *solely as it pertains
> to the package to which it was affixed*.
Correct, and that is the sense in which we distribute it unmodified.
> However, barring protections on
> the license itself, I could take the text of the GPL, modify it, and apply
> the modified version to my own software -- or just publish the Goerzen
> Public License version 2. (Nah, that wouldn't be confusing at all...)
>
> The copyright statement on the GPL prevents me from doing this.
>
> It seems *very* similar to the RFC problem.
This is the second point, below.
> > Secondly, there is no convincing reason to believe that this statement
> > is binding in law, because nobody has presented any evidence that
> > copyright subsists in a license _at all_. Remember, copyright is not a
> > natural thing, it was invented in the past few decades in order to
> > improve the profit margins of corporations.
>
> In U.S. law, copyright was actually codified in our *constitution* in
> section 8, clause 8. That was passed just a we bit more than a few decades
> ago.
It's Title 17 of the United States Code, passed in 1947, and
completely revised in 1976.
The stuff in the constitution is so vague as to be almost meaningless,
and certainly has no bearing on modern copyright law - which is not
intended to "promote ye the Progresse of Science and useful Arts", but
rather to profit from them (as of the 1976 revision, iirc).
> However, your argument has a lot of problems. First, that which is the case
> with U.S. law may not be the case internationally. On this list, we have
> always erred on the side of caution, assuming that the requirements in a
> license are legally enforceable. Or are you suggesting that we should
> special case the GPL?
We have only assumed that in cases where it was reasonable to believe
it was true. For example, we are presently ignoring SCO's claims.
If you want to work on the assumption that you would lose any lawsuit,
then you might as well give up and go home, because in the US you can
sue anybody for anything and have a chance of winning.
> Secondly, there are pending court cases right now in the U.S. alleging
> copyright violations from legal papers filed in court cases.
Vague, but it doesn't *sound* relevant.
> Thirdly, there is legal precedent for restrictions on the distribution of
> licenses (which are just a special case of contracts), though usually from a
> trade secret point of view.
Please provide citations. In the absence of evidence to the contrary,
I do not believe that any such cases exist which relate to
copyright. Trade secrets are an entirely different set of laws, and
cannot be used to enforce the notice at the top of the GPL (because
it's not a trade secret).
> > Thirdly, we are distributing software, not licenses. We wouldn't
> > include them at all if we didn't have to; we only accept them because
> > forces beyond our control require us to.
>
> Are you really saying that we have been violating our own Social Contract
> for years because we either lack the power to remove the GPL from our
> distribution or the will to switch to non-GPL software?
>
> I find that a rather farfetched notion.
What makes you think this is specific to the GPL? It applies to all
licenses.
> I don't see anybody forcing us to ship the GPL on our hard disks. I do see
> us required to put it there *if we distribute GPL'd software*. But that's
> the rub, isn't it? We're only required to distribute those invariant
> sections if we distribute the manual. So we're back to removing the GPL by
> the same argument that removes FDL documents.
This argument is flawed.
In the case of FDL documents, we are able to create free documents to
replace them which are placed under free licenses.
In the case of copyright law, we have no power to create copyright
laws which satisfy our notion of freedom. If we could, then none of
this would be necessary anyway.
John H. Robinson, IV
> On Fri, Aug 08, 2003 at 02:16:39AM +0100, Matthew Garrett wrote:
> > Sergey V. Spiridonov wrote:
> >
> > >Documentation and some other kinds of data can be used without computer.
> > >Documentation can be printed and sold as books. One does not need a
> > >computer to read a printed documentation.
> >
> > Is http://www.codon.org.uk/~mjg59/scratch/ifupdown-0.6.4/ifupdown.nw
> > software or documentation?
>
> I was waiting for that to come up. I would say it's both, and that it must
> pass the DFSG and any documentation guidelines we care to draft.
s/software/a program/
i would say neither. ifupdown.nw is a data file that will produce
documentation when fed to the appropriate program.
all electronic data files, all electronic programs, and all electronic
documentation fit into the classification of software. think back to
venn diagrams.
documentation, data, and programs all intersect each other; similar to
the three colour circles in this image:
http://home.att.net/~RTRUSCIO/images/ADDHUE1.JPG
surrounding those three is another venn circle that comprises software.
we can even intersect software and hardware, and call that firmware.
unless you can convince me that electronic bits are somehow not
software, you are going to have a very hard time convincing me that
electronic documentation is not software. i will agree that programs are
not documentation. i will agree that data is not documentation.
-john
Joe Moore
> "Adapt it to your needs" is violated by the FDL "Invariant Section"
> requirements. Notably, the 'embedded' and 'reference card' examples
> apply (although RMS espoused a interesting theory involving "multiple
> volumes").
A (IMHO) stronger example would be creating a "How to write Free Software
documentation with Free Software" manual, and using a chapter from the Emacs
manual.
The required invariant section of the Emacs manual is no longer secondary to
the combined work, thus the license is inconsistant.
--Joe
Dylan Thurston
> OK. How about a GR saying "We will not accept anything non-free in
>...
> I bet a lot of people would be satisfied by the following more general
> statement as a GR. This seems to correspond to the viewpoint I've seen
> taken about license texts.
>
> "License texts, copyright notices, warranty disclaimers, and other
> legal notices, are not a particularly desired part of any software
Is the Preamble to the GPL a legal notice?
Peace,
Dylan
Fedor Zuev
JG>Documentation consists of instructions primarily intended to be
JG>human-readable regarding the operation of something such as a program.
JG>Programs consist of instructions primarily intended to be machine-readable
JG>that either contain machine language binary data or instructions designed to
JG>be interpreted or converted into that at runtime. Programs will always
JG>contain source code or machine language code, and often both.
Hmmm.
My suggestion:
Software "is a set of statements" primarily intended to
perform some operations on the some set of input information "in
order to bring about a certain result" with this information.
Regardless of the way it does so.
Data "is a set of statements" primarily intended to describe
itself (as such) to a reader, be latter the human or the program.
Regardless of the way it does so.
Data primarily intended to describe itself to human reader
is a documentation.
Wouter Verhelst
> On Fri, Aug 08, 2003 at 09:44:54AM +0200, Wouter Verhelst wrote:
>
> > What any sensible person would do in such a situation would be to go
> > through the trouble of writing and submitting a new RFC which is
> > distributed alongside the program, rather than modifying RFC2822 (or
> > rather 2821, which defines SMTP) and distributing that modified version.
>
> (did you mean to reply to me privately?)
No, sorry. Assuming you didn't either:
> What if the IETF don't want to publish it?
Well, that's their right, although it's very unlikely the IETF would
not want to publish anything related to network standards. Even if they
wouldn't, you could write something that references the original RFC,
and distribute that original RFC along with your other document.
As you would do would you write a new RFC.
You'd never modify RFC2822's contents, and distribute that *as* RFC2822,
would you?
> What if my modification is a
> joke? (Parody is protected in certain parts of the world, but not
> universally)
In that case, you probably wouldn't be modifying it, you'd be writing a
new document. If that weren't the case, (i.e., you'd be modifying just
one sentence in a joking manner), you'd deserve to be shot for confusing
people all over the place.
--
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts."
-- National Geographic Channel, in a documentary about large African beasts.
Matthew Garrett
>On Fri, Aug 08, 2003 at 12:25:49PM +0100, Matthew Garrett wrote:
>> What if the IETF don't want to publish it?
>
>Well, that's their right, although it's very unlikely the IETF would
>not want to publish anything related to network standards. Even if they
>wouldn't, you could write something that references the original RFC,
>and distribute that original RFC along with your other document.
And I could provide a patch file to a piece of non-Free software. Why
should we accept a lower class of freedom for documentation?
>You'd never modify RFC2822's contents, and distribute that *as* RFC2822,
>would you?
It's not what I'm proposing, no.
>> What if my modification is a=20
>> joke? (Parody is protected in certain parts of the world, but not=20
>> universally)
>
>In that case, you probably wouldn't be modifying it, you'd be writing a
>new document. If that weren't the case, (i.e., you'd be modifying just
>one sentence in a joking manner), you'd deserve to be shot for confusing
>people all over the place.
I want to modify RFC2822 (and probably 2821) to describe a protocol and
message format for controlling a washing machine. Plainly, this is
unlikely to be a serious proposal and the IETF are unlikely to want to
publish it (except possibly as an April 1st joke, which is some distance
away). The license that the RFCs are under prevents me from doing that.
I work on Dasher, a predictive text entry application. People are free
to modify the corpus used to generate the predictions by, say, including
large quantities of racist text. They can then distribute this,
potentially giving the impression that I hold opinions other than those
I do. This is obviously less than ideal, but removing that possibility
would result in the software being non-Free. A modified Debian could
contain a white-supremacist message in /etc/motd. Again, we allow that
because to not do so would compromise what we see as necessary freedoms.
Why should we not hold documentation to the same standard?
--
Matthew Garrett | mjg59-chiark.ma...@srcf.ucam.org