FAQ   Download latest   Download recent   Download old/stable   Linux Packages  

There is no license problem in the original cdrtools

Sun lawyers made a full legal review on the cdrtools package between August and November 2008 and did not find any license problem, so they ship binary versions compiled from the original cdrtools.

Oracle lawyers made a full legal review on the cdrtools package in Spring 2011 and did not find any license problem, so they ship binary versions compiled from the original cdrtools.

SuSE lawyers made a full legal review on the cdrtools package in Fall 2013 and did not find any license problem, so they ship binary versions compiled from the original cdrtools.

The claims from Eduard Bloch obviously conflict with the GPL license text. See the GPL legal review from Lawrence Rosen an independent lawyer who worked for the OpenSource initiative.

Time table of a social incidence introduced by Debian

2001, SuSE distributed a modified version of the cdrtools that claimed to raise security. It however introduced bugs and a serious security vulnerability

2002 with cdrtools-1.11a17 in aggreement with Debian, the use of the original name is forbidden with variants that come with intentional bugs.

May 2004, Debian (Eduard Bloch) asks for including a patch to mkisofs.

May 2004, the patch is rejected as it does not do what it was announced to do and because it is buggy.

May 2004, Debian starts their own defective fork from cdrtools and a diffamation campaign against cdrtools.

December 2004, a wish to replace the unwilling Eduard Bloch for cdrtools was rejected by Debian.

Summer 2005, Debian claims that cdrecord has a GPL problem even though 100% of cdrecord is GPL and nothing was changed.

May 2006, in defence of the attacks from Debian, cdrecord, readcd and cdda2wav have been relicensed under CDDL. Mkisofs remains 100% GPL.

Septemer 2006, Debian still claims "GPL problems in cdrecord" even though cdrecord is 100% CDDL.

September 2006, Debian was instructed to rename their defective fork from May 2004.

September 2006, Debian renamed their fork and started to claim they just created it.

December 2006, Eduard Bloch introduces changes into the code that are in violation with the Copyright law.

May 2007, All significant activities in the Debian fork stop. Only typo corrections appeared since then.

2014, the Debian fork only supports 30-40% of the features of recent code.

2014, Most Linux distros that have become victims of believing in the Debian attacks converted back to original code. Only Debian & dependencies and RedHat & dependencies remain hostile to OpenSource.

May 2014, we are awaiting the 10 year anniversary of Debian as a OSS hostile entity.

The people behind the attacks against cdrtools

Eduard Bloch <blade@debian.org>. This is the person who started the attacks with his unwillingness to deliver a minimum level of quality.

Jörg Jaspert <joerg@debian.org>. This person supports the attacks inside Debian and promised Simon Phipps on March 6th 2009 at CeBIT to integrate the original cdrtools into Debian again within less than 6 weeks. He never had the intention to implement this promise.

Erich Schubert <schube@dbs.ifi.lmu.de>. This person frequently attacks cdrtools on Wikipedia using the account chire or IP addresses from Vodafone or Deutsche Telekom from the Munic area. He also tried to attack SuSE for reintegrating cdrtools.

Many Linux distributions now come with broken variants of cdrtools

If you are on Debian, RedHat and some other Linux distributions, you need to take extreme care as these distributions replaced cdrtools by a fork that is based on an outdated version of cdrtools. This fork did not fix bugs but rather introduced new bugs that never have been in the original software.

For other Linux distributions, I suggest to have a look at /usr/bin/cdrecord and check whether this is a link to another program or whether there is an original program file. Also call "cdrecord -version" to check what version you are using. The affected distributions replaced all programs from cdrtools (cdrecord, cdda2wav, readcd, mkisofs, ...) by programs from the fork.

How do I find out whether I am running a recent original version of cdrtools?

Call "cdrecord -version" and check the output. If you see something like:

Cdrecord-ProDVD-ProBD-Clone 3.02a06 (i386-pc-solaris2.11) Copyright (C) 1995-2016 Jörg Schilling

If you are running the original software, also check the other programs to have the same version number in order to be 100% sure. If you see version numbers below 2.01.01a09 (including 2.01), you are running outdated software that needs an update if you are running Linux- or newer.

Starting with 2.01.01a32, all original programs contain the year (2007 or later) and Jörg Schilling in the first line of the -version output. As an Example, "mkisofs -version" outputs:

mkisofs 2.01.01a74 (i386-pc-linux) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2010 Jörg Schilling

