A possible GFDL compromise
John Goerzen
sections, which may not be removed or altered (save for some very
inconsequential exceptions.) One thing about the invariant sections is that
the GFDL specifically states that they "contain nothing that could fall
directly within the overall subject." They have thus typically been used to
hold philosophical documents, licenses, etc.
I suggest that even if the GFDL did not allow modification of the invariant
sections, if it at least allowed removal of them, we would be in much better
shape. It would, for instance, allow people to better take the manual from
program A and adapt it for program B, even if they disagreed with the GNU
Manifesto or used a different license for program B.
In the case of a manual that includes invariant sections, we could then
throw just the invariant section into non-free, keeping the balance of the
manual in main. (Or perhaps just delete the invariant sections entirely.)
What do people here think about that, and is there any indication if the FSF
would be amenable to this change?
-- John
--
To UNSUBSCRIBE, email to debian-leg...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David B Harris
John Goerzen <jgoe...@complete.org> wrote:
> I suggest that even if the GFDL did not allow modification of the invariant
> sections, if it at least allowed removal of them, we would be in much better
> shape. It would, for instance, allow people to better take the manual from
> program A and adapt it for program B, even if they disagreed with the GNU
> Manifesto or used a different license for program B.
Certainly, allowing removal of Invariant sections would be adequate for
Debian's uses. At least, if we could remove portions of them - one
could put the copyright notice in an Invariant section and also spend 30
pages discussing the quality of one's navel lint. If we couldn't remove
the crap about navel lint because we can't remove the copyright notice
(keeping in mind they're both in the same Invariant section), there are
problems :) If we could though, that'd be fine - all GFDL-licensed
documents in Debian would have their Invariant sections stripped because
people can't modify them, but at least the docs could go in :)
Assuming we were allowed to distribute them, anwyays. See below.
> In the case of a manual that includes invariant sections, we could then
> throw just the invariant section into non-free, keeping the balance of the
> manual in main. (Or perhaps just delete the invariant sections entirely.)
>
> What do people here think about that, and is there any indication if the FSF
> would be amenable to this change?
I don't think it's enough. Clause 2 of the GFDL (and a few similar
points elsewhere) are even more insidious than Invariant sections (in
my opinion). People who distribute GFDL'd documents on a CD (for
instance) should be very careful and be prepared to provide the
copyright holder with a computer with a CD reader, and electricity to
run it. And you better hope that no judge feels that the layout on the
CD (or the format of the archive the document may be in, if any) is
"obscure" :)
That being said, at least RMS has gone on record here on -legal stating
that he has very strong feelings about Invariant sections and thinks
they're entirely acceptable. So I doubt the FSF is amenable to the
change(s).
Andrew Suffield
> One of the main sticking points with the GFDL is the use of invariant
> sections, which may not be removed or altered (save for some very
> inconsequential exceptions.) One thing about the invariant sections is that
> the GFDL specifically states that they "contain nothing that could fall
> directly within the overall subject." They have thus typically been used to
> hold philosophical documents, licenses, etc.
>
> I suggest that even if the GFDL did not allow modification of the invariant
> sections, if it at least allowed removal of them, we would be in much better
> shape. It would, for instance, allow people to better take the manual from
> program A and adapt it for program B, even if they disagreed with the GNU
> Manifesto or used a different license for program B.
>
> In the case of a manual that includes invariant sections, we could then
> throw just the invariant section into non-free, keeping the balance of the
> manual in main. (Or perhaps just delete the invariant sections entirely.)
We'd probably go with this one, which is why the FSF won't buy into
this: they want their documents to force certain pieces of their
propaganda upon all distributors. They'll phrase it differently, but
that is fundamentally what they are trying to accomplish.
In short, the FSF wants non-free documentation. There's nothing
intrinsically wrong with that, it's just no use to us. We want free
documentation instead. I predict that within a few years, free
documentation will be produced (possibly even by the people who wrote
it for the FSF originally) and the FSF will cease to be relevant on
this issue.
Other than that, you have successfully managed to approximate the
position from which we *started* the GFDL debate, presumably without
actually bothering to research it.
Plus, invariant sections are just one of many issues that have been
raised with the GFDL. Replacing one non-free license with another
which is less non-free, but still non-free, is not useful to us.
As for compromises: no. Free or fuck off.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Mark Rafn
> One of the main sticking points with the GFDL is the use of invariant
> sections
But not the only sticking point, I'm afraid.
> I suggest that even if the GFDL did not allow modification of the invariant
> sections, if it at least allowed removal of them, we would be in much better
> shape.
Vastly better shape. I still believe the other problems with the GFDL
would render it non-free, but at least it wouldn't be as bizarrely
contrary to what I thought the FSF stood for.
> What do people here think about that, and is there any indication if the FSF
> would be amenable to this change?
Aside from one secondhand comment on this list, I've seen no indication
that the FSF is amenable to any discussion of possible changes.
--
Mark Rafn da...@dagon.net <http://www.dagon.net/>
MJ Ray
wrote:
[delete invariants]
> What do people here think about that, and is there any indication if
> the FSF
> would be amenable to this change?
I haven't seen anything to make me think that they would be, but ICBW.
It seems to strike at one of their reasons for having unremovable
unfixable sections, which is to allow advertising (or, in other words,
writing on the relationship of the publisher to the work) and make the
licence more acceptable to old-fashioned publishers.
--
MJR/slef My Opinion Only and possibly not of any group I know.
Brian T. Sniffen
problems which affect only some GFDL documents. but I don't think it
addresses the problems which affect all GFDL documents: the
requirements for transparent formats, and the "anti-DMCA" clause (the
ban on technical access control measures). It also doesn't
well-address the problems with the difficulty of properly applying the
license: what happens when someone says a non-secondary section is
invariant, for example?
A few weeks ago, on a Friday, you said that you'd take the weekend to
think about it and try to propose a set of Debian Free Documentation
Guidelines on Monday. I'd be interested to see the output of that
thought process: since I haven't seed a Goerzen FDG, I'd like to know
why you didn't come up with one, and what complexities made it hard --
or did you just come up with a rephrasing of the DFSG?
-Brian
--
Brian T. Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
John Goerzen
> That's an interesting compromise you propose, and it would solve the
> problems which affect only some GFDL documents. but I don't think it
I'm well aware of that.
> addresses the problems which affect all GFDL documents: the
> requirements for transparent formats, and the "anti-DMCA" clause (the
> ban on technical access control measures). It also doesn't
That doesn't seem to me to be any more non-free than the GPL requiring
people that distribute binaries also distribute soures.
> well-address the problems with the difficulty of properly applying the
> license: what happens when someone says a non-secondary section is
> invariant, for example?
That is indeed a problem, and we'd probably have to err on the side of
caution and consider it invariant.
> A few weeks ago, on a Friday, you said that you'd take the weekend to
> think about it and try to propose a set of Debian Free Documentation
> Guidelines on Monday. I'd be interested to see the output of that
> thought process: since I haven't seed a Goerzen FDG, I'd like to know
> why you didn't come up with one, and what complexities made it hard --
> or did you just come up with a rephrasing of the DFSG?
I didn't post it yet because I'm not yet sure in my own mind what the right
guidelines are. Despite the assertions of some, I do not think that just
accepting GFDL 100% is the right thing to do here.
I see the following scenarios:
1. I'm a Free Software user. I am using Emacs, a large Free system that
requires documentation to learn by any means. But that documentation is
missing or obsolete because of GFDL. I cannot make use of this Free
package.
2. I'm a Free Software developer and want to make a derivative program, but
can't because it requires documentation, and I disagree with the GNU
manifesto and can't adapt it, and don't have the time to rewrite the manual
from scratch.
As a developer myself, and a believer in the principles of the free software
movement, I'm inclined to conclude that #2 is the larger problem in the long
run. I wasn't necessarily so inclined two weeks ago.
Regardless, I still maintain that documentation is not software and does
need separate guidelines.
-- John
Jamin W. Collins
> On Fri, Aug 22, 2003 at 01:41:55PM -0400, Brian T. Sniffen wrote:
> >
> > addresses the problems which affect all GFDL documents: the
> > requirements for transparent formats, and the "anti-DMCA" clause (the
> > ban on technical access control measures). It also doesn't
>
> That doesn't seem to me to be any more non-free than the GPL requiring
> people that distribute binaries also distribute soures.
Nothing in the GPL indicates (at least TMK) that I can not provide the
sources via some access control measure.
--
Jamin W. Collins
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
Andrew Suffield
> requires documentation to learn by any means. But that documentation is
> missing or obsolete because of GFDL. I cannot make use of this Free
> package.
This is easily mutable into:
1. I'm a Free Software user. I am using Debian, a large Free system
that requires web access by any means. But that access is missing or
obsolete because netscape is non-free. [Fill in the rest yourself]
We rejected it then, and I fully expect we'll do the same now.
Furthermore, note this:
Netscape was replaced by free browsers. The same thing will happen to
the emacs manual.
[Besides, I've read the emacs manual, and it sucks. I have to look at
the bloody source code more often than the manual, to figure out what
something does or why. This is not the hallmark of a good manual].
David B Harris
John Goerzen <jgoe...@complete.org> wrote:
> > addresses the problems which affect all GFDL documents: the
> > requirements for transparent formats, and the "anti-DMCA" clause (the
> > ban on technical access control measures). It also doesn't
>
> That doesn't seem to me to be any more non-free than the GPL requiring
> people that distribute binaries also distribute soures.
The GPL is not worded in such a way that can realistically open
distributors up to lawsuits. The GFDL is. It is very vague, and anything
that may be classified as a "technical measure to obstruct or control
the reading or further copying of the copies you make or distribute" can
be argued in court as a license violation.
It wouldn't surprise me in the least if there were many judges who would
say that putting the document in a directory that's readable only by
yourself (or storing it on an encrypted volume, for instance) is a
violation of the license. Certainly copying it by transmitting it over
SSL is a violation of the license, no doubts about that. SSL is
explicitly designed and used to restrict who has access to the data (the
server and the recipient only, generally speaking), and as such would
certainly be described as a technical measure intended to obstruct the
copying of the document.
Less likely, though I certainly wouldn't say it's impossible, is a judge
ruling that without providing electricity, a working computer with a CD
reader, and a technician to operate it and read the words aloud,
distributing the documentation on a standard ISO9660 CD is in violation
of the license.
(Yes, the above is a deliberately silly example. It's obsurd. If a judge
did maintain that position, we would all think the judge is nuts. But
there are judges that are nuts when it comes to technology - a LOT of
them. The example is meant to show a flaw in the GFDL.)
> > well-address the problems with the difficulty of properly applying the
> > license: what happens when someone says a non-secondary section is
> > invariant, for example?
>
> That is indeed a problem, and we'd probably have to err on the side of
> caution and consider it invariant.
If the license used is the GFDL, and somebody marks a non-secondary
section as Invariant, you either don't distribute the documentation or
you go to court to clarify the issue. The documentation would be
licensing inconsistent, and you may or may not be able to distribute
it. Go to court, to not pass GO, do not collect $200.
Brian T. Sniffen
> Less likely, though I certainly wouldn't say it's impossible, is a judge
> ruling that without providing electricity, a working computer with a CD
> reader, and a technician to operate it and read the words aloud,
> distributing the documentation on a standard ISO9660 CD is in violation
> of the license.
>
> (Yes, the above is a deliberately silly example. It's obsurd. If a judge
> did maintain that position, we would all think the judge is nuts. But
> there are judges that are nuts when it comes to technology - a LOT of
> them. The example is meant to show a flaw in the GFDL.)
Actually, isn't there a complicated set of trademark and patent claims
preventing manufacture of a CD reader without paying money to Phillips
and some trade organizations? This may not be that ridiculous.
-Brian
--
Brian T. Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
John Goerzen
> > > addresses the problems which affect all GFDL documents: the
> > > requirements for transparent formats, and the "anti-DMCA" clause (the
> > > ban on technical access control measures). It also doesn't
> >
> > That doesn't seem to me to be any more non-free than the GPL requiring
> > people that distribute binaries also distribute soures.
>
> Nothing in the GPL indicates (at least TMK) that I can not provide the
> sources via some access control measure.
But you cannot make it such that the people that receive sources from you
are prevented from copying them. GFDL seems to be doing the same to me.
David B Harris
b...@alum.mit.edu (Brian T. Sniffen) wrote:
> David B Harris <da...@eelf.ddts.net> writes:
> > Less likely, though I certainly wouldn't say it's impossible, is a judge
> > ruling that without providing electricity, a working computer with a CD
> > reader, and a technician to operate it and read the words aloud,
> > distributing the documentation on a standard ISO9660 CD is in violation
> > of the license.
> >
> > (Yes, the above is a deliberately silly example. It's obsurd. If a judge
> > did maintain that position, we would all think the judge is nuts. But
> > there are judges that are nuts when it comes to technology - a LOT of
> > them. The example is meant to show a flaw in the GFDL.)
>
> Actually, isn't there a complicated set of trademark and patent claims
> preventing manufacture of a CD reader without paying money to Phillips
> and some trade organizations? This may not be that ridiculous.
(s/obsurd/absurd/, BTW :)
You mean if Phillips is the distributor? That's certainly what the
clause in the GFDL is supposed to prevent (people making proprietary
formats, charging for access to them or their decoders, then releasing
GFDL'd documentation under that format), so perhaps.
I don't know the details about the CD market though :)
Branden Robinson
> sections, which may not be removed or altered (save for some very
> inconsequential exceptions.)
> What do people here think about that, and is there any indication if the FSF
> would be amenable to this change?
This is far from the only objection that this list has come up with
with respect to the GNU FDL, though it was almost the only one we were
publicly discussing about 2 years ago.
Please catch up on the archives of this list for the past year or so.
--
G. Branden Robinson | Of two competing theories or
Debian GNU/Linux | explanations, all other things
bra...@debian.org | being equal, the simpler one is to
http://people.debian.org/~branden/ | be preferred. -- Occam's Razor
Branden Robinson
> sections, if it at least allowed removal of them, we would be in much better
> shape. It would, for instance, allow people to better take the manual from
> program A and adapt it for program B, even if they disagreed with the GNU
> Manifesto or used a different license for program B.
Oh yeah, I forgot to mention:
RMS has repeatedly and explicitly rejected such an alteration of the GNU
FDL's terms. Please review his mails to this list over the past 2
years.
--
G. Branden Robinson | If you make people think they're
Debian GNU/Linux | thinking, they'll love you; but if
bra...@debian.org | you really make them think, they'll
http://people.debian.org/~branden/ | hate you.
Henning Makholm
> On Fri, Aug 22, 2003 at 01:41:55PM -0400, Brian T. Sniffen wrote:
> > addresses the problems which affect all GFDL documents: the
> > requirements for transparent formats, and the "anti-DMCA" clause (the
> > ban on technical access control measures). It also doesn't
> That doesn't seem to me to be any more non-free than the GPL requiring
> people that distribute binaries also distribute soures.
It fails the dissident test. The dissidents would not be able to
exchange copies of the covered work in encrypted emails (which they
might have every reason to want to, if the work contains information
that the secret police does not want people to know).
--
Henning Makholm "In my opinion, this child don't
need to have his head shrunk at all."
Joe Wreschnig
> On Fri, Aug 22, 2003 at 01:27:53PM -0600, Jamin W. Collins wrote:
> > > > addresses the problems which affect all GFDL documents: the
> > > > requirements for transparent formats, and the "anti-DMCA" clause (the
> > > > ban on technical access control measures). It also doesn't
> > >
> > > That doesn't seem to me to be any more non-free than the GPL requiring
> > > people that distribute binaries also distribute soures.
> >
> > Nothing in the GPL indicates (at least TMK) that I can not provide the
> > sources via some access control measure.
>
> But you cannot make it such that the people that receive sources from you
> are prevented from copying them. GFDL seems to be doing the same to me.
But it does it in a way that makes it useless in some cases (encrypted
filesystems) and a pain in the ass in others (if you wrote it in MS Word
form, you'd have to distribute it as one of the "open formats" MS Word
supports, which are HTML and plain text - both of which are lossy
conversions from the *real* source).
The GPL says you have to distribute the source, which is your preferred
format for modification. The GFDL says you have to distribute the
source, and that the source has to be in the *FSF's* preferred form for
modification.
--
Joe Wreschnig <pi...@debian.org>
Brian T. Sniffen
No. There's a consortium of companies, led by Phillips, which hold
the trademarks on CDDA, CD-ROM, CD-R, "Compact Disc", and a pool of
patents applicable to making compact discs and the devices to
manipulate them. I can't just burn a disc and sell it with the CDDA
logo on the side, nor can I make a machine which plays CDs and sell it
as a CD player. Or rather, if I do, Phillips and the CD Consortium
will sue me.
-Brian
Sergey V. Spiridonov
> I suggest that even if the GFDL did not allow modification of the invariant
> sections, if it at least allowed removal of them, we would be in much better
This make no sence. It is the same as not to have invariant sections at
all.
--
Best regards, Sergey Spiridonov
John Goerzen
> > That doesn't seem to me to be any more non-free than the GPL requiring
> > people that distribute binaries also distribute soures.
>
> It fails the dissident test. The dissidents would not be able to
> exchange copies of the covered work in encrypted emails (which they
> might have every reason to want to, if the work contains information
> that the secret police does not want people to know).
Hmm, good point. I think I at some point got in my mind what I thought they
were trying to do, and confused it with what they actually do.
John Goerzen
> On Fri, Aug 22, 2003 at 10:14:31AM -0500, John Goerzen wrote:
> This is far from the only objection that this list has come up with
> with respect to the GNU FDL, though it was almost the only one we were
> publicly discussing about 2 years ago.
I am well aware of that.
> Please catch up on the archives of this list for the past year or so.
Which is unfortunately not, to me, a very helpful suggestion, as I do not
have the days or weeks to spare to do that. Perhaps you could summarize the
main points?
John Goerzen
> John Goerzen wrote:
>
> >I suggest that even if the GFDL did not allow modification of the invariant
> >sections, if it at least allowed removal of them, we would be in much
> >better
>
> This make no sence. It is the same as not to have invariant sections at
> all.
That is the point. What makes no sense about it?
Nathanael Nerode
> One of the main sticking points with the GFDL is the use of invariant
> sections, which may not be removed or altered (save for some very
> the GFDL specifically states that they "contain nothing that could fall
> directly within the overall subject." They have thus typically been used to
> hold philosophical documents, licenses, etc.
>
> sections, if it at least allowed removal of them, we would be in much better
> program A and adapt it for program B, even if they disagreed with the GNU
> Manifesto or used a different license for program B.
>
> throw just the invariant section into non-free, keeping the balance of the
> manual in main. (Or perhaps just delete the invariant sections entirely.)
>
> would be amenable to this change?
first thing I spotted as obviously non-free, and the most repugnant.
However, non-removabability was essential to RMS's original motivation
behind the Invariant Sections. He wanted everyone who distributes an
Emacs manual to be forced to distribute the GNU Manifesto with it. So
getting the FSF to accept this change will probably be about as easy as
getting them to abandon Invariant Sections entirely.
--Nathanael
Sergey V. Spiridonov
>>This make no sence. It is the same as not to have invariant sections at
>>all.
>
> That is the point. What makes no sense about it?
It is the same as allowing to modify invariant section. One can remove
existing invariant secion and insert his own.
BTW, I understand, FDL with invariant section infringements freedoms of
the distributor, as Debian. Distributor is the last instance where the
software package can be modified before it will be delivered to user.
Distributor have more control of the package contents in this case. So
FDL shifts control over specific parts of the documentation to software
author.
--
Best regards, Sergey Spiridonov
Richard Stallman
the GNU Manifesto an invariant section in the Emacs Manual, was to
make sure they could not be removed. Specifically, to make sure that
distributors of Emacs that also distribute non-free software could not
remove the statements of our philosophy, which they might think of
doing because those statements criticize their actions.
Changing the GFDL to permit removal of these sections
would defeat the purpose.
Nowadays we have to struggle constantly against the tendency to bury
the free software movement and pretend that we advocate "open source".
So I don't think we can conclude that such precautions are no longer
necessary.
Wouter Verhelst
> The goal of invariant sections, ever since the 80s when we first made
> the GNU Manifesto an invariant section in the Emacs Manual, was to
> make sure they could not be removed. Specifically, to make sure that
> distributors of Emacs that also distribute non-free software could not
> remove the statements of our philosophy, which they might think of
> doing because those statements criticize their actions.
>
> Changing the GFDL to permit removal of these sections
> would defeat the purpose.
At a cost. While I understand the desire for the invariant sections, it
can be wondered what freedom is most desirable: the freedom to run,
study, redistribute and improve for everyone, or the freedom to run,
study, redistribute and improve for only those that agree with your
philosophy, and will not remove it from any accompanying documentation.
If people disagree with what you say, you should not prohibit them from
doing so. You're still a well-known person who can reasonably assume
that what you write or say will not go unnoticed. Even if it's removed
from one distribution of a manual.
> Nowadays we have to struggle constantly against the tendency to bury
> the free software movement and pretend that we advocate "open source".
Is a manual the right place for advocacy? Isn't the purpose of a manual
to document a piece of software?
--
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
-- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Joe Wreschnig
> The goal of invariant sections, ever since the 80s when we first made
> the GNU Manifesto an invariant section in the Emacs Manual, was to
> make sure they could not be removed. Specifically, to make sure that
> distributors of Emacs that also distribute non-free software could not
> remove the statements of our philosophy, which they might think of
> doing because those statements criticize their actions.
>
> Changing the GFDL to permit removal of these sections
> would defeat the purpose.
Richard,
Several Debian developers have claimed that they are working with the
FSF to make the GFDL DFSG-free and GPL-compatible, specifically:
Anthony Towns wrote:
> In short, some members of the FSF have asked for us to give them some
> more time to come up with a GFDL that's DFSG-free before we go all
> gung-ho about putting it in non-free and having bigger controversies.
> Martin (wearing his DPL hat) talked to me about this at debcamp.
and also,
On Sun, 2003-08-24 at 09:10, Jérôme Marant wrote:
> One thing we are sure about, is that, according to RMS, FSF is aware
> of the GPL compatibility problem and is going to work this out, as soon
> as it gets enough manpower.
Since I see no way to reconcile GPL-compatibility and maintaining the
invariance of invariant sections, should I believe this is not the case
(and possibly never was)?
--
Joe Wreschnig <pi...@debian.org>
Andrew Suffield
consensus as I perceive it; there are always dissenters in Debian on
any issue]
On Sat, Aug 23, 2003 at 08:09:53PM -0400, Richard Stallman wrote:
> The goal of invariant sections, ever since the 80s when we first made
> the GNU Manifesto an invariant section in the Emacs Manual, was to
> make sure they could not be removed. Specifically, to make sure that
> distributors of Emacs that also distribute non-free software could not
> remove the statements of our philosophy, which they might think of
> doing because those statements criticize their actions.
>
> Changing the GFDL to permit removal of these sections
> would defeat the purpose.
I believe we are all quite aware of this. Much like people who
distribute proprietary software, you are willing to trade certain
freedoms[0] for something which is of value to you[1].
It is not of value to us, and we are not willing to trade our freedom
for it.
Ironically, this is having the opposite effect to that which you had
originally desired. Because these sections have been made invariant
and non-removable, we now want to remove them (even if that means
removing the entire manual). If they were not, then we would almost
certainly be content to let them stay.
[0] To modify the work for any purpose
[1] The forced inclusion of GNU propaganda
Fedor Zuev
>At a cost. While I understand the desire for the invariant
>sections, it can be wondered what freedom is most desirable: the
>freedom to run, study, redistribute and improve for everyone, or
>the freedom to run, study, redistribute and improve for only those
>that agree with your philosophy, and will not remove it from any
>accompanying documentation.
>If people disagree with what you say, you should not prohibit them
>from doing so. You're still a well-known person who can reasonably
>assume that what you write or say will not go unnoticed. Even if
>it's removed from one distribution of a manual.
I cannot see any connection between disagreement with anyone
opinion, and the right to censor somebody else's opinion, so
angrily demanded by you.
But, since these demands and these sophisms repeated only on
this list only in the last several days several times already, I
should conclude, that FSF was completely right, when included
counter-censorship measures in its license.
Josselin Mouette
> >If people disagree with what you say, you should not prohibit them
> >from doing so. You're still a well-known person who can reasonably
> >assume that what you write or say will not go unnoticed. Even if
> >it's removed from one distribution of a manual.
>
> I cannot see any connection between disagreement with anyone
> opinion, and the right to censor somebody else's opinion, so
> angrily demanded by you.
>
> But, since these demands and these sophisms repeated only on
> this list only in the last several days several times already, I
> should conclude, that FSF was completely right, when included
> counter-censorship measures in its license.
Can't you understand nobody would ask for removing these sections if
they were as free as the FSF would like to call them ?
OH MY GOD, WE DON'T INCLUDE ACROBAT IN DEBIAN MAIN, THIS IS
*CENSORSHIP*, WE HAVE NO RIGHT TO EXCLUDE IT FROM DISTRIBUTION!
--
.''`. Josselin Mouette /\./\
: :' : josselin...@ens-lyon.org
`. `' jo...@debian.org
`- Debian GNU/Linux -- The power of freedom
Joe Wreschnig
> On Sun, 24 Aug 2003, Wouter Verhelst wrote:
>
> >At a cost. While I understand the desire for the invariant
> >sections, it can be wondered what freedom is most desirable: the
> >freedom to run, study, redistribute and improve for everyone, or
> >the freedom to run, study, redistribute and improve for only those
> >that agree with your philosophy, and will not remove it from any
> >accompanying documentation.
>
> >If people disagree with what you say, you should not prohibit them
> >from doing so. You're still a well-known person who can reasonably
> >assume that what you write or say will not go unnoticed. Even if
> >it's removed from one distribution of a manual.
>
> I cannot see any connection between disagreement with anyone
> opinion, and the right to censor somebody else's opinion, so
> angrily demanded by you.
>
> But, since these demands and these sophisms repeated only on
> this list only in the last several days several times already, I
> should conclude, that FSF was completely right, when included
> counter-censorship measures in its license.
Thankfully I don't know anyone else advocating the GFDL who holds an
opinion this stupid. Also thankfully, you've hopefully guaranteed that
no one else involved in any side of this debate will take you seriously.
--
Joe Wreschnig <pi...@debian.org>
Branden Robinson
> Aside from one secondhand comment on this list,
...which was itself hearsay...
> I've seen no indication that the FSF is amenable to any discussion of
> possible changes.
--
G. Branden Robinson | To stay young requires unceasing
Debian GNU/Linux | cultivation of the ability to
bra...@debian.org | unlearn old falsehoods.
http://people.debian.org/~branden/ | -- Robert Heinlein
Josselin Mouette
> BTW, I understand, FDL with invariant section infringements freedoms of
> the distributor, as Debian. Distributor is the last instance where the
> software package can be modified before it will be delivered to user.
> Distributor have more control of the package contents in this case. So
> FDL shifts control over specific parts of the documentation to software
> author.
Do you realize you are reasoning just like the proprietary software
folks the FDL is supposedly meant to fight ?
Branden Robinson
> Other than that, you have successfully managed to approximate the
> position from which we *started* the GFDL debate, presumably without
> actually bothering to research it.
In case anyone reading this doubts Andrew's words, I invite them to
check out:
http://lists.debian.org/debian-legal/2001/debian-legal-200111/msg00006.html
...and read pretty much all the rest of the -legal traffic for the
succeeding month and a half.
> Plus, invariant sections are just one of many issues that have been
> raised with the GFDL. Replacing one non-free license with another
> which is less non-free, but still non-free, is not useful to us.
I will add that there was a time when we didn't clearly perceive this.
So there is some language (including quite a bit from me personally) in
the discussions from 2 years ago that presumes "GNU FDL without
Invariant Sections or Cover Texts" is DFSG-free.
That is no longer the general opinion, thanks to our attention being
drawn to the condition "You may not use technical measures to obstruct
or control the reading or further copying of the copies you make or
distribute."
If "make or" were stricken, and perhaps some clarification added to
ensure that secure transport channels between distributor and
distributee were not a problem, this particular problem might go away.
--
G. Branden Robinson | Build a fire for a man, and he'll
Debian GNU/Linux | be warm for a day. Set a man on
bra...@debian.org | fire, and he'll be warm for the
http://people.debian.org/~branden/ | rest of his life. - Terry Pratchett
Branden Robinson
> No. There's a consortium of companies, led by Phillips, which hold
> the trademarks on CDDA, CD-ROM, CD-R, "Compact Disc", and a pool of
> patents applicable to making compact discs and the devices to
> manipulate them. I can't just burn a disc and sell it with the CDDA
> logo on the side, nor can I make a machine which plays CDs and sell it
> as a CD player. Or rather, if I do, Phillips and the CD Consortium
> will sue me.
In Candada, at least, the RIAA (or its Canadian equivalent), get a piece
of the revenues from every blank CD-* medium sold.
--
G. Branden Robinson | No math genius, eh? Then perhaps
Debian GNU/Linux | you could explain to me where you
bra...@debian.org | got these... PENROSE TILES!
http://people.debian.org/~branden/ | -- Stephen R. Notley
Branden Robinson
> On Fri, Aug 22, 2003 at 11:54:15PM +0200, Henning Makholm wrote:
> > It fails the dissident test. The dissidents would not be able to
> > exchange copies of the covered work in encrypted emails (which they
> > might have every reason to want to, if the work contains information
> > that the secret police does not want people to know).
>
> Hmm, good point. I think I at some point got in my mind what I thought they
> were trying to do, and confused it with what they actually do.
Stop thinking about what the FSF is *trying* to do. Read the text of
the license as written and consider its implications.
It will not always be the FSF enforcing the terms of this license.
--
G. Branden Robinson | There is no housing shortage in
Debian GNU/Linux | Lincoln today -- just a rumor that
bra...@debian.org | is put about by people who have
http://people.debian.org/~branden/ | nowhere to live. -- G. L. Murfin
Anthony DeRobertis
>> This make no sence. It is the same as not to have invariant sections
>> at
>> all.
>
> That is the point. What makes no sense about it?
It makes no sense that the FSF would agree to it. Why else would there
put invariant sections in, in the first place?
Anthony DeRobertis
On Sunday, Aug 24, 2003, at 15:44 US/Eastern, Fedor Zuev wrote:
>
> I cannot see any connection between disagreement with anyone
> opinion, and the right to censor somebody else's opinion, so
> angrily demanded by you.
Hmmm, who here wants to put to use this new-found right (how the f---
is censorship a right? It's a power, but oh well...) of censorship to
use against Fedor Zuev? I suggest we find some Men in Black in Russia
to go rough him up a bit.
There a VERY large difference, as black from white, between me deciding
not to repeat certain portions of Mr. Zuev's post[0] and sending people
to intimidate or kill him. The former is known, at least in the free
world, as free speech; the latter as censorship.
It's pretty damn simple. There is no coercion, no intimidation; there
is no censorship. If a newspaper decides not to print your letter to
the editor, too bad, that's not censorship. If Debian decides not to
distribute your essay on perverting the language for fraudulent
arguments, thats not censorship either.
[0] Just like cutting the philosophical sections from a manual.
Branden Robinson
> On Fri, Aug 22, 2003 at 04:30:11PM -0500, Branden Robinson wrote:
> > Please catch up on the archives of this list for the past year or so.
>
> Which is unfortunately not, to me, a very helpful suggestion, as I do not
> have the days or weeks to spare to do that. Perhaps you could summarize the
> main points?
It would take far less than a day. If you have the time to keep up with
this mailing list, you can spend a few hours to read portions of the web
archives of this mailing list.
Some relevant threads include:
http://lists.debian.org/debian-legal/2001/debian-legal-200110/threads.html
# xfig-doc has license problems in examples
http://lists.debian.org/debian-legal/2001/debian-legal-200111/threads.html
# Date licenses [he meant "data", and this features an appearance by
RMS]
# The old DFSG-lemma again... [features me attempting to hammer out a
compromise with RMS]
http://lists.debian.org/debian-legal/2001/debian-legal-200112/threads.html
# GFDL is a DFSG-compliant license [by Bruce Perens, espousing a
position he no longer holds]
# existing FDL documentation won't hurt
# PROPOSED: interpretive guidelines regarding DFSG 3, modifiability,
and invariant text [the first of a two attempts by me to -- gasp --
let the FSF's GNU FDLed manuals stay in main]
# FWD: Bug#121916: analog should be in non-free
# REVISED PROPOSAL regarding DFSG 3 and 4, licenses, and modifiable
text [my second attempt; it's interesting to note who was fighting
my proposal tooth-and-nail back then and yet today insists that we
keep GNU FDLed manuals in main :)] [1]
# How about a new section "[partially free]"?
# Re: LDP in main?
# LDP licences
# Final Draft: Interpretive Guideline regarding DFSG clause 3 (the
actual "proposed" part of this describes how we actually operate as
far as I can tell, except for GNU FDLed manuals from the FSF, but
the impact statement is no longer understood to be correct)
# An attempt to narrow the issues
# A concrete proposal
# GDB manual
# [summary] Interpretive Guideline regarding DFSG clause 3
http://lists.debian.org/debian-legal/2002/debian-legal-200201/threads.html
# GDB manuals
# license requirements for a book to be in free section
http://lists.debian.org/debian-legal/2002/debian-legal-200202/threads.html
# FSF seeks comments on draft 1.2 of the FDL
# Comments on GNU FDL 1.2 Draft
# Problems in GNU FDL 1.2 Draft
http://lists.debian.org/debian-legal/2002/debian-legal-200203/threads.html
# Re: distributable but non-free documents
# I want doc-rfc in Woody! (license issues)
# Preprints/Reprints of Academic Papers in Packages
There's six months' worth to get you started. It's only the beginning,
but for whatever reason[2] we seem to be retreading the basics lately.
Note that if you wish to summarize the above threads (plus perhaps some
others that catch your fancy), your efforts would likely be valued and
appreciated.
[1] I freely admit that my proposal was always vendor-neutral; that is,
GNU FDLed works from the FSF would not be held to a different
standard than GNU FDLed works from anyone else, which is the present
status quo.
[2] Well, I okay, I can think of three reasons: Sergey Spiridonov, Fedor
Zuev, and John Goerzen.
--
G. Branden Robinson |
Debian GNU/Linux | Ab abusu ad usum non valet
bra...@debian.org | consequentia.
http://people.debian.org/~branden/ |
Branden Robinson
> the free software movement and pretend that we advocate "open source".
"Let those who fight monsters take care lest they themselves become
monsters." - Friedrich Nietzsche
Steve Langasek
> On Sun, 24 Aug 2003, Wouter Verhelst wrote:
> >At a cost. While I understand the desire for the invariant
> >sections, it can be wondered what freedom is most desirable: the
> >freedom to run, study, redistribute and improve for everyone, or
> >the freedom to run, study, redistribute and improve for only those
> >that agree with your philosophy, and will not remove it from any
> >accompanying documentation.
> >If people disagree with what you say, you should not prohibit them
> >from doing so. You're still a well-known person who can reasonably
> >assume that what you write or say will not go unnoticed. Even if
> >it's removed from one distribution of a manual.
> I cannot see any connection between disagreement with anyone
> opinion, and the right to censor somebody else's opinion, so
> angrily demanded by you.
Censoring somebody else's opinion by doing something like killfilling
them?
<plonk>
--
Steve Langasek
postmodern programmer
Nathanael Nerode
>The goal of invariant sections, ever since the 80s when we first made
>the GNU Manifesto an invariant section in the Emacs Manual, was to
>make sure they could not be removed. Specifically, to make sure that
>distributors of Emacs that also distribute non-free software could not
>remove the statements of our philosophy, which they might think of
>doing because those statements criticize their actions.
>Changing the GFDL to permit removal of these sections
>would defeat the purpose.
Removal in a *copy*. Remember that.
>Nowadays we have to struggle constantly against the tendency to bury
>the free software movement and pretend that we advocate "open source".
>So I don't think we can conclude that such precautions are no longer
>necessary.
Au contraire. In the early 80s, the only way the GNU Manifesto was available
to the general public was through distribution along with programs or
documentation.
Now, the World Wide Web exists. And the FSF has its own website. Anyone who
looks at the attribution of any FSF program or manual can probably find the
website. People who have never seen an FSF program or manual can find the
website, too. The website will always contain the GNU Manifesto, unmodified,
regardless of the actions of distributors.
In other words, what happens to the local copies simply isn't as important as
it used to be.
---
In any case, your argument for Invariant Sections applies just as well to
programs as it does to manuals!
Would you consider a hypothetical program license to be free if it allowed
'off-topic' text which must be present unmodified in source and object code
of all derived versions, and must be displayed (perhaps through a
command-line option) by every derived program? Maybe you would, in which
case you're consistent. I wouldn't.
How about a license which allowed off-topic code (say, a 'hangman' game in
the 'ls' program) which must be present unmodified in source code of all
derived versions, and must be invoked (perhaps through a command-line option)
by every derived program?
I see nothing inherently wrong with the occasional non-free manual, when it's
non-free for a good reason (like yours), but it's still non-free.
Jacobo Tarrio
> drawn to the condition "You may not use technical measures to obstruct
> or control the reading or further copying of the copies you make or
> distribute."
> If "make or" were stricken, and perhaps some clarification added to
> ensure that secure transport channels between distributor and
> distributee were not a problem, this particular problem might go away.
Or if this condition and the "transparent format" stuff were changed to say
something to the effect to "if you distribute this work in a format that
obstructs the exercise of the rights given by this license, you must provide
a way for its recipient to get a full copy of the work in a format that
doesn't obstruct the exercise of these rights".
With more legalese and other lawyer-y words, I guess :-)
--
Tarrío
(Compostela)
Joe Wreschnig
> O Domingo, 24 de Agosto de 2003 ás 16:54:53 -0500, Branden Robinson escribía:
>
> > drawn to the condition "You may not use technical measures to obstruct
> > or control the reading or further copying of the copies you make or
> > distribute."
> > If "make or" were stricken, and perhaps some clarification added to
> > ensure that secure transport channels between distributor and
> > distributee were not a problem, this particular problem might go away.
>
> Or if this condition and the "transparent format" stuff were changed to say
> something to the effect to "if you distribute this work in a format that
> obstructs the exercise of the rights given by this license, you must provide
> a way for its recipient to get a full copy of the work in a format that
> doesn't obstruct the exercise of these rights".
>
> With more legalese and other lawyer-y words, I guess :-)
How about the GPL v2? "The source code for a work means the preferred
form of the work for making modifications to it"; binary or object code
is anything that is not source. I don't see the problem in applying this
standard all software (meaning programs and documentation). LaTeX to PDF
is no different than C to ELF, and HTML in Mozilla is no different than
Ruby in /usr/bin/ruby.
All suggestions for improvements in the GFDL that I've seen, are already
present in the GPL v2. It's really a wonderful license.
The problem is that some organizations, like the FSF, seem to be
hell-bent on distributing non-free documentation to accompany their free
programs.
--
Joe Wreschnig <pi...@debian.org>
David B Harris
Branden Robinson <bra...@debian.org> wrote:
> If "make or" were stricken, and perhaps some clarification added to
> ensure that secure transport channels between distributor and
> distributee were not a problem, this particular problem might go away.
I disagree, the wording is far too vague, even with that modification.
It opens distributors up to lawsuits that may very well be lost if they
do something like, say, distribute it in an archive format which has a
new type of (very effective) compression which may be publically
documented but isn't actually implemented anywhere other than the
distributor's own software.
Jacobo Tarrio
> How about the GPL v2? "The source code for a work means the preferred
> form of the work for making modifications to it"; binary or object code
> is anything that is not source. I don't see the problem in applying this
> standard all software (meaning programs and documentation).
Well, that has already been discussed and it is apparently quite
troublesome ("if I convert a HTML file into plain text, which is the
preferred form for modification?"). My formulation doesn't have that problem:
if you can modify, translate, excerpt, etc., it's ok.
Well, it has problems of its own: I'd accept "no you cannot modify the file
it is distributed in but you can copy'n'paste into a new file and modify it"
as fulfilling the requirement, while others might not. Hey, in documents
it's the text what matters: if the text (and illustrations, possibly) is the
same, the document's file format (or physical medium) doesn't really matter,
does it? :-)
Joe Wreschnig
> O Domingo, 24 de Agosto de 2003 ás 19:36:20 -0500, Joe Wreschnig escribía:
>
> > How about the GPL v2? "The source code for a work means the preferred
> > form of the work for making modifications to it"; binary or object code
> > is anything that is not source. I don't see the problem in applying this
> > standard all software (meaning programs and documentation).
>
> Well, that has already been discussed and it is apparently quite
> troublesome ("if I convert a HTML file into plain text, which is the
> preferred form for modification?").
Whichever form you prefer to modify it in. Ask a hard one next time.
--
Joe Wreschnig <pi...@debian.org>
Branden Robinson
Okay. I don't yet have a strong feel for how easy it is to fix; I just
know it's a problem for DFSG-compliance.
--
G. Branden Robinson | A committee is a life form with six
Debian GNU/Linux | or more legs and no brain.
bra...@debian.org | -- Robert Heinlein
http://people.debian.org/~branden/ |
Sergey V. Spiridonov
> Do you realize you are reasoning just like the proprietary software
> folks the FDL is supposedly meant to fight ?
There is a basic difference between free software foundation folks and
proprietary software folks. But both try to use practical and ethical
reasoning. As Josselin Mouette said:
> Can't you understand nobody would ask for removing these sections if
> they were as free as the FSF would like to call them ?
This is a good example of the freedom, which is not used. So, why not to
take away it? GPL does similar things, it takes away the freedom of
using proprietary code with the GPL code from user. But we got something
in exchange - wide free software and documentation spreading.
I do not think Debian can safely ignore proprietary software existence,
as some people on this list do[1]. If the world would be
black-and-white, I will put FDL on the white side of the black-and-white
world, together with GPL, FSF, Debian.
While we discussing FDL, clearly non-free software is still disributed
by Debian.
[1] probably, those people profess non-resistance to evil ;)
--
Best regards, Sergey Spiridonov.
Fedor Zuev
>> drawn to the condition "You may not use technical measures to obstruct
>> or control the reading or further copying of the copies you make or
>> distribute."
>> If "make or" were stricken, and perhaps some clarification added to
>> ensure that secure transport channels between distributor and
>> distributee were not a problem, this particular problem might go away.
> Or if this condition and the "transparent format" stuff were changed to say
>something to the effect to "if you distribute this work in a format that
>obstructs the exercise of the rights given by this license, you must provide
>a way for its recipient to get a full copy of the work in a format that
>doesn't obstruct the exercise of these rights".
All these reqirements is completely miss the point, IMHO,
and, therefore, completely unneeded.
Documentation in not a software. There is no any one-way
transformation from the source to the binary. All problems with
distribution and modification of documents is a legal, not technical
problems.
At the very least, if you can read the document, you always,
technically, can OCR it. An experience shows, that, if you should
not care about legal requirements (because you has the right from
license, you OCR public domain or, simply, you do not care about a
law), it takes no more than 24-48 man\hours to completely OCR a
large 500-700pages book. And there always will bee volunteers to do
that.
So, GFDL really needed only one requrement: forbidding to
place further legal restriction on the format of derivative work.
But, BTW, I do not see how these restrictions in the current GFDL
any more restrective than similar restrictions in GPL.
Fedor Zuev
>Le dim 24/08/2003 ? 14:57, Sergey V. Spiridonov a ?crit :
>> BTW, I understand, FDL with invariant section infringements freedoms of
>> the distributor, as Debian. Distributor is the last instance where the
>> software package can be modified before it will be delivered to user.
>> Distributor have more control of the package contents in this case. So
>> FDL shifts control over specific parts of the documentation to software
>> author.
>Do you realize you are reasoning just like the proprietary software
>folks the FDL is supposedly meant to fight ?
No. Freedom of _distributor_ is not an issue for the free
software _at_ _all_. No written document says that goal of a free
software is to promote freedom of a mere distributors (besides, of
course, the freedom to distribute itself). Free software is about
the freedom of _users_ and _authors_. It is in the best interest of
users to receive unstripped version of manual. It is also in the
best interest of authors. Interest of distributor is non-issue.
Joe Wreschnig
> On Sun, 24 Aug 2003, Josselin Mouette wrote:
>
> >Le dim 24/08/2003 ? 14:57, Sergey V. Spiridonov a ?crit :
> >> BTW, I understand, FDL with invariant section infringements freedoms of
> >> the distributor, as Debian. Distributor is the last instance where the
> >> software package can be modified before it will be delivered to user.
> >> Distributor have more control of the package contents in this case. So
> >> FDL shifts control over specific parts of the documentation to software
> >> author.
>
> >Do you realize you are reasoning just like the proprietary software
> >folks the FDL is supposedly meant to fight ?
>
> No. Freedom of _distributor_ is not an issue for the free
> software _at_ _all_. No written document says that goal of a free
> software is to promote freedom of a mere distributors (besides, of
> course, the freedom to distribute itself). Free software is about
> the freedom of _users_ and _authors_.
No, free software is about freedom for *everyone*, regardless of stupid
labels *you* invent. I'm a "user", "author", and "distributor"; do I
only need 1/3rd as much freedom as a normal user? I sure hope not.
> It is in the best interest of users to receive unstripped version of
> manual.
It is also in the best interest of users to recieve a manual they can
use, modify, and distribute, like they want, provided they prevent no
one else from doing so.
> It is also in the best interest of authors.
Except the GFDL takes freedom away from authors. What it *adds* is not
freedom, but control - the original author of the document is exercising
control over all subsequent authors and users.
> Interest of distributor is non-issue.
So go start your own undistributable GNU/Linux distribution. As a
distributor, Debian doesn't consider our interest a non-issue.
Your arguments get stupider with each new message of yours I read. Let's
fix that.
*plonk*
--
Joe Wreschnig <pi...@debian.org>
Joe Wreschnig
> Josselin Mouette wrote:
>
> > Do you realize you are reasoning just like the proprietary software
> > folks the FDL is supposedly meant to fight ?
>
> There is a basic difference between free software foundation folks and
> proprietary software folks. But both try to use practical and ethical
> reasoning. As Josselin Mouette said:
>
> > Can't you understand nobody would ask for removing these sections if
> > they were as free as the FSF would like to call them ?
>
> This is a good example of the freedom, which is not used. So, why not to
> take away it?
What the hell? "Not many people are using this freedom, so let's just
take it away." Ignoring the fact that many people on this list have
proposed many reasons why the freedom to remove them *is* desirable, the
idea "I don't use my freedom so I'll get rid of it" is the second
dumbest thing I've read in 24 hours, after accusations of Debian's
"censorship" of documents.
I never used my freedom to modify /bin/du - let's take that away, too.
/bin/less hasn't been changed since January, and I remember it working
fine for 7 years before that (and I'm told before that, too); I think we
don't need freedom to modify it anymore, either.
> I do not think Debian can safely ignore proprietary software existence,
> as some people on this list do[1]. If the world would be
> black-and-white, I will put FDL on the white side of the black-and-white
> world, together with GPL, FSF, Debian.
>
> While we discussing FDL, clearly non-free software is still disributed
> by Debian.
While Debian is working hard to maintain a complete free software
operating system, clearly non-free software is being advocated by you,
and published by the Free Programs-But-Not-Documentation Foundation.
--
Joe Wreschnig <pi...@debian.org>
Don Armstrong
> Documentation in not a software. There is no any one-way
> transformation from the source to the binary.
In many cases, such as TeX source to pdf, there's a one way
transformation with loss of information. (Comments are lost, internal
reference names are lost. In fact, any information not included in the
final binary is lost. [By definition.])
In fact, it's really rare for there to be a non-trivial transformation
that doesn't loose information.
> At the very least, if you can read the document, you always,
> technically, can OCR it.
At the very least, if you can use the software, you always,
technically, can dissassemble it.
> So, GFDL really needed only one requrement: forbidding to place
> further legal restriction on the format of derivative work.
>
> But, BTW, I do not see how these restrictions in the current GFDL
> any more restrective than similar restrictions in GPL.
Your line of reasoning in these two sentences is well hidden.
Exactly what are you trying to claim in regards to the GFDL and its
relationship to the GPL?
Don Armstrong
--
If a nation values anything more than freedom, it will lose its
freedom; and the irony of it is that if it is comfort or money it
values more, it will lose that, too.
-- W. Somerset Maugham
http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu
Fedor Zuev
>Le dim 24/08/2003 ? 21:44, Fedor Zuev a ?crit :
>> >If people disagree with what you say, you should not prohibit them
>> >from doing so. You're still a well-known person who can reasonably
>> >assume that what you write or say will not go unnoticed. Even if
>> >it's removed from one distribution of a manual.
>>
>> I cannot see any connection between disagreement with anyone
>> opinion, and the right to censor somebody else's opinion, so
>> angrily demanded by you.
>>
>> But, since these demands and these sophisms repeated only on
>> this list only in the last several days several times already, I
>> should conclude, that FSF was completely right, when included
>> counter-censorship measures in its license.
>Can't you understand nobody would ask for removing these sections
>if they were as free as the FSF would like to call them ?
I do not know the man named Nobody. I can believe that
personally _you_ will never remove sections from documentation you
distribute just because you disagree with author. Even the majority
of debian developers will not do that.
But Wouter Verhelst, to whom letter I reply, clearly stated
otherwise. And, this letter was not first, even on this list.
>OH MY GOD, WE DON'T INCLUDE ACROBAT IN DEBIAN MAIN, THIS IS
>*CENSORSHIP*, WE HAVE NO RIGHT TO EXCLUDE IT FROM DISTRIBUTION!
No. If you do not include Acrobat at all, it will not a
censorship. Nobody expect from you to distribute everything.
But if you take Acrobat, remove, say, the Adobe EULA, and
distribute the rest, it will be censorship or, at least, very
similar. Because you conceal from users the information from
creator, that they reasonable expect to receive from you. Against
the will both the user and creator. It may, also, be copyright
infringement, of course.
(Hypothetical ability to receive this information from the other
sources is completely irrelevant here. Majority of even
goverment-censored information can be accesed from the legitimate
sources. If you exactly know, what and where to find.)
David Starner
> Documentation in not a software.
This has been refuted so many times. What about help2man, which turns software
into documentation? What about the numerous other times documentation is
embedded into source code or source code is embedded into documentation?
What about literate programming?
> There is no any one-way transformation from the source to the binary.
It so happens that I do a lot of work for Project Gutenberg, and have
experience in this matter. Our output - no output I've seen to anything
meaningfully called source - is not convertable into the original. We lose
a lot of book related detail, and even stuff that may or may not be relevant
like fonts and font sizes. The original in this digital age is maybe the
result of a lossy conversion from an original that was marked up with content
orientated tags to a paper format or a more presentation orientated format.
HTML -> ASCII loses information and has no reliable reverse transformation
even for the information it doesn't loose.
On the flip side, the transformation from the source to the binary for
programs is not one-way. You can turn that binary back into source - look
at dozens of Java disassemblers, and the theory is the same for any
source->binary language.
> if you can read the document, you always, technically, can OCR it.
No. OCR programs only work at DPIs and quality levels much higher then
the human threshold. And only if they can get images, which is may
be hard to do for a proprietary reader. 72 or 100 DPI isn't high
enough to OCR from, anyway.
> it takes no more than 24-48 man\hours to completely OCR a
> large 500-700pages book.
For a simple novel, yes. A computer software manual would be much
harder. How long would it take to turn ls back into
a reasonable facsimile of the source code? Probably not a whole lot
longer, given a skilled programmer. A simple quantitive difference
does not a qualitative difference make.
______________________________________________________________________
Do you want a free e-mail for life ? Get it at http://www.email.ro/
Wouter Verhelst
> On Sun, 24 Aug 2003, Josselin Mouette wrote:
> >Le dim 24/08/2003 ? 21:44, Fedor Zuev a ?crit :
> >> >If people disagree with what you say, you should not prohibit them
> >> >from doing so. You're still a well-known person who can reasonably
> >> >assume that what you write or say will not go unnoticed. Even if
> >> >it's removed from one distribution of a manual.
> >> I cannot see any connection between disagreement with anyone
> >> opinion, and the right to censor somebody else's opinion, so
> >> angrily demanded by you.
> >>
> >> But, since these demands and these sophisms repeated only on
> >> this list only in the last several days several times already, I
> >> should conclude, that FSF was completely right, when included
> >> counter-censorship measures in its license.
>
> >Can't you understand nobody would ask for removing these sections
> >if they were as free as the FSF would like to call them ?
>
> I do not know the man named Nobody. I can believe that
> personally _you_ will never remove sections from documentation you
> distribute just because you disagree with author. Even the majority
> of debian developers will not do that.
>
> But Wouter Verhelst, to whom letter I reply, clearly stated
> otherwise. And, this letter was not first, even on this list.
I wouldn't be so sure I stated that so clearly. I said people should
have the right to do so, if they would want to; but I never suggested I
would.
Check your facts next time, please.
> >OH MY GOD, WE DON'T INCLUDE ACROBAT IN DEBIAN MAIN, THIS IS
> >*CENSORSHIP*, WE HAVE NO RIGHT TO EXCLUDE IT FROM DISTRIBUTION!
>
> No. If you do not include Acrobat at all, it will not a
> censorship. Nobody expect from you to distribute everything.
Exactly. We're not expected to distribute computer programs or their
documentation if we feel the license doesn't fit in our DFSG.
Since we feel this is the case for the GFDL (well, at least most of us
do), we're not expected to distribute any GFDL'ed document.
You were saying?
> But if you take Acrobat, remove, say, the Adobe EULA, and
> distribute the rest, it will be censorship or, at least, very
> similar.
We're not doing that. I suggested people should have the right to remove
non-essential parts of a manual. They could have legitimate reasons for
that, but currently, the GFDL doesn't allow them to do so.
The alternative is to not distribute the parts of the software that are
licensed under the GFDL. Which is something entirely different from
'removing the Adobe EULA from its distribution'.
> Because you conceal from users the information from
> creator, that they reasonable expect to receive from you. Against
> the will both the user and creator. It may, also, be copyright
> infringement, of course.
That is not of our concern. What is copyright infringement, and what is
not, is defined by the license. If the license clearly states that it is
OK to remove non-essential information, or to modify the software in
another way, there is no copyright infringement. If the license states
that such is not allowed, the software cannot go in main, and there will
be no copyright infringement either.
--
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
-- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
David Starner
> But if you take Acrobat, remove, say, the Adobe EULA, and
> distribute the rest, it will be censorship or, at least, very
> creator, that they reasonable expect to receive from you. Against
> the will both the user and creator.
First, let's be honest here. The number of users who will be annoyed
by the wasted disk space probably outnumber the number of users who
want the GNU manifesto attached to every GNU manual. It is in the
nature of users to be pragmatic. The number of users who really
want to see the Adobe EULA is much lower. Furthermore, the Adobe
EULA, being a license document, is moot.
Taken to the extreme, a program which happens to search through your
files for porn and emails it back to the upstream is performance art,
and therefore should not be touched. More classic free speech would
be a program that pops up a box if you run it on a non-free system
and reads to you the GNU manifesto before letting you do anything.
Would we tolerate that as free software? I sure wouldn't.
If an author wants to tack his lecture onto his free manual for free
software, I expect the same rights, to delete the annoying and
space-wasting parts. More importantly, what happens when Joe Bob's
pop-mail 0.1 becomes ESR's fetchmail 179.3? Free software means that
can happen; but your definition won't let that happen for free
documentation, because Joe Bob hated guns and put a thirty page
manifesto to that effect in his 'free' documentation, making it
unusable for ESR's fetchmail. I guess ESR could toss in a thirty
page manifest about how guns are good, but I'd rather not see
a flame war in my manual.
That is the nature of free software and free documentation,
to put Debian under our control, to let things go beyond
one solitary point of control and one opinion.
> It may, also, be copyright infringement, of course.
That's why we're having this argument, because we can't go around
breaking licenses. Duh.
Josselin Mouette
> At the very least, if you can read the document, you always,
> technically, can OCR it. An experience shows, that, if you should
> not care about legal requirements (because you has the right from
> license, you OCR public domain or, simply, you do not care about a
> law), it takes no more than 24-48 man\hours to completely OCR a
> large 500-700pages book. And there always will bee volunteers to do
> that.
And you can always modify a binary because it is possible to edit the
assembly code.
Once again, you have absolutely no idea of what you are talking about.
--
.''`. Josselin Mouette /\./\
: :' : josselin...@ens-lyon.org
`. `' jo...@debian.org
`- Debian GNU/Linux -- The power of freedom
Josselin Mouette
> Josselin Mouette wrote:
>
> > Do you realize you are reasoning just like the proprietary software
> > folks the FDL is supposedly meant to fight ?
>
> There is a basic difference between free software foundation folks and
> proprietary software folks. But both try to use practical and ethical
> reasoning. As Josselin Mouette said:
>
> > Can't you understand nobody would ask for removing these sections if
> > they were as free as the FSF would like to call them ?
>
> This is a good example of the freedom, which is not used. So, why not to
> take away it? GPL does similar things, it takes away the freedom of
> using proprietary code with the GPL code from user. But we got something
> in exchange - wide free software and documentation spreading.
GPL doesn't take away freedom. It is a copyleft, full stop. As long as
you respect the copyleft, you are free to do anything you want with the
software. There is no limitation in what you can do, the limitation is
on how you have to do it.
The GFDL is very different. It adds restrictions you often find in
proprietary software: discrimination against fields of endeavour,
restrictions on modification.
> I do not think Debian can safely ignore proprietary software existence,
> as some people on this list do[1]. If the world would be
> black-and-white, I will put FDL on the white side of the black-and-white
> world, together with GPL, FSF, Debian.
We are not talking about color of things. We are talking about their
DFSG-freeness.
> While we discussing FDL, clearly non-free software is still disributed
> by Debian.
I already answered on that specific issue [1], are you *again* trying to
move the discussion to a completely unrelated point?
[1] http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg00771.html
Josselin Mouette
> No. Freedom of _distributor_ is not an issue for the free
> software _at_ _all_. No written document says that goal of a free
> software is to promote freedom of a mere distributors (besides, of
> course, the freedom to distribute itself). Free software is about
> the freedom of _users_ and _authors_. It is in the best interest of
> users to receive unstripped version of manual. It is also in the
> best interest of authors. Interest of distributor is non-issue.
Are you trying to assert point 2 of the GFDL doesn't restrict freedom of
users?
You are a completely dumb moron.
Andrew Suffield
> No. Freedom of _distributor_ is not an issue for the free
> software _at_ _all_. No written document says that goal of a free
> software is to promote freedom of a mere distributors (besides, of
> course, the freedom to distribute itself). Free software is about
> the freedom of _users_ and _authors_.
What are you blabbering about? In many jurisdictions, the _only_
people who can be restricted _at all_ by copyright law are the
distributors. The word "copy" in "copyright" is there for a reason.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Jacobo Tarrio
> Documentation in not a software. There is no any one-way
> transformation from the source to the binary. All problems with
> distribution and modification of documents is a legal, not technical
> problems.
That doesn't matter. To make a derivative of some program, you would
normally need some human-readable source code. To make a derivative of a
manual (for example, a translation or a summary), you only need the text.
> At the very least, if you can read the document, you always,
> technically, can OCR it. An experience shows, that, if you should
> not care about legal requirements (because you has the right from
> license, you OCR public domain or, simply, you do not care about a
> law), it takes no more than 24-48 man\hours to completely OCR a
> large 500-700pages book. And there always will bee volunteers to do
> that.
What are you trying to rebute from my "clause" with it? It is more or less
my reasoning: you can translate the book having only a hardcopy of it. Well,
it is even standard practice. If you want to actually modify it -- well, you
may either OCR it, or you may ask the publisher for a modifiable soft copy
of the book.
--
Tarrío
(Compostela)
Jacobo Tarrio
> How about the GPL v2? "The source code for a work means the preferred
> form of the work for making modifications to it"; binary or object code
> is anything that is not source. I don't see the problem in applying this
> standard all software (meaning programs and documentation).
Anyway, that wasn't my point.
First: why have to deal with "source code" or "the preferred form for
modification" when, for some of the rights the GFDL gives, these things are
not even necessary? For example, to translate a document you don't really
need modifiable source code: you only need to be able to read the original
document.
Second: the "don't use technical measures to limit further copying" clause
is "difficult" because it tries to limit a mechanism, not an intention. What
is someone who "uses technnical measures to limit further copying" trying to
do? Impede that the recipient of the work redistributes new copies. Well,
then why isn't there a clause saying "you must not limit the recipient's
ability to make and distribute new copies of this document"?
Third: if we were to enumerate each and every right in the license, it
would be much longer and more complex (and imagine if we started combining
the rights "you must not limit the recipient's ability to make and
distribute new copies of excerpted versions of this document"). Thus, a
single, simple clause I proposed: "if the format or physical medium this
work is distributed in limits the recipient's ability to exercise the rights
given by this license, access to a copy of this work in a format or physical
medium that allows for the exercise of the rights must be provided".
That would mean -- if you want to modify it and cannot because you don't use
Word, you have the right to obtain from your distributor a plain text copy.
Richard Braakman
> O Luns, 25 de Agosto de 2003 ás 13:35:21 +0900, Fedor Zuev escribía:
>
> > Documentation in not a software. There is no any one-way
> > transformation from the source to the binary. All problems with
> > distribution and modification of documents is a legal, not technical
> > problems.
>
> That doesn't matter. To make a derivative of some program, you would
> normally need some human-readable source code. To make a derivative of a
> manual (for example, a translation or a summary), you only need the text.
But to make a new edition with some spelling errors fixed, you
definitely need the source.
(I'm not sure what you're trying to say here. Are you claiming that
translations and summaries are all you'll want to do with documentation?)
Richard Braakman
Richard Braakman
> In any case, your argument for Invariant Sections applies just as well to
> programs as it does to manuals!
>
> Would you consider a hypothetical program license to be free if it allowed
> 'off-topic' text which must be present unmodified in source and object code
> of all derived versions, and must be displayed (perhaps through a
> command-line option) by every derived program? Maybe you would, in which
> case you're consistent. I wouldn't.
Heh, you choose an interesting example there.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
Richard Braakman
Jacobo Tarrio
> But to make a new edition with some spelling errors fixed, you
> definitely need the source.
Of course.
> (I'm not sure what you're trying to say here. Are you claiming that
> translations and summaries are all you'll want to do with documentation?)
No, I was just proposing a way to require source code to be distributed in
a free documentation license, which is (IMO) saner than the one currently in
the GFDL.
--
Tarrío
(Compostela)
Joe Moore
> On Sun, Aug 24, 2003 at 06:26:07PM -0400, Nathanael Nerode wrote:
>> In any case, your argument for Invariant Sections applies just as well
>> to programs as it does to manuals!
>>
>> Would you consider a hypothetical program license to be free if it
>> allowed 'off-topic' text which must be present unmodified in source
>> and object code of all derived versions, and must be displayed
>> (perhaps through a command-line option) by every derived program?
>> Maybe you would, in which case you're consistent. I wouldn't.
>
> Heh, you choose an interesting example there.
>
A better example:
A program that starts up a browser to display http://www.fsf.org/philosophy/
on startup. The license of the program forbids changing or disabling the
browser code (which is completely unrelated to the program's purpose of
managing local users/passwords), or changing the startup URL.
Is that a free software license?
--Joe
Richard Stallman
FSF to make the GFDL DFSG-free and GPL-compatible, specifically:
I think I see two misunderstandings here. Just who has misunderstood,
I cannot tell.
First, as far as I have heard, Debian has not yet voted on the
question of which GFDL-covered documents to accept. I have therefore
been trying to convince Debian developers that the GFDL is a free
license and should be accepted. Has Debian actually made this
decision?
Second, the FSF is not working on changing the GFDL now. We intend to
continue to use invariant sections that cannot be removed, as we have
always done. The only issue being considered (if it is still being
considered) is what decision Debian will make about use of the GFDL.
To make the GFDL somehow compatible with the GPL would be desirable,
but it is not simple. It would require making a sort of
combined-license with terms like the GPL for software and terms like
the GFDL for documentation. That raises lots of difficult issues. At
this point all we have done is begin to think about it in very general
terms. We won't try to go beyond that until after GPL 3 is ready--and
we're not making much progress on GPL 3 due to lack of manpower.
Richard Stallman
> the free software movement and pretend that we advocate "open source".
"Let those who fight monsters take care lest they themselves become
monsters." - Friedrich Nietzsche
That danger always exists, but it can't be happening here in regard to
invariant sections, because they are not a change. We've been using
invariant sections in our manuals since at least 15 years ago.
What the GFDL changed in regard to invariant sections was to formalize
the criteria, stating explicitly that sections that cover part of the
manual's topic cannot be invariant, and to increase compatibility by
providing a way to merge manuals with different invariant sections.
Richard Stallman
can be wondered what freedom is most desirable: the freedom to run,
study, redistribute and improve for everyone, or the freedom to run,
study, redistribute and improve for only those that agree with your
philosophy, and will not remove it from any accompanying documentation.
The GFDL's permissions apply to everyone, regardless of whether they
agree with philosophy expressed in the invariant sections. Those who
disagree might choose not to exercise the freedom, but the GFDL does
not deny it to them.
If people disagree with what you say, you should not prohibit them from
doing so.
I agree completely. The GFDL does not prohibit people from expressing
their own views. It only says that those who redistribute our manuals
must include our statements of our views. If they wish, they can also
say they disagree with our views.
> Nowadays we have to struggle constantly against the tendency to bury
> the free software movement and pretend that we advocate "open source".
Is a manual the right place for advocacy? Isn't the purpose of a manual
to document a piece of software?
We try to make everything do multiple duty if possible.
Brian T. Sniffen
> Third: if we were to enumerate each and every right in the license, it
> would be much longer and more complex (and imagine if we started combining
> the rights "you must not limit the recipient's ability to make and
> distribute new copies of excerpted versions of this document"). Thus, a
> single, simple clause I proposed: "if the format or physical medium this
> work is distributed in limits the recipient's ability to exercise the rights
> given by this license, access to a copy of this work in a format or physical
> medium that allows for the exercise of the rights must be provided".
>
> That would mean -- if you want to modify it and cannot because you don't use
> Word, you have the right to obtain from your distributor a plain text copy.
So if I distribute any text document in hard copy, I should be
prepared to provide a Braille edition, as well as translations into a
variety of obscure languages? I don't think that's Free either. I
like the idea of what you're trying to do, but I think any phrasing of
this requirement is either going to leave loopholes or cover too much:
it will either be exploitable or non-free. This is a social problem,
and best solved with social means, not with precise technical phrasing.
-Brian
--
Brian T. Sniffen b...@alum.mit.edu
http://www.evenmere.org/~bts/
Fedor Zuev
JM>> the freedom of _users_ and _authors_. It is in the best interest of
JM>> users to receive unstripped version of manual. It is also in the
JM>> best interest of authors. Interest of distributor is non-issue.
JM>Are you trying to assert point 2 of the GFDL doesn't restrict
JM>freedom of users?
Exactly, I still not see any non-stupid demonstration of the
contrary. I prefer not to state anything else.
Fedor Zuev
>There a VERY large difference, as black from white, between me deciding
>not to repeat certain portions of Mr. Zuev's post[0] and sending people
>to intimidate or kill him. The former is known, at least in the free
>world, as free speech; the latter as censorship.
So, there is no censorship in the world as long as no one
threaten to kill you? Well.
>[0] Just like cutting the philosophical sections from a manual.
No. Not like.
Please note, that you do not need a special license from me
to include (or even not include) portion of my post in your. But for
manual you expect explicit permission.
Fedor Zuev
>Would you consider a hypothetical program license to be free if it
>allowed 'off-topic' text which must be present unmodified in source
>and object code of all derived versions, and must be displayed
>(perhaps through a command-line option) by every derived program?
>Maybe you would, in which case you're consistent. I wouldn't.
This is the exactly what old BSD license do.
>How about a license which allowed off-topic code (say, a 'hangman'
>game in the 'ls' program) which must be present unmodified in
>source code of all derived versions, and must be invoked (perhaps
>through a command-line option) by every derived program?
It almost certainly affect the normal use of program and
will be unacceptable because of this, not because of mere existence
of such code.
Joe Wreschnig
> Several Debian developers have claimed that they are working with the
> FSF to make the GFDL DFSG-free and GPL-compatible, specifically:
>
> I think I see two misunderstandings here. Just who has misunderstood,
> I cannot tell.
>
> First, as far as I have heard, Debian has not yet voted on the
> question of which GFDL-covered documents to accept. I have therefore
> been trying to convince Debian developers that the GFDL is a free
> license and should be accepted. Has Debian actually made this
> decision?
>
> Second, the FSF is not working on changing the GFDL now. We intend to
> continue to use invariant sections that cannot be removed, as we have
> always done. The only issue being considered (if it is still being
> considered) is what decision Debian will make about use of the GFDL.
Thank you for clearing this up.
You are correct that Debian has not yet voted on whether or not to allow
GFDLd works into its distribution. The consensus of debian-legal is that
works under the GFDL does not meet the DFSG.
This means if they are to be included in Debian, amendments will need to
be made to the Social Contract, and some sort of "Debian Free
Documentation Guidelines" outlining the necessary freedoms for
documentation needs to be proposed and voted on.
No one has yet done this, for various reasons.
--
Joe Wreschnig <pi...@debian.org>
Florian Weimer
> Nowadays we have to struggle constantly against the tendency to bury
> the free software movement and pretend that we advocate "open source".
> So I don't think we can conclude that such precautions are no longer
> necessary.
It's true that many have gladly taken GNU software while ignoring the
GNU philosophy (or actively working against it). But I doubt that
invariant sections alone can ensure that the message will be heard.
For example, I might want to distribute the GNU Emacs manual without
the GNU Manifesto. I could achieve something which is very close,
even though the Manifesto is an invariant section: I just patch the
Info viewers not to display the Manifesto. As far as I can see, I'm
still allowed to distribute the modified Info viewer under the GPL,
and the (unmodified) manual under the GFDL.
However, if someone did something similar, I'd expect quite a lot
of additional publicity for the GNU Manifesto. Furthermore, the
publicity wouldn't depend much on the legality of the removal or
suppression. Journalists who are interested in free software
philosphy and its battles would report it nevertheless, and those who
are after awkward legal problems have such a limited audience that
their silence wouldn't matter that much.
Josselin Mouette
> Several Debian developers have claimed that they are working with the
> FSF to make the GFDL DFSG-free and GPL-compatible, specifically:
>
> I think I see two misunderstandings here. Just who has misunderstood,
> I cannot tell.
>
> First, as far as I have heard, Debian has not yet voted on the
> question of which GFDL-covered documents to accept. I have therefore
> been trying to convince Debian developers that the GFDL is a free
> license and should be accepted. Has Debian actually made this
> decision?
Regarding the results of the survey on this issue, almost everyone on
that list agrees on the fact a document with invariant sections cannot
be considered as free. Furthermore, a large majority thinks that no
GFDL'ed document can be considered at suitable for Debian main.
However, several developers believe we should have different rules for
documentation. It is not likely to happen before a long time, as it
requires changing the social contract, and they will encounter strong
opposition.
No decision has been made yet, but it is quite likely that after the
sarge release (which will include GFDL'ed documents as stated by the
Release Manager), some or all documents under the GFDL are removed from
our distribution and moved to non-free.
> We won't try to go beyond that until after GPL 3 is ready--and
> we're not making much progress on GPL 3 due to lack of manpower.
As for GPL 3, do you intend to use clauses similar to invariant sections
or to the technical measures stuff in GFDL section 2? This is a matter
of concern on this list.
Regards,
Branden Robinson
> > Nowadays we have to struggle constantly against the tendency to bury
> > the free software movement and pretend that we advocate "open source".
>
> "Let those who fight monsters take care lest they themselves become
> monsters." - Friedrich Nietzsche
>
> That danger always exists, but it can't be happening here in regard to
> invariant sections, because they are not a change. We've been using
> invariant sections in our manuals since at least 15 years ago.
The FSF hasn't started promoting the usage of Invariant Sections by
others until recently. The FSF clearly promulgates usage of the GNU FDL
by third parties on its website.
Furthermore, several GNU Manuals that used to be DFSG-free no longer
are; take, for example, the GDB Manual.
It's not just a continuation of the status quo that is taking place
here. The FSF has adopted an expansionist policy with respect to
Invariant Sections.
--
G. Branden Robinson | The only way to get rid of a
Debian GNU/Linux | temptation is to yield to it.
bra...@debian.org | -- Oscar Wilde
http://people.debian.org/~branden/ |
Fedor Zuev
> What are you trying to rebute from my "clause" with it? It is more
>or less my reasoning: you can translate the book having only a
>hardcopy of it. Well, it is even standard practice. If you want to
>actually modify it -- well, you may either OCR it, or you may ask
>the publisher for a modifiable soft copy of the book.
Your clause is too broad. It demand from distributor not
provide some limited service, but care about user's ability of
exercise rights. What if user have only an ancient Amiga?
David B Harris
Fedor Zuev <fe...@earth.crust.irk.ru> wrote:
> On Mon, 25 Aug 2003, Josselin Mouette wrote:
>
> JM>> the freedom of _users_ and _authors_. It is in the best interest of
> JM>> users to receive unstripped version of manual. It is also in the
> JM>> best interest of authors. Interest of distributor is non-issue.
>
> JM>Are you trying to assert point 2 of the GFDL doesn't restrict
> JM>freedom of users?
>
> Exactly, I still not see any non-stupid demonstration of the
> contrary. I prefer not to state anything else.
My $HOME is on an encrypted filesystem. If I have any GFDL documents on
that filesystem, I'm in violation of the license.
If I want to send a friend one of these GFDL documents, I may not use
SSL or any other form of encryption.
If I'm on a shared, multi-user system, I must leave any directories a
GFDL document is in as world-readable; to restrict permissions would be
to use a technical measure to restrict the further reading of the
document.
Are those examples allright? I could come up with more if you'd like.
Sergey V. Spiridonov
> GPL doesn't take away freedom. It is a copyleft, full stop. As long as
> you respect the copyleft, you are free to do anything you want with the
> software. There is no limitation in what you can do, the limitation is
> on how you have to do it.
Sorry, but GPL have restrictions on what you can do with the code. One
of the most noticeble is a restriction on using GPL code in(with)
proprietary works.
> The GFDL is very different. It adds restrictions you often find in
> proprietary software: discrimination against fields of endeavour,
> restrictions on modification.
As with GPL, those FDL resrictions have completely another background in
comparison with proprietary software. One, who ignores the difference in
the FDL background should reject GPL also (if he wants to be consistent).
I wish to have the world clear from proprietary software, but this will
not happen automagically. GPL and FDL do the great job for reaching this
goal.
--
Best regards, Sergey Spiridonov
Josselin Mouette
> Josselin Mouette wrote:
>
> > GPL doesn't take away freedom. It is a copyleft, full stop. As long as
> > you respect the copyleft, you are free to do anything you want with the
> > software. There is no limitation in what you can do, the limitation is
> > on how you have to do it.
>
> Sorry, but GPL have restrictions on what you can do with the code. One
> of the most noticeble is a restriction on using GPL code in(with)
> proprietary works.
The work being proprietary has nothing to do with the contents of the
work itself, which is just what I stated above. Please don't answer to a
message by showing you haven't even read it, this behavior is quite
prone to get you put in some killfiles (which already happened).
> > The GFDL is very different. It adds restrictions you often find in
> > proprietary software: discrimination against fields of endeavour,
> > restrictions on modification.
>
> As with GPL, those FDL resrictions have completely another background in
> comparison with proprietary software. One, who ignores the difference in
> the FDL background should reject GPL also (if he wants to be consistent).
I don't see much difference between a proprietary work you can't modify
and a proprietary work you can't modify with a "Free" stick. Blabbering
about world domination of free software without even ensuring works you
release are free is a good way to fail: when world domination is
achieved, you realize you made so many exceptions that you are far from
your original vision.
Andrew Suffield
> On Sun, 24 Aug 2003, Nathanael Nerode wrote:
>
> >Would you consider a hypothetical program license to be free if it
> >allowed 'off-topic' text which must be present unmodified in source
> >and object code of all derived versions, and must be displayed
> >(perhaps through a command-line option) by every derived program?
> >Maybe you would, in which case you're consistent. I wouldn't.
>
> This is the exactly what old BSD license do.
No it isn't. The 4-clause BSD license requires you to add text to any
advertising materials you may produce. Nothing to do with the content
of the program.
Andrew Suffield
> Please note, that you do not need a special license from me
> to include (or even not include) portion of my post in your. But for
> manual you expect explicit permission.
This is false. I can legally quote you anywhere I want to, so long as
I am quoting you accurately.
I can even misquote you if I'm creating satire.
Sergey V. Spiridonov
> The work being proprietary has nothing to do with the contents of the
> work itself, which is just what I stated above. Please don't answer to a
This is irrelevant. I do not really understand, why do you think it is
that important. Do you think that "restricting" is not the same as
"taking away the freedom"? Why it is important for you, in which way it
is done?
>>>The GFDL is very different. It adds restrictions you often find in
>>>proprietary software: discrimination against fields of endeavour,
>>>restrictions on modification.
>>As with GPL, those FDL resrictions have completely another background in
>>comparison with proprietary software. One, who ignores the difference in
>>the FDL background should reject GPL also (if he wants to be consistent).
>
> I don't see much difference between a proprietary work you can't modify
> and a proprietary work you can't modify with a "Free" stick. Blabbering
> about world domination of free software without even ensuring works you
> release are free is a good way to fail: when world domination is
> achieved, you realize you made so many exceptions that you are far from
> your original vision.
There is such a danger. People who want to produce software without any
restrictions and danger prefer Public Domain. They try to ignore
proprietary software existance.
Dylan Thurston
> I didn't post it yet because I'm not yet sure in my own mind what the right
> guidelines are. Despite the assertions of some, I do not think that just
> accepting GFDL 100% is the right thing to do here.
>
> I see the following scenarios:
>
> 1. I'm a Free Software user. I am using Emacs, a large Free system that
> requires documentation to learn by any means. But that documentation is
> missing or obsolete because of GFDL. I cannot make use of this Free
> package.
>
> 2. I'm a Free Software developer and want to make a derivative program, but
> can't because it requires documentation, and I disagree with the GNU
> manifesto and can't adapt it, and don't have the time to rewrite the manual
> from scratch.
>
> As a developer myself, and a believer in the principles of the free software
> movement, I'm inclined to conclude that #2 is the larger problem in the long
> run. I wasn't necessarily so inclined two weeks ago.
>
> Regardless, I still maintain that documentation is not software and does
> need separate guidelines.
If you do end up coming to the conclusion that the GFDL (with
invariant sections) would not meet your standards for free
documentation, you should make sure to include an example of some
license that would be judged differently under your proposed free
documentation guidelines and the DFSG. (Do you have such an example
in mind already?)
Peace,
Dylan Thurston
Anthony DeRobertis
On Monday, Aug 25, 2003, at 10:44 US/Eastern, Fedor Zuev wrote:
>
> So, there is no censorship in the world as long as no one
> threaten to kill you? Well.
That's not what I said, and even if it were, there are other forms of
coercion, intimidation, etc. besides death threats.
[And there is a big difference between censoring a person and censoring
a copy of a document, btw.]
>
>> [0] Just like cutting the philosophical sections from a manual.
>
> No. Not like.
Care to explain how?
>
> Please note, that you do not need a special license from me
> to include (or even not include) portion of my post in your. But for
> manual you expect explicit permission.
Not at all. I can include portions of (or, if needed, the whole) manual
for similar purposes in a document I write, at least in the US. We call
it "fair use."
David Starner
Fedor Zuev <fe...@earth.crust.irk.ru> writes
> >How about a license which allowed off-topic code (say, a 'hangman'
> >game in the 'ls' program) which must be present unmodified in
> >source code of all derived versions, and must be invoked (perhaps
> >through a command-line option) by every derived program?
> It almost certainly affect the normal use of program and
> will be unacceptable because of this, not because of mere existence
> of such code.
How does ls --hangman bringing up a hangman program affect the normal
use of the program more then a large manifesto affect the normal use
of the manual? If you don't know that ls --hangman brings up a hangman
program and don't look at the code, you'll never know it's there, unlike
a manifest, which is always hanging in your face, appearing in searches,
and driving up the cost of printed versions.
______________________________________________________________________
Do you want a free e-mail for life ? Get it at http://www.email.ro/
Nathanael Nerode
>>dictionary.
>
> Heh.
>
> "Why that ugly, non-free GPL license demand from me to
>distribute source code? Source would still be freely available from
>the FSF website! Lack of forced distribution do not harm a
>freedom!" Agree?
Now you've changed the terms of your argument; I guess you admit that it's
not 'censorship'. Good. :-)
In response to your new, different argument:
When I distribute GPL'ed binaries, I do not in fact have to distribute source
with them. I could also distribute, for instance:
* a written offer to provide source
* a copy of the written offer to provide source which I received
But more importantly, if I make a *modified version* of a GPL'ed program, I
only have to distribute source to my *modified version*. I do *not* have to
distribute the source code to the FSF's version of GCC when I distribute my
hacked-up version!
If I make a *modified version* of a GFDL'ed manual, no matter how
dramatically altered, I still have to distribute the *original* Invariant
Sections.
The situations are not similar.
I will not reply to any further nonsense on your part. If you have something
sensible and rational to say, go ahead.
Nathanael Nerode
>On Mon, Aug 25, 2003 at 11:21:09AM -0400, Richard Stallman wrote:
>> > Nowadays we have to struggle constantly against the tendency to bury
>> > the free software movement and pretend that we advocate "open
source".
>>
>> "Let those who fight monsters take care lest they themselves become
>> monsters." - Friedrich Nietzsche
>>
>> That danger always exists, but it can't be happening here in regard to
>> invariant sections, because they are not a change. We've been using
>> invariant sections in our manuals since at least 15 years ago.
>
>The FSF hasn't started promoting the usage of Invariant Sections by
>others until recently. The FSF clearly promulgates usage of the GNU FDL
>by third parties on its website.
>
>Furthermore, several GNU Manuals that used to be DFSG-free no longer
>are; take, for example, the GDB Manual.
>
>It's not just a continuation of the status quo that is taking place
>here. The FSF has adopted an expansionist policy with respect to
>Invariant Sections.
This is a very important point. I have stated before that I would not have
serious objections to the FSF issuing a small number of non-free manuals for
a good reason, as it has been doing for 15 years. (Nearly the entire GNU
Project website is 'verbatim copying and distribution of this entire article'
only, so there's further precedent for the GNU Project distributing non-free
material.)
In contrast, I have major objections to the FSF promoting the creation of
lots and lots of non-free manuals. And further objections to the FSF
claiming while doing so that they are free manuals. These policies *are* a
significant change.
--Nathanael Nerode
Richard Stallman
Anyone who looks at the attribution of any FSF program or manual
can probably find the website. People who have never seen an FSF
program or manual can find the website, too. The website will
always contain the GNU Manifesto, unmodified, regardless of the
actions of distributors.
In other words, what happens to the local copies simply isn't as
important as it used to be.
These facts have not prevented the open source movement from quite
effectively covering up what we stand for, and our movement's very
existence. They cannot make any specific person forget, but they
have led most US journalists to deny our existence, so that
most people never find out about us. We need every method of
informing them that we can get.
Joe Wreschnig
> Now, the World Wide Web exists. And the FSF has its own website.
> Anyone who looks at the attribution of any FSF program or manual
> can probably find the website. People who have never seen an FSF
> program or manual can find the website, too. The website will
> always contain the GNU Manifesto, unmodified, regardless of the
> actions of distributors.
>
> In other words, what happens to the local copies simply isn't as
> important as it used to be.
>
> These facts have not prevented the open source movement from quite
> effectively covering up what we stand for, and our movement's very
> existence. They cannot make any specific person forget, but they
> have led most US journalists to deny our existence, so that
> most people never find out about us. We need every method of
> informing them that we can get.
Out of curiousity - Has these actually been a case of people removing,
say, the GNU Manifesto or the LINUX-GNU file from Emacs, and then
distributing it on a large scale? Or removed other philosophical
documents from GNU manuals or programs when they are normally
distributed together, the specific example is unimportant.
Do you think this was the fault of open source movement (or those
misinformed by their rhetoric), or perhaps was it someone concerned
about disk or physical (e.g. number of printed pages) space?
--
Joe Wreschnig <pi...@debian.org>
Don Armstrong
> These facts have not prevented the open source movement from quite
> effectively covering up what we stand for, and our movement's very
> existence. They cannot make any specific person forget, but they
> have led most US journalists to deny our existence, so that most
> people never find out about us.
The ineptitude of many US journalists continues to increase without
bounds.[1] They often report on what they don't understand, or what
they haven't read. Frankly, they are the second to last people who
would ever read GFDL'ed documentation, let alone the GNU Manifesto
within some of the same.[2]
> We need every method of informing them that we can get.
Then why not go the Reiser[3] way and require that an advertisement
for the Free Software movement be printed out at every interactive
invocation of a GNU derived GPLed program?
While the intention of spreading the word about the free software
movement is laudable, the people most heavily affected by these
methods are often free software's staunchest, although often not the
most outspoken, supporters.
Don Armstrong
1: I refer you to Fox News and MSNBC for rather depressing examples of
the same.
2: I'd imagine that people who can't read would be the last, but I
could have the order wrong.
3: http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01295.html
--
You could say she lived on the edge... Well, maybe not exactly on the edge,
just close enough to watch other people fall off.
-- hugh macleod http://www.gapingvoid.com/batch8.htm
http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu
Sergey Spiridonov
> This is a very important point. I have stated before that I would not have
> serious objections to the FSF issuing a small number of non-free manuals for
> a good reason, as it has been doing for 15 years. (Nearly the entire GNU
> Project website is 'verbatim copying and distribution of this entire article'
> only, so there's further precedent for the GNU Project distributing non-free
> material.)
>
What about DFSG FAQ draft? Do you think this can be applied to FDL
documentation?
# Q: Does whether some software is free depend solely on its license?
A: Almost always, but there are rare exceptions. When necessary we take
other considerations into account. So two packages with the same license
could be judged differently based on extra-license comments the
copyright holder has made regarding intent or interpretation, or based
on how the contents of the package interact with license stipulations.
--
Best regards, Sergey Spiridonov
--
Nathanael Nerode
>On Sun, Aug 24, 2003 at 06:26:07PM -0400, Nathanael Nerode wrote:
>> In any case, your argument for Invariant Sections applies just as well to
^-(here I refer to Richard Stallman's argument)
>> programs as it does to manuals!
>> Would you consider a hypothetical program license to be free if it allowed
code
>> of all derived versions, and must be displayed (perhaps through a
>> command-line option) by every derived program? Maybe you would, in which
>
>
> c) If the modified program normally reads commands interactively
> when run, you must cause it, when started running for such
> interactive use in the most ordinary way, to print or display an
> announcement including an appropriate copyright notice and a
> notice that there is no warranty (or else, saying that you provide
> a warranty) and that users may redistribute the program under
> these conditions, and telling the user how to view a copy of this
> License. (Exception: if the Program itself is interactive but
> does not normally print such an announcement, your work based on
> the Program is not required to print an announcement.)
>
>Richard Braakman
My example was deliberate. :-)
I am not very fond of that clause of the GPL myself. But it's worth noting
that it doesn't specify any particular text. Instead, it gives a rather
generic set of requirements. In a modified version, I can (must, in fact)
fulfill these requirements with an announcement which is quite different from
the one used on the original program. Furthermore, the announcement
requirements are directly related to the legal status of the distributed
program. So it's a very different case from GFDL-style Invariant Sections,
and does not correspond to my example.
--Nathanael
Dmitry Borodaenko
> They cannot make any specific person forget, but they have led most US
> journalists to deny our existence, so that most people never find out
> about us.
I don't know about US, but I know that here in Belarus this problem does
not exist. People who care tend to know about both FSF and OSI and about
their history. People who don't care just use the software and don't pay
attention to underlying philosophy, and no amount of propaganda would
make them care about either FSF or OSI. There's no use in blaming
journalists or OSI for some people's indifference, that's a more
fundamental problem and should be treated as such.
> We need every method of informing them that we can get.
Every? That sounds just like "Noble goal justifies vile means". Even if
you don't believe that "there is no such Good on Earth that is worth a
single child's teardrop", can you at least agree that _some_ methods are
not worth the goal, and that _some_ cure is worse than the desease?
--
Dmitry Borodaenko
Branden Robinson
> Every? That sounds just like "Noble goal justifies vile means". Even if
> you don't believe that "there is no such Good on Earth that is worth a
> single child's teardrop", can you at least agree that _some_ methods are
> not worth the goal, and that _some_ cure is worse than the desease?
There's no point in asking that question. People seldom come to doubt their
own means retrospectively.
--
G. Branden Robinson | That's the saving grace of humor:
Debian GNU/Linux | if you fail, no one is laughing at
bra...@debian.org | you.
http://people.debian.org/~branden/ | -- A. Whitney Brown
Branden Robinson
> What about DFSG FAQ draft? Do you think this can be applied to FDL
> documentation?
>
> # Q: Does whether some software is free depend solely on its license?
>
> A: Almost always, but there are rare exceptions. When necessary we take
> other considerations into account. So two packages with the same license
> could be judged differently based on extra-license comments the
> copyright holder has made regarding intent or interpretation, or based
> on how the contents of the package interact with license stipulations.
I suggest:
s/Almost always/Usually/
s/rare //
Perhaps my perception of the frequency of exceptional cases is distorted
by the fact that I subscribe to debian-legal, though. :)
--
G. Branden Robinson | You could wire up a dead rat to a
Debian GNU/Linux | DIMM socket and the PC BIOS memory
bra...@debian.org | test would pass it just fine.
http://people.debian.org/~branden/ | -- Ethan Benson
Fedor Zuev
>Fedor Zuev <fe...@earth.crust.irk.ru> writes:
>> Documentation in not a software.
>This has been refuted so many times. What about help2man, which
>turns software into documentation? What about the numerous other
>times documentation is embedded into source code or source code is
>embedded into documentation? What about literate programming?
I aware. Yes, distinction is often unclear.
But this is irrelevant. It is enough that _law_ (majority of
existed copyright laws) makes this difference. Difference, based not
on the structure of work, but on its function, btw. In some cases
you can't anyway ignore such difference, because law demands to make
it. And in some other cases you should not ignore it, even if you
can, because such difference benefits you.
>> There is no any one-way transformation from the source to the binary.
>It so happens that I do a lot of work for Project Gutenberg, and
>have experience in this matter. Our output - no output I've seen to
>anything meaningfully called source - is not convertable into the
>original. We lose a lot of book related detail, and even stuff that
>may or may not be relevant like fonts and font sizes. The original
>in this digital age is maybe the result of a lossy conversion from
>an original that was marked up with content orientated tags to a
>paper format or a more presentation orientated format. HTML ->
>ASCII loses information and has no reliable reverse transformation
>even for the information it doesn't loose.
Of course. But, please note,
1) All this is a elements of formatting, not a
copyrighted|public domain literary work itself. Formatting usually
not copyrighted, but where it is (AFAIK, in UK) copyright to
formatting is different from copyright to the work itself.
2) You, probably, lose information while converting not
because you can't preserve it al all, but because you do not have
proper convention for preserving such things.
3) And you do not have convention just because in majority
of cases this elements of formatting is completely unimportant for
using the text.
>On the flip side, the transformation from the source to the binary for
>programs is not one-way. You can turn that binary back into source - look
>at dozens of Java disassemblers, and the theory is the same for any
>source->binary language.
No. It is essentially one-way. At least for the PDP11, x80,
x86, 68xxx. In many cases you can't even monosemantic disassemble
the binary. As for more abstract languages....to _which_ language
(or dialect of language) you going to decompile the binary?
Of course, there are some excetpions, where decompilation
possible, but they are rare.
>> if you can read the document, you always, technically, can OCR it.
>No. OCR programs only work at DPIs and quality levels much higher then
>the human threshold. And only if they can get images, which is may
>be hard to do for a proprietary reader. 72 or 100 DPI isn't high
>enough to OCR from, anyway.
You can resize the picture in GIMP. Or you can photograph a
computer display. Both techniques are really used by me or my
friends and gives reasonable results. Not perfect, but reasonable to
use.
>> it takes no more than 24-48 man\hours to completely OCR a
>> large 500-700pages book.
>For a simple novel, yes. A computer software manual would be much
>harder.
Many OCR programs preserve much from formatting also.
>How long would it take to turn ls back into a reasonable facsimile
>of the source code? Probably not a whole lot longer, given a
>skilled programmer. A simple quantitive difference does not a
>qualitative difference make.
Longer. Much longer. Specifically, much longer than rewrite
ls from scratch, using only manpage for reference.
There are _many_ OCR programs in the world. There is _no_
x86-disassembler, which assure compilable output, in the world.