Request review of cdrtools-3.0 for inclusion in Debian
Hello, I seek clarification on how closely cdrtools-3.0 meets the Debian Free Software Guidelines. Web: http://cdrecord.berlios.de/private/cdrecord.html Tarball: ftp://ftp.berlios.de/pub/cdrecord/cdrtools-3.00.tar.gz Would an official debian legal representative please consider the cdrtools-3.0 release for review? 1. Does cdrtools-3.0 release pass the DFSG? Why or why not, and please could this be supported by legal or official decision by the Debian project? 2. If changes to cdrtools need to be made to pass the DFSG, what are the specific minimum changes needed? No urgency needed. It would be of greatest help to focus on an official and updated decision to reflect this latest stable release cdrtools-3.0 Many thanks, Eric Shattow -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANV2PTMw1qLoWYGuKV9y7WfUZdN9kGHGmXefO=yn85dui81...@mail.gmail.com
Re: Request review of cdrtools-3.0 for inclusion in Debian
Hi Eric, On Tue, Nov 13, 2012 at 03:20:22PM -0800, Eric Shattow wrote: I seek clarification on how closely cdrtools-3.0 meets the Debian Free Software Guidelines. Web: http://cdrecord.berlios.de/private/cdrecord.html Tarball: ftp://ftp.berlios.de/pub/cdrecord/cdrtools-3.00.tar.gz Would an official debian legal representative please consider the cdrtools-3.0 release for review? 1. Does cdrtools-3.0 release pass the DFSG? Why or why not, and please could this be supported by legal or official decision by the Debian project? It doesn't matter if the stated license of cdrtools passes the DFSG. The author and copyright holder of cdrtools has an adversarial relationship with the Debian project, and cdrtools was removed from Debian as a direct result of this conflict and the author's clear intent to disallow modifications that must be permitted under the DFSG. Jörg Schilling's software is not welcome in Debian. We have no need for litigious upstreams, and cdrtools has been obsoleted by cdrkit which, contrary to Mr. Schilling's representations, is more featureful and less buggy on Linux than cdrtools. See http://bugs.debian.org/377109 for the full history here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: cdrtools
On Saturday 12 August 2006 02:47 am, Thomas Bushnell BSG wrote: Daniel Schepler [EMAIL PROTECTED] writes: According to the GPL, section 0: The act of running the Program is not restricted... And since dynamic linking is done at the time the program is run, this would appear to me to be what applies. In particular, it appears to me that you could satisfy the GPL and still dynamically link against a non-free library, and distribute both, by invoking the mere aggregation clause of section 2. This does not mean that anything that happens when you run the program is not restricted. For example, the act of running GNU cp and sed is not restricted, but that cann't possibly mean that the GPL gives you carte blanche to go ahead and violate the GPL through use of cp and sed. I'm afraid I don't see what your point is, here. Of course the GPL allowing me to use a GPL'd httpd to distribute non-free software doesn't automatically mean I would be blameless if I used it to distribute, say, a non-free program foo linked against libmad. The point, I think, is that distributing such a thing as the non-free binary of foo along with a package of a shared libmad is essentially the same as distributing a binary with libmad linked in statically, which is clearly disallowed. Both are just different ways of distributing the combined work of foo + libmad. -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Daniel Schepler [EMAIL PROTECTED] writes: On Saturday 12 August 2006 02:47 am, Thomas Bushnell BSG wrote: Daniel Schepler [EMAIL PROTECTED] writes: According to the GPL, section 0: The act of running the Program is not restricted... And since dynamic linking is done at the time the program is run, this would appear to me to be what applies. In particular, it appears to me that you could satisfy the GPL and still dynamically link against a non-free library, and distribute both, by invoking the mere aggregation clause of section 2. This does not mean that anything that happens when you run the program is not restricted. For example, the act of running GNU cp and sed is not restricted, but that cann't possibly mean that the GPL gives you carte blanche to go ahead and violate the GPL through use of cp and sed. I'm afraid I don't see what your point is, here. Of course the GPL allowing me to use a GPL'd httpd to distribute non-free software doesn't automatically mean I would be blameless if I used it to distribute, say, a non-free program foo linked against libmad. The point, I think, is that distributing such a thing as the non-free binary of foo along with a package of a shared libmad is essentially the same as distributing a binary with libmad linked in statically, which is clearly disallowed. Both are just different ways of distributing the combined work of foo + libmad. Yes, I agree completely. This seems to be the exact opposite of what you said in the quoted text above. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL question [Was: Re: cdrtools]
On Friday 11 August 2006 18:10 pm, Goswin von Brederlow wrote: I believe that the totaly interchangable option of specifying -static or not should not change the free-ness of the source or resulting binary. So if you link static and you agree that it is a violation that way then you should not be able to get away with it by linking dynamically. The GPL is viral in nature and specificaly made to work across linking boundaries. People should not be able to add non-free portitons to the source by hiding them in libraries. I agree, but then should and is sometimes disagree. But after thinking about it some more, I believe a dynamically linked binary together with the corresponding shared libraries should be considered as a distribution method for the complete program that gets assembled in a common address space. Consider for example the case of EvilCo, back before dynamic linking was widespread, trying to use a GPL'd library in their non-free program. They try to get around the GPL by distributing their compiled program code in a single .o file in a mere aggregate along with the GPL library .a file, and ask users to link the program themselves. This is obviously bogus; they've just created an alternate means of distribution of the resulting binary, and so the binary itself must be distributable under the terms of the GPL, which it isn't. And the case of a dynamically linked executable with shared libraries is almost exactly the same as this scenario, only it's the system dynamic linker doing the work instead of the user doing it manually. Anyway, as somebody else pointed out, this is off-topic for debian-devel, and I apologize. Please direct any replies to debian-legal (too bad kmail doesn't let me set Followup-To afaik). -- Daniel Schepler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools
Eduard Bloch wrote: #include hallo.h * Kevin Bube [Fri, Jul 07 2006, 11:29:21AM]: Eduard Bloch [EMAIL PROTECTED] writes: * Adam Borowski [Fri, Jul 07 2006, 10:38:32AM]: * dvdrtools, a fork of the last GPLed version, is in non-free Please look at dvdrtools' files, eg. cdrecord.c before claiming that. What is wrong with that? The blurb [1] seems quite okay (i.e. GPL) to me. Grep for not.allowed and decide yourself whether such remarks are applicable to the GPL (as applicable in your country). Eduard. OK. Here are the not allowed elements in dvdrtools: First, cdrecord.c: /* * Warning: you are not allowed to modify or to remove this * version checking code! */ This is false and unacceptable. I believe this constitutes an error on the part of the dvdrtools upstream maintainer, who thought he'd forked from before this was introduced. I suggest reporting this upstream and seeing if there's an earlier version which it can be forked from. librscg/scsi-remote.c libscg/scsi-*.c These are all shim layers for interfacing with different kernels' implementations of SCSI. My suspicion is that the best move would be to replace this library entirely. Doesn't the Linux kernel have a fairly clean and reasonable interface to CD-ROMs these days? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dual licensing [Was: Re: cdrtools]
On Saturday 08 July 2006 08:41, Don Armstrong wrote:
We've stepped into -legal territory now. MFT set to send messages only
to -legal; please respond there only.
Sure.
On Sat, 08 Jul 2006, George Danchev wrote:
Well, I have the following 'and' vs. 'or' type of licensing
question. While it is clear now that Debian can not distribute a
product when some of its parts are under GPL and the rest are under
CDDL ('and'), is it fine to double-license {GPL|CDDL} the whole
product like Perl does with GPL | Artistic, so either the whole
thing is under GPL or the whole thing under CDDL as accepted by the
licensee. In short, could you double license under two incompatible
licenses ?
As far as I understand it (TINLA, IANAL, YHBW, etc.) so long as there
is a subset of licenses available which you can use to actually
distribute the work, you ignore the licenses which you don't
distribute under. It is a good practice to list the other licenses in
the copyright file as a service to our users, but strictly speaking
they are superfluous. [In the cases where they are not, you're not
actually dual licensing the work.]
That's fine and that is what I have in my /usr/share/doc/libqt3-mt/copyright
Qt 3.3 is dual licensed under the QPL and the GPL... So I see no worries to
distribute CDDL and GPL dual licensed works the same way, unless somebody
proves me wrong.
Of course, you have to actually own the copyright on the parts that
you are (re)licensing but that's probably obvious. ;-)
Yes, it is pretty obvious.
--
pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dual licensing [Was: Re: cdrtools]
George Danchev a écrit :
On Saturday 08 July 2006 08:41, Don Armstrong wrote:
We've stepped into -legal territory now. MFT set to send messages only
to -legal; please respond there only.
Sure.
On Sat, 08 Jul 2006, George Danchev wrote:
Well, I have the following 'and' vs. 'or' type of licensing
question. While it is clear now that Debian can not distribute a
product when some of its parts are under GPL and the rest are under
CDDL ('and'), is it fine to double-license {GPL|CDDL} the whole
product like Perl does with GPL | Artistic, so either the whole
thing is under GPL or the whole thing under CDDL as accepted by the
licensee. In short, could you double license under two incompatible
licenses ?
As far as I understand it (TINLA, IANAL, YHBW, etc.) so long as there
is a subset of licenses available which you can use to actually
distribute the work, you ignore the licenses which you don't
distribute under. It is a good practice to list the other licenses in
the copyright file as a service to our users, but strictly speaking
they are superfluous. [In the cases where they are not, you're not
actually dual licensing the work.]
That's fine and that is what I have in my /usr/share/doc/libqt3-mt/copyright
Qt 3.3 is dual licensed under the QPL and the GPL... So I see no worries to
distribute CDDL and GPL dual licensed works the same way, unless somebody
proves me wrong.
Dual licensing is the best way to increase the liberty of the license.
Users can choice to use the best license for them, and if all
contributions are under the same dual license, the whole source code
will be compatible with both license. Double licensing under two
incompatible license is the only interesting practice, because they
become compatible. If you choose to dual license two compatible license
(LGPL/GPL; BSD/GPL), it is useless because the compatibility already
exist. Sorry for my bad English.
Of course, you have to actually own the copyright on the parts that
you are (re)licensing but that's probably obvious. ;-)
Yes, it is pretty obvious.
...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Dual licensing [Was: Re: cdrtools]
Dual licensing is certainly workable for incompatible licenses, example MYSQL using GPL and Commercial licenses
Dual licensing [Was: Re: cdrtools]
We've stepped into -legal territory now. MFT set to send messages only
to -legal; please respond there only.
On Sat, 08 Jul 2006, George Danchev wrote:
Well, I have the following 'and' vs. 'or' type of licensing
question. While it is clear now that Debian can not distribute a
product when some of its parts are under GPL and the rest are under
CDDL ('and'), is it fine to double-license {GPL|CDDL} the whole
product like Perl does with GPL | Artistic, so either the whole
thing is under GPL or the whole thing under CDDL as accepted by the
licensee. In short, could you double license under two incompatible
licenses ?
As far as I understand it (TINLA, IANAL, YHBW, etc.) so long as there
is a subset of licenses available which you can use to actually
distribute the work, you ignore the licenses which you don't
distribute under. It is a good practice to list the other licenses in
the copyright file as a service to our users, but strictly speaking
they are superfluous. [In the cases where they are not, you're not
actually dual licensing the work.]
Of course, you have to actually own the copyright on the parts that
you are (re)licensing but that's probably obvious. ;-)
Don Armstrong
--
THERE IS NO GRAVITY THE WORLD SUCKS
-- Vietnam War Penquin Lighter
http://gallery.donarmstrong.com/clippings/vietnam_there_is_no_gravity.jpg
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
On Fri, 24 Mar 2006 01:28:37 + Måns Rullgård wrote: Francesco Poli [EMAIL PROTECTED] writes: On Tue, 21 Mar 2006 18:19:52 +0100 Eduard Bloch wrote: Don't count much on dvdrtools, it has no active upstream at all (no, I don't mean the guys whoes only heroic act was the replacement of the Schilly build system with autodev-stuff). That's a good reason to find someone willing to take over dvdrtools maintenance and development... We should really seek someone interested. Umm... they released a new version just a couple of weeks ago. What do you require of a project to count it as active? That's a question for Eduard, he is the one saying that dvdrtools lacks an active upstream... I was just concerned by the situation depicted by Eduard! ;-) -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpWvrqvcKw15.pgp Description: PGP signature
Re: cdrtools - GPL code with CDDL build system
On Tue, 21 Mar 2006 18:19:52 +0100 Eduard Bloch wrote: #include hallo.h * Francesco Poli [Tue, Mar 21 2006, 12:18:37AM]: [...] I used to hope that ignoring upstream insane statements doesn't include ignoring DFSG-freeness issues with the package, though!! :-( Relax. Let's expect an answer to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350739 - either cdrtools will be declared as licensed under the GPL or not under GPL, then we know what we are on. And yes, we shold face the possibility of the removal of cdrtools from Debian. It's hard to relax in these strange days, when some serious licensing bugs are magically declared non-bugs by the majority of the project (see GR-2006-001)... :-( Anyway, let's go on waiting (I've been waiting since september 2004...). since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. Assuming that its debian/copyright file is accurate (in Debian sid), it seems that the same license (and added restrictions, passed off as license interpretation) applies. If this is the case, my bet is that dvdrtools is in non-free for pretty the same reason why cdrtools should not be in main (at least, not as it is now)... Awkward! :-((( Don't count much on dvdrtools, it has no active upstream at all (no, I don't mean the guys whoes only heroic act was the replacement of the Schilly build system with autodev-stuff). That's a good reason to find someone willing to take over dvdrtools maintenance and development... We should really seek someone interested. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp26yzUJcVvu.pgp Description: PGP signature
Re: cdrtools - GPL code with CDDL build system
Francesco Poli [EMAIL PROTECTED] writes: On Tue, 21 Mar 2006 18:19:52 +0100 Eduard Bloch wrote: Don't count much on dvdrtools, it has no active upstream at all (no, I don't mean the guys whoes only heroic act was the replacement of the Schilly build system with autodev-stuff). That's a good reason to find someone willing to take over dvdrtools maintenance and development... We should really seek someone interested. Umm... they released a new version just a couple of weeks ago. What do you require of a project to count it as active? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
#include hallo.h * Francesco Poli [Tue, Mar 21 2006, 12:18:37AM]: D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Aaargh! :-( I was hoping this problem had been fixed... [...] How can such a package still be in main with this non-freeness? I'm surprised that nobody filed a serious bug for this... I guess everyone has just gotten used to Schilling's inane ramblings, and ignores him without further thought. I used to hope that ignoring upstream insane statements doesn't include ignoring DFSG-freeness issues with the package, though!! :-( Relax. Let's expect an answer to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350739 - either cdrtools will be declared as licensed under the GPL or not under GPL, then we know what we are on. And yes, we shold face the possibility of the removal of cdrtools from Debian. since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. Assuming that its debian/copyright file is accurate (in Debian sid), it seems that the same license (and added restrictions, passed off as license interpretation) applies. If this is the case, my bet is that dvdrtools is in non-free for pretty the same reason why cdrtools should not be in main (at least, not as it is now)... Awkward! :-((( Don't count much on dvdrtools, it has no active upstream at all (no, I don't mean the guys whoes only heroic act was the replacement of the Schilly build system with autodev-stuff). Eduard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
On Mon, 20 Mar 2006 01:21:08 + Måns Rullgård wrote: Francesco Poli [EMAIL PROTECTED] writes: On Sat, 18 Mar 2006 22:05:53 + Måns Rullgård wrote: Eduard Bloch [EMAIL PROTECTED] writes: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Aaargh! :-( I was hoping this problem had been fixed... [...] How can such a package still be in main with this non-freeness? I'm surprised that nobody filed a serious bug for this... I guess everyone has just gotten used to Schilling's inane ramblings, and ignores him without further thought. I used to hope that ignoring upstream insane statements doesn't include ignoring DFSG-freeness issues with the package, though!! :-( Just use dvdrtools instead. ITYM dvd+rw-tools, That's what I use for burning DVDs. It doesn't handle CDs though. Ouch! It seems that we are left with *no* DFSG-free tools to burn CDs in Debian, until someone forks cdrtools (from a version prior to the license clarifications) or implements an equivalent program suite... since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. Assuming that its debian/copyright file is accurate (in Debian sid), it seems that the same license (and added restrictions, passed off as license interpretation) applies. If this is the case, my bet is that dvdrtools is in non-free for pretty the same reason why cdrtools should not be in main (at least, not as it is now)... Awkward! :-((( -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpEeLBCn5Ul1.pgp Description: PGP signature
Re: cdrtools - GPL code with CDDL build system
Francesco Poli [EMAIL PROTECTED] writes: On Mon, 20 Mar 2006 01:21:08 + Måns Rullgård wrote: Francesco Poli [EMAIL PROTECTED] writes: On Sat, 18 Mar 2006 22:05:53 + Måns Rullgård wrote: Just use dvdrtools instead. ITYM dvd+rw-tools, That's what I use for burning DVDs. It doesn't handle CDs though. Ouch! It seems that we are left with *no* DFSG-free tools to burn CDs in Debian, until someone forks cdrtools (from a version prior to the license clarifications) or implements an equivalent program suite... JS insists that his clarifications also apply to previous versions of cdrecord... since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. Assuming that its debian/copyright file is accurate (in Debian sid), it seems that the same license (and added restrictions, passed off as license interpretation) applies. If this is the case, my bet is that dvdrtools is in non-free for pretty the same reason why cdrtools should not be in main (at least, not as it is now)... The dvdrtools web page has this paragraph: dvdrtools is a fork of cdrtools, with the primary goals of remaining 100% Free Software (dvdrtools is a fork of the last version of cdrtools without any you are not allowed to modify this section comments), and adding support for DVD-R/DVD-RW drives and media. Checking the source, none of the troublesome bits from cdrtools are there, and the build system is replaced with automake. I can't see any problem with it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
#include hallo.h * Måns Rullgård [Sun, Mar 19 2006, 01:50:24AM]: Sam Morris [EMAIL PROTECTED] writes: These are the bits I'm referring to, from cdrecorc.c (sorry for the long lines, but that's how it's written): ---BEGIN QUOTE--- /* * 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) ... For completeness, here's GPL 2c: ---BEGIN QUOTE--- c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) ---END QUOTE--- Take note that cdrecord is never interactive, so GPL 2c doesn't apply. Wrong. It displays messages by default and tells you how to stop the command etc. IMO this can clearly be interpreted as interaction. And since it does print such an announcement by default then it should be kept. However, I disagree on the level appropriateness - stuff like This is a broken Linux system does not belong to the disclaimer/copyright category. I don't know why JS refers to it, but then JS does a lot of things that nobody understands. This question is out of scope here. Eduard.
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Måns Rullgård [Sun, Mar 19 2006, 01:50:24AM]: Sam Morris [EMAIL PROTECTED] writes: These are the bits I'm referring to, from cdrecorc.c (sorry for the long lines, but that's how it's written): ---BEGIN QUOTE--- /* * 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) ... For completeness, here's GPL 2c: ---BEGIN QUOTE--- c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) ---END QUOTE--- Take note that cdrecord is never interactive, so GPL 2c doesn't apply. Wrong. It displays messages by default and tells you how to stop the command etc. IMO this can clearly be interpreted as interaction. It does not read commands interactively, which is the provision for GPL 2c applying. If every program that exits when it receives certain signals is interactive, then all programs are interactive (think SIGKILL). And since it does print such an announcement by default then it should be kept. However, I disagree on the level appropriateness - stuff like This is a broken Linux system does not belong to the disclaimer/copyright category. It is clearly not a copyright notice or disclaimer, and not being this restricting its removal is non-free. -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
* Mns Rullgrd [EMAIL PROTECTED] [060319 01:14]: Don Armstrong [EMAIL PROTECTED] writes: Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. I think derivative or not is not the question here, but the GPL explicitly demands that the build system is available under GPL-compatible changes. from Section 2 of the GPL: # b) You must cause any work that you distribute or publish, that in # whole or in part contains or is derived from the Program or any # part thereof, to be licensed as a whole at no charge to all third # parties under the terms of this License. from Section 3 of the GPLL: # Accompany it with the complete corresponding machine-readable # source code, which must be distributed under the terms of Sections # 1 and 2 above on a medium [...] # For an executable work, complete source # code means all the source code for all modules it contains, plus any # associated interface definition files, plus the scripts used to # control compilation and installation of the executable. scripts used to control compilation is clearly what we currently refer to as build system. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Bernhard R. Link [EMAIL PROTECTED] writes: * Mns Rullgrd [EMAIL PROTECTED] [060319 01:14]: Don Armstrong [EMAIL PROTECTED] writes: Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. I think derivative or not is not the question here, but the GPL explicitly demands that the build system is available under GPL-compatible changes. from Section 2 of the GPL: # b) You must cause any work that you distribute or publish, that in # whole or in part contains or is derived from the Program or any # part thereof, to be licensed as a whole at no charge to all third # parties under the terms of this License. from Section 3 of the GPLL: # Accompany it with the complete corresponding machine-readable # source code, which must be distributed under the terms of Sections # 1 and 2 above on a medium [...] # For an executable work, complete source # code means all the source code for all modules it contains, plus any # associated interface definition files, plus the scripts used to # control compilation and installation of the executable. scripts used to control compilation is clearly what we currently refer to as build system. Point taken. The obvious solution is to replace the build system with an acceptably licensed one. While at it, one could also make it work properly. Incidentally, this is what the dvdrtools folks have already done. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch wrote: ---BEGIN QUOTE--- c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) ---END QUOTE--- Take note that cdrecord is never interactive, so GPL 2c doesn't apply. Wrong. It displays messages by default and tells you how to stop the command etc. IMO this can clearly be interpreted as interaction. Even if, for the sake of argument, we accept that send SIGINT to stop this program satisfies read[ing] commands interactively when run, notice the first part of the the text: If the *modified* program normally... So, if I modify the program to no longer prompt, I am no longer required to include that notice. What that clause is really covering is stuff like this: [EMAIL PROTECTED]:~$ bc bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. bc, unlike cdrecord, does actually read commands from standard input (its a calculator, if you're not familiar with it) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Måns Rullgård wrote: Incidentally, this is what the dvdrtools folks have already done. Ummm, come to think of it, why is dvdrtools in non-free while cdrecord is in main? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
#include hallo.h * Anthony DeRobertis [Sun, Mar 19 2006, 11:42:58AM]: Måns Rullgård wrote: Incidentally, this is what the dvdrtools folks have already done. Ummm, come to think of it, why is dvdrtools in non-free while cdrecord is in main? I am waiting for the answer of its maintainer. I suggest to desist from further speculation before it arrives. Eduard.
Re: cdrtools - GPL code with CDDL build system
On Sun, 19 Mar 2006 13:12:25 + Måns Rullgård wrote: And since it does print such an announcement by default then it should be kept. However, I disagree on the level appropriateness - stuff like This is a broken Linux system does not belong to the disclaimer/copyright category. It is clearly not a copyright notice or disclaimer, and not being this restricting its removal is non-free. Definitely non-free. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpjd3dj1VyIU.pgp Description: PGP signature
Re: cdrtools - GPL code with CDDL build system
On Sat, 18 Mar 2006 22:05:53 + Måns Rullgård wrote: Eduard Bloch [EMAIL PROTECTED] writes: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Aaargh! :-( I was hoping this problem had been fixed... I pointed out this very issue on debian-legal back in September _2004_: http://lists.debian.org/debian-legal/2004/09/msg3.html Steve McIntyre stated that cdrtools should have been forked from a version prior to the license clarifications: http://lists.debian.org/debian-legal/2004/09/msg9.html I thought that this was going to happen soon, and then had no more time to follow the issue. Now I see that the issue is still there! :-(( How can such a package still be in main with this non-freeness? I'm surprised that nobody filed a serious bug for this... Just use dvdrtools instead. ITYM dvd+rw-tools, since dvdrtools is in non-free too... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpAVfjedavUo.pgp Description: PGP signature
Re: cdrtools - GPL code with CDDL build system
Francesco Poli [EMAIL PROTECTED] writes: On Sat, 18 Mar 2006 22:05:53 + Måns Rullgård wrote: Eduard Bloch [EMAIL PROTECTED] writes: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Aaargh! :-( I was hoping this problem had been fixed... [...] How can such a package still be in main with this non-freeness? I'm surprised that nobody filed a serious bug for this... I guess everyone has just gotten used to Schilling's inane ramblings, and ignores him without further thought. Just use dvdrtools instead. ITYM dvd+rw-tools, That's what I use for burning DVDs. It doesn't handle CDs though. since dvdrtools is in non-free too... Someone's launched an investigation into the reason for this. Let's wait and see what comes back. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
On 3/18/06, Eduard Bloch [EMAIL PROTECTED] wrote: [...] Now the question: how GPL-compatible should we consider this CDDL-like license? And what's the scale and gradations for GPL-compatibility in your brainwashed (linking triggers GPL-incompatibility) mind? I just wonder. hahaha regards, alexander.
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch [EMAIL PROTECTED] writes: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Just use dvdrtools instead. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
#include hallo.h * Alexander Terekhov [Sat, Mar 18 2006, 10:44:54PM]: On 3/18/06, Eduard Bloch [EMAIL PROTECTED] wrote: [...] Now the question: how GPL-compatible should we consider this CDDL-like license? And what's the scale and gradations for GPL-compatibility in your brainwashed (linking triggers GPL-incompatibility) mind? I just wonder. hahaha Troll feeding day is friday. You are too late, please come next week. Eduard. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch [EMAIL PROTECTED] wrote: Now the question: how GPL-compatible should we consider this CDDL-like license? See http://www.gnu.org/licenses/license-list.html for details. The CDDL and GPL are incompatible. We have the option of splitting the source package into code (GPLed) and meta-code (CDDL). Would that be suitable for main? No. In fact, you can not even distribute it in non-free. You have to replace the build system. Sorry for the bad news. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
On Sat, 18 Mar 2006, Eduard Bloch wrote: Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. Can we just fork from a version of the build system which did not contain the CDDL and make whatever changes to it are necessary for it to build? In #350739, the reporter claims that we and JS are violating the GPL because not all files required to create the executable work are available under the GPL license. It's not that they have to be available, it's just that they have to be compatible. [Moreover, JS violation of the GPL isn't interesting because he's presumably the copyright holder, and can therefore do whatever he wants with his work.] CDDL is considered GPL-incompatible for linking with GPLed code. Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. Discussion with upstream in hope to make it double-licensed was not very fruitfull. He defines his tarball as medium (in terms of our DFSG!) where the two parts of the software (code and build system) are allowed to coexist, and if we would not allow that, then we had prooved that GPL violates the DFSG (because it infects other software on the same medium, hahaha). It would then activate the GPL's mere aggregation clause, but that's clearly not the case here. Now the question: how GPL-compatible should we consider this CDDL-like license? See http://www.gnu.org/licenses/license-list.html for details. The FSF's summary on this issue is fairly authoritative. Indeed, the patent reciprocity clause may also render software under this license non-free. We have the option of splitting the source package into code (GPLed) and meta-code (CDDL). Would that be suitable for main? I don't see how this would get around the GPL incompatibility issues, as the build system is only useful for cdrecord. Don Armstrong -- When I was a kid I used to pray every night for a new bicycle. Then I realised that the Lord doesn't work that way so I stole one and asked Him to forgive me. -- Emo Philips. http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: cdrtools - GPL code with CDDL build system
Don Armstrong [EMAIL PROTECTED] writes: On Sat, 18 Mar 2006, Eduard Bloch wrote: Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. In #350739, the reporter claims that we and JS are violating the GPL because not all files required to create the executable work are available under the GPL license. It's not that they have to be available, it's just that they have to be compatible. [Moreover, JS violation of the GPL isn't interesting because he's presumably the copyright holder, and can therefore do whatever he wants with his work.] Even if JS can do whatever he wants, Debian can't lawfully distribute a work with inconsistent license terms. CDDL is considered GPL-incompatible for linking with GPLed code. Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. We have the option of splitting the source package into code (GPLed) and meta-code (CDDL). Would that be suitable for main? I don't see how this would get around the GPL incompatibility issues, as the build system is only useful for cdrecord. Not that I'd go so far as to call it useful, but JS does use the same makefile templates for other software. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
On Sun, 19 Mar 2006, Måns Rullgård wrote: Don Armstrong [EMAIL PROTECTED] writes: It's not that they have to be available, it's just that they have to be compatible. [Moreover, JS violation of the GPL isn't interesting because he's presumably the copyright holder, and can therefore do whatever he wants with his work.] Even if JS can do whatever he wants, Debian can't lawfully distribute a work with inconsistent license terms. Clearly. The parenthetical is there only to deal with the claim that JS is violating the GPL. It has no bearing on what Debian must do. Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. The makefiles direct the assembly of the executable, just like the source code directs the operation of the compiler. [And indeed, some question as to whether some part of the executable is a dirived work of the compiler exists as well; luckily there are exceptions in the licences of gcc to deal with this case.] There are multiple different ways that the compiler and assembler can be directed by the makefile; quite a large number of them will produce an operational executable. Don Armstrong -- Never underestimate the power of human stupidity. -- Robert Heinlein http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: cdrtools - GPL code with CDDL build system
Måns Rullgård wrote: Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Just use dvdrtools instead. Oh? How is it in main then? -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Don Armstrong [EMAIL PROTECTED] writes: On Sun, 19 Mar 2006, Måns Rullgård wrote: Don Armstrong [EMAIL PROTECTED] writes: Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. The makefiles direct the assembly of the executable, just like the source code directs the operation of the compiler. [And indeed, some question as to whether some part of the executable is a dirived work of the compiler exists as well; luckily there are exceptions in the licences of gcc to deal with this case.] There are multiple different ways that the compiler and assembler can be directed by the makefile; quite a large number of them will produce an operational executable. Given only the source files, writing a makefile that will produce a working executable is fairly simple. I see makefiles as more of a convenience than a necessity to build a program. You might as well argue that every program in Debian is a derivative of apt and the package descriptions, since the former uses rules in the latter to decide what to install. Again, I say this is just a convenience that saves users the time to find out and install the dependencies manually. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
It also contains a file whose location can't be legally changed. In my opinion it has always been non-free since the clauses were added. It's not really GPL. andrew On 3/19/06, Sam Morris [EMAIL PROTECTED] wrote: Måns Rullgård wrote: Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious warnings about using device names), so it's certainly not DFSG-free. Just use dvdrtools instead. Oh? How is it in main then? -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Andrew Donnellan http://andrewdonnellan.com http://ajdlinux.blogspot.com Jabber - [EMAIL PROTECTED] --- Member of Linux Australia - http://linux.org.au Debian user - http://debian.org Get free rewards - http://ezyrewards.com/?id=23484 OpenNIC user - http://www.opennic.unrated.net
Re: cdrtools - GPL code with CDDL build system
* 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.297 of cdrecord.c */
if (flags F_VERSION)
exit(0);
/*
* End restricted code for quality assurance.
*/
---END QUOTE---
The linuxcheck() function can be found near the end of the same file:
---BEGIN QUOTE---
/*
* I am sorry that even for version 1.297 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.
*/
#if defined(linux) || defined(__linux) || defined(__linux__)
#ifdef HAVE_UNAME
#include sys/utsname.h
#endif
#endif
LOCAL void
linuxcheck()/* For version 1.297 of cdrecord.c */
{
#if defined(linux) || defined(__linux) || defined(__linux__)
#ifdef HAVE_UNAME
struct utsname un;
if (uname(un) = 0) {
/*
* I really hope that the Linux kernel developers will soon
* fix the most annoying bugs (as promised). Linux-2.6.8
* has still much more reported problems than Linux-2.4.
*/
if ((un.release[0] == '2' un.release[1] == '.')
(un.release[2] == '5' || un.release[2] == '6')) {
errmsgno(EX_BAD,
Warning: Running on Linux-%s\n, un.release);
errmsgno(EX_BAD,
There are unsettled issues with Linux-2.5 and
newer.\n);
errmsgno(EX_BAD,
If you have unexpected problems, please try Linux-2.4
or Solaris.\n);
}
if ((un.release[0] == '2' un.release[1] == '.')
(un.release[2] '6' ||
(un.release[2] == '6' un.release[3] == '.'
un.release[4] = '8'))) {
errmsgno(EX_BAD,
Warning: Linux-2.6.8 introduced incompatible interface
changes.\n);
errmsgno(EX_BAD,
Warning: SCSI transport does no longer work for suid
root programs.\n);
errmsgno(EX_BAD,
Warning: if cdrecord fails, try to run it from a root
account.\n);
}
}
#endif
if (streql(HOST_VENDOR, suse)) { /* For version 1.297 of cdrecord.c */
/* 1.297 */ errmsgno(EX_BAD,
/* 1.297 */ SuSE Linux is known to ship bastardized and defective versions
of cdrecord.\n);
/* 1.297 */ errmsgno(EX_BAD,
/* 1.297 */ SuSE is unwilling to cooperate with the authors.\n);
/* 1.297 */ errmsgno(EX_BAD,
/* 1.297 */ If you like to have a working version of cdrtools, get the\n);
/* 1.297 */ errmsgno(EX_BAD,
/* 1.297 */ original source from ftp://ftp.berlios.de/pub/cdrecord/\n;);
}
#endif
}
---END QUOTE---
For completeness, here's GPL 2c
Re: cdrtools - GPL code with CDDL build system
On Sat, Mar 18, 2006 at 10:07:09PM +0100, Eduard Bloch wrote: Hello debian-legal experts ;-), I need a bit support to clarify the issue with cdrtools' build system. Summary: a while ago, Joerg Schilling (upstream) replaced the copyright headers in the files of his build system inside of the cdrtools package with references to a CDDL license context. In #350739, the reporter claims that we and JS are violating the GPL because not all files required to create the executable work are available under the GPL license. CDDL is considered GPL-incompatible for linking with GPLed code. Discussion with upstream in hope to make it double-licensed was not very fruitfull. He defines his tarball as medium (in terms of our DFSG!) where the two parts of the software (code and build system) are allowed to coexist, and if we would not allow that, then we had prooved that GPL violates the DFSG (because it infects other software on the same medium, hahaha). The GPL specifies: For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. This unambiguously includes the make scripts as part of the source for the work. Under the GPL, this means the make scripts must be distributable under the same terms as the work. Since they are not, we have no license to distribute this work in compiled form. It's perfectly valid for the copyright holder(s) of cdrtools to grant an exception to the GPL, exempting the build scripts from the GPL source requirements. That doesn't address the fact that some (myself included) think the CDDL is non-free on its own, though. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: cdrtools - GPL code with CDDL build system
.\n); /* 1.297 */ errmsgno(EX_BAD, /* 1.297 */ If you like to have a working version of cdrtools, get the\n); /* 1.297 */ errmsgno(EX_BAD, /* 1.297 */ original source from ftp://ftp.berlios.de/pub/cdrecord/\n;); } #endif } ---END QUOTE--- For completeness, here's GPL 2c: ---BEGIN QUOTE--- c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) ---END QUOTE--- Take note that cdrecord is never interactive, so GPL 2c doesn't apply. I don't know why JS refers to it, but then JS does a lot of things that nobody understands. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Andrew Donnellan http://andrewdonnellan.com http://ajdlinux.blogspot.com Jabber - [EMAIL PROTECTED] --- Member of Linux Australia - http://linux.org.au Debian user - http://debian.org Get free rewards - http://ezyrewards.com/?id=23484 OpenNIC user - http://www.opennic.unrated.net
Re: cdrtools - GPL code with CDDL build system
Andrew Donnellan [EMAIL PROTECTED] writes: Why is he quoting the GPL *preamble*? Preambles aren't supposed to have legal effect, are they? I guess JS is as thoroughly confused about legal matters as he is about device naming. (Interesting looking at the case of the preamble question in Australia's 1999 constitutional referendum - the 'no' case says that the preamble could have had legal effect.) Could you elaborate on this, or provide some pointers? -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Måns Rullgård wrote: Don Armstrong [EMAIL PROTECTED] writes: On Sun, 19 Mar 2006, Måns Rullgård wrote: Don Armstrong [EMAIL PROTECTED] writes: Not just linking; it's the creation of a derivative work of a GPLed work. Frankly, I don't see how you can argue that cdrecord is not a derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. The makefiles direct the assembly of the executable, just like the source code directs the operation of the compiler. [And indeed, some question as to whether some part of the executable is a dirived work of the compiler exists as well; luckily there are exceptions in the licences of gcc to deal with this case.] There are multiple different ways that the compiler and assembler can be directed by the makefile; quite a large number of them will produce an operational executable. Given only the source files, writing a makefile that will produce a working executable is fairly simple. I see makefiles as more of a convenience than a necessity to build a program. You might as well argue that every program in Debian is a derivative of apt and the package descriptions, since the former uses rules in the latter to decide what to install. Again, I say this is just a convenience that saves users the time to find out and install the dependencies manually. If that is the case, wouldn't the simplest course of action be simply to strip the build system from the tarball and replace it with a free one written by the maintainer? signature.asc Description: OpenPGP digital signature
Re: cdrtools - GPL code with CDDL build system
On Sun, 19 Mar 2006, Måns Rullgård wrote: Given only the source files, writing a makefile that will produce a working executable is fairly simple. I see makefiles as more of a convenience than a necessity to build a program. You could extend this argument to any segment of sourcecode in the program. Since the output that you get from the compiler is dependent on the way in which the compiler was called, just like the way in which the source code was written determines the object code you get out, this argument isn't terribly persuasive. Don Armstrong -- You could say she lived on the edge... Well, maybe not exactly on the edge, just close enough to watch other people fall off. -- hugh macleod http://www.gapingvoid.com/batch8.htm http://www.donarmstrong.com http://rzlab.ucr.edu
Re: cdrtools - GPL code with CDDL build system
Benjamin Seidenberg wrote: If that is the case, wouldn't the simplest course of action be simply to strip the build system from the tarball and replace it with a free one written by the maintainer? Oops, missed where Don mentioned this earlier in thread. Sorry! Benjamin signature.asc Description: OpenPGP digital signature
Re: cdrtools - GPL code with CDDL build system
Don Armstrong [EMAIL PROTECTED] writes: On Sun, 19 Mar 2006, Måns Rullgård wrote: Given only the source files, writing a makefile that will produce a working executable is fairly simple. I see makefiles as more of a convenience than a necessity to build a program. You could extend this argument to any segment of sourcecode in the program. Not at all. Every piece of source code gets compiled into some machine code (except parts that get optimized out), and so is part of the work, both before and after compilation. Exactly how the source code is transformed into machine code is irrelevant. You might use compiler A, I might use compiler B, and someone else might prefer to do it all by hand. In each case, the executable is a transformed version of the source code. In neither case does any part of a makefile (or equivalent) get included in the output. A work can't be derived from another work without including some piece of it (ignoring for the moment reuse of literary characters without any verbatim copying of text taking place). In many cases a program could be compiled with a command like find . -name '*.c' | xargs gcc If the program is large, gcc will probably run out of memory, but that makes no difference in principle. The makefile describes how the work can be done in smaller steps, nothing else. Is a printed book a derivative work of the manual for the printing press? Since the output that you get from the compiler is dependent on the way in which the compiler was called, just like the way in which the source code was written determines the object code you get out, this argument isn't terribly persuasive. The output depends on which compiler is used, and on which options were given to that compiler. This still does not change the fact that the output is a mechanical transformation of the input, and is not a derivative of anything of which the source was not already. You can certainly not be arguing that the source code is derived from the makefiles. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
On Sun, 19 Mar 2006, Måns Rullgård wrote: A work can't be derived from another work without including some piece of it This is actually not the case; including output of a work (or generated by a work) in another work can make that work a derivative work of the first work. Is a printed book a derivative work of the manual for the printing press? This is the wrong analogy. The right analogy is: Is a printed book a derivative work of the typeface used in the printing press? Don Armstrong -- When I was a kid I used to pray every night for a new bicycle. Then I realised that the Lord doesn't work that way so I stole one and asked Him to forgive me. -- Emo Philips. http://www.donarmstrong.com http://rzlab.ucr.edu
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
Andreas Metzler [EMAIL PROTECTED] wrote: On Wed, Oct 02, 2002 at 04:25:45PM +0200, Andreas Metzler wrote: cdrtools uses this library, too, the license is: The libedc_ecc sources are protected intellectual property of Heiko Eißfeldt. The libedc_ecc sources are definitely not under GPL. [...] The issue has been solved upstream, libedc_ecc in A38 is GPL. cu andreas
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Sun, 2002-10-06 at 13:16, Henning Makholm wrote: Scripsit Anthony DeRobertis [EMAIL PROTECTED] Um, isn't this just a clarification of GPL 2(a)? True, it's marginally more strict than what the GPL says (namely, the GPL does not require pointing to the original version) but the difference is not so big as to make no sense whatsoever. It is a fair amount more, in that it also requires me to justify why I made that change. Notice the and why part. I also must change the documentation as well. To recap, in order to make that change, the following are required above the GPL: 1) I must change the documentation to add the following statements: a) A reason why I decided to make said change b) A statement where the official version is at c) A statement that my new file name only applies to non-official versions The are all additional restrictions, and, if the documentation is considered other software, may run afoul the DFSG as well. The GPL explicitly prohibits additional restrictions, so any additional restriction --- no matter how small --- is contradictory with the GPL. Thus, it doesn't make any sense whatsoever. signature.asc Description: This is a digitally signed message part
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
Scripsit Anthony DeRobertis [EMAIL PROTECTED] It is a fair amount more, in that it also requires me to justify why I made that change. Notice the and why part. Is that a substantial requirement? I did it because the Voices told me to. So? The GPL explicitly prohibits additional restrictions, so any additional restriction --- no matter how small --- is contradictory with the GPL. Thus, it doesn't make any sense whatsoever. I still think this is wrongly put. The net result clearly makes sense. It is a different licence from the GPL, and not compatible with the original, but it is not meaningless either. -- Henning Makholm You propose to avoid dying? I will be interested to hear the method you plan for this endeavour.
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
Scripsit Anthony DeRobertis [EMAIL PROTECTED] defaults.c is also under the plain GPL. There is a comment block about this: /* * 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. Considering the file is under the GPL, this doesn't make any sense whatsoever. Um, isn't this just a clarification of GPL 2(a)? True, it's marginally more strict than what the GPL says (namely, the GPL does not require pointing to the original version) but the difference is not so big as to make no sense whatsoever. -- Henning MakholmDe er da bare dumme. Det skal du bare sige til dem.
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Wed, Oct 02, 2002 at 04:25:45PM +0200, Andreas Metzler wrote: cdrtools uses this library, too, the license is: The libedc_ecc sources are protected intellectual property of Heiko Eißfeldt. The libedc_ecc sources are definitely not under GPL. [Please Cc me on replies.] Hello, cdrecord can compiled without linking against libedc_ecc (edit cdrecord/Makefile), it still works with reduced functionality, ie. you cannot use the -raw* modi for data-tracks. According to JS this is ATM mainly a problem for low cost cd-writers (Phillips OEM) with broken firmware. - These writers don't support SAO, so you are stuck with TAO. Proposed solution: Upload a new version of cdrtools-nolibedc_ecc (1.11a36) to main but remove libedc_ecc for the source. Build misofs, cdda2wav, cdrecord-dev and additionally a new package named cdrecord-nolibedc from this source package - document the fact that libedc has been disabled in manpage and package description. This package should have Provides|Replaces|Conflicts with cdrecord. Upload a new version of cdrtools to non-free, which has complete upstream sources and does not include the patches from Debian that change cdrecord, ie. especially 03_cdr_mmap. Only build a binary package cdrecord from this source-package, that Replaces|Conflicts with cdrecord-nolibedc. Anything that has versioned depends on cdrecord will have to change them to Depends: cdrecord-nolibedc (version) | cdrecord (version). Is it ok for a package in main to have Depends: something_in_main | something_in_non-free? I've chosen cdrecord-nolibedc/cdrecord instead of cdrecord/cdrecord-nonfree because I think that the package cdrecord should contain what it always has been: a full fledged version. This'll keep breakage for users a minimum. Comments? cu andreas pgpmNWp2xTgx5.pgp Description: PGP signature
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Fri, 2002-10-04 at 12:35, Branden Robinson wrote: Strictly speaking, our concerns are only whether a license is legimitate, and whether it's DFSG-free. Well, when we see stuff like the cdrdao license, which appears to create a dual-licensed mess along the lines of my hypothetical, I'd have concerns about that license being legitimate. Since it really doesn't make any sense what so ever, I don't think the author intended to actually apply the GPL. However, that someone would wwant to dual-license a work under the GPL and something extremely unpalatable shouldn't really concern us. It should if the answer is they didn't want it; instead, they wanted something that sort of looks like the GPL, but isn't. Your example above is a poor one because licensors often offer some kind of carrot to offset the stick, e.g., waiving the must-distribute-source requirement of the GPL. Well, it quite resembles the cdrdao license, doesn't it? -- G. Branden Robinson| Never underestimate the power of Debian GNU/Linux | human stupidity. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | signature.asc Description: This is a digitally signed message part
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Sat, Oct 05, 2002 at 08:28:30AM -0400, Anthony DeRobertis wrote: On Fri, 2002-10-04 at 12:35, Branden Robinson wrote: Strictly speaking, our concerns are only whether a license is legimitate, and whether it's DFSG-free. Well, when we see stuff like the cdrdao license, which appears to create a dual-licensed mess along the lines of my hypothetical, I'd have concerns about that license being legitimate. Since it really doesn't make any sense what so ever, I don't think the author intended to actually apply the GPL. It is perfectly reasonable for us to err on the side of caution and elect not to distribute a work when the copyright license on it is self-contradictory and confusing. Indeed, to avoid distributing it is the best defense against an allegation of copyright infringement. -- G. Branden Robinson|I am sorry, but what you have Debian GNU/Linux |mistaken for malicious intent is [EMAIL PROTECTED] |nothing more than sheer http://people.debian.org/~branden/ |incompetence! -- J. L. Rizzo II pgpZsTIfY3mph.pgp Description: PGP signature
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Fri, Oct 04, 2002 at 12:20:31AM +0200, Henning Makholm wrote: Scripsit Andreas Metzler [EMAIL PROTECTED] cdrecord has this: [...] | - The fact that cdrecord is linked against libedc_ecc does not |make libedc_ecc licensed under GPL. Section 2 of the GPL does |not apply in this special case. This is very confused writing. Apparently the cdrecord author has tried to follow Eißfeld's fudful instructions about GPL without actually checking what the GPL says in its section 2. Hello! He probably wanted something like fetchmail, with s/OpenSSL/libedc_ecc/ | Specific permission is granted for the GPLed code in this | distribition to be linked to OpenSSL without invoking GPL | clause 2(b). http://sourceforge.net/forum/forum.php?forum_id=213313 implies that a free (partial?) replacement for libedc_ecc is being worked on. One may hope that it can be plugged into cdrecode as well. It has to be, it is the same library. Warning: the andreasm behind the sourceforge notice seems to be different from the Andreas Metzler in this thread. Yes, you,ll usually find me as [EMAIL PROTECTED] | If you create a work derived from cdrecord, you may not ship | this derived work with libedc_ecc. Conflicts with the second half DFSG #3 and/or DFSG #9. This clause will have to go even if a replacement for libedc_ecc is found/made. The author is trying to tell that libedc_ecc is non-free software and that you needed explicit permission from its author to use it in your own project, even if it were a fork of cdrtools. | Even if you create a work derived from cdrecord, you may not ship | this derived work with libedc_ecc, you'll have to get explicit | permission from libedc_ecc to use it. cu andreas PS: Branden could you please Cc me on your replies, too? - The Mail-fup2 is set accordingly, thanks. pgpCfN1Z3RZav.pgp Description: PGP signature
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Thu, 2002-10-03 at 22:26, Branden Robinson wrote: On Thu, Oct 03, 2002 at 06:48:31PM -0400, Glenn Maynard wrote: In short (as I understand it), placing software under the GPL with additional restrictions simply doesn't work. It does, if you dual-license it. If you don't, then in general you've got software without a license. Hmm? Given the choice of the dual licenses: You can take my software, and use it under the GPL or You can take my software, and use it under something that sort of looks like the GPL, but does't allow you to modify files foo.c, bar.c, or baz.c in this certain way. doesn't make too much sense. Well, legally, maybe it does. But practically, everyone would take the first license, and just forget the second one. GPL dual-licensing only works when you want to remove GPL-imposed restrictions. signature.asc Description: This is a digitally signed message part
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Thu, 2002-10-03 at 17:04, Andreas Metzler wrote: |- | This software is under GPL with the following limitations: | | | - You may not modify certain copyright messages in cdrecord.c | | See cdrecord.c for further information. hmmm? cdrecord.c is under the plain GPL; see the top of the file... | | | - You may (with a few exceptions) not modify the location of the | configuration file /etc/default/cdrecord. | | See defaults.c for further information. defaults.c is also under the plain GPL. There is a comment block about this: /* * 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. */ Considering the file is under the GPL, this doesn't make any sense whatsoever. signature.asc Description: This is a digitally signed message part
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Fri, Oct 04, 2002 at 10:09:04AM -0400, Anthony DeRobertis wrote: Hmm? Given the choice of the dual licenses: You can take my software, and use it under the GPL or You can take my software, and use it under something that sort of looks like the GPL, but does't allow you to modify files foo.c, bar.c, or baz.c in this certain way. doesn't make too much sense. Well, legally, maybe it does. Correct. But practically, everyone would take the first license, and just forget the second one. Probably. But that's not *our* problem. GPL dual-licensing only works when you want to remove GPL-imposed restrictions. Strictly speaking, our concerns are only whether a license is legimitate, and whether it's DFSG-free. IMO we should also issue advisory opinions on licensing when asked that will make it easier for us to fulfill our Social Contract (e.g., mindless license proliferation is not good for the Free Software community). However, that someone would wwant to dual-license a work under the GPL and something extremely unpalatable shouldn't really concern us. Your example above is a poor one because licensors often offer some kind of carrot to offset the stick, e.g., waiving the must-distribute-source requirement of the GPL. -- G. Branden Robinson| Never underestimate the power of Debian GNU/Linux | human stupidity. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | pgpURgxW6AIcW.pgp Description: PGP signature
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Wed, Oct 02, 2002 at 09:35:13PM -0500, Branden Robinson wrote: On Thu, Oct 03, 2002 at 01:02:11AM +0100, Colin Watson wrote: On Wed, Oct 02, 2002 at 07:39:17PM -0400, Brian Ristuccia wrote: [libecc/edc is non-free] Actually, the author offered to relicense the problem code under the GPL for EUR250, which would not be specific to just Debian. Oh, sorry, I followed the first link in the original post rather than the second and didn't see that offer. I'll go away now. If someone within the Project volunteered to write a Free replacement for no fee, or for a fee less than EUR250, that might set a better precedent. In the meantime, the packages that include this code need to be moved out of main. Hello, What is the best way to do this? Bugreport against cdrtools? This is unfortunate, it would require moving ~20 Packages out of main, including debian-cd and pgi. cu andreas PS: Please CC me on replies. PPS: I am Ccing cdrtools' maintainer Michael Stone.
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Thu, Oct 03, 2002 at 10:37:08PM +0200, Andreas Metzler wrote: On Wed, Oct 02, 2002 at 09:35:13PM -0500, Branden Robinson wrote: [libecc/edc is non-free] In the meantime, the packages that include this code need to be moved out of main. What is the best way to do this? Bugreport against cdrtools? This is unfortunate, it would require moving ~20 Packages out of main, including debian-cd and pgi. Hello, Sorry, I am too silly to read, the different parts of cdrtools have different licenses, mkisofs is GPLv2 and cdrecord has this: |- | This software is under GPL with the following limitations: | | | - 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. | | | - The fact that cdrecord is linked against libedc_ecc does not | make libedc_ecc licensed under GPL. Section 2 of the GPL does | not apply in this special case. | | If you create a work derived from cdrecord, you may not ship | this derived work with libedc_ecc. |- cu andreas
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
Scripsit Andreas Metzler [EMAIL PROTECTED] cdrecord has this: |- | This software is under GPL with the following limitations: | - You may not modify certain copyright messages in cdrecord.c | See cdrecord.c for further information. That appears to be fair game. | - You may (with a few exceptions) not modify the location of the | configuration file /etc/default/cdrecord. That smells of functional restriction. Unless the furter information referenced mitigates this impression, this will be non-free in and of itself. | - The fact that cdrecord is linked against libedc_ecc does not | make libedc_ecc licensed under GPL. Section 2 of the GPL does | not apply in this special case. This is very confused writing. Apparently the cdrecord author has tried to follow Eißfeld's fudful instructions about GPL without actually checking what the GPL says in its section 2. http://sourceforge.net/forum/forum.php?forum_id=213313 implies that a free (partial?) replacement for libedc_ecc is being worked on. One may hope that it can be plugged into cdrecode as well. Warning: the andreasm behind the sourceforge notice seems to be different from the Andreas Metzler in this thread. | If you create a work derived from cdrecord, you may not ship | this derived work with libedc_ecc. Conflicts with the second half DFSG #3 and/or DFSG #9. This clause will have to go even if a replacement for libedc_ecc is found/made. -- Henning Makholm You want to know where my brain is, spetsnaz girl? Do you? Look behind you.
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Thu, Oct 03, 2002 at 11:04:11PM +0200, Andreas Metzler wrote: | This software is under GPL with the following limitations: This alone reminds me of this: http://lists.debian.org/debian-legal/2002/debian-legal-200205/msg00062.html In short (as I understand it), placing software under the GPL with additional restrictions simply doesn't work. Are there any more succinct explanations of this? This problem comes up often, and I don't like pointing people at that particular post as an explanation (much of it being CUPS-specific, and the dual-licensing stuff will confuse people). I can't find anything about this in the GPL FAQ. -- Glenn Maynard
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Thu, Oct 03, 2002 at 06:48:31PM -0400, Glenn Maynard wrote: In short (as I understand it), placing software under the GPL with additional restrictions simply doesn't work. It does, if you dual-license it. If you don't, then in general you've got software without a license. -- G. Branden Robinson| Organized religion is a sham and a Debian GNU/Linux | crutch for weak-minded people who [EMAIL PROTECTED] | need strength in numbers. http://people.debian.org/~branden/ | -- Jesse Ventura pgpo7nb4D9wep.pgp Description: PGP signature
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Wed, Oct 02, 2002 at 04:25:45PM +0200, Andreas Metzler wrote: Perhaps Debian could solve this issue once and forever by paying 250 Euros to libedc_ecc's author, Heiko Eißfeldt? No. It's not the same to pay money to recover a proyect like Blender than to recover a little piece of software like this. As it's said here: http://www.mail-archive.com/cdwrite@other.debian.org/msg03407.html a GPL replacement could be written quite easy. And as Adreas Muller says here: http://www.mail-archive.com/cdwrite@other.debian.org/msg03415.html he's going to write a replacement for that tool in some weeks. -- Jose Carlos Garcia Sogo [EMAIL PROTECTED]
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Wed, Oct 02, 2002 at 11:21:01PM +0200, Jose Carlos Garcia Sogo wrote: On Wed, Oct 02, 2002 at 04:25:45PM +0200, Andreas Metzler wrote: Perhaps Debian could solve this issue once and forever by paying 250 Euros to libedc_ecc's author, Heiko Eißfeldt? No. It's not the same to pay money to recover a proyect like Blender than to recover a little piece of software like this. As it's said here: http://www.mail-archive.com/cdwrite@other.debian.org/msg03407.html a GPL replacement could be written quite easy. And as Adreas Muller says here: http://www.mail-archive.com/cdwrite@other.debian.org/msg03415.html he's going to write a replacement for that tool in some weeks. EUR250,- is not much money and until the replacement has been written, Debian is without distributable CD-writing software. - I am still hoping somebody'll come forward and tell me that it is ok to distribute the modified version of cdrecord. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! vim:ls=2:stl=***\ Sing\ a\ song.\ ***
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Thu, Oct 03, 2002 at 12:49:48AM +0200, Andreas Metzler wrote: EUR250,- is not much money and until the replacement has been written, Debian is without distributable CD-writing software. Paying for a licence specific to Debian is not going to help us distribute it in main, though ... -- Colin Watson [EMAIL PROTECTED]
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Thu, Oct 03, 2002 at 12:36:00AM +0100, Colin Watson wrote: On Thu, Oct 03, 2002 at 12:49:48AM +0200, Andreas Metzler wrote: EUR250,- is not much money and until the replacement has been written, Debian is without distributable CD-writing software. Paying for a licence specific to Debian is not going to help us distribute it in main, though ... Actually, the author offered to relicense the problem code under the GPL for EUR250, which would not be specific to just Debian. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Wed, Oct 02, 2002 at 07:39:17PM -0400, Brian Ristuccia wrote: On Thu, Oct 03, 2002 at 12:36:00AM +0100, Colin Watson wrote: On Thu, Oct 03, 2002 at 12:49:48AM +0200, Andreas Metzler wrote: EUR250,- is not much money and until the replacement has been written, Debian is without distributable CD-writing software. Paying for a licence specific to Debian is not going to help us distribute it in main, though ... Actually, the author offered to relicense the problem code under the GPL for EUR250, which would not be specific to just Debian. Oh, sorry, I followed the first link in the original post rather than the second and didn't see that offer. I'll go away now. -- Colin Watson [EMAIL PROTECTED]
Re: cdrdao license issues show that cdrtools package is non DFSG, too?
On Thu, Oct 03, 2002 at 01:02:11AM +0100, Colin Watson wrote: On Wed, Oct 02, 2002 at 07:39:17PM -0400, Brian Ristuccia wrote: Actually, the author offered to relicense the problem code under the GPL for EUR250, which would not be specific to just Debian. Oh, sorry, I followed the first link in the original post rather than the second and didn't see that offer. I'll go away now. If someone within the Project volunteered to write a Free replacement for no fee, or for a fee less than EUR250, that might set a better precedent. In the meantime, the packages that include this code need to be moved out of main. -- G. Branden Robinson| I suspect Linus wrote that in a Debian GNU/Linux | complicated way only to be able to [EMAIL PROTECTED] | have that comment in there. http://people.debian.org/~branden/ | -- Lars Wirzenius pgpf9WKD96pKj.pgp Description: PGP signature
