cdrtools is undistributable

[Matthew Garrett]

cdrecord includes the mkisofs binary. mkisofs itself is under the GPL, but the binary links statically against included libraries that are under the CDDL. The CDDL contains restrictions not present in the GPL, preventing us from providing the complete source to the binary under terms compatible with the GPL. As a consequence, the binaries are impossible to distribute while satisfying their license. We should remove the package from the archive until this is corrected.

[Schily (schilling-fokus)]

Your claims are a result of missreading the GPL - sorry your claims are wrong.

[Paul Sladen (sladen)]

How did this get uploaded in the first place? I thought we were shipping the sanitised Debian version without the licensing mess.

Or... there's always the option of using the LRM/volatile method and distributing the two incompatible libraries separately (link on demand in a tmpfs). :)

Ideally the software and library would be made available together under a single license (CDDL or GPL) which would solve all the issues.

[Schily (schilling-fokus)]

There is no issue as the GPL allows non-GPL code to be used from a GPLd project.

The GPL _only_ forbids to use GPLd code from non-GPL projects, but this does not
happen in cdrtools

[Mario Đanić (mario-danic)]

Please, not again. Do I really have to lose all respect I had some time ago for you guys?
All of the sudden everybody appears to be hero. My knowledge of the licences is at the point
where I understand most of it, but I'm not a lawyer, so I don't wanna get into that discussion.

Cdrtools, Cdrkit, Libburnia. Three friendly competitors on the FOSS arena in the area of
cd-recording. There have been numerous discussions (even inside Ubuntu, I'll get to that
later) what to use, what should be uploaded, what shouldn't and what is the way of the future.

I believe I will say no lie if I claim that anyone but siretart wasn't interested at all.
We discussed, we fought, we made technical arguments, we made human arguments,
yet everyone choose to let it pass by.

I used to say ages ago that cdrkit isn't and cannot be the way of the future. Nobody
was developing it, and all maintaince that was taking place in it was changing build
system and pull changes from the cdrtools which were under GPL. That was Debians
choice, that was your choice. They had all rights to do it, if you look at the licence.
They choose to *improve* the software. Yet again, a valid point in this world of ours.
Ideology mattered, people did not. I was flamed and insulted. Yet what I used to say back
then became the truth.

People used to say cdrtools shouldn't be used of it's licence(s) and it's maintainer, who
often took wrong approach with discussion to people. I am not here to discuss what's he
or what you're like, but me and Thomas talk with him with mostly no spark between us.
Our discussion are strictly technical. O, why can't we just all get along? Licences?
What about people? Shouldn't people be more important? Did we forget once again why
we are here? And can't we just get around the desk, and create an agreement?

We decided to give users choice. Isn't that what Free/Open Source software is all
about? And collaboration? Plus if that wasn't enough, it was put in Multiverse to
prevent any possible arguments against it licence-wise. We talked with Schily,
he agreed to help with bugs on LP and it doesn't get any better then that when
you have upstream author helping with bugs. Wrong approach sometimes? Perhaps ...
But we need to help ourselves, we need to help Schily, and he will help us.
All I ever saw was flaming, with no technical and human discussion from any side.
Who will make the first move? Will it be us? Or will you do another fork?

I am a Libburnia developer. I do not see the future...
... but I know we all need to collaborate to make sure future
is bright for each and every one of us.

I know each and every one of you do great work, let's not forget that,
so please don't think I have anything against you.

I am no one in the Ubuntu community, I understand, but I did help
form this decision of uploading cdrtools, and I firmly stand behind it.

Sincerely,
M.

[Matthew Garrett (mjg59)]

Under the existing licensing, cdrtools simply can't be legally distributed at all. By doing so we are infringing the copyright of several people. Keeping it in multiverse doesn't help that. The solutions are either for the libraries and build system to be relicensed under terms compatible with the GPL (keeping them under the CDDL as well is perfectly acceptable), for all the other copyright holders to grant permission for the current licensing or for cdrtools to be removed from the archive. The latter should be done in any case, until the situation is resolved.

[Schily (schilling-fokus)]

Matthew, please try to avoid writing such claims before we had the chance for a discussion on the
topic. I am sure you will change your mind as you cannot require constraints that cannot be ensured
even for a 100% GPL program.

[Steve Langasek (vorlon)]

