- is it valid to refer to GPL and add such severe restrictions in
an appendix?
No.
Trying to add extra restrictions onto the GNU GPL results
in a sort of self-contradiction, where it is not clear
what the license of a modified version should be.
- is this a "free soft
I think we are having two misunderstandings at the same time.
You seem to be talking about the specific case of modules for Linux,
based on the specifics of the extra permission that Linus gave.
That case is different and what I say does not apply to it.
You are focusing on the definition of "der
> It's the same case as Windows NDIS drivers loading on linux. They were
> created in a different environment, and would exist as they are even if
> linux did not exist. Provided GPL'd glue code, you can load them in the
> linux kernel, and they are _not_ derivative works.
The i
I believe there was never a time when only the FSF pushed for free
software.
I should have said "the GNU Project" rather than "the FSF", since the
GNU Project led to FSF and has always been larger.
When the GNU Project started, there was no other organized effort
to make software free. W
You are criticizing Debian based on things you can imagine we might
do, and have imagined no end of nasty possibilities.
I have hardly criticized Debian at all in this discussion. I was
trying to convince Debian developers that they should regard
GFDL-covered manuals as free.
I have only
> The Free Software Foundation built the free software community,
> years before Debian was started,
This is at least much of a "nasty cheap shot" as what I said. And
you've done it before.
It is not a "shot" at all. I was defending the FSF from an
accusation, not attacking Debi
There wasn't supposed to be a link to the Debian web site on
www.gnu.org, because it lists non-free software packages. Except in
the Free Software Directory, we do not link to sites that specifically
suggest the use of any non-free program, or that say how to get a copy
of one.
This policy has ex
Everything in Debian is software; the "official logo" is not free, and
therefore is not in Debian.
Fortunately it is not necessary for me to understand this.
We want to have freedom over what we distribute in "binary" packages.
We are willing to tolerate noxious restrictions like the TeX ones only
because they do not impact what we can distribute in the binary
package: they only restrict the hoops that the source package must go
thro
You have previously suggested we should consider whether documentation
is free, based on the four basic freedoms as specified on
http://www.fsf.org/philosophy/ . That includes 'the freedom to run the
program, for any purpose'. Since a manual can't be run, I'll interpret
that as
Your casual suggestion to "pick whichever seems better" leaves out the
object: better for whom? For the Free Software community? For the
Free Software Foundation, whose goals are quite different?
That is a cheap shot, because it reflects only your decision to be
nasty. I could make
I don't think
> it needs to be possible to use text from manuals in a program.
> A manual is free if you can publish modified versions as manuals.
And is a text editor free if you can only publish modified versions as
text editors -- not as manuals or tetris games or news-rea
As has been pointed out before, such a proposal doesn't belong here. The
function of -legal is to interpret the DFSG and vet the free-ness of
software[1] licenses in accordance with said interpretation. It is *not*
its role to decide which parts of Debian the DFSG should adhere to (
You should probably read the whole thread before replying.
Prior to this message, I must have read half-a-dozen or more messages
saying...
I can't do that. Those messages probably did not arrive on my machine
until after I sent my message out.
I do mail transfers in batches, usually
> If the whole doc was DFSG free, I believe no Debian maintainer
> would remove the political statements one could find in it.
>
> Two people have just said they would remove any essay that cannot
> be modified.
Notice that the first person said "DFSG free", and y
1) Because the borders between the cases are ambiguous and uncertain.
I sent a message a day or two ago (perhaps after you sent this one)
which addresses that issue.
2) Because we want to be able to combine works from different sources,
As I explained, this desire is usually impossible d
> Not long ago, people were trying to reassure me that if invariant
> sections were removable, nobody would remove them. I guess not.
>
> This reinforces my conclusion that it is essential for these sections
> to be unremovable as well as unmodifiable.
You have misundersto
I am seeing a persistent pattern where you accuse me of dishonesty
based on little except supposition. Here are several examples from
the mail I received last night.
> Thomas Bushnell proposed another interpretation, in which certain
> things that are included in the Debian package files
While superficially
ironic, this is in fact quite fundamental: you cannot truly build a
free society without granting its participants the freedom to reject
the very notion of freedom itself.
The idea that people should be "free to reject freedom" is a
fundamental philosophical
> I don't think that section titles are a problem--it would not be
> hard to put them in a program. But it is true that you cannot take
> text from a GFDL-covered manual and put it into most free programs.
> This is because the GFDL is incompatible with the normal free
> softwa
> I value freedom in documentation just as much as I do for programs. I
> value it so much that I designed the GFDL specifically to induce
> commercial publishers to publish free documentation.
You don't value the freedom to modify the whole book. You value
freedom in *docume
> This reinforces my conclusion that it is essential for these sections
> to be unremovable as well as unmodifiable.
To serve the ends of GNU, perhaps. But it doesn't seem to serve the
needs of the larger Free Software community.
It serves the free software community by resisting
Do you have numbers to back the claim that it is more widespread? I
thought only English had the free/free ambiguity enough to create a
market for the more ambiguous term "open source".
Most of the computer-using world uses English, and the English-language
press is most influential
My point is precisely that a GFDL manual *cannot* be incorporated into
*ANY* free software project. And this is *different* from the old
documentation license, which did not have that problem.
I have never considered the question of whether the GFDL is a free
software license. The qu
It's annoying but it can be dealt with. The distinction I, personally,
was trying to make is that that's a finite, known, limited amount. You
didn't respond to the point that the amount for the GFDL is not a
maximum amount at all, just a current amount.
I see the distinction,
> But I think
> that would not be free, because this behavior is substantive, not mere
> packaging. It's not the same as just printing an informative message
> about something nontechnical.
You often refer to the inclus
FYI, that's not going to convince anyone.
We could all speculate about what might or might not convince certain
other persons, but doing so is attempting to speak for them, so let's
not do it.
But what if an Invariant Section was the only part of the document that
fell foul of the law?
I guess nobody could distribute that version, so it might be
non-free.
However, all free software and free documentation licenses share this
problem. You could simply add code for a DeCSS progr
While you are free to state the terms by which the GFDL should be
interpreted for GNU documentation, this is not always the case. We have
in the past seen cases where copyright holders have interpreted
seemingly unambiguous statements in a pathological fashion (see Pine,
for ins
>The main difference between a program and documentation is that a
>program does something, while documentation is passive;
By this argument, source code to a program (of the sort which must be
compiled to run) is not a program.
That's a pedantic approach to the issue. I'd say a
If the whole docu would be DFSG-free, than there would be no cause to
remove polical statements.
According to Don Armstrong, a non-modifiable text cannot under any
circumstances be considered DFSG-free, so it would have to be removed
from the manual. Others have (it appears) said the same
I am not sure that it is, but the FSF seem to be suspicious of the
free press movement.
I don't know what that message said, or who wrote it, but it does not
speak for the FSF. If the free press movement means indymedia, I am
sympathetic to it, but the FSF has no opinion about it.
If the whole doc was DFSG free, I believe no Debian maintainer
would remove the political statements one could find in it.
Two people have just said they would remove any essay that cannot
be modified.
>I don't think that section titles are a problem--it would not be
>hard to put them in a program.
In a *binary executable* ?!?! That's what I'm talking about here.
I am not sure if you are right; this might be impossible or it might
be easy. I have never thought about what this requ
> A few weeks ago someone was trying to argue that nobody would do
> this, and that invariant sections were designed to solve a
> nonexistent problem. Now we know the problem is not just
> theoretical.
No, it's still a theoretical problem.[1] The above has nothing to do
wi
If, OTOH, your only goal is to persuade Debian to accept the GFDL
with invariant sections as free enough for inclusion in our
distribution, I don't see that such a discussion could ever bear
fruit without a concrete proposal spelling out the alternative
guidelines that should ap
But if they were only removable without being
modifiable, then yes, removing them would be the only way to include the
accompanying documentation while still ensuring that all bits in Debian
guarantee the freedoms that we require.
Not long ago, people were trying to reassure me t
None of these differences correctly classifies Hello as both a program
and documentation, as far as I can tell.
Hello is an example program.
It is difficult
to deal with such grey areas and I assume that it requires a
case-by-case review.
I have never found it difficult.
> Someone else criticized the idea (though no one had proposed it) of
> giving the FSF special consideration; now you seem to be saying just
> the opposite, that you believe in giving the FSF less cooperation that
> you would give to anyone else. The consequences of such an approac
As far as the logo, the name "Mathieu Roy" isn't free in the
DFSG-sense. Neither is the Debian name. I don't see why the Debian logo
should be either.
I don't believe the logo needs to be free; I think the way it is being
handled is appropriate. However, others were arguing recently
Ok, so for this "distribution section", I agree, it should not be
invariant as it is almost "technical" (how do I get more
information...), and the point of view of RMS about that would be
interesting.
This section explains what free software means, mention the existence
of the FS
> The words of the social contract clearly equate software to programs.
I encourage you to look closer. The only part of the social contract
which even contains the word programs is #5, a part both of us would
like removed.
Several parts of the DFSG contain the word "program".
>> I'm curious: Considering the GPL prohibits binary-only distribution
>> under section 3, do you still hold that position?
>
> GPL 3b and 3c deal with that quite nicely. Debian, for example,
> distributes its GPL'd software by offering the source on the same
> medium.
Manuals, essays, licenses, and logos *encoded as bits on a
computer* are software.
Defining all these thing as software is a peculiar way to use the
word. I don't think that is the best way to interpret the DFSG,
because it leads to unnecessary inflexibility.
I do not try to tell the
> If the GPL were used, it would have to be accompanied by 6 pages
> of additional invariant material. That is still bigger than the
> reference card. Do you object to the GPL on these grounds?
There's a critical difference here. The GPL can accompany the
reference card. The
If you are aware of the existence of unmodifyable essays and logos in
debian main, please file an RC bug against the package in question.
You seem to be saying that if our political statements, which are
included as invariant sections, could be removed from our manuals, you
would make a po
It containts detailed
mathematicly research on how the improvements were made, details which
are not evident in the source and therefore reverse engineering of the
documentation from just the source is not possible. Included in his
update to the documentation is an Invariant
If you are willing to disregard the explanation of the meaning of
a text by its author in order to reinterpret it, you're on the
wrong way. It is absurd to argue rigidly that "the DFSG obviously
doesn't say that" when its author says it is.
To point out what the words of the DFSG a
2. The GFDL prevents you from using the technical material in the manual
in nearly any program, because most programs don't have a lot of the
specific things the GFDL refers to ("section titles", etc.), so there's
no legally clear way to satisfy its requirements.
I don't think t
The DFSG explicitly
> codifies my specific decision about TeX,=20
It does nothing of the sort; there is no mention of the word 'TeX' in
the DFSG.
Section 4 does precisely that, though without mentioning TeX by name.
In other words: I can live with Donald Knuth issuing a lic
But you want to be part of the discussion, right?
Debian developers on this list explicitly asked me to be part of the
discussion. They have often asked me questions, suggesting that I
send the answer to the list, and I have often done that. I don't
insist on discussing the matter here. A
Remember the hypothetical "emacs reference card", which must be
accompanied by 12 pages of additional invariant material? Sounds like a
big deal to me.
If the GPL were used, it would have to be accompanied by 6 pages
of additional invariant material. That is still bigger than the
The "document" consists of both packages. The fact that users are not
obligated to download both at the same time is irrelevant, just as it is
irrelevant to the GPL that users can choose to download binaries without
source; and just as it is irrelevant that users can choose to d
> Manuals are not free software, because they are not software.
> The DFSG very clearly treats "software" and "programs" as
> synonymous.
In that case, the DFSG prohibits their distribution outright.
That's one way to interpret it, but I don't think it is the best way.
The DFSG is
The Social contract uses the "that which is not hardware" definition of
software.
The words of the social contract clearly equate software to programs.
In that sense, there is nothing but software in Debian.
But Debian contains essays, logos, and licenses that cannot be
modified. T
Richard, for the sake of my blood pressure, please read
http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg00690.html
(bis repetita)
When you first told me about the page, you seemed to be criticizing me
for taking o long to read it. How I could have done what you asked
> I've decided not to do that. The development of GNU licenses is not a
> Debian issue.
Neither is the inclusion of GNU manuals in Debian a FSF issue.
That's what I said--at least twice in the past week.
> Manuals are not free software, because they are not software.
> The DFSG very clearly treats "software" and "programs" as
> synonymous.
Richard, once and for all, please read
http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg00690.html
Thanks for mentioning th
> Manuals are not free software, because they are not software.
> The DFSG very clearly treats "software" and "programs" as
> synonymous.
And we very clearly treat everything in Debian as software (see the
first clause of the Social Contract).
That clause appears to neglect t
Can you give us an indication as to what the clarified text will look
like, or what restrictions it will contain? [Just so we're all on the
same page with regards to the sections problems.]
I've decided not to do that. The development of GNU licenses is not a
Debian issue.
I couldn't believe that RMS actually wrote that when I read it.
You shouldn't have believed I actually wrote that, because he
misunderstood what I wrote. He omitted a crucial part of the
argument, so that what remained was absurd; then he went on at length
pointing out just how absurd it was.
As has been previously pointed out, fair use is far from a universal
concept. Within the United Kingdom, it doesn't exist, and copying a
single paragraph from a GFDLed work would require me to fulfil the
license conditions.
I am pretty sure something along the same lines as fair us
Well, since Debian will contain only 100% Free Software, and I think most
of us
(and you, if I interpret your previous emails correctly) agree that GFDL
manuals are not Free Software, it would seem to be a natural conclusion
that
Debian will not contain them.
Manuals are not f
Recently you said you'd contact a lawyer with respect to section 2 of
the GFDL. If you've had the chance, would you mind sharing the lawyer's
conclusion with debian-legal?
We decided to clarify the text there but it will take some time
to actually do so.
The argument for that is that there are many
> such manuals and they would be useful to include, and the DFSG can
> be interpreted to accept it.
The arguments appear to be:
1) There are many GFDL manuals.
2) The many GFDL manuals would be useful to include.
That's two
> It has to be prohibitively impractical in real cases. The
> inconveniences that occur in some cases with the GFDL are not
> prohibitive.
I'm a little sure what is "prohibitive". Can you flesh it out?
If you are asking for a bright line as to what is or isn't
prohibitive, I don
TeX allows us to make any changes we like provided we distribute the
changed source as a patch file, and provided we change the name if the
result doesn't pass the Trip test.
Yes, but my point is that the original TeX source code must be
included in the source distribution, and you can
> You have mistaken the objection. There is no reason to think it would
> be a small fractional increase, especially since little parts of
> manuals--single paragraphs even--are useful reusable bits just in the
> way that single functions of Lisp are.
>
> R
> The GNU Project's motive for using invariant sections is not the issue
> here; that's a GNU Project decision, not a Debian decision.
You are arguing that you should have a voice in what Debian does.
I have said nothing of the kind. The Debian developers decide what
Debian does, and
> So I think there really is no difference.
I meant that the GFDL requires you to have the license content itself as
part of the document, whereas it can be a seaprate file for the GPL.
Part of the document can be a separate file,
because a document can be more than one file.
This de
The only question I intend to discuss on this list is Debian's
decision about whether to use or not use GFDL-covered manuals.
They may cause practical
> inconvenience for some kinds of uses, but no more than that. The
> issue is basically the same as the issue of the preamble of the GPL.
Yes, they do. They say "you may not use this technical material
unless you also do this unrelated non-technical
Would you accept a similar restriction in a software license, and
still call the license free? (Say, one which said "you must always
distribute this function as part of the system".)
Yes, and the case of TeX is an example. It requires more than just
one function that you must include
To use one page of the GFDL-licensed work required one paragraph in the
Copyright page, the page I wanted to use, and a copy of the GFDL (so far the
same), plus:
1. the required front-cover text (on a page by itself before the excerpt:
"bracket" in the terms of the GFDL),
2.
The principal argument in favor of the GFDL seems
to be "this is the only way we can get our message out".
The GNU Project's motive for using invariant sections is not the issue
here; that's a GNU Project decision, not a Debian decision.
The question at hand is whether Debian should acc
For example, I might use a manual by tearing it into pieces and using
the individual pages as confetti for a parade. But I cannot copy
GFDL'd manuals and then do this.
I congratulate you on your imagination--it never occurred to me to
think about this as a use of a manual.
As it ha
You have mistaken the objection. There is no reason to think it would
be a small fractional increase, especially since little parts of
manuals--single paragraphs even--are useful reusable bits just in the
way that single functions of Lisp are.
Reusing a single paragraph is fair us
Then what is a real lack of freedom? I could use the regex code under
an invariant license;
If the license for the code did not allow modification, you could not
make it implement different behavior. You would substantively lack
the ability to change the functionality. That is a lack of
> The issue at hand for Debian is whether to include GFDL-covered
> manuals in the Debian GNU/Linux system. I am sticking to that
> issue.
Under the current GFDL 1.2, with the anti-DRM clause, there is
essentially no chance of that.
With all due respect, you do not necessaril
Someone writing
the (GFDL) manual for the GF45 compiler might have invariant sections,
but won't be willing to copy my rant into his work; better to rewrite
the section then annoy half the users.
The fact that you're talking about a hypothetical example decades away
suggests that
> My experience is just the opposite: our views are mostly suppressed.
> The open source movement is very effective at substituting their word
> for ours. I find that most of the people who use our software have
> never even heard of our philosophy.
I find that to be a cheap,
> > I explained in a message here, a couple of months ago, that this
> > difference in wording does not really lead to a difference in
> > consequences.
>
> Um, yes it does. Importantly, it allows for more flexible
> distribution strategies.
>
Not the same so far. As I read it, you can have the text of the FDGL as
(Did you mean "can't"? I think so.)
a separate file in /usr/share/doc/PACKAGE/copyright, it has to be
included in the derived work itself.
I'm not sure whether your talking about the files as installed
in a ma
So your purpose is to spread GNU propaganda in invariant sections of GNU
documentation, adding practical inconvenience where there shouldn't be.
It adds some practical inconvenience, but practically speaking the
magnitude is not great, so there's no reason not to do it.
How would you
> I explained in a message here, a couple of months ago, that this
> difference in wording does not really lead to a difference in
> consequences.
Um, yes it does. Importantly, it allows for more flexible
distribution strategies.
They allow the same distribution strategies.
I don't really believe it. In the 1980s, formalized free software was a
new concept for almost everybody. Today, there are too many free
software projects for the word _not_ to get out.
My experience is just the opposite: our views are mostly suppressed.
The open source movement is v
You have missed the point here, so I'll repeat it.
I didn't miss the point--I had not even seen it. The point you say I
"missed" was in a message that had not even arrived on my machine when
I wrote those words. I was responding to various points that I recall
having seen others make.
It ta
You can include the GPL as a separate file. It doesn't have to be
included in the derived work itself.
I explained in a message here, a couple of months ago, that this
difference in wording does not really lead to a difference in
consequences.
But there is a difference between the GPL-required text:
...
And the GFDL-required text:
They are different, but neither of them is really short, so I think
the practical consequences are more or less the same.
[ Page 12 is the "front cover" of the GFDL'd subwork, so has just the
Then, a license allowing to freely distribute a software or a modified
version
of this software in binary form only is free, but with a practical
inconvenience.
If you interpret my statements by stretching the term "practical
inconvenience" to the point where it means nothing any mo
- Maybe GNU should consider the option to provide its manuals
in two versions, one without philosophical/political/historical
texts, one as the current manuals.
I considered this possibility in the 1980s, not as an option but
rather as a potential problem. So I
"Other users consider proprietary manuals acceptable for the same reason
so many people consider proprietary software acceptable: they judge in
purely practical terms, not using freedom as a criterion. These people
are entitled to their opinions, but since those opinions spring from
Then, why don't you just create your own distribution based on
Debian? Take the official CD set, remove all references to
non-free, and distribute it from your server. Problem solved.
We thought about that, and we're still thinking about it.
In the past, this sort of thing was unusu
> I think you have demonstrated, better than I ever could,
> that your criticism is based on an unfair standard.
It isn't unfair, precisely because I think it's a two way street.
This is the standard that applies to both sides.
This "standard" is an indirect way of claiming you ar
Not having source is a mere inconvenience; you can always decompile the
program, read the assembly, translate it back into C, etc. Not being
able to distribute the program is only an inconvenience; you can always
rewrite it from scratch.
Those words are simply an indirect way of de
Saying "you can modify the documentation, just not the invariant
sections" isn't enough, incidentally, to answer this, because the
attachment of the invariant section to the documentation *is* a
property of the documentation. (Consider if there were such a thing
on a piece of s
> The term "heavily affected" is still an exaggeration. In any case,
> the effect is simply due to incompatibility. I posted a long message
> explaining that this sort of thing is a consequence of the existence
> of incompatible free licenses.
No, you've missed the point.
That's not a serious and sustained conversation. Such a
conversation would require that you seriously and carefully attend to
all the questions that other people ask, even the ones that make you
mad, even the ones that you think are attacks, even the ones that you
think are unf
... the fact that either you've stopped endorsing Debian, or
you've become more vocal about it.
I have never endorsed Debian, because ever since it became mature
enough to be technically suitable, it had the problem of recommending
and including non-free packages. Of course, the other a
> Another form of tangent is citing practical inconveniences, often
> shared with many other accepted free licenses, as if they were
> reasons to consider a license non-free.
This is incorrect. Practical inconveniences are precisely the point
in deciding whether a restriction
1 - 100 of 279 matches
Mail list logo