If you are not running the original software, get recent original software from the "Download recent" or from the "Download latest" location. Unpack, compile by running "make" and install. Make sure that all programs that send (SCSI) commands to CD/DVD/Blu-Ray drives are installed to be suid root.

If you are running cdrtools frontends that on your installation might have been bastardized by Debian (like k3b, brasero and others) and if you do not like to replace these programs with original versions, you should remove files like /usr/bin/wodim, /usr/bin/genisoimage, /usr/bin/icedax, /usr/bin/readom and replace them by links to the original software. Note that an unmodified k3b prefers the original cdrtools from /opt/schily/bin over the fork because it knows about the bugs in the fork.

Linux controversy

The problem was initiated by a hostile Debian packet maintainer (Eduard Bloch). In May 2004, Eduard Bloch created a defective fork at Debian (by modifying the SCSI transport code) and asked to add a patch to the upstream mkisofs and because that patch was full of bugs, he was asked to fix the bugs before the patch could be incorporated. Bloch rejected to fix the bugs, but immediately started to send repeated personal insults to Jörg Schilling over a long period of time. He later started to spread incorrect claims about the cdrtools project. It was not possible to convince Debian to suspend Eduard Bloch from being a packager for cdrtools at that time.

In March 2006, a group of Debian maintainers started to attack the cdrtools project based on the incorrect claims from Eduard Bloch.

The latter attacks have been based on the fact that cdrtools was licensed under the GPL and based on an illegitimate interpretation of the GPL license text. As a result, on May 15th 2006 most projects from the cdrtools project bundle have been relicensed under CDDL (giving more freedom to users than the GPL does). At the same time, an important amount of additional code (DVD support code from Jörg Schilling and a Reed Solomon decoder from Heiko Eißfeldt) has been added to the freely published sources.

In summer 2006, the attacks from the group of Debian maintainers escalated and in September 2006, these people renamed the fork Eduard Bloch created in Spring 2004, keeping all bugs Bloch introduced in 2004. They soon added a lot more bugs and this way turned the "fork" into a questionable experiment. The last work on this "fork" has been done eight months later on May 6th 2007, then the leader of the attacks stopped his efforts on the fork and instead started to advertize for nerolinux. During the Debian project activity, the source code distributed by Debian was modified in a way that violates GPL and Copyright and makes it impossible to legally distribute this "fork" called "cdrkit". There is no license problem with the original cdrtools.

Although there is no "project" activity on the "fork" anymore (except e.g. single char changes in man pages) since more than 3.5 years (which is more than five times of the pseudo activity period), there are still people who spread incorrect claims on both the original project and the fork. Please help the free original project by correcting these incorrect claims.

Strange license claims from some Debian maintainers

This is what the group of Debian maintainers used to attack the cdrtools project:

They claimed that the GPL requires the build system (used to compile GPL software) to be included and to be published under GPL if binaries from the compiled GPL sources are published, even though the build system is a completely independent project and work.

They then took old cdrtools sources and replaced the original build system by something that is not under GPL (nor under a GPL compatible license) either. They even omit parts of the build system they use from the sources they distribute (although GPL §3 is very explicit about this).

Now you only need to become crazy to understand why they believe the Debian fork is "free" but the original cdrtools is not.

Sun is doing the same with GNOME and many programs owned by the FSF

Later, Debian added the claim that GPLd programs cannot be linked against CDDLs libraries but Sun does the same (as done in cdrtools) with many programs on Solaris.

Sun is happily waiting since 2005 for being sued by a Copyright holder of a related GPLd program in order to defend the freedom of OSS in court.

Even the FSF did not sue Sun, so it is obvious that the FSF knows that there is no problem with this combination.

Debian agreed on distributing the original cdrtools as soon as possible

On March 6th 2009 at CeBIT, Simon Phipps (Sun Opensurce Evangelist) helped to get an agreement with Debian. There was a meeting between Simon Phipps (Sun), Jörg Jaspert (Debian FTP Master), Jörg Schilling (Cdrtools Author and Maintainer) and a neutral observer, where Jörg Jaspert in a legally binding way agreed on distributing the original cdrtools again for Debian as soon as possible. Jörg Jaspert told us that this would be within three months. We are currently waiting for this promise to become reality. Unfortunately Debian seems to be extremely slow as Debian did not finish this after 6 months.

OpenSuSE started to distribute the original and unmodified cdrtools again on September 6th 2009. This was a result of a discussion with the SuSE legal managers started three weeks before. In 2013, SuSE repeated their legal review with the same result and now plans to kick out the unmaintained cdrkit.

