cdrecord: weird GPL interpretation
Francesco Poli
in cdrtools-2.01a38 I found the following weird GPL interpretation.
I wonder if this is considered acceptable for main (I would say that
this is non-free). I don't know whether cdrecord links with (or is
otherwise a derivative work of) other GPL'd software (whose copyright is
held by other people): in that case I would say that this is even
undistributable... :(
What do you think about this?
There already is a Debian BTS bug report
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265546) about this
issue (it was filed when it was even worse, it seems...), but it says
it's resoved with version 2.01a38. I wonder if you agree...
NOTE: I am Cc:ing the the package maintainer (Joerg Jaspert) and the
bug-report filer (Andreas Metzler).
I don't know if they would like to be Mail-Followup:ed...
Issue description follows:
-=-=-=-= cdrecord/LICENSE =-=-=-=-
This software is under GPL but you should read the following
clarifications:
- You may not modify certain copyright messages in cdrecord.c
See cdrecord.c for further information.
- You may (with a few exceptions) not modify the location of the
configuration file /etc/default/cdrecord.
See defaults.c for further information.
Please note that this is just the way I interpret the GPL and as this
is my software, users should follow my interpretation of the GPL and not
use their own different interpretations.
-=-=-=-= cdrecord/cdrecord.c (sorry for linewrapping) =-=-=-=-
[...]
/*
* Begin restricted code for quality assurance.
*
* Warning: you are not allowed to modify or to remove the
* Copyright and version printing code below!
* See also GPL § 2 subclause c)
*
* If you modify cdrecord you need to include additional version
* printing code that:
*
* - Clearly states that the current version is an
* inofficial (modified) version and thus may have bugs
* that are not present in the original.
*
* - Print your support e-mail address and tell people that
* you will do complete support for this version of
* cdrecord.
*
* Or clearly state that there is absolutely no support
* for the modified version you did create.
*
* - Tell the users not to ask the original author for
* help.
*
* This limitation definitely also applies when you use any other
* cdrecord release together with libscg-0.6 or later, or when you
* use any amount of code from cdrecord-1.11a17 or later.
* In fact, it applies to any version of cdrecord, see also
* GPL Preamble, subsection 6.
*
* I am sorry for the inconvenience but I am forced to do this because
* some people create inofficial branches. These branches create
* problems but the initiators do not give support and thus cause the
* development of the official cdrecord versions to slow down because
* I am loaded with unneeded work.
*
* Please note that this is a memorandum on how I interpret the GPL.
* If you use/modify/redistribute cdrecord, you need to accept it
* this way.
*
*
* The above statement is void if there has been neither a new version
* of cdrecord nor a new version of star from the original author
* within more then a year.
*/
/*
* Ugly, but Linux incude files violate POSIX and #define printf
* so we cannot include the #ifdef inside the printf() arg list.
*/
# define PRODVD_TITLE ""
#ifdef CLONE_WRITE
# define CLONE_TITLE "-Clone"
#else
# define CLONE_TITLE ""
#endif
if ((flags & F_MSINFO) == 0 || lverbose || flags & F_VERSION) {
printf("Cdrecord%s%s %s (%s-%s-%s) Copyright (C) 1995-2004 Jörg
Schilling\n",
PRODVD_TITLE,
CLONE_TITLE,
cdr_version,
HOST_CPU, HOST_VENDOR, HOST_OS);
#if defined(SOURCE_MODIFIED) || !defined(IS_SCHILY_XCONFIG)
#define INSERT_YOUR_EMAIL_ADDRESS_HERE
#define NO_SUPPORT 0
printf("NOTE: this version of cdrecord is an inofficial
(modified) release of cdrecord\n");
printf(" and thus may have bugs that are not present in the
original version.\n");
#if NO_SUPPORT
printf(" The author of the modifications decided not to
provide a support e-mail\n");
printf(" address so there is absolutely no support for this
version.\n");
#else
printf(" Please send bug reports and support requests to
<%s>.\n", INSERT_YOUR_EMAIL_ADDRESS_HERE);
#endif
printf(" The original author should not be bothered with
problems of this version.\n");
printf("\n");
#endif
#if !defined(IS_SCHILY_XCONFIG)
printf("\nWarning: This version of cdrecord has not been
configured via the standard\n");
printf("autoconfiguration method of the Schily makefile system.
There is a high risk\n");
printf("that the code is not configured correctly and for this
reason will not behave\n");
printf("as expected.\n");
#endif
}
/*
* I am sorry that even for version 1.295 of cdrecord.c, I am forced to
do
* things like this, but defective versions of cdrecord cause a lot of
* work load to me and it seems to be impossible to otherwise convince
* SuSE to cooperate.
* As people contact me and bother me with the related problems,
* it is obvious that SuSE is violating subsection 6 in the preamble of
* the GPL.
*
* The reason for including a test against SuSE's private
* distribution environment is only that SuSE violates the GPL for
* a long time and seems not to be willing to follow the requirements
* imposed by the GPL. If SuSE starts to ship non defective versions
* of cdrecord or informs their customers that they would need to
* compile cdrecord themselves in order to get a working cdrecord,
* they should contact me for a permission to change the related test.
*
* Note that although the SuSE test is effective only for SuSE, the
* intention to have non bastardized versions out is not limited
* to SuSE. It is bad to see that in special in the "Linux" business,
* companies prefer a model with many proprietary differing programs
* instead of cooperating with the program authors.
*/
linuxcheck(); /* For version 1.295 of cdrecord.c */
if (flags & F_VERSION)
exit(0);
/*
* End restricted code for quality assurance.
*/
[...]
-=-=-=-= cdrecord/defaults.c =-=-=-=-
[...]
LOCAL int
open_cdrdefaults()
{
/*
* WARNING you are only allowed to change this filename if you also
* change the documentation and add a statement that makes clear
* where the official location of the file is why you did choose a
* nonstandard location and that the nonstandard location only refers
* to inofficial cdrecord versions.
*
* I was forced to add this because some people change cdrecord without
* rational reason and then publish the result. As those people
* don't contribute work and don't give support, they are causing extra
* work for me and this way slow down the cdrecord development.
*/
return (defltopen("/etc/default/cdrecord"));
}
[...]
--
| GnuPG Key ID = DD6DFCF4 | $ fortune
Francesco | Key fingerprint = | Q: What is purple
Poli | C979 F34B 27CE 5CD8 DC12 | and commutes?
| 31B5 78F4 279B DD6D FCF4 | A: A boolean grape.
Måns Rullgård
> Hi all,
> in cdrtools-2.01a38 I found the following weird GPL interpretation.
> I wonder if this is considered acceptable for main (I would say that
> this is non-free). I don't know whether cdrecord links with (or is
> otherwise a derivative work of) other GPL'd software (whose copyright is
> held by other people): in that case I would say that this is even
> undistributable... :(
>
> What do you think about this?
> There already is a Debian BTS bug report
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265546) about this
> issue (it was filed when it was even worse, it seems...), but it says
> it's resoved with version 2.01a38. I wonder if you agree...
>
> NOTE: I am Cc:ing the the package maintainer (Joerg Jaspert) and the
> bug-report filer (Andreas Metzler).
> I don't know if they would like to be Mail-Followup:ed...
>
> Issue description follows:
>
> -=-=-=-= cdrecord/LICENSE =-=-=-=-
>
> This software is under GPL but you should read the following
> clarifications:
>
> - You may not modify certain copyright messages in cdrecord.c
>
> See cdrecord.c for further information.
Looks like an invariant section of GFDL infamy.
> - You may (with a few exceptions) not modify the location of the
> configuration file /etc/default/cdrecord.
>
> See defaults.c for further information.
Looks like lunacy. I don't recall ever reading anything about that in
the GPL.
> Please note that this is just the way I interpret the GPL and as this
> is my software, users should follow my interpretation of the GPL and not
> use their own different interpretations.
>
> -=-=-=-= cdrecord/cdrecord.c (sorry for linewrapping) =-=-=-=-
I take it someone on this list followed the recent flame war on lkml.
--
Måns Rullgård
m...@mru.ath.cx
--
To UNSUBSCRIBE, email to debian-leg...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Glenn Maynard
> -=-=-=-= cdrecord/LICENSE =-=-=-=-
>
> This software is under GPL but you should read the following
> clarifications:
>
>
> - You may not modify certain copyright messages in cdrecord.c
>
> See cdrecord.c for further information.
>
>
> - You may (with a few exceptions) not modify the location of the
> configuration file /etc/default/cdrecord.
>
> See defaults.c for further information.
>
> Please note that this is just the way I interpret the GPL and as this
> is my software, users should follow my interpretation of the GPL and not
> use their own different interpretations.
This came up previously:
http://lists.debian.org/debian-legal/2003/10/msg00398.html
I concur with Mathieu Roy: this is not an interpretation that follows
from the GPL. The GPL clearly says you can do certain things and can
not do certain other things; this "interpretation" contradicts the
text of the GPL.
I don't think it's safe to distribute a work where the author says one
thing in his license text and a different thing in his "interpretation".
This person does not want the GPL; he wants something else.
I do not believe that granting a license and then applying a bizarre
"interpretation" or "clarification" to those terms is an acceptable
approach to setting license terms.
I also don't think Debian should distribute works that claim to be under
the "GPL" when they're being modified by weird "interpretations".
(This is only my own opinion, of course, and not necessarily Debian policy.)
> -=-=-=-= cdrecord/cdrecord.c (sorry for linewrapping) =-=-=-=-
>
> [...]
> /*
> * Begin restricted code for quality assurance.
> *
> * Warning: you are not allowed to modify or to remove the
> * Copyright and version printing code below!
This is still clearly non-free. Requiring an appropriate copyright
notice is acceptable; prohibiting me from modifying the code that does
so is not.
> * See also GPL § 2 subclause c)
> *
> * If you modify cdrecord you need to include additional version
> * printing code that:
> *
> * - Clearly states that the current version is an
> * inofficial (modified) version and thus may have bugs
> * that are not present in the original.
> *
> * - Print your support e-mail address and tell people that
> * you will do complete support for this version of
> * cdrecord.
> *
> * Or clearly state that there is absolutely no support
> * for the modified version you did create.
This has been improved since the last time this came up, at least.
> *
> * - Tell the users not to ask the original author for
> * help.
I don't know if it's free to require all of this cruft. I sure don't like
having to say "this software is buggy, the original is probably better!".
It's not clear whether this needs to be printed every time, or just in eg.
"--version" output. I don't know if the answer to that affects freeness.
> * This limitation definitely also applies when you use any other
> * cdrecord release together with libscg-0.6 or later, or when you
> * use any amount of code from cdrecord-1.11a17 or later.
> * In fact, it applies to any version of cdrecord, see also
> * GPL Preamble, subsection 6.
I wasn't aware that the GPL's preamble had subsections.
> /*
> * WARNING you are only allowed to change this filename if you also
> * change the documentation and add a statement that makes clear
> * where the official location of the file is why you did choose a
> * nonstandard location and that the nonstandard location only refers
> * to inofficial cdrecord versions.
> *
> * I was forced to add this because some people change cdrecord without
> * rational reason and then publish the result. As those people
> * don't contribute work and don't give support, they are causing extra
> * work for me and this way slow down the cdrecord development.
> */
> return (defltopen("/etc/default/cdrecord"));
Requiring that I explain (or even have) rationale for changes can't possibly
be free.
--
Glenn Maynard
MJ Ray
> Francesco Poli <f...@firenze.linux.it> writes:
>> in cdrtools-2.01a38 I found the following weird GPL interpretation.
[...]
>> - You may not modify certain copyright messages in cdrecord.c
>> See cdrecord.c for further information.
> Looks like an invariant section of GFDL infamy. [...]
Well, this is like a misapplied bad invariant section, one that relates to the main subject and may actually be untrue. As far as I can tell, it's not an interpretation or clarification, but a direct contradiction of the GPL. The same goes for the restrictions on the config file default location. I guess that means we don't have a viable licence :-/
> I take it someone on this list followed the recent flame war on lkml.
Heh. Any flame war in particular?
--
MJR/slef My Opinion Only and not of any group I know
http://www.ttllp.co.uk/ for creative copyleft computing
Please email about: BT alternative for line rental+DSL;
Education on SMEs+EU FP6; office filing that works fast
Måns Rullgård
> On 2004-09-01 23:40:43 +0100 Måns Rullgård <m...@mru.ath.cx> wrote:
>
>> Francesco Poli <f...@firenze.linux.it> writes:
>>> in cdrtools-2.01a38 I found the following weird GPL interpretation.
> [...]
>>> - You may not modify certain copyright messages in cdrecord.c See
>>> cdrecord.c for further information.
>> Looks like an invariant section of GFDL infamy. [...]
>
> Well, this is like a misapplied bad invariant section, one that
> relates to the main subject and may actually be untrue. As far as I
> can tell, it's not an interpretation or clarification, but a direct
> contradiction of the GPL. The same goes for the restrictions on the
> config file default location. I guess that means we don't have a
> viable licence :-/
>
>> I take it someone on this list followed the recent flame war on
>> lkml.
>
> Heh. Any flame war in particular?
Jörg Schilling vs. rest of list.
Steve McIntyre
>On Thu, Sep 02, 2004 at 12:19:26AM +0200, Francesco Poli wrote:
>> Please note that this is just the way I interpret the GPL and as this
>> is my software, users should follow my interpretation of the GPL and not
>> use their own different interpretations.
>
>This came up previously:
>
> http://lists.debian.org/debian-legal/2003/10/msg00398.html
>
>I concur with Mathieu Roy: this is not an interpretation that follows
>from the GPL. The GPL clearly says you can do certain things and can
>not do certain other things; this "interpretation" contradicts the
>text of the GPL.
>
>I don't think it's safe to distribute a work where the author says one
>thing in his license text and a different thing in his "interpretation".
>This person does not want the GPL; he wants something else.
>
>I do not believe that granting a license and then applying a bizarre
>"interpretation" or "clarification" to those terms is an acceptable
>approach to setting license terms.
>
>I also don't think Debian should distribute works that claim to be under
>the "GPL" when they're being modified by weird "interpretations".
>
>(This is only my own opinion, of course, and not necessarily Debian policy.)
Joerg's changes are clearly non-free; I've not seen anybody arguing
otherwise. We basically need to route around him at this point, and
fork from a previous free version. His ridiculous statement that his
new statements also apply to older (GPL) versions of cdrtools should
just be ignored as the puffery that it is IMHO...
--
Steve McIntyre, Cambridge, UK. st...@einval.com
Getting a SCSI chain working is perfectly simple if you remember that there
must be exactly three terminations: one on one end of the cable, one on the
far end, and the goat, terminated over the SCSI chain with a silver-handled
knife whilst burning *black* candles. --- Anthony DeBoer
Bas Zoetekouw
You wrote:
> Joerg's changes are clearly non-free; I've not seen anybody arguing
> otherwise. We basically need to route around him at this point, and
> fork from a previous free version. His ridiculous statement that his
> new statements also apply to older (GPL) versions of cdrtools should
> just be ignored as the puffery that it is IMHO...
Please note that also the dvdrtools currently in Debian has this same
license. I'll file a bug in a minute.
--
Kind regards,
+--------------------------------------------------------------------+
| Bas Zoetekouw | GPG key: 0644fab7 |
|----------------------------| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| b...@o2w.nl, b...@debian.org | a2b1 2bae e41f 0644 fab7 |
+--------------------------------------------------------------------+
Brian Thomas Sniffen
> Joerg's changes are clearly non-free; I've not seen anybody arguing
> otherwise. We basically need to route around him at this point, and
> fork from a previous free version. His ridiculous statement that his
> new statements also apply to older (GPL) versions of cdrtools should
> just be ignored as the puffery that it is IMHO...
While legally you're right, I think from a point of view of politeness
you're wrong. Maybe somebody who isn't Debian will fork cdrtools, but
in the meantime it should just be moved to non-free.
-Brian
--
Brian Sniffen b...@alum.mit.edu
Andrew Suffield
> Steve McIntyre <st...@einval.com> writes:
>
> > Joerg's changes are clearly non-free; I've not seen anybody arguing
> > otherwise. We basically need to route around him at this point, and
> > fork from a previous free version. His ridiculous statement that his
> > new statements also apply to older (GPL) versions of cdrtools should
> > just be ignored as the puffery that it is IMHO...
>
> While legally you're right, I think from a point of view of politeness
> you're wrong. Maybe somebody who isn't Debian will fork cdrtools, but
> in the meantime it should just be moved to non-free.
We need a valid license to ship it in non-free, and this doesn't
really seem to be one.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Måns Rullgård
> Steve McIntyre <st...@einval.com> writes:
>
>> Joerg's changes are clearly non-free; I've not seen anybody arguing
>> otherwise. We basically need to route around him at this point, and
>> fork from a previous free version. His ridiculous statement that his
>> new statements also apply to older (GPL) versions of cdrtools should
>> just be ignored as the puffery that it is IMHO...
>
> While legally you're right, I think from a point of view of politeness
> you're wrong.
Go read some postings by JS and you won't feel any need for
politeness.
--
Måns Rullgård
m...@mru.ath.cx
Brian Thomas Sniffen
> Brian Thomas Sniffen <b...@alum.mit.edu> writes:
>
>> Steve McIntyre <st...@einval.com> writes:
>>
>>> Joerg's changes are clearly non-free; I've not seen anybody arguing
>>> otherwise. We basically need to route around him at this point, and
>>> fork from a previous free version. His ridiculous statement that his
>>> new statements also apply to older (GPL) versions of cdrtools should
>>> just be ignored as the puffery that it is IMHO...
>>
>> While legally you're right, I think from a point of view of politeness
>> you're wrong.
>
> Go read some postings by JS and you won't feel any need for
> politeness.
I've read them. It doesn't seem any worse than the drivel which shows
up here regularly. Joerg tells Alan Cox he doesn't know anything
about Linux systems or security. People here say things about that
ridiculous once a week -- you've seen them too.
On the other hand, I find this message interesting:
http://lkml.org/lkml/2004/8/19/111
In particular, he seems to be relying on German "Authors' Rights", and
claims to be in discussion with Debian people. That's nearly a month
ago.
Raul Miller
> you're wrong. Maybe somebody who isn't Debian will fork cdrtools, but
> in the meantime it should just be moved to non-free.
Distributing a forked copy is just as polite (or impolite) as distributing
a forkable copy.
--
Raul
Raul Miller
> http://lkml.org/lkml/2004/8/19/111
Is there any chance that someone has hacked his account?
Alternatively, is there any chance that he's writing in german and
relying on a program to translate what he says?
Or, maybe, that he has some really significant problems understanding
what a number of english words mean?
--
Raul
Steve McIntyre
>Steve McIntyre <st...@einval.com> writes:
>
>> Joerg's changes are clearly non-free; I've not seen anybody arguing
>> otherwise. We basically need to route around him at this point, and
>> fork from a previous free version. His ridiculous statement that his
>> new statements also apply to older (GPL) versions of cdrtools should
>> just be ignored as the puffery that it is IMHO...
>
>While legally you're right, I think from a point of view of politeness
>you're wrong. Maybe somebody who isn't Debian will fork cdrtools, but
>in the meantime it should just be moved to non-free.
Politeness works both ways. Joerg is one of the most difficult FS
authors I've ever dealt with, and has been causing flamewars on many
lists for a long time. It wouldn't be the first time that we had
forked software to get away from an awkward upstream licensing change;
look at XFree86, for example. If he takes offence, that's his problem;
he should not have released under GPL.
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"C++ ate my sanity" -- Jon Rabone
Brian Thomas Sniffen
> On Thu, Sep 02, 2004 at 09:19:58AM -0400, Brian Thomas Sniffen wrote:
>> While legally you're right, I think from a point of view of politeness
>> you're wrong. Maybe somebody who isn't Debian will fork cdrtools, but
>> in the meantime it should just be moved to non-free.
>
> Distributing a forked copy is just as polite (or impolite) as distributing
> a forkable copy.
I suppose that's true, but I don't see how it is relevant. The author
claims, madly, that his code isn't forkable in this regard and never
has been. It doesn't matter that his assertions about the GPL are
dribbling lunacy, and that I wouldn't trust him to interpret the
meaning of a bowl of oatmeal, much less EU Authors' Rights law.
In this case, what matters is that nobody be able to say "Debian took
this guy's software and did something he didn't want done with it."
-Brian
--
Brian Sniffen b...@alum.mit.edu
Raul Miller
> In this case, what matters is that nobody be able to say "Debian took
> this guy's software and did something he didn't want done with it."
Given the nonsense that's been posted in his name, there's some serious
doubt that we even know what he wants done with it -- and more doubt
that what he wants done with it is self consistent.
I do agree that we should avoid upgrading to versions he's provided which
are accompanied by statements about copyright which conflict with the GPL.
But I don't see any valid reason for pulling prior versions out of main.
--
Raul
Måns Rullgård
> Måns Rullgård <m...@mru.ath.cx> writes:
>
>> Brian Thomas Sniffen <b...@alum.mit.edu> writes:
>>
>>> Steve McIntyre <st...@einval.com> writes:
>>>
>>>> Joerg's changes are clearly non-free; I've not seen anybody arguing
>>>> otherwise. We basically need to route around him at this point, and
>>>> fork from a previous free version. His ridiculous statement that his
>>>> new statements also apply to older (GPL) versions of cdrtools should
>>>> just be ignored as the puffery that it is IMHO...
>>>
>>> While legally you're right, I think from a point of view of politeness
>>> you're wrong.
>>
>> Go read some postings by JS and you won't feel any need for
>> politeness.
>
> I've read them. It doesn't seem any worse than the drivel which shows
> up here regularly. Joerg tells Alan Cox he doesn't know anything
> about Linux systems or security. People here say things about that
> ridiculous once a week -- you've seen them too.
Add to that an arrogant center-of-the-world attitude (you can't change
the kernel now, cdrecord is in code freeze pending release and similar
statements).
> On the other hand, I find this message interesting:
>
> http://lkml.org/lkml/2004/8/19/111
>
> In particular, he seems to be relying on German "Authors' Rights", and
> claims to be in discussion with Debian people. That's nearly a month
> ago.
More specifically, he claims to be in discussion with Debian how to
stop SuSE from doing what they have every right to do. I know nothing
about German law, so I can't comment on that bit.
--
Måns Rullgård
m...@mru.ath.cx
Brian Thomas Sniffen
> I do agree that we should avoid upgrading to versions he's provided which
> are accompanied by statements about copyright which conflict with the GPL.
>
> But I don't see any valid reason for pulling prior versions out of main.
I see this as a similar circumstance to Pine. UW had very clearly
given a free license, then switched to a loopy interpretation where we
didn't have a license to distribute modified versions. So it got
pulled from main. They changed their license for future versions --
sure, they called it a clarification, but it was a pretty big change.
But Debian doesn't distribute that old pine, because -- even when the
copyright holder has gone insane -- it's polite to accede to their
wishes.
The same action is appropriate here.
-Brian
--
Brian Sniffen b...@alum.mit.edu
Raul Miller
> I see this as a similar circumstance to Pine. UW had very clearly
> given a free license, then switched to a loopy interpretation where we
> didn't have a license to distribute modified versions. So it got
> pulled from main. They changed their license for future versions --
> sure, they called it a clarification, but it was a pretty big change.
> But Debian doesn't distribute that old pine, because -- even when the
> copyright holder has gone insane -- it's polite to accede to their
> wishes.
>
> The same action is appropriate here.
If the situation is the way you've described (that the previous Pine
license was free), I think the same action was inappropriate then.
If things are the way you described, we put the priorities of our users
and of the free software community below the priorities of someone else.
That said, if there were other reasons (for example, perhaps there were
critical bugs in the free code that no one wanted to fix, or perhaps
there was no free code), then the situation is different.
Thanks,
--
Raul
Måns Rullgård
> Raul Miller <mo...@debian.org> writes:
>
>> I do agree that we should avoid upgrading to versions he's provided which
>> are accompanied by statements about copyright which conflict with the GPL.
>>
>> But I don't see any valid reason for pulling prior versions out of main.
>
> I see this as a similar circumstance to Pine. UW had very clearly
> given a free license, then switched to a loopy interpretation where we
> didn't have a license to distribute modified versions. So it got
> pulled from main. They changed their license for future versions --
> sure, they called it a clarification, but it was a pretty big change.
> But Debian doesn't distribute that old pine, because -- even when the
> copyright holder has gone insane -- it's polite to accede to their
> wishes.
>
> The same action is appropriate here.
There's a slight difference, if I am not mistaken. UW did not change
the license, and then claim that the new license would apply to
copies of old versions of the software received under the old
license. What they did was to clarify their interpretation of the
license, which although highly unusual was not self-contradicting.
--
Måns Rullgård
m...@mru.ath.cx
Brian Thomas Sniffen
> On Thu, Sep 02, 2004 at 11:18:11AM -0400, Brian Thomas Sniffen wrote:
>> I see this as a similar circumstance to Pine. UW had very clearly
>> given a free license, then switched to a loopy interpretation where we
>> didn't have a license to distribute modified versions. So it got
>> pulled from main. They changed their license for future versions --
>> sure, they called it a clarification, but it was a pretty big change.
>> But Debian doesn't distribute that old pine, because -- even when the
>> copyright holder has gone insane -- it's polite to accede to their
>> wishes.
>>
>> The same action is appropriate here.
>
> If the situation is the way you've described (that the previous Pine
> license was free), I think the same action was inappropriate then.
The previous pine license was clearly and unambiguously free. UW, the
copyright holder, devised an interpretation which was non-free.
Debian deferred to the copyright holder's interpretation in that case.
There's an additional problem: cdrtools, at least as Debian
distributes it, uses some code for which Schilling is not the
copyright holder. The HFS support, for example, is copyright Robert
Leslie, and licensed under the normal, sanely interpreted GPL.
cdrecord is not distributable by anybody, including Schilling, in this
state.
> If things are the way you described, we put the priorities of our users
> and of the free software community below the priorities of someone else.
No, we put the priority of our users to have kewl warez below the
priority to keep our users safe from lawsuits.
> That said, if there were other reasons (for example, perhaps there were
> critical bugs in the free code that no one wanted to fix, or perhaps
> there was no free code), then the situation is different.
>
> Thanks,
>
> --
> Raul
--
Brian Sniffen b...@alum.mit.edu
Raul Miller
> The previous pine license was clearly and unambiguously free. UW, the
> copyright holder, devised an interpretation which was non-free.
> Debian deferred to the copyright holder's interpretation in that case.
That doesn't really sound like clearly and unambiguously free, to me.
It sounds as if at least some people in debian were convinced of the
copyright holder's interpetation.
Also, if we were to follow that precedent here -- if Debian defers to
Joerg's interpretation -- we would need to move every GPLed package out
of main.
Alternatively, if we decide that the text of the license in question is
irrelevant and it's only the stated wishes of the copyright holder that
matters, we should not consider "arbitrary termination" clauses as being
any different from any other free software license.
--
Raul
Brian Thomas Sniffen
> On Thu, Sep 02, 2004 at 12:28:09PM -0400, Brian Thomas Sniffen wrote:
>> The previous pine license was clearly and unambiguously free. UW, the
>> copyright holder, devised an interpretation which was non-free.
>> Debian deferred to the copyright holder's interpretation in that case.
>
> That doesn't really sound like clearly and unambiguously free, to
> me.
It's a license accepted as free elsewhere.
> It sounds as if at least some people in debian were convinced of the
> copyright holder's interpetation.
>
> Also, if we were to follow that precedent here -- if Debian defers to
> Joerg's interpretation -- we would need to move every GPLed package out
> of main.
No. Joerg is only the copyright holder on some code, and lazy
evaluation is important here. What he's saying is best interpreted as
"My package is not and never was under the GPL; it's under this
non-free license over here. I think this has always been the case."
Sure, he's nuts, but why pick a fight with him over this?
> Alternatively, if we decide that the text of the license in question is
> irrelevant and it's only the stated wishes of the copyright holder that
> matters, we should not consider "arbitrary termination" clauses as being
> any different from any other free software license.
Debian requires many permissions that it will never use, because these
permissions must be provided to end-users. Debian might never remove
the cdrtools SUSE-annoying code, or Hans Reiser's advertisements and
credits, but it requires the permission to remove them.
It's perfectly consistent to insist on a right to continue
distributing when the copyright holder wants you to stop while ceasing
distribution when the copyright holder asks.
-Brian
--
Brian Sniffen b...@alum.mit.edu
Brian Thomas Sniffen
maintainers kept the separate threads of ownership so clear. It does
make it pretty clear that cdrecord is not distributable.
Followup-For: Bug #265546
Joerg Schilling's license is essentially the GNU GPL plus some extra
restrictions. These restrictions are probably non-free. Call this
the
JS-GPL
But cdrtools uses code copyrighted by others and licensed only under
the real GNU GPL. The HFS code, for example, is copyright Robert
Leslie. Some of the Mac isofs code is copyright James Pearson.
The eltorito.c file in mkisofs is copyright Red Hat, and much of
the rest is Yggdrasil's.
Taken altogether, it looks like this package is not distributable by
anybody with parts under the JS-GPL.
-Brian
--
Brian Sniffen b...@alum.mit.edu
Raul Miller
> Taken altogether, it looks like this package is not distributable by
> anybody with parts under the JS-GPL.
I've taken a look at a copy from January, and it has the same problem.
I don't know how far back we'd have to go to find a legally distributable
copy.
--
Raul
Bernhard R. Link
> > In particular, he seems to be relying on German "Authors' Rights", and
> > claims to be in discussion with Debian people. That's nearly a month
> > ago.
>
> More specifically, he claims to be in discussion with Debian how to
> stop SuSE from doing what they have every right to do. I know nothing
> about German law, so I can't comment on that bit.
Only thing in German law I could imagine is that he could withdraw some
of his work. Which would require him to pay everyone what it is
currently worth before the ban can take effect and make it impossible
for him to allow others to use it. Anyone knows some reading if there is
any other possibility and if this possibilty is even applicaple to
software?
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
Brian Thomas Sniffen
> * M?ns Rullg?rd <m...@mru.ath.cx> [040902 17:11]:
>> > In particular, he seems to be relying on German "Authors' Rights", and
>> > claims to be in discussion with Debian people. That's nearly a month
>> > ago.
>>
>> More specifically, he claims to be in discussion with Debian how to
>> stop SuSE from doing what they have every right to do. I know nothing
>> about German law, so I can't comment on that bit.
>
> Only thing in German law I could imagine is that he could withdraw some
> of his work. Which would require him to pay everyone what it is
> currently worth before the ban can take effect and make it impossible
> for him to allow others to use it. Anyone knows some reading if there is
> any other possibility and if this possibilty is even applicaple to
> software?
Wow. <does some reading on withdrawal of works>.
Some people make the kookiest laws. And hundreds of them have been
elected to run Europe. It's like letting the crew of the B-ark take
over... these are a perfectly valid system of laws for a society that
isn't anything like this one peopled by people who aren't human. It's
not that free software is impossible under a system with Authors'
Rights and Withdrawal; you can't do business at all!
Thanks for mentioning this law, Bernhard, but I have to hope that
Joerg Schilling isn't relying on it.
-Brian
--
Brian Sniffen b...@alum.mit.edu
Glenn Maynard
> On Thu, Sep 02, 2004 at 12:28:09PM -0400, Brian Thomas Sniffen wrote:
> > The previous pine license was clearly and unambiguously free. UW, the
> > copyright holder, devised an interpretation which was non-free.
> > Debian deferred to the copyright holder's interpretation in that case.
>
> That doesn't really sound like clearly and unambiguously free, to me.
> It sounds as if at least some people in debian were convinced of the
> copyright holder's interpetation.
How is "Permission to use, copy, modify, and distribute this software...
is hereby granted" ambiguous? [1] It seems clear that UW deliberately
contrived a bogus "interpretation" of their license in order to revoke
their freeing of Pine. I've never heard of anyone in Debian actually
believing in it.
It's possible to devise interpretations of most licenses which are non-free.
One which came up recently was the MIT license: one could claim that
"supporting documentation" includes even manuals written by a third party
and not derived from the software at all. Aside from probably being
unenforcable, this would certainly be non-free license contamination.
[1] http://www.washington.edu/pine/faq/legal.html#10.2
(Accusing Free Software programmers of "perverting" the license by doing
things they were clearly granted permission to do; that's wonderful.)
--
Glenn Maynard
Adam McKenna
> [1] http://www.washington.edu/pine/faq/legal.html#10.2
>
> (Accusing Free Software programmers of "perverting" the license by doing
> things they were clearly granted permission to do; that's wonderful.)
Wasn't the force behind the license "re-interpreation" to stop people from
distributing Pine with a maildir patch?
--Adam
--
Adam McKenna <ad...@debian.org> <ad...@flounder.net>
Arnoud Engelfriet
> * M?ns Rullg?rd <m...@mru.ath.cx> [040902 17:11]:
> > > In particular, he seems to be relying on German "Authors' Rights", and
> > > claims to be in discussion with Debian people. That's nearly a month
> > > ago.
> >
> > More specifically, he claims to be in discussion with Debian how to
> > stop SuSE from doing what they have every right to do. I know nothing
> > about German law, so I can't comment on that bit.
>
> Only thing in German law I could imagine is that he could withdraw some
> of his work. Which would require him to pay everyone what it is
> currently worth before the ban can take effect and make it impossible
> for him to allow others to use it. Anyone knows some reading if there is
> any other possibility and if this possibilty is even applicaple to
> software?
I think he's trying to say that his moral rights were violated
by SuSE when they made a "broken" version of cdrecord. You are
indeed not allowed under German law to modify a work in such a way
as to damage the original author's reputation or good name.
However that doesn't cancel the license. It merely is a ground for
a civil lawsuit to obtain damages.
Arnoud
--
Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Sven Luther
> On Thu, Sep 02, 2004 at 04:30:04PM -0400, Glenn Maynard wrote:
> > [1] http://www.washington.edu/pine/faq/legal.html#10.2
> >
> > (Accusing Free Software programmers of "perverting" the license by doing
> > things they were clearly granted permission to do; that's wonderful.)
>
> Wasn't the force behind the license "re-interpreation" to stop people from
> distributing Pine with a maildir patch?
Like cdrecord with a dvdrecord patch, and yaboot with anything but pristing
upstream source ? Altough at lest in the yaboot case, it is not licencing that
is used, but threat to remove the debian yaboot mention from the official yaboot
web page of supported yaboto versions.
Friendly,
Sven Luther
Andreas Metzler
[...]
> On the other hand, I find this message interesting:
>
> http://lkml.org/lkml/2004/8/19/111
>
> In particular, he seems to be relying on German "Authors' Rights", and
> claims to be in discussion with Debian people. That's nearly a month
> ago.
Hello,
This was about the recent change of license in a36 that was widely covered in
the news, e.g. lwn or heise.de
http://weblogs.mozillazine.org/gerv/archives/006193.html
We (cdrools Debian maintainers) were in indeed private contact with Joerg about
this and successfully managed to resolve this, a38 undid the newly introduced
non-freeness issue, the code in question (linuxcheck()) is not encumbered by a
specific license anymore, it may be removed like anything else.
This is resolved and completely orthogonal to this thread, so please ignore it.
cu andreas
Andreas Metzler
[...]
> There's an additional problem: cdrtools, at least as Debian
> distributes it, uses some code for which Schilling is not the
> copyright holder. The HFS support, for example, is copyright Robert
> Leslie, and licensed under the normal, sanely interpreted GPL.
>
> cdrecord is not distributable by anybody, including Schilling, in this
> state.
cdrtools consists of a bunch of largely independent applications and libraries
(e.g cdrecord, readcd, mkisofs, cdda2wav), debian/copyright lists the licenses
and copyright holders in detail.
The two issues mentioned in this thread influence different parts of cdrtools:
* defaults.c /*
* WARNING you are only allowed to change this filename if you also
* change the documentation and add a statement that makes clear
* where the official location of the file is why you did choose a
* nonstandard location and that the nonstandard location only refers
* to inofficial cdrecord versions.
*
* I was forced to add this because some people change cdrecord without
* rational reason and then publish the result. As those people
* don't contribute work and don't give support, they are causing extra
* work for me and this way slow down the cdrecord development.
*/
This one is used and linked against all applications of cdrtools since 2.01a26
(previously only in cdrecord). If it is GPL incompatible it indeed breaks the
e.g. mkisofs' and cdda2wav's original copyrights.
The second issue
* If you modify cdrecord you need to include additional version
* printing code that [...]
in cdrecord/cdrecord.c only applies to cdrecord which is completely copyrighted
by JS. Therefore he is able to license it as GPL+restrictions and if the
restrictions are still DFSG free we are able to ship it as part of Debian/main.
- If cdrtools stopped being distributed as whole and would be split into
separate tarballs for the different applications, because otherwise this part of
GPL ...
--------------------------
But when you distribute the same sections as part of a whole which is a work
based on the Program, the distribution of the whole must be on the terms of this
License, whose permissions for other licensees extend to the entire whole, and
thus to each and every part regardless of who wrote it.
--------------------------
... could give us a headache.
cu andreas
Andreas Metzler
> I don't know how far back we'd have to go to find a legally distributable
> copy.
Probably February or January 2002.
cu andreas
Glenn Maynard
> > The two issues mentioned in this thread influence different parts of cdrtools:
> >
> > * defaults.c /*
> > * WARNING you are only allowed to change this filename if you also
> > This one is used and linked against all applications of cdrtools since 2.01a26
> > (previously only in cdrecord). If it is GPL incompatible it indeed breaks the
> > e.g. mkisofs' and cdda2wav's original copyrights.
>
> it affects functional behavior, I'd call it non-free. "You must
> change this filename" requirements are generally considered non-free,
> so I'd expect "You may not change this filename without paying this
> fee" requirements to be non-free.
Why do we have to use the word "fee" to describe this sort of requirement?
It's unnatural, and seems contrived to fit DFSG#1, which is unnecessary,
since "fees" are not the only sort of restrictions prohibited by DFSG#1.
I agree that this is non-free, as is any requirement that I explain myself
before distributing a modification.
--
Glenn Maynard
Glenn Maynard
> The second issue
> * If you modify cdrecord you need to include additional version
> * printing code that [...]
> in cdrecord/cdrecord.c only applies to cdrecord which is completely copyrighted
> by JS. Therefore he is able to license it as GPL+restrictions and if the
> restrictions are still DFSG free we are able to ship it as part of Debian/main.
Only if the implementation of that license is clear and consistent. I
don't believe a work under the GPL with "clarifications" that don't
follow from the GPL in any way is either.
If he wants something like the GPL with extra restrictions, he should
follow the procedure for modifying the GPL: rename it (the CDRPL),
remove the preamble, and actually modify the text of the license.
--
Glenn Maynard
Brian Thomas Sniffen
service. It really doesn't mean "money only," in any context where
precise language is used. If I have to perform in some way to obtain
a license, then that's a fee.
Do you have a better word, taking brevity and clarity into account?
-Brian
--
Brian Sniffen b...@alum.mit.edu
Raul Miller
> Because "fee" is an English word meaning a payment for a good or
> service. It really doesn't mean "money only," in any context where
> precise language is used. If I have to perform in some way to obtain
> a license, then that's a fee.
>
> Do you have a better word, taking brevity and clarity into account?
Requirement.
--
Raul
Glenn Maynard
> Because "fee" is an English word meaning a payment for a good or
> service. It really doesn't mean "money only," in any context where
> precise language is used. If I have to perform in some way to obtain
> a license, then that's a fee.
>
> Do you have a better word, taking brevity and clarity into account?
"Restriction". It includes all fees, and also includes things which are
obviously not fees (such as, again, "only on Tuesday"), and is also directly
tied to DFSG#1. I prefer it because contrived-feeling (whether legitimate
or not) use of "fee" may spread the notion that only "fees" are covered by
DFSG#1, and not other restrictions; and lead to more pointless dictionary-
lawyering over whether something is a "fee" or not.
--
Glenn Maynard
Brian Thomas Sniffen
> On Fri, Sep 03, 2004 at 08:16:27PM -0400, Brian Thomas Sniffen wrote:
>> Because "fee" is an English word meaning a payment for a good or
>> service. It really doesn't mean "money only," in any context where
>> precise language is used. If I have to perform in some way to obtain
>> a license, then that's a fee.
>>
>> Do you have a better word, taking brevity and clarity into account?
>
> Requirement.
That's a much broader word. For example, a license which says I may
only make modifications in French has a requirement, but that is not a
fee.
-Brian
--
Brian Sniffen b...@alum.mit.edu
Raul Miller
> >
> > Requirement.
On Fri, Sep 03, 2004 at 11:00:28PM -0400, Brian Thomas Sniffen wrote:
> That's a much broader word. For example, a license which says I may
> only make modifications in French has a requirement, but that is not a
> fee.
For that matter, DFSG #1 does not, in general, deal with restrictions
on modifications -- it only deals with restrictions on distribution.
--
Raul
Glenn Maynard
> > On Fri, Sep 03, 2004 at 08:16:27PM -0400, Brian Thomas Sniffen wrote:
> >> Because "fee" is an English word meaning a payment for a good or
> >> service. It really doesn't mean "money only," in any context where
> >> precise language is used. If I have to perform in some way to obtain
> >> a license, then that's a fee.
> >>
> >> Do you have a better word, taking brevity and clarity into account?
> >
> > Requirement.
>
> That's a much broader word. For example, a license which says I may
> only make modifications in French has a requirement, but that is not a
> fee.
The point was that "fee" is a narrower word, and its use in this context
("explaining rationale") is awkward, and only invites dictionary debates.
I believe both "requirement" and "restriction" are better choices here
(personally preferring "restriction" for its easy relationship to "may
not restrict" in the DFSG).
I don't think having to explain to the world at large in the readme why you
did something is a fee or payment. We don't need to agree on this point,
though; it's clearly a restriction. What matters is whether the restriction
is considered onerous or not; whether it's a fee is irrelevant.
--
Glenn Maynard
Francesco Poli
[...]
> Hello,
> This was about the recent change of license in a36 that was widely
> covered in the news, e.g. lwn or heise.de
> http://weblogs.mozillazine.org/gerv/archives/006193.html
>
> We (cdrools Debian maintainers) were in indeed private contact with
> Joerg about this and successfully managed to resolve this, a38 undid
> the newly introduced non-freeness issue, the code in question
> (linuxcheck()) is not encumbered by a specific license anymore, it may
> be removed like anything else.
>
> This is resolved and completely orthogonal to this thread, so please
> ignore it.
So, IIUC, debian bug #265546
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265546) is related to
linuxcheck() only.
I instead thought that it was related to the whole bunch of weird
restrictions that go well beyond the GPL license, and that it was filed
when the non-freeness was even worse and then marked resolved when one
of the issues went away.
So, since I noticed that many issues were still there, I wondered if the
bug should be reopened.
I apologize for the misunderstanding.
Well, if I *now* understand the situation correctly, we have version
2.01a38 with *another* set of non-freeness and non-distributability
issues to deal with...
So probably a different bug should be filed, at least if sid already
includes version 2.01a38...
--
| GnuPG Key ID = DD6DFCF4 | $ fortune
Francesco | Key fingerprint = | Q: What is purple
Poli | C979 F34B 27CE 5CD8 DC12 | and commutes?
| 31B5 78F4 279B DD6D FCF4 | A: A boolean grape.
Josh Triplett
> On Thu, Sep 02, 2004 at 02:12:54PM -0700, Adam McKenna wrote:
>
>>On Thu, Sep 02, 2004 at 04:30:04PM -0400, Glenn Maynard wrote:
>>
>>>[1] http://www.washington.edu/pine/faq/legal.html#10.2
>>>
>>>(Accusing Free Software programmers of "perverting" the license by doing
>>>things they were clearly granted permission to do; that's wonderful.)
>>
>>Wasn't the force behind the license "re-interpreation" to stop people from
>>distributing Pine with a maildir patch?
>
> Like cdrecord with a dvdrecord patch, and yaboot with anything but pristing
> upstream source ? Altough at lest in the yaboot case, it is not licencing that
> is used, but threat to remove the debian yaboot mention from the official yaboot
> web page of supported yaboto versions.
That's interesting; could you point me towards a reference for this? I
can't seem to find one via Google. (Or was it in private mail?)
- Josh Triplett
Sven Luther
It was in the now archived bug against yaboot :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=242348
Me :
| > BTW, i also have a patch which adds amiga partitioning support to
| > yaboot, would you consider including it ?
Ethan :
| not in 1.x.
|
| if debian starts patching yaboot severely i will add debian to the
| unsupported dists category.
The code is one which couldn't have any effect on existing plateforms using
yaboot, since there is only one interaction, which is the probing for an amiga
partition table, which happens only if no MBR or Mac partition tables or iso
filesystems were found. As a result, i cannot get a yaboot version which works
on my pegasos into debian, and need to resort to a local built package.