Will remove the following packages from hardy:

  cdda2wav | 10:2.01.01a33-0ubuntu2 | amd64, hppa, i386, ia64, lpia, powerpc, sparc
  cdrecord | 10:2.01.01a33-0ubuntu2 | amd64, hppa, i386, ia64, lpia, powerpc, sparc
  cdrtools | 10:2.01.01a33-0ubuntu2 | source
   mkisofs | 10:2.01.01a33-0ubuntu2 | amd64, hppa, i386, ia64, lpia, powerpc, sparc

------------------- Reason -------------------
(vorlon) inconsistent license, not distributable (LP #177154)
----------------------------------------------

Going to remove the packages now.
Continue (y/N)? y
Deleting... done.

[Chris K. Jester-Young (cky)]

@Schily:

In regards to your claim of "There is no issue as the GPL allows non-GPL code to be used from a GPLd project", this only applies to licences that are GPL-compatible. CDDL is not one such licence: http://www.gnu.org/licenses/license-list.html

Therefore, a special exception needs to be granted by the copyright holders of the GPL code before it can be linked to CDDL libraries: http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

Now, the above links all refer to the opinion of the Free Software Foundation, and I realise that it's not a universally-agreed opinion. However, in looking at the source licence notices on mkisofs (as distributed with cdrtools-2.01.01a39), there is a multitude of contributors who have licensed their code under GPLv2+, without said special exception, and it's quite possible that at least some of these authors share the FSF's view of GPL licensing.

I apologise for flogging a dead horse; really, I came to this thread because I was quite frustrated about not having cdrtools (specifically cdrecord) to use on Hardy Heron, and sought to discover why it was removed. Unfortunately for me (as somebody wishing to use cdrtools without having to build my own package), the premise of this bug report is quite justifiable: read according to the FSF stance, mkisofs really cannot be distributed.

Personally, I don't use mkisofs all that much, and would therefore be happy with a middle ground where all the cdrtools packages are reinstated, bar mkisofs. However, regardless of whether Ubuntu would agree to go along this path, the mkisofs licensing issue should be fixed, either by getting in touch with all the copyright holders for a special exception, or by dual-licensing the parts that mkisofs uses.

I understand that both paths are really troublesome: the former because you have to track down lots of authors; the latter because you have to identify all the CDDL code that mkisofs uses, all the code that said CDDL code uses, and so on and so forth, and arrange to have them dual-licensed, and if some of these have other copyright holders, then to have their assent to the dual-licensing as well.

Anyway, long story short, I'm just writing as a happy user of cdrtools who is now unhappy that it can no longer be distributed with Ubuntu. Lately I have coastered two CDs trying to burn the new OpenSolaris 2008.05 release with cdrkit, and am only too glad to see cdrtools return. I don't know if the above can really be resolved at all, but this is my hope that it will. All the best!

[Schily (schilling-fokus)]

First, you need to know the background information:

wodim and cdrkit in general is undistributable because
it is in conflict with the Copyright law and the GPL.

The original cdrtools have absolutely no license problem.
This was proved two times by an in depth license review made
by the Sun legal departement.

I don't care about the FSF GPL FAQ because it is in conflict with the
GPL license text. The "FSF GPL FAQ" was not written by lawyers but
by a laymen who is (acording to Eben Moglen) incorrectly informed.

The GPL was made intentionally compatible with _any_ library under
_any_ license and this is one important reason why there is no license problem
with the original code. If you like to read non-biased information about the
GPL, I recommend to read the GPL review made by the lawyer of the
OpenSource initiative:

http://www.rosenlaw.com/html/GPL.PDF

and a word by word discussion in:

http://www.rosenlaw.com/Rosen_Ch06.pdf

Note that even Debian agreed on March 6th 2009 to go back to the original
cdrtools as soon as possible. Ubuntu should become legal too and go back
to recent well maintained and legal original software instead of using a
questionable and buggy fork.

[Michael (michaeljt)]

It seems to me that a major part of the discussion here is whether it would be legal to distribute cdrtools if some of the people who contributed to cdrecord (and other parts?) under the GPL objected to the fact that it is now CDDL. Are those contributors known? If so, can't they be asked to clearly state whether or not they object? If they don't then there is no issue - if they do, then regardless of the legal situation it is probably best not to distribute their contributions, given that the FOSS community is based on the whole on good will and respect of other people's work. And even if tracking down the contributors is a bit tricky, there should be enough interested people to make the job easier - and perhaps the nice people at lwn.net could be asked to put a short article on their front page about the issue.

[Schily (schilling-fokus)]

First let me point to something important: The fork "cdrkit" is in conflict
with the Copyright law and for this reason undistributable (neither in binary
nor in source). The fact that some Linux distributors distribute "cdrkit"
seems to unveil a social problem.

We currently have a strange situation where some Linux distributors
distribute non-legal software and at the same time refuse to distribute
the legal original software while claiming this is a result of so-called
license problems. There are even other OSS projects that are based
on code from cdrtools (e.g. GNU vcdimager) that do not legally use the
code they took from cdrtools. Vcdimager did e.g. did claim that the code
is under GPL although that code never has been published under GPL
by it's author and the author did never give permission to put this code
under GPL. So it seems that even the FSF has a very strange interpretation
of legality.

If the Linux distributors would really do things based on a legal analysis,
they would of course not distribute vcdimager and cdrkit.

If those Linux distributors would be serious, they would distribute the original
cdrecord, cdda2wav, readcd, ....as the only GPLd program that uses non-GPLd
code is mkisofs. THe rest is 100% CDDL. It is obvious that some Linux distributors
have a social problem that needs to be addressed.....

The GPL is very clear about the fact that GPLd code may call non-GPLd code.
If this was not the case, then all Linux distributions would be illegal. So even
with mkisofs, there is no problem as mkisofs only does what the GPL intends
to be OK.

The lisense change did happen 3.5 years ago and the related contributors
of the GPLd code of course know about the license change. Nobody who
owns Copyright on related code did ever even try to discuss the current
situation, so it is obvious that what happens with mkisofs (a work under GPL
calls code from _other_ works being not under GPL) is not only intended to be
legal by the GPL but also accepted by all Copyright holders.

The dispute was started by a completely unrelated person who owns absolutely
no Copyright on cdrtools and who for this reason cannot sue people for what
happens in cdrtools.

Meanwhile, some Linux distributions (e.g. Suse) did start to distribute cdrtools
again.

What we need to discuss now is merely whether Ubuntu likes to stay at the
dark side or whether Ubuntu makes fact based decisions and comes back to the
FOSS community that collaborates.

[Michael (michaeljt)]

I agree that it would be surprising if said contributors did not know of the licence change, and that if they have not complained yet it would be surprising if they had issues with it. Again though, are those contributors known? If they can be contacted and confirm that they are satisfied then the current objections to distributing cdrtools will become pretty much unmaintainable, even from the point of view of the people who are objecting now. And presumably everyone who wants to burn CDs will be the happier for it.

[Eric Towers (fuzzyeric)]

Submitter asserts "The CDDL contains restrictions not present in the GPL" without citation, making the assertion nonactionable. Does there exist a clear and detailed argument about the incompatibility asserted?

I find in other places that the use of CDDL'ed smake to build is identified as a blockage.
GPL v2 requires the build scripts, but not the build tools be distributed. GPLv2: "The source code for a work means the preferred form of the work for making modifications to it. 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." Including the smake scripts appears to be required. Including (binary or source) smake in the OS distribution may or may not be required by the next sentence in the GPLv2: "However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." (As an aside, ..., forking smake seems far more likely to be a successful project than cdrkit has ever been.)
GPL v3 requires the build scripts and explicitly allows the nondistribution of smake: "The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work." smake seems to qualify as a generally available free program which is not part of the work and therefore its inclusion does not seem to be required under GPLv3.

Overcoming the smake blockage seems straightforward. Assuming the other unidentified blockages are similarly trivial, forward motion seems easy. Without actually identifying these other blockages, it is impossible to classify them as trivial or not.

So, what are the asserted blockages, in sufficient detail that they can be evaluated?

[Matthew Bassett (hewbass)]

Oops -- pressed the wrong button. Have reverted my accidental change (I am surprised I was able to make it though!)

[Mårten Woxberg (maxmc)]

Matthew Basset: What do you mean, it's still in Fix Released state.

[Jonas Ådahl (jadahl)]

He first changed to Fix Committed by mistake, then changed back to Fix Released.

[Schily (schilling-fokus)]

In any case, it is wrong: You cannot "fix" a nonexisting problem.
Cdrtools of course is distributable.

...and Ubuntu still distributes a buggy, dead and undistributable fork instead of original software :-(