Ark Linux started to distribute the original cdrtools again on September 10th 2009. This was an own decision from Ark Linux.

The Debian fork violates the GPL and the Urheberrecht

This is a list of violations in the Debian fork. It does not claim to be complete. The Urheberechtsgesetz will be named UrhG below.

The GPL preamble (see also Urheberrecht §14 below) disallows modifications in case they are suitable to affect the original author's reputation. As Debian installs symlinks with the original program names and as many people still believe that the symlinks with the original program names are the original software, Debian does not follow the GPL.

GPL §2a requires to keep track of any author and change date inside all changed files. This is not done in the fork.

GPL §2c requires modified programs to print Copyright messages as intended by the original author. This is not done in the fork wodim.

GPL §3 requires the complete source to be distributed if there is a binary distribution. The Debian fork tarball does not include everything needed to compile the cdrtools fork (complete source) and Debian does not give a written offer to deliver the missing parts.

UrhG §13 requires redistributors to accept the way the author likes to mark his ownership. Debian removed such marks from the source of the fork against the will of the author and did ignore hints on this fact.

In the book »Die GPL kommentiert und erklärt« Till Jäger (the lawyer from Harald Welte) explains on page 63 why removing these ownership marks is also a clear violation of the GPL.

UrhG §14 forbids modifications that may affect personal interests of the author in the work. Debian introduced such modifications as Debian knowingly introduced bugs that prevent use and changed the behavior in a way that makes the command line syntax non-portable and Debian still makes the work available under the original names.

