Mailinglist Archive: opensuse-features (404 mails)

< Previous Next >
[openFATE 311186] original cdrtools
Feature changed by: Michal Marek (michal-m)
Feature #311186, revision 24
Title: original cdrtools

Package Wishlist: Rejected by Michal Marek (michal-m)
reject date: 2011-02-11 14:17:14
reject reason: License issue must be resolved first.
Requester: Important

Requested by: Christopher Yeleighton (yecril71pl)
Partner organization:

openSuSE distributes the package wodim instead of the package cdrtools.
The reason this happens is a claim of the Debian maintainers that the
present license of the package cdrtools is incompatible with GPL.
However, even if it were the case, it does not make a good reason to
exclude cdrtools from openSuSE.

Business case (Partner benefit): cdrtools is better maintained and it is less buggy.

#1: Christopher Yeleighton (yecril71pl) (2011-01-31 22:22:32)
See also: Many Linux distributions now come with broken variants of
cdrtools (

#2: Tim Edwards (tk83) (2011-02-07 12:39:23)
This topic has been done to death, not least in the huge flamewar on
the Debian mailing list between the cdrecord author and some of the
Debian developers. It's not based on some half-arsed claim by the
Debian maintainers either: all the major distributions, including the
commercial ones Redhat and Novell, have looked at the legal
implications of the license on cdrecord and determined that they can't
legally distribute it.
This is a very good reason for not including cdrtools in Opensuse.
Plus, cdrkit (wodim etc.) is still being developed.

#3: Christopher Yeleighton (yecril71pl) (2011-02-07 13:07:03) (reply to
Any documents to back up your claims? I am particularly interested in an
official and verifiable statement for Novell.

#4: Tim Edwards (tk83) (2011-02-07 13:30:43) (reply to #3)
You can read the whole sordid tale here:
Even some of the Debian developers believed that the licence change was
motivated by personal problems between them and Joerg Schilling.
Redhat's reasoning for the Fedora project:
From some of the Opensuse developers:
Note here that the developers don't believe that patches to cdrecord
get accepted upstream. And also that since these messages were posted
cdrkit has started releasing again. Discussion on this is just beating
a long dead horse - if you want cdrecord just head over to software. untick "Exclude user's home projects" and search - it's

#5: Tim Edwards (tk83) (2011-02-07 14:26:01) (reply to #4)
If you want official statements try the release notes: And
there's nothing more verifiable than the fact that cdrkit is used in
all the major distros in place of cdrecord.
Another informative thread:

#6: Christopher Yeleighton (yecril71pl) (2011-02-07 19:51:02) (reply to
This caused both my brain and my machine to overheat :-)
Unfortunately, the release notes
( do
not say why cdrtools are dropped.
The informative thread
does not name the party whose copyright laws are offended by cdrtools .
The present source of cdrtools , 3.01, contains two components licensed
under GPL: autoconf and mkisofs . autoconf is a build tool so it is
irrelevant. mkisofs is indeed GPL but it is a separate program,
therefore it can coëxist with CDDL software if it is distributed as a
separate package.

#7: Tim Edwards (tk83) (2011-02-07 20:18:05) (reply to #6)
The first post in the Debian bug I posted lays out what the problem is
quite clearly. "In cdrtools 2.01.01a03 license of several makefiles
have been changed to a custom version of CDDL, which is a non-GPL-
compatible license." Nothing to do with autoconf. Unless the cdrecord
author has reversed those license changes none of the major Linux
distros will pick up cdrecord again, that horse has been flogged to
death many times

#8: Christopher Yeleighton (yecril71pl) (2011-02-07 21:08:37) (reply to
CDDL, modified or not, is incompatible with GPL, at least if we believe the
FSF (believe the FSF) (the reasons why it is deemed incompatible are
not explained.) If this were reason to drop cdrecord , we would have to
drop flash-player as well, wouldn’t we?

#9: Tim Edwards (tk83) (2011-02-07 21:29:04) (reply to #8)
No. The cdrecord licence is (at least in the opinion of most Linux
distros) not legally valid because it puts CDDL licensed files in a GPL
program. That is why they don't want to distribute it.
Flash, on the other hand, is a completely separate program licensed
under a legally valid license. The Flash license, even though it's not
open source, allows re-distribution - which is why you'll find it in
the non-oss ("non open source") repository.

#10: Christopher Yeleighton (yecril71pl) (2011-02-07 22:27:56) (reply
to #9)
cdrecord puts CDDL-licensed files into what GPL program?
( cdrecord itself is CDDL)

#11: Tim Edwards (tk83) (2011-02-07 22:47:51) (reply to #10)
I should have said it the other way round (GPL parts in a CDDL licensed
program). Again just read the Debian link in my first post - the first
post in that bug explains the problem as clear is it can be explained.
quote:"In cdrtools 2.01.01a03 license of several makefiles have been
changed to a custom version of CDDL, which is a non-GPL-compatible

#12: Christopher Yeleighton (yecril71pl) (2011-02-08 00:07:56) (reply
to #11)
There are no GPL parts in cdrtools, except for mkisofs which can easily
be taken out.

#13: Tim Edwards (tk83) (2011-02-08 00:55:24) (reply to #12)
It still looks like a mix of CDDL and GPL, including the custom build
system he has in there. It's also only had one release in nearly 7
years now (in 2009 AFAICT) and from the comments by developers in
forums he won't accept patches from other people.
Even if the GPL/CDDL ambiguity was fully resolved by removing the last
bits of GPL code there's no chance that Linux distros would include
CDDL stuff when there's a perfectly good GPL project that does the same
thing, and actually gets some development done.

#14: Jan Engelhardt (jengelh) (2011-02-10 16:46:10) (reply to #13)
Yeah? cdrkit lacks DVD+ and BD support, do I need say more?

#15: Tim Edwards (tk83) (2011-02-10 17:27:44) (reply to #14)
But dvd+rw-tools does, and is installed by default, used by apps such
as Kde and has no licensing issues.

#16: Christopher Yeleighton (yecril71pl) (2011-02-10 21:21:35) (reply
to #13)
Jörg says: ‘I am accepting any patches that make sense and that are
portable.’ His target of choice is Solaris.

#17: Christopher Yeleighton (yecril71pl) (2011-02-11 10:22:27) (reply
to #10)
Problem: mkisofs (GPL) links to libschily (CDDL)

#18: Christopher Yeleighton (yecril71pl) (2011-02-11 10:31:39) (reply
to #17)
IMHO, GPL code can link to commercial libraries (although not the other
way round). It is discouraged but legally possible.

#19: Michal Marek (michal-m) (2011-02-11 14:17:00) (reply to #18)
No, unless these libraries are a normally part of an operating system,
which is not the case of libschily.

#21: Christopher Yeleighton (yecril71pl) (2011-02-11 17:21:07) (reply
to #19)
So how can be Dev-C++ distributed under GPL? Delphi libraries are not
part of an operating system either.

+ #22: Michal Marek (michal-m) (2011-02-14 10:25:08) (reply to #21)
+ Dev-C++ is a Delphi program, right? I'm not a lawyer to asses this, but
+ the delphi libraries could be considered part of the "compiler" as
+ well.

#20: Christopher Yeleighton (yecril71pl) (2011-02-11 17:19:03) (reply
to #18)
It seems the problem is that CDDL does not allow linking GPL to it
( :
* After speaking to Jörg we began our review of the complete source of
cdrtools, and soon verified that GPL compliance on mkisofs was broken.
This is incorrect, CDDL compliance is broken, if anything.
* while CDDL Section 3.6 permits combination with code under other
licenses, it nonetheless requires that "the requirements of this
License are fulfilled for the [ combined program ]." Since it is
impossible to observe certain requirements of the CDDL while
simultaneously respecting the GPL's prohibition of additional
restrictions (GPLv2 Section 6), the CDDL Section 3.6 permission is
insufficient to allow the combination.
This is still as vague as can be, so the best I can do is to paste the
relevant texts here:
* You may create a Larger Work by combining Covered Software with other
code not governed by the terms of this License and distribute the
Larger Work as a single product. In such a case, You must make sure the
requirements of this License are fulfilled for the Covered Software.
Here are the points:
1) There is no need to distribute mkisofs with libschily.
2) Note the "mistakes" made by Mr. Moglen, here in italic.

openSUSE Feature:

< Previous Next >
This Thread