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,
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
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
> 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
> 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
> 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
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 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
> 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
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
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
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 (
> 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
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
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
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
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
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.
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
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
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
> 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 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
- 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 guess I didn't say that too well. I feel betrayed because I thought
> the GPL was about respecting the work of other people.
The GPL is about establishing and defending the freedom to share and
change published software--about respecting community and cooperation.
The way to respect a
I agree with you and think this is an honorable things to do when the
author wishes it. I cannot agree that disrespecting an author's wishes
is the way to respect the author's program.
There's a certain level of respect that everyone deserves, but some
people have grandiose ideas of t
I believe clause 3 is compatible with the GPL, because the GPL has a
stricter requirement.
Clauses 4 and 5 are incompatible with the GPL because they are stated
as conditions of the license for the copyright. If similar
requirements were based on the publicity right (which exists in
certain juris
I believe that you can distribute a program under the GNU General Public
License and a seperate Trademark license. That is what AbiSource does with
AbiWord. And I don't think it restricts the freedom of the user since it
is still allowed to distribute derived works.
I agree.
W
IMAPD is included in main because it has a license which people
usually interpret as giving permission to distribute modified
versions.
But the University of Washington explicitly says they don't believe it
means this. In effect, we cannot consider IMAPD as free software
unless we are willing to
Here's a copy of the license:
# Copyright 1998 by the University of Washington
#
# Permission to use, copy, modify, and distribute this software and its
# documentation for any purpose and without fee is hereby granted, provided
Most people interpret this license wording as g
However, since the language of this license appears to have been borrowed
from the original MIT/X Consortium license, perhaps the people who wrote it
could be tracked down to offer their opinion.
We got lots of people on record saying they believe this license means
what we always thou
I've been told that you, or someone working with you, has threatened to
sue the FSF (Free Software Foundation) for distributing modified copies
of IMAPD.
I should point out that what I told you was not this. I said that the
U of W threatened to sue us if we distributed a modified vers
Can you email me a copy of the original pine source, which had this
license on it, so I can see for myself what I'm talking about?
Sorry, I cannot find that myself.
One crucial question that you did not ask was this one:
Can Debian distribute a modified version of IMAPD *and give everyone
permission to distribute their own secondary modified versions of
the Debian version*?
"Yes" would mean that people who get the Debian version would be
allowed to red
I've an outstanding, unanswered question which I've sent to UW in a
related context (IMAPD): what specific clause of the copyright is being
violated, when modified versions are distributed.
Their position was that the words "permission to copy, distribute and
modify" do not grant permi
Then it must also be true that one cannot copy and then distribute, or
distribute and then copy. Have you attempted to challenge them on this
point? Do they have English professors at UWash, or just semioticians?
I never thought of this argument. It could be a good point to raise
in
> Their position was that the words "permission to copy, distribute and
> modify" do not grant permission to distribute a modified version. In
> other words, they say you can distribute the software, and you can
> modify the software, but you can't modify it and then distribute the
> I don't either--but that is not the point. The point is that the U of
> W has actually threatened to sue the FSF for distributing a modified
> version of a program that was released under the same words.
Personally, I'm still in the process of confirming this.
I hope that the U
My program works well without the GPL library. Now if I sell this program,
and add a module that the customer may link with the GPL library, would I
violate the GPL of the library, and why ?
No court has ruled on this, but the FSF position is that this would
violate the GPL. The GPL w
My difficulty with this argument is that an owner of the copy of the GPL
library has a wide right to make a derivative work on the owner's computer
by virtue of the GPL and/or a more limited right in the U.S. by virtue of
section 117 of the U.S. Copyright Act.
In the scenario we we
The conclusion so far on debian-legal is that the DFARS clause simply
annuls most of the extra rights that US copyright law ordinarily
grants to the government, and so is not discriminating *against* the
government.
I am not a lawyer, and I don't know for sure what the clause means
What is the adequate licence for data, allowing the data to be accessible
by
all, used in all circumstances, and garanties the fact that all "redived
datas" are to be accessible in the very same way ?
You can use the GPL--it will work for anything as long as you
can figure out what
I believe that
data in a database (by that I mean a structured table or a collection of
structured tables maybe with a common data) are rather specific too and
need
a specific licence.
I think the question "what is the right license for data bases"
is too broad to be useful; di
Debian is speaking not so much about what you should use, but what
would count as "free" in the "free software" sense.
Is that right? Is that what the issue is?
Your message seems to start from the premise that the GNU FDL is
unacceptable. That is a rather controversial assertion, and you gave
no grounds for it. The only serious objection your message states is
this one:
there's nothing
stopping an author from marking an entire work as invariant
For instance, when a piece of software is submitted to Debian
and purports to be licensed under the GNU GPL, then -- in general -- it
is completely unproblematic.
Not quite--because you have to check that it really IS licensed
properly and clearly under the GPL. Sometimes the develo
I see no harm in your idea for /usr/share/doc//copyright, but
trying to exclude such material from elsewhere would cause big
problems between Debian and GNU. I will urge Debian most strongly
not to adopt this policy.
> I think "scour" is too strong a word. The invariant sections have to
> be listed in the notice that says the work is under the GFDL.
Yes, but again, you're relying on the honor system and hoping authors
will be principled.
That is always true, for any license. I explained that
At the same time I think you can understand why permitting works under a
given license into Debian if they come from the FSF, but not some other
organization, would be a problematic approach.
I agree. Debian should permit GFDL manuals from any source, provided
the GFDL has been applie
You're exaggerating my goal. I would be deluded indeed if I thought I
could pre-emptively snuff any future flamewars on this subject. What I
am trying to do is have a bright-line test (thanks for nailing down the
term for me) in place that will reduce their quantity and ferocity,
Such material may not exceed 16 binary kilobytes (16,384 bytes)
when viewed in plain-text form (treating all adjacent white space
characters as one byte).
GNU Emacs comes with more than 16k of such material. Much more. And
that is not even counting the material that is part of the
I don't see why. It is pretty obvious to me that the existing DFSG
provides no exceptions to clause 3. The work must be modifiable and
modified versions must be redistributable under the same license as the
original. Period. It doesn't say "except for the license text itself".
> GNU Emacs comes with some auxiliary material (non-technical articles)
> that does not allow modification. I think that should be ok
> because they are non-technical.
That's a perfectly legitimate position in its own right, but it cannot
reasonably be construed from the text
This is one possibility I proposed to RMS. Essentially, I proposed that
all Invariant Sections had to be placed in debian/copyright, and that
any duplicates of his Invariant text in the "actual" documentation would
be modifiable.
That is unacceptable because it would allow modifie
> That is unacceptable because it would allow modified versions of the
> GNU Manifesto.
=2E..but not modified versions that carried the FSF's endorsement (unless
the FSF decided to do so),
I understand that, but this won't be enough to make sure our message
gets through. So I wil
And you will continue doing that, even when pointed out that this puts
an obstacle to the reuse of technical documentation even among manuals
for free, GPL-licensed software?
It is not an obstacle--at most a small detour. And it is very
important to spread the word about GNU and free
I think Henning was referring to the case where one wants to use small
portions of a GNU Manual verbatim.
This is not a very serious issue, since it isn't hard to rewrite a
small amount of text. You can also refer to it with a hypertext link
instead of copying it.
I don't think there is
> This is not a very serious issue, since it isn't hard to rewrite a
> small amount of text. You can also refer to it with a hypertext link
> instead of copying it.
s/\/code/
Would you still feel the same way?
Text and code are very different--I'm not even sure what it would
Why does is this answer not sufficient in the case of software? When
the noxious BSD advertising clause was under consideration, this kind
of argument was no good.
The problem with the BSD advertising clause had to do with the special
situation of advertisements--for instance, the l
After further consideration, and discussions with some people whose
advice I rely on, I concluded that the Vim license does qualify as a
free software license. Its requirements don't go as far as the ones
that we rejected many years ago.
If you provide the source code with the modified program, but the
receiver loses it, he may ask for it again.
Under the GPL, if you distribute the source with the binaries, nobody
can insist on getting anything from you subsequently.
If you distribute just binaries, you must provide a wri
The Vim license keeps an
opening for a company to make a modified version of Vim and sell it, if
he can agree with me on the conditions.
This is always true. Regardless of what license you *state* in the
program, you always have the possibility of agreeing to some other
arrangement
What happens
to me if I am Joe Q. Ignorant User running my GNU/Linux distribution
with no source code on the machine, and I give my friend a copy of my
gcc executable?
Under the GPL, this is only allowed if you obtained this executable
with a written offer to provide source code,
Ten million Linux users can't be wrong!
If they think of themselves as "Linux users", they are wrong already
;-). The system is GNU; Linux is the kernel. They are really
GNU/Linux users.
See http://www.gnu.org/gnu/linux-and-gnu.html for more
explanation.
I notice Vim in testing links against libgpm, which is GPL (according
to /usr/doc/libgpmg1/copyright). Is this a problem, Vim's license being
GPL-incompatible?
Yes it is.
> Yep, that's the GPL. Of course, the person you give the binary to can
> say "you don't need to give me the source", and then you're off the
> hook. =20
Er, I don't think that's permitted, either.
Yes it is. You have to provide or offer the sources, but the person
who receives
Theoretically this would be possible. However, for the software to be
distributed with another license every person that contributed would have
to agree with it, since each person has the copyright for the part he
contributed under the GPL. Since there hardly ever is an explicit
We had this discussion before. Most people call the whole thing
"Linux". It's just a name that people use. It's very common for people
to use a name which isn't 100% right, but they do it anyway.
I am aware of how common this mistake is. However, this is more than
just a mistake; t
I have attempted to add the possibility to allow people to distribute a
modified Vim, under the condition that they include the source code.
This is a free software license, and I think it is better than the
current Vim license. So I encourage you to switch to this license.
It is not GPL-
>From Vim's point of view, the entire GPL'ed code constitute an
addition (a special case of a "change"), so it is all subject to the
conditions you apply to changes.
If you want to exempt, say, the addition of library code from your
conditions on modifications in general, you n
c) Provide the changes, including source code, with every copy of the
modified Vim you distribute. This may be done in the form of a
context diff. You can chose what license to use for new code you
add, so long as it does not restrict others fr
Another problem that I'm worried about is that many people will think
Vim _is_ GPL. It will be mentioned in lists in magazines and on web
sites. We would have to check and request correction where it's wrong.
Perhaps it would help to give a good name to the dual license. GPL++
> 2) A user of the modified Vim must be able to see that it was modified,
at
> least in the version information and in the intro screen.
>
> The GPL has a similar kind of requirement, but this is more specific,
> hence not GPL-compatible.
I could not find the simil
Because the company I worked for does not allow my work to be distributed
outside of the company, and that conflicts with the GPL.
This is a complete misunderstanding of the GPL. It does not require
anyone to release modified versions at all.
Hmm, I could add a 3e, which explicitly says that distribution under the
GPL is allowed, but only if the changes are also under the GPL license.
That would at least solve the problem of linking with the GPM library.
That might work--I'd have to see the precise wording before I could sa
What if I have a copy with no changes at all, and want to distribute it
linked against GPM? I have to make a change (so it's a "modified Vim")?
Linking against GPM counts as making a change in the program as a whole.
So that does not raise an issue.
However, one thing that should be note
This is wholly satisfactory to me, at least. To address one of your
other concerns, I don't think it would hurt to add the following
sentence:
"You are encouraged to license your changes under the Vim license as
well, and submit them to the Vim maintainer for possible inclusio
The GPL requires the freedom to be *allowed* to distribute the software
to anyone. The company rules forbid the distribution of the changes to
parties outside of the company. These two rules conflict.
It is not really a conflict. These copies belong to the company and
have never bee
I would rather see a note that this is not
the original Vim but a modified version. But I suppose I can't require
that without becoming GPL-incompatible...
I'm working on changing the GPL to make it possible to add certain
requirements along those lines. You might want to wait to s
If linking is "changing", that would seem to make licenses that say "you can
distribute unmodified binaries only" impossible--you'd only be able to
distribute binaries supplied by the author.
Not necessarily--these things are not as rigid as symbolic logic.
It's a matter of what intent
The first paragraph of the Vim license says that an unmodified Vim can
be distributed without restrictions. This is GPL compatible, right?
At this point, I am having trouble being sure. It depends on
questions which perhaps could be argued in different ways.
If you want to make a licens
That's a good thing. But I don't want to wait too long with the new Vim
license, hopefully Vim 6.1 will be released soon.
If you're happy with GPL version 2, then you can make the license
GPL-compatible now.
Also, some software
w
Claire M. Connelly" <[EMAIL PROTECTED]> has pointed out several other
problematic files. Some with a clear non-free license (e.g. "not on
cdrom" or "not sell") have been removed. But most of the packages have
some unclear status and I wonder if this should be resolved before I
m
Have you addressed all of the problem cases? (It looks that way, but
I'd need to look up the previous discussion and compare to determine
the answer. Whereas you probably know the answer already.)
Assuming that it is so, when are you expecting a new release?
--
To UNSUBSCRIBE, email to [EMAIL
The teTeX-beta from 2002-05-30 no longer contains any of the packages
with a known problematic license. I am now working towards a new stable
teTeX release and I don't think that we have to wait a long time for it.
This is good news--finally a truly free version of TeX!
--
To UNSUBS
My question is: do you think this license exception is
acceptable for use? That is, does it prevent the proprietary hijacking
of the linked GPL-incompatible library? Can you see any flaws in this?
I see one possible flaw: if someone includes a different COPYING.OpenSSL
file,
I suppose it would be tighter then, if you were to include the
OpenSSL license as an appendix to the copyright exception itself?
Yes. Or you could say "a derivative of the program OpenSSL published
by NAME OF ORGANIZATION".
Could we also pseudo-uniquely identify COPYI
1. Add a statement to the top of the file LICENSE.OpenSSL saying that
since it was effectively an extension to the license statements in the
individual source files in the hpoj package, only the copyright holder(s)
of those source files (namely HP) may update the LICENSE.OpenSSL fi
> Certain source files in this program permit linking with the OpenSSL
> library (http://www.openssl.org), which otherwise wouldn't be allowed
> under the GPL. For purposes of identifying OpenSSL, most source files
> giving this permission limit it to versions of OpenSSL having a l
I think word lists are copyrightable. The selection is a matter of
choice, not simple fact. Note that Feist applies only to the US;
phone directories may be copyrightable in some countries.
Compatibility with the GPL is not an issue here; the dictionary is
legally a separate work from any progra
> I think word lists are copyrightable. The selection is a matter of
> choice, not simple fact.
Is this a position statement of the FSF, at least if one reads the "are"
as "should be"?
It is a simple statement of the factual situation as I understand it.
It expresses no opinion.
I've been discussing this with the FSF's outside counsel, Dan Ravicher.
I have some ideas for how to generate a new word-list if we do end up
needing one, but I don't want to discuss them until I've talked with a
lawyer.
It looks like this "license" applies only to one of the word
I'm CCing RMS here because I know he's interested in hearing the
tentative decision we've come to.
The text I saw seems to say that this is one among several word lists
that Aspell comes with. My tentative decision was that we should
remove that particular word list from Aspell, and simpl
The GPL. They are proceeding with a good-faith effort to contact every
past and current contributor to ask if anyone has objections to a
license change. They also have another goal of assigning copyright to
the FSF in order to eventually get the package folded into Emacs.
I am gl
These are really important projects that claim to be free in the sense
of freedom. But I'd like to know, what Free Software Foundation and
readers of debian-legal think about those licences. So, please, evaluate
those licences carefully
The Creative Commons licenses are not suppos
But Helix DNA can handle other CODECs, too. Even Ogg Vorbis-support is
under development. If problems of RPSL will be rectified, even without
Real*-CODECs Helix DNA might be both free and useful software.
I guess so...but are we really able to do anything with it that
we can't do witho
Not consistently. The GNU FDL is a licensing initiative that is
apparently intended to be used for all FSF documentation. The
traditional GNU documentation license did not always include Invariant
Sections.
In the past, some of our manuals included invariant sections and some
did
Is the FSF willing to dual-license manuals that previously had no
invariant sections at all, such as _Debugging with GDB_, under the GNU
FDL and the traditional GNU documentation license simultaneously?
I don't see a reason to do so, but I won't absolutely rule it out.
Finally, wo
> In the past, some of our manuals included invariant sections and some
> did not. Today that is still the case. However, in the past we
> needed an ad hoc license to have invariant sections. What changed
> with the GFDL is that it is a single license that covers both cases.
101 - 200 of 279 matches
Mail list logo