What are the problems when running programs from the broken fork?

  • In all programs of the fork that send SCSI commands, you may be unable to access any of the CD/DVD/Blu-Ray drives at all if you are on Linux- or later. This is due to a missing workaround for the Linux kernel interface change that happened with Linux-
  • In the cdrecord clone from the fork, messages have been removed that would warn you in case that you are not running cdrecord as root. As some of the SCSI commands used by cdrecord need root privileges, cdrecord may fail later with strange problems because of this hack. Note that cdrecord supports (and needs to support) many vendor unique features of drives (e.g. for optimized writing of CDs and DVDs). Linux filters away all vendor specific SCSI commands in case the program that sends them does not have root privileges. There are other non vendor unique commands that are filtered also.

    The mature DVD support from the original cdrecord (that exists since February 1998) has been ripped off and replaced by something of very poor quality. The replacement code misses key features (like -atip extraction and printout). As a result the DVD code in the fork is not correctly parameterized.

    All recent cdrecord enhancements like better CUE Sheet for CDs support and Blu-Ray support are missing in the clone.

  • The mkisofs clone from the fork is the worst of all. The web is full of bug reports for the clone.

    The original mkisofs fixed dozens of bugs from the early days of mkisofs (1993-1997). These bugs are still present in the fork.

    The original mkisofs added support for multi-extent files that may be > 4 GB (up to 8 TB) while the fork does not support single files to be bigger than 4 GB.

    The original mkisofs added find(1) command line support into mkisofs via libfind and thus gives a lot new features that are important for people who like to use mkisofs for simple backups or like to avoid the need to create a copy of the tree that is going to be processed by mkisofs. This feature is missing in the fork.

    The original mkisofs added support for Rock Ridge Version-1.12 and now supports correctly working hard links. This feature is missing in the fork.

    The original mkisofs added support for correct link counts on all files and directories. This feature is missing in the fork.

    The original mkisofs replaced the GNU getlongopt based CLI interface by something with much less bugs. The design for the mkisofs options from the early days introduced a lot of similar named long options. The old GNU getlongopt based code does not detect typo's in the options but rather finds the option with the longest substring that does not have a typo and assigns it a string parameter that contains the typo.

    The original mkisofs added working support for UTF-8 based locales and support for iconv based translations. The clone claims to do the same but disabled key features from mkisofs with the attempt to support UTF-8 and may create images with incorrect file name lengths without even printing a warning.

    The original mkisofs added much better UDF support (such as support for symlinks, userids/groupids and permissions as well as support for MacOS extensions). These features are missing in the fork.

    The mkisofs clone will create unusable filesystems in some cases when Joliet is used. This is a bug that never existed in the original.

    Ask your Linux distributor to include recent originals instead of broken forks

    Inform them that if they force you to use the defective fork instead of allowing you to choose the correctly working original cdrtools, they publish a non-free Linux distribution.

    Tell them that you like to decide yourself which program you choose. Whether it is the fork or whether it is the original program depends on which package works better.

    Some Linux distributions ship both and do not try to patronize their users, others do not give their users the freedom.

    The following Linux distributions currently work against the freedom of their users:

    Debian, RedHat, Fedora

    If you know of other unfree distributions, please report.

    The following Linux distributions currently grant their users the freedom to select the better CD/DVD/Blu-Ray writing software:


    Slackware ships the original cdrtools and does not even ship the broken fork.


    Gentoo cdrecord packet


    OpenSuSE cdrecord packet

    Ark Linux

    Ak Linux ships both

    Cdrtools-3.00 for Ubuntu from user Antiqua see ubuntu forum...

    The Ubuntu burning team is preparing a package for the original cdrtools.

    Ubuntu cdrecord+mkisofs+cdd2wav packet
    Package archive of the ubuntu burning team with attitional hints (e.g. how to modify /etc/apt/sources.list to allow the installation).

    Unfortunately, Mark Shuttleworth seems no longer be interested in freedom and stopped the attempt to make Ubuntu legal again, so be very careful on Ubuntu.

    What is the background for the forks?

    When the Open Software movement has been started by people like Larry Wall, Rich Salz and others in the late 1970s, it was important for all authors of free software to write software that runs best on all available platforms.

    Later, when the Free Software Foundation was created by Richard Stallman in the mid 1980s, it was still important to write software that runs best on all available platforms. This continued until the late 1990s. Linux did already exist but the software that many people now call "linux software" was mainly developed on Sun systems until the mid 1990s.

    Then around y2000, more and more free software became non-portable because it's maintainers moved to Linux and did not care about portability anymore.

    At the same time, Linux distributions got into trouble because more and more Linux users did no longer buy Linux distributions but downloaded them from the network. This caused pressure on the commercial Linux distributors. RedHat is a well known commercial Linux distributor, but even Debian needs to be called a "commercial Linux distributor". Key people from Debian are paid for their work on Debian (see here) and for this reason do no longer represent community interests but the commercial interests of their investors.

    How is this all related to cdrtools?

    As commercial Linux distributions are interested in revenue, they need "arguments" they can print on glossy paper...

    In order to get these arguments, they are no longer interested in code quality. Instead they are interested in marketing "facts".

    If they add UNICODE UTF-8 support to the list of key features of their distribution, they need to be able to tell their users that all available software supports UTF-8. A lot of Open Source software does not support UTF-8 yet and with many of the OSS programs this problem is not obvious. With other software like mkisofs, the problem is obvious.

    Linux distributors could cooperate with the author and try to help with the implementation of UTF-8 support.....

    In fact, this happened around y2004. I received a patch that was intended to add UTF-8 support to mkisofs.

    Unfortunately, the code quality of this patch was lousy. It tried to incorrectly initialize a structure and it handled only a few obvious cases. Many important issues with UTF-8 support have been completely ignored. As a result, I rejected this patch because I do care about code quality (I still need to be able to maintain the code in a few years). The people in the Linux distribution could have fixed the problems and created a useful solution but they did not do this.

    Now these people have been in trouble and needed an excuse for their behavior. They created the fairy tale that there is a license problem in cdrtools. They created a network of "cooperation" and supported some people which created a fork of cdrtools based on the fairy tale.....

    This fork created a lot of pseudo actions in the first few months. As (in contrary to the original cdrtools) it is not based on code quality, this fork did experiment with Linux specific behavior but finally failed to create any new or better interface.

    The results are a mess. The cdrecord fork on SuSe-10.2 (running on a well supported IBM laptop) is completely unable to talk to the built in CD/DVD drive. The unmodified original cdrecord is able to talk to the drive, even if the dev= parameter is omitted. In 2007, the related packet maintainer from SuSe claimed that he needs to patch the original software in order to add support for things that are supposed to be missing in the original software. Well, the original cdrtools meanwhile do support UTF-8 correctly....did he intend to reduce the code quality to what SuSe users "expect"?

    Despite all these interests, the fork died in May 2007.

    What are the real interests of the Linux distributors?

    Are the Linux distributors still interested in Free and Open Software?

    Will Linux distributors reveal that they did make a mistake and go back to the real FROSS model?

    I invite all Linux distributors to go back to support real Free and Open Source Software and to show that they are able to correct a mistake from the past.

    Last Change 16/04/06
    Berlios Berlios Homepage Schily Schily's Homepage Schily Cdrecord VED powered