Re: The debate on Invariant sections (long)
On Sun, 1 Jun 2003 12:18:37 +0200, Alexandre Dulaunoy [EMAIL PROTECTED] said: Yes No. For example, a Free Software author wants to warn user for a specific usage of the software. The classical example is a RFID software that can be used as a tool against privacy. He adds a warning note in the documentation, the text is irremovable but other people can comment on the warning but they can't remove the warning. Hmm. If the software is free, I can then change the software to remove the specific behaviour being warned against; but the documentation still contains a incorrect, and irremovable warning. I supppose I can tack on even more irremovable text to counter the warning (perhaps confusing the users). I would consider that not free for other electronic entities; I consider it similarily limiting when it comes to the documentation. manoj -- The way these things go, there are probably 6 or 8 kludgey ways to do it, and a better way that involves rethinking something that hasn't been rethunk yet. Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Source Code of Music (was: various opinions on Debian vs the GFDL)
Thomas Uwe Gruettmueller [EMAIL PROTECTED]: You have a similar but less severe problem if A is a high-precision digital recording (with lots of random noise in the low bits) and D is a compressed version: clearly A is source of D, I would argue that D is an excerpt of A. If someone were to improve the compression algorithm then you would want to go back and recompute D, particularly if D has an audible artefact, so I would say that A is source. Of course, if we're talking about lossless compression (possibly preceded by throwing away the low bits) then I might agree it's an excerpt, but I was thinking about something like Ogg Vorbis. Edmund
License of Emacs modes
Hi, Since Emacsen are GPL-licensed, do Emacs modes have to be shipped under a GPL-compatible license? I discovered one of them which could be problematic. Thanks. -- Jérôme Marant
Re: License of Emacs modes
Jérôme Marant [EMAIL PROTECTED] wrote: Since Emacsen are GPL-licensed, do Emacs modes have to be shipped under a GPL-compatible license? Pretty much. It is possible to write stand-alone elisp code that only uses Emacs internals. At that point you are okay, treating Emacs has an interpreter only (so the code it interprets doesn't have to be under a GPL-compatible license). But as soon as you load an Emacs lisp library and use it, then you'll using a GPL'ed library (as opposed to an LGPL'ed one) and your code must be GPL-compatible (if you distribute it of course). I discovered one of them which could be problematic. Is it ilisp? Peter
Re: License of Emacs modes
En réponse à Peter S Galbraith [EMAIL PROTECTED]: Jérôme Marant [EMAIL PROTECTED] wrote: Since Emacsen are GPL-licensed, do Emacs modes have to be shipped under a GPL-compatible license? Pretty much. It is possible to write stand-alone elisp code that only uses Emacs internals. At that point you are okay, treating Emacs has an interpreter only (so the code it interprets doesn't have to be under a GPL-compatible license). But as soon as you load an Emacs lisp Err, I thought the license of interpreted programs had to be compatible with the license of interpreters (I recall the Python licensing problems, before Python 2.1). Did I misunderstand? library and use it, then you'll using a GPL'ed library (as opposed to an LGPL'ed one) and your code must be GPL-compatible (if you distribute it of course). Ah, you mean that there is only a problem when an elisp code loads some elisp libraries ? I discovered one of them which could be problematic. Is it ilisp? No, erlang-mode, which is licensed under EPL. Cheers, -- Jérôme Marant [EMAIL PROTECTED] [EMAIL PROTECTED] http://marant.org
Re: Open Software License
On Tue, Jun 03, 2003 at 05:21:48PM -0700, Walter Landry wrote: Anthony DeRobertis [EMAIL PROTECTED] wrote: On Mon, 2003-06-02 at 16:16, Joey Hess wrote: 10) Jurisdiction, Venue and Governing Law. You agree that any lawsuit arising under or relating to this License shall be maintained in the courts of the jurisdiction wherein the Licensor resides or in which Licensor conducts its primary business, and under the laws of that jurisdiction excluding its conflict-of-law provisions. Haven't we rejected these clauses before? This is no different than Under the laws of the Commonwealth of Virginia, United States except its much more confusing (where does the licensor live today?) I don't think so. It isn't GPL compatible, which is why there was a big fuss about the Python license. But it wasn't considered non-free. I've argued that it's non-free, though. Moreover, from a copyright law perspective, nothing grants a copyright holder the power to forum-shop. -- G. Branden Robinson| It just seems to me that you are Debian GNU/Linux | willfully entering an arse-kicking [EMAIL PROTECTED] | contest with a monstrous entity http://people.debian.org/~branden/ | that has sixteen legs and no arse. pgpVMtg0vB417.pgp Description: PGP signature
Re: License of Emacs modes
Jérôme Marant [EMAIL PROTECTED] wrote: En réponse à Peter S Galbraith [EMAIL PROTECTED]: Jérôme Marant [EMAIL PROTECTED] wrote: Since Emacsen are GPL-licensed, do Emacs modes have to be shipped under a GPL-compatible license? Pretty much. It is possible to write stand-alone elisp code that only uses Emacs internals. At that point you are okay, treating Emacs has an interpreter only (so the code it interprets doesn't have to be under a GPL-compatible license). But as soon as you load an Emacs lisp Err, I thought the license of interpreted programs had to be compatible with the license of interpreters I don't think so. (I recall the Python licensing problems, before Python 2.1). Did I misunderstand? I don't recall what the issues were. library and use it, then you'll using a GPL'ed library (as opposed to an LGPL'ed one) and your code must be GPL-compatible (if you distribute it of course). Ah, you mean that there is only a problem when an elisp code loads some elisp libraries ? Right. I discovered one of them which could be problematic. Is it ilisp? No, erlang-mode, which is licensed under EPL. Yeah, it loads various libraries. I haven't looked at the license to see what makes it GPL-uncompatible. While you're at it, ask the DD to byte-compile the files like most all other elisp packages do! :-) Peter
Re: License of Emacs modes
En réponse à Peter S Galbraith [EMAIL PROTECTED]: Err, I thought the license of interpreted programs had to be compatible with the license of interpreters I don't think so. You are right. There answer is there: http://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat No, erlang-mode, which is licensed under EPL. Yeah, it loads various libraries. I haven't looked at the license to see what makes it GPL-uncompatible. EPL is a MPL derivative. You can find a link to it at www.erlang.org. While you're at it, ask the DD to byte-compile the files like most all other elisp packages do! :-) OK. Cheers, -- Jérôme Marant
Re: Source Code of Music (was: various opinions on Debian vs the GFDL)
Hi Edmund,
On Dienstag 03 Juni 2003 19:12, Edmund GRIMLEY EVANS wrote:
Thomas Uwe Gruettmueller [EMAIL PROTECTED]:
You have a similar but less severe problem if A is a
high-precision digital recording (with lots of random
noise in the low bits) and D is a compressed version:
clearly A is source of D,
I would argue that D is an excerpt of A.
If someone were to improve the compression algorithm then you
would want to go back and recompute D, particularly if D has
an audible artefact, so I would say that A is source.
The GPL defines the source code for a work [to mean] the
preferred form of the work for making modifications to it (l.
155f). If I take a wav file, compress it into the Vorbis format,
and decompress it back to wav, I can modify this file the same
way as I could do with the original one. There are differences
in the files' contents, but there is no functional difference.
(The resulting file will even have the same length as the
original one, which is not true for a decompressed MP3.)
This is IMHO something entirely different than compiling and
decompiling a program. In this case, the entire program would
become less readable and thus much less modifyable.
Of course, if we're talking about lossless compression
(possibly preceded by throwing away the low bits)
With lossless compression algorithm (like flac), nothing is
thrown away. It works more like gzip.
then I might agree it's an excerpt, but I was thinking about
something like Ogg Vorbis.
I was thinking about these cases:
A) I don't have enough bandwith or webspace to distribute the
entire uncompressed work. So, in order to reduce the file size,
I could reduce the duration of the recording, by only
distributing the most interesting part. This would be clearly an
excerpt.
B) If I wanted to preserve the sample's duration, I could also
throw away details all across the sample, by reducing the sample
rate, the bit resolution, and the number of channels. I would
still consider this an excerpt.
C) I could also use a more advanced lossy compression codec like
Vorbis. Like in A and B, I would throw away data, but the losses
would be better selected. I would still consider this an
excerpt, and an even more desirable one than the one in B,
especially for modification purposes.
cu,
Thomas
}:o{#
--
http://www.bildungsbande.de/~sloyment/
Look! They have different music on the dance floor...
Re: GDB Manual
Whether to change the GFDL is not a Debian decision, so I've decided not to discuss that here. Is there a public forum where you are willing to discuss that? Not now, and not in the way that some people want to discuss it (they throw stones at me while I stand there and get hit). They outnumber me, and I can't keep up with them, so I don't think it is useful to try. This is a remarkable interpretation of the generally polite, reasoned discussion here. We aren't trying to throw stones at you. We certainly don't want you to keep up (by throwing stones back ?!?). I, anyway, attribute no malice to you. (Merely incompetence. ;-) ) Do you realize that at least one GNU contributor is quite unhappy about the use of the GFDL on their work? See http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00256.html You still haven't answered two questions put to you publicly, which are important for clarification of where you're coming from. If we got clearer answers, we wouldn't keep asking you questions. 1. I asked: Where there is definite consensus is that shackling a technical manual to a political statement imposes unacceptably non-free restrictions on the right to modify the technical manual. You clearly believe that these restrictions simply aren't important. This appears to be because you believe that the types of modification which are restricted (generally speaking, modifications to fit in tightly limited spaces, either physical or programmatic) aren't necessary for freedom. Is this correct? ^^^ If it's correct, I, for one, will not discuss this with you further, because I see no way of changing such an opinion. If I am *wrong* and I have misunderstood your position, I want to be corrected so that I do not misrepresent you! 2. Branden Robinson said to you: Aside from yourself, is there anyone entitled to interpret the GNU Project's standards? This is a real question. If the answer is no, obviously there's no point in talking to anyone *but* you about the GNU Project's standards. If the answer is yes, then there are other people who we can ask questions of, see if they have different opinions, or simply if we can get clearer and more specific responses.
Re: The debate on Invariant sections (long)
RMS said: I've looked at the problems people have reported. Many of them are misunderstandings (what they believe is not allowed actually is allowed), many of these cases have adequate workarounds, and the rest are real inconveniences that shouldn't be exaggerated. OK... but... I've explained examples of all of these. Actually, that's where you're wrong. You *haven't* explained examples of all of these, and some of those explanations you have given have been found woefully insufficient. (Of course, *you* don't need to do this; I'm sure you're very busy. Any official representative of the FSF would do just fine.) -- I couldn't find a single instance of a 'misunderstanding' explained by you. In a few cases, you claimed that something was allowed by fair use, but you were in fact wrong for at least the UK. -- The only instance of an 'adequate workaround' I saw was a license incompatibility problem, where you claimed that it was 'always better' for a manual to be separate from the code and read by the code. Several people felt that this was not an adequate workaround for the incompatibility, let alone 'better'. -- Pretty much everything else you responded to, you said was an inconvenience being exaggerated, but was not non-free because it was only a 'packaging restriction'. (An interesting point, certainly. Although it took a ridiculous amount of time before we managed to get this statement on why you believed non-removable sections did not render a document non-free; previously we'd been trying to guess your position, which doesn't usually work.) Several people tried to open a debate about the issue of when a restriction is a packaging restriction and when it's a fundamental restriction, since they disagreed. You refused to discuss this. The only real problems seem to come from incompatibility of licenses. I'm glad you recognize those problems. :-) Happiness! Now, does the FSF have plans to do anything about them? If so, great! If not, why not? --Nathanael
