cdrtools - a tale of two licenses [LWN.net]

When Sun Microsystems set down to create a license for the release of Solaris and other code, the end result was the Common Development and Distribution License or CDDL. Most people who have looked hard at the license have agreed that it is, indeed, a free software license. It is also, however, considered to be incompatible with the GNU General Public License (GPL); the Free Software Foundation has this to say about the CDDL:

This is a free software license which is not a strong copyleft; it has some complex restrictions that make it incompatible with the GNU GPL. It requires that all attribution notices be maintained, while the GPL only requires certain types of notices. Also, it terminates in retaliation for certain aggressive uses of patents. So, a module covered by the GPL and a module covered by the CDDL cannot legally be linked together. We urge you not to use the CDDL for this reason.

This license incompatibility has, among other things, put a roadblock in the way of incorporating any Solaris code into the Linux kernel (and vice versa). The two remain in their own separate licensing universes, and cannot mix.

Not everybody appears to share this opinion, however. Consider Debian bug 377109, filed by the sharp-eyed license watchers in that camp. It seems that Jörg Shilling, the maintainer of cdrtools (containing cdrecord, mkisofs, and other tools), decided to license his build system for those tools under the CDDL. The GPL requires that build tools and scripts also be released under the GPL, so mixing the CDDL build system with the GPL-licensed CD/DVD tools made the whole thing undistributable - at least, in the eyes of the Debian developers.

Since that bug was filed, the situation has evolved somewhat. The current 2.01.01 cdrtools release has relicensed a number of code components under the CDDL. The relicensed bits include cdrecord and libscg. Other components, such as mkisofs and libparanoia, remain under the GPL and LGPL, respectively. Some of these licenses are unlikely to change; the mkisofs code has copyrights held by a number of people (and companies) other than Mr. Schilling, and going back as far as 1986. Since mkisofs, at least, is built with libscg, the resulting system is a combination of GPL and CDDL-licensed code. In the minds of most observers, this combination is not distributable.

The Debian developers are now trying to figure out what to do about this situation. As most people familiar with the relevant personalities would likely expect, conversations with Mr. Schilling have not come to any sort of productive outcome - though it has yielded an amusing nine-point plan from Mr. Schilling on how to fix Debian's cdrecord problems. A very possible outcome is that Debian will drop Mr. Schilling's cdrtools distribution and maintain a fork starting from the last distributable version; other distributors may well follow suit. The dvdrtools project has been pointed out as a possible starting point.

Forking cdrtools is not a particularly new idea. This package has been the subject of a long series of inflammatory disputes with its maintainer, who does not always agree with the Linux way of doing things. People have often wondered in public just why this version of cdrtools was still in use. The answer, presumably, lies in the fact that (1) cdrecord works for most people, who can happily ignore its maintainer, and (2) CD/DVD recording is a complex and tricky business which intimidates many developers who might otherwise jump into the code. Whatever the reasons might be, no cdrtools fork has gotten very far.

The licensing issue might just be the final straw that makes a viable fork happen. Distributors can ignore a difficult maintainer, but it is harder for them to ignore possible licensing issues. If they decide that cdrtools cannot be distributed in it current form, they will have no alternative to ceasing distribution - and that means coming up with a replacement. This may be the year when, finally, cdrtools for Linux finds a new maintainer.

to post comments

cdrtools - a tale of two licenses

Posted Aug 12, 2006 20:30 UTC (Sat) by Zomb (guest, #23391) [Link] (4 responses)

Actually the libburn project has been kinda revived. Development of a fork started few days/weeks ago, see http://libburn.pykix.org/wiki/WikiStart for details.

Another fork was maintained by the author of cdrskin in the last months. Currently cdrskin can already emulate many of cdrecord's functions and most of its command line interface.

We can expect both efforts to become merged RSN and be a viable alternative to cdrtools in near future.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 9:22 UTC (Sun) by elanthis (guest, #6227) [Link]

Good to hear that libburn is still alive in some fashion.

I recall the conversations that spawned libburn, which focused on creating GUI CD-burning tools. The choice came down between (a) wrapping cdrecord and hoping that input/output of the program never changed in ways the wrapper couldn't handle gracefully, (b) modifying the rather complex cdrecord code into being a library, or (c) doing things from scratch.

I advocated very heavily towards either option that made a real library that wouldn't be subject to cdrecord changing and causing either non-functional or dangerously dysfunctional tools. Turned out cdrecord was too ugly to modify into a library for most people, so libburn was born.

I was pretty sad that it never really got anywhere.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 19:17 UTC (Sun) by tetromino (subscriber, #33846) [Link]

Too bad that libburn is GPL and not LGPL. Using GPL for a system library virtually guarantees more stupid license incompatibilities in the future.

Although I suppose if libburn uses some cdrtools code, GPL was the only choice.

cdrtools alternatives sought. (cdrdao anyone?)

Posted Aug 17, 2006 9:41 UTC (Thu) by bjornen (guest, #38874) [Link] (1 responses)

I feel the need to mention http://cdrdao.sourceforge.net/ here...

Q: What features of cdrecord is not present in cdrdao?

cdrtools alternatives sought. (cdrdao anyone?)

Posted Aug 17, 2006 11:10 UTC (Thu) by wookey (guest, #5501) [Link]

You can't do cdrdao image.iso

cdrdao seems to fundamentally designed around the idea that you put files on a CD. That's fine except when what you have is a CD image and that's what you want to put on the CD. It works fine for me for putting files on CDs, but I rarely do that - I usually put isos on CDs and for that I still have to use cdrecord. Somebody fix this omission and I could certianly use dvdtools and cdrdao and get rid of schilly's tiresome (but effective) software.

cdrtools - a tale of two licenses

Posted Aug 12, 2006 20:49 UTC (Sat) by johnkarp (guest, #39285) [Link]

Haven't the licensing issues been going on for a while? : http://lists.debian.org/debian-devel/2004/10/msg00487.html

cdrtools - a tale of an incompatible author

Posted Aug 12, 2006 21:24 UTC (Sat) by erich (guest, #7127) [Link] (9 responses)

Form all I've heard and read, Jörg Schilling seems to be hard to work with. A couple of factors play a role, he seems to be quite arrogant and ignorant about the work and preferences of others.

I'd be very happy if we would end up with an cdrtools-equivalent (in terms of functionality, not of obscurity) with no code of his involved.

For this it would be very helpful if other would join the existing efforts of making a "free" cdrecord, i.e. the libburn and dvdrecord projects.

It's not just Debian. SuSE had some serious trouble with Mr. Schilling, too. I think he put code into cdrtools once to nag users when they used SuSE.

That Debian is more active probably is a reason that the decisions are made by the developers who have to deal with Mr. Schilling, and not by the commercial interests of a company having to sell a linux distribution with working CD and DVD writing support. The recent move of e.g. Fedora and OpenSuSE to more community-developed distributions will make them care more about such things, too.

cdrtools - a tale of an incompatible author

Posted Aug 12, 2006 21:34 UTC (Sat) by jsarets (guest, #39560) [Link] (6 responses)

Jörg Schilling, I'd like to introduce you to David Dawes. You two should get along quite famously.

cdrtools - a tale of an incompatible author

Posted Aug 13, 2006 7:06 UTC (Sun) by louie (guest, #3285) [Link] (5 responses)

The two of them could get together with Branden Robinson and JWZ and write some software together- it would be a blast! For those of you new to the general scene, if you want a good chuckle, go read the famous "choke on a bucket of cocks" post right now :)

cdrtools - a tale of an incompatible author

Posted Aug 14, 2006 8:35 UTC (Mon) by nix (subscriber, #2304) [Link] (4 responses)

Actually, jwz and David can at least listen to reason in most areas (jwz in pretty much all, as far as I can tell: he just has strong opinions and a quirky sense of humour).

Joerg lives in his own universe and is impervious to rational argument on every subject I've ever seen him discuss (if one can use that word with respect to Joerg: to me, 'discussion' implies at least the possibility of movement on both sides). He's right and everyone else is wrong, on every subject, no matter what, and that's it. The facts are not important and every possible debating trick is usable, no matter how unethical, in service of that.

cdrtools - a tale of an incompatible author

Posted Aug 14, 2006 12:03 UTC (Mon) by arafel (subscriber, #18557) [Link]

Joerg is one of those people where dpm's comment applies in full force. Thankfully, people with quite this level of obliviousness are comparatively rare...

You go right on thinking that. Don't let reality stop you. -- dpm

cdrtools - a tale of an incompatible author

Posted Aug 15, 2006 4:18 UTC (Tue) by kirkengaard (guest, #15022) [Link] (2 responses)

And, however off-the-wall or b0rken, whatever some UNIX does (other than Linux) is more important. Joerg has demonstrated a remarkable capacity to try to serve every UNIX alive simultaneously, and so when Linux does something perfectly sensible, but not bound by the logic of every other UNIX in existence, Joerg tells us we're wrong, and uses his code as a bludgeon.

cdrtools - a tale of an incompatible author

Posted Aug 15, 2006 9:07 UTC (Tue) by nix (subscriber, #2304) [Link]

For values of 'every other UNIX in existence' equal to 'Solaris and only Solaris', you're right. He tries to serve every other Unix in existence by a) writing an indirection layer to make them look like Solaris (which is fine), b) insisting that users use device-choice semantics appropriate only to old versions of Solaris (which is silly), and c) badgering everyone else to try to force them to be more like Solaris (which is annoying).

It's not as if cdrecord looks remotely like any other Solaris application in existence in command-line argument layout or in user interface. The whole thing is a triumph of NIH, from the, ahem, `unique' makefile system with its manifold annoyances through to the `unique' command line with *its* manifold annoyances (which make it amazingly hard to parse the output of from scripts: *another* way in which dvdrecord beats it).

cdrtools - a tale of an incompatible author

Posted Aug 18, 2006 13:32 UTC (Fri) by job (guest, #670) [Link]

His tar utility is lovely, my secret wish is that it ends up replacing GNU tar in a distant future, at least the features and file format compatibility.

cdrtools - a tale of an incompatible author

Posted Aug 13, 2006 9:35 UTC (Sun) by lamikr (subscriber, #2289) [Link] (1 responses)

It just seems that dvdrtools is not very active project.
Latest commit I found seems to be commit number 26, made over 6 months ago...

http://www.arklinux.org/projects/dvdrtools/log/trunk/README
(Mention that we don't support DVD+R(W) (yet))

Mika

cdrtools - a tale of an incompatible author

Posted Aug 17, 2006 13:52 UTC (Thu) by kenmoffat (guest, #4807) [Link]

true, dvdrtools is not active at the moment, but it does work very well - you don't get the later code that defaults to burning as fast as the drive allows (so you need the old-style invocation) but it does build straightforwardly on architectures beyond x86 (e.g. x86_64 and ppc64) - no need to work around Mr Schilling's incomprehensible* build system.

* that is, incomprehensible to a mere mortal, he obviously understands his own plaything.

cdrtools - a tale of two licenses

Posted Aug 12, 2006 21:53 UTC (Sat) by jwb (guest, #15467) [Link] (4 responses)

cdrecord also has the distiction of being among the worst programs ever written. I'd be happy to rid my life of that over-verbose, stderr-spamming, malfunctioning trash forever. Thanks to Mr. Schilling for providing the motivation for the community to replace his third-rate product at long last.

cdrtools - a tale of two licenses

Posted Aug 12, 2006 23:12 UTC (Sat) by liljencrantz (guest, #28458) [Link] (2 responses)

While Shilling is obvioulsy a rather difficult character with some rather annoying ideas about having everything his way, saying that cdrecord is garbage is rather unfair. If cdrecord truly was garbage, then one of the many attempts to replace it over the years would have won by now. Fact of the matter is that in spite of Jörg, cdrecord has remained _the_ cd recording program for most Unices for something like a decade. It is obviously a _lot_ harder to write a cd recording utility than you'd belive. My understanding is that nearly every new type of recorder is incompatible with all previous recorders. It's basically your average maintainership nightmare. Kind of like Ide was before SATA.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 0:07 UTC (Sun) by Zomb (guest, #23391) [Link]

From cdrtool's README:

It seems that all drives that have been initially released in 1999
or later are MMC compliant. If a recent drive does not work with
cdrecord, you most likely found a firmware bug in this drive.
Contact your drive vendor in this case.

So there have something close to a stable interface since... seven years? I cannot remember when I sold or threw away the last CD recorder from the time before, sorry.

cdrtools - a tale of two licenses

Posted Sep 5, 2006 7:58 UTC (Tue) by lacostej (guest, #2760) [Link]

I don't get it. Has anyone heard of regression testing ?

For a package like cdrecord there should be a full functional test suite simulating the various recorders and their strange/buggy behavior.

With that in place, maintaining it would be much easier than the way it is now.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 8:37 UTC (Mon) by nix (subscriber, #2304) [Link]

To give it its due the code is substantially more readable than that of, say, procmail/formail.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 2:21 UTC (Sun) by k8to (guest, #15413) [Link] (7 responses)

dvdrtools already works for me; has documentation that I can read and
isn't full of Joerg's insane irrelevant ramblings, incorrectly describing
10 year old bugs; and seems to be moving along nicely.

Is it not viable for some subset of users at this time?

cdrtools - a tale of two licenses

Posted Aug 13, 2006 2:41 UTC (Sun) by joey (guest, #328) [Link] (6 responses)

Ditto, I tried to remember the last time I used cdrecord and couldn't. It's all DVDs for my purposes now.

OTOH, I recently burnt a 150 mb debian netinst image to DVD, which is not the most efficient use of space and money. It was cheaper than buying a new stack of CDs though.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 5:58 UTC (Sun) by k8to (guest, #15413) [Link] (5 responses)

I meant that dvdrecord works fine for burning CDs. I don't have a DVD burner.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 6:56 UTC (Sun) by JoeF (guest, #4486) [Link] (4 responses)

You still need mkisofs to create the filesystem for the CD...

From my experience, Joerg doesn't seem to accept any patches. Mkisofs contains some braindead code that results in significant slowdowns (Joerg claims it came from the original author Eric Yougdale).
I sent him a first version of a fix 4 years ago, another, improved version two years ago. It still is not added to the code. In the meantime, I have put up the patch myself on my website...

cdrtools - a tale of two licenses

Posted Aug 13, 2006 9:29 UTC (Sun) by k8to (guest, #15413) [Link] (3 responses)

dvdrtools is working on mkisofs as well: http://www.arklinux.org/projects/dvdrtools/changeset/16

If you have not already done so, consider sending your improvement suggestions to the team.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 17:00 UTC (Sun) by JoeF (guest, #4486) [Link] (2 responses)

Thanks for the info.
I will send it to them.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 20:25 UTC (Mon) by drag (guest, #31333) [Link] (1 responses)

growisofs rocks for me. It's a front end for mkisofs and it's aviable at least through Debian.

growisofs -Z /dev/dvd somethingthing.iso

Or you can pipe into it to burn data directly to the cdrom after a iso format conversion.

My favorite of course is splitpipe and I've mentioned it in a couple different places.

Splitpipe is a handy little program that is similar to split, but instead of just spliting files it performs a action on every segment it produces after it produces it.
http://ds9a.nl/splitpipe/

A slightly modified example of what you can do:
tar c /home | splitpipe -s dvd -o 'growisofs -Z /dev/dvd=/dev/stdin'

So then it will just feed it data until it needs a new dvd. It pauses, you insert a new dvd, and then hit enter. You just feed it dvds until it's finished. Then to do the restore there is a 'joinpipe' command.

Joerg is ok.

I mean he is a pompus jerk sometimes. He is a solaris lover to absurd lengths... If you disagree with him he will simply say something like:
"Oh, this is how SOLARIS does it. How you do it is broken"

That sort of thing.

The only thing that gives him validity is there have been nearly a dozen forks of cdrecord and related items away from him... AND ALL OF THEM FAILED.

All of them. So obviously he has some good points on how and why he does what he does.

The only thing that pisses me off is that he is trying to use cdrecord and related open source items as a reason for selling his propriatory ProDVD application. So he has delibrately made DVD recording difficult in Linux in order to sell his app.

growisofs is not just a front end

Posted Aug 26, 2006 9:01 UTC (Sat) by anton (subscriber, #25547) [Link]

growisofs is mainly DVD writing software, and I am very happy with it.

It uses mkisofs when you write some directory tree to the DVD, or it can just directly write ISO images.

Unfortunatley, it does not make cdrtools completely unnecessary, for two reasons:

1) mkisofs is part of cdrtools

2) At least the version I have of growisofs does not write CDs

cdrtools - a tale of two licenses

Posted Aug 13, 2006 8:18 UTC (Sun) by dmantione (guest, #4640) [Link] (42 responses)

Schilling is right here.

The dispute:
* Schilling says his Makefiles are and independent work, because it is a
whole program.
* The GPL says that the Makefiles belong to the source code and the GPL
does not allow mixing these licenses.

Now, if I release a program under GPL, this usually means the Makefiles
are also GPL. So, the GPL requires that if someone distributes the
binary, I also need to distributes the Makefiles.

But, the GPL cannot go beyond the boundaries of copyright law. If,
according to copyright law two works are independend, then the GPL has
nothing to say about it. Its contents are irrelevant.

Now Schilling is claiming his Makefile, because it is a full program, is
an independend work. That means the GPL is irrelevant until you prove it
is not an independend work.

However, the Debian people are trying to prove the Makefile is GPL by
reading the GPL. This is wrong, you first need to prove the Makefile is
not an independend work, and only then you can start reading the GPL. The
only document that matters at this time is this:
http://bundesrecht.juris.de/urhg/ , the German copyright law.

Proving that is Makefile is a derrived work is not very easy. In
copyright, the opinion of the author matters a lot. Now the author of
both cdrtools and the Makefile considers them independend works.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 9:33 UTC (Sun) by ajf (guest, #10844) [Link] (2 responses)

Where have "the Debian people" (which people?) claimed that the Makefiles are under the GPL? If I understood the discussion correctly, the claim is that Schilling is failing to comply with the requirements of the GPL by including Makefiles which aren't compatible with the GPL. They could hardly claim that if they believed, as you seem to be suggesting, the Makefiles already are GPL.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 10:11 UTC (Sun) by dmantione (guest, #4640) [Link] (1 responses)

You are right, I should rewrite the sentence in question to "However, the
Debian people are trying to prove the Makefile has to be GPL by reading
the GPL."

The rest doesn't matter, because: If a work does not contain Makefiles,
you are not required to redistribute any Makefiles with the binaries.
However, if the work does contain them, the GPL requires people
distributing binaries to distribute them with the source.

So, you must again proof the Makefiles are part of the GPL work, of which
the only relevant document is the German copyright law.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 12:05 UTC (Sun) by khim (subscriber, #9252) [Link]

If a work does not contain Makefiles, you are not required to redistribute any Makefiles with the binaries.

Sure. You are not required to distribute anything. You must offer GPL-compatible Makefiles upon request.

It does not matter if Makefiles are separate work or not. What does matter is GPL requirement: you must offer build-system on GPL-compatible terms.

But I don't wanna! It's my build system, it's my scripts! I can do anything I want with them!

Sure - but then you are losing your permission to distribute GPL-licensed body of the problem so you can not distribute any binaries. You surely can distribute your makefiles and files you hold copyright to on any terms you want - but you can not distribute other peoples work unless you agree to distribute Makefiles with GPL-compatible license. You've lost the permission, end of story.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 9:33 UTC (Sun) by k8to (guest, #15413) [Link]

The GPL says that in order for it to be specially allowed for you to distribute the program (which is not normally allowed), you must provide the build system under the same terms.

You can argue until you are blue in the face that the build system is a seperate work, but unless you can fulfill the GPL's requirements you are not granted the right to redistribute the software. GPL cannot force you to license the build system under GPL, but since it considers the build system to be part of the necessary valid version of the work, you must meet its expectations in order for the world to be distributable.

You could perhaps argue that there is some kind of undesired effect here, but that is a different point entirely.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 10:04 UTC (Sun) by kleptog (subscriber, #1183) [Link] (5 responses)

Eh? It says in GPL:

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. [emphasis mine]

Now, Jourg has argued that Makefiles are not scripts. You can argue that ofcourse, but that's just playing with words, IMHO.

You're right that the GPL cannot go beyond copyright law, but it's the GPL that controls the distribution the main source and it insists on being shipped with the makefiles under a compatible licence. Whether the makefiles are a seperate work or not is orrelevent.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 10:14 UTC (Sun) by dmantione (guest, #4640) [Link] (4 responses)

No, the GPL'ed work does not contain scripts. There is no reason you
cannot GPL a bunch of .c files. However, if you include a Makefile in the
work, the GPL says it belongs to the source code and a third party has to
redistribute it.

Schilling is claiming his Makefile does not belong to the work and he
GPL'ed a bunch of .c files. You can only prove that it belongs to the
work using copyright law.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 12:12 UTC (Sun) by khim (subscriber, #9252) [Link]

Schilling is claiming his Makefile does not belong to the work and he GPL'ed a bunch of .c files. You can only prove that it belongs to the work using copyright law.

There are no need. If you are using Makefiles to build the program - then you can not distribute the result (GPL forbids it). If you don't use CDDL-licensed makefiles - then of course you can distribute the binary and can just remove offending CDDL-licensed Makefiles (why keep them around if they are not needed, after all?). But it'll be too cumbersome, I afraid. Makefiles are independent work - but resulting binary is not. It uses both Makefiles and source files and since these files have incompatible licenses... you can not redistribut the binary.

Note: Schilling did nothing wrong here. Debian (or any other distribution-creator) will be copyright offender. And this means it's time to adandon cdrecord (what other stupidity will Schilling invent next?).

cdrtools - a tale of two licenses

Posted Aug 13, 2006 13:08 UTC (Sun) by k8to (guest, #15413) [Link] (2 responses)

Is that you Jörg?

Again, it does not matter whether the GPL work "contains scripts". The GPL requires that the necessary scripts used to build the work be made available under the same terms as the source, that is under the GPL. It does not matter whether these scripts are "part of the work". If they are not available under the GPL, then the GPL license is not satisfied, and you are not granted permission to redistribute.

Now, in this case the scripts and program are authored by the same person. If he is the exclusive copyright holder, it is possible he could certainly modify the license under which the program is distributed to make it a GPL program with the added permission that the script system he authors under CDDL may be used as a substitute. (It is possible I misunderstand what kinds of special exceptions may be provided.) However, even if this is possible, Jörg refuses to do so because he refuses to understand the licenses, and expects every one else to agree with his highly irregular interpretation.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 17:24 UTC (Mon) by AJWM (guest, #15888) [Link] (1 responses)

>The GPL requires that the necessary scripts used to build the work be made available under the same terms as the source

That only applies if "the work" is an executable. As an above poster pointed out, if you're just distributing a bunch of C source files, there are no scripts involved -- the work is what it is. As soon as somebody compiles that and distributes the binary, _then_ they have to pass on the source and build scripts too.

Debian's role

Posted Aug 14, 2006 19:53 UTC (Mon) by dark (guest, #8483) [Link]

Debian is in the "then" position -- it compiles binary packages and ships them, along with the source. If it can't do that in accordance with the terms of the license, then that package won't go into Debian.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 10:19 UTC (Sun) by nhippi (subscriber, #34640) [Link] (27 responses)

This is actually irrelevant as Schilly decided to CDDL a lot more than the build scripts. This can only be seen as a part of his long-going crusade against GPL and Linux.

GPL defines that complete sources includes build scripts:

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 is important because vital parts of program logic may be implemented during build phase. Consider programs with yacc parser.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 10:34 UTC (Sun) by dmantione (guest, #4640) [Link] (26 responses)

Correct, this is the weak part of his defense: He is linking GPL code
with CDDL code. According to the GPL this is not allowed.

But: I fear Schilling is well aware of a GPL issue. The GPL depends on
clauses in the US copyright law that deal with "derived works". European
copyright laws do not have this, and have nothing to replace it.
Therefore it is doubted wether some of the viral aspects of the GPL are
enforcable in Europe. The FSF is aware of this and has adapted the texts
in the GPL V3 to be compatible with European laws, but the issue remains
in doubt.

So, it might be the case that Schilling is going to claim his CDDL
libraries and for example mkisofs are independend works and get away with
it.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 10:57 UTC (Sun) by ewan (guest, #5533) [Link] (20 responses)

No, you're missing the point. This isn't about the 'derived work' clause
at all. The point is that the GPL requires the build scripts to be
considered part of the source. Then it requires that the source be
distributable along with the binaries.

If I were to take proprietary source, build it, then claim I was releasing
the binary under the GPL I couldn't do it, because I'd have no right to
release the source, which is required by the GPL.

No-one is saying that build scripts are derived works of the main program,
or that the build scripts are somehow magically GPLed, but simply that if
the source and the build scipts cannot both be used under the terms of the
GPL then the resulting binary cannot either be used under the terms of the
GPL.

Of course, if all of the source and build scripts were under the CDDL then
the binary could be distributed under the terms of the CDDL; however, in
this case they're not, since some are GPL.

There is no single licence that covers the whole lot, so no licence under
which the binary can be distributed.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 11:07 UTC (Sun) by dmantione (guest, #4640) [Link] (19 responses)

As I said before, you can release a work under the GPL without scripts.
For example, let me release the following under the GPL:

----
#include <stdio.h>

int main() {
printf("Hello world\n");
return 0;
};
----

There is nothing that stops me doing this, the GPL does not require you
to write a Makefile. However, if I had included a Makefile, it did belong
to the source, and anyone distributing a binary would also need to
distribute the source.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 12:25 UTC (Sun) by khim (subscriber, #9252) [Link] (18 responses)

Gosh. You are reading too much. Think about origins of copyright: what if you want to publish collection of stories ? You must obtain permissions from all copyright holders. And if two of them hate each others guts - you fine idea to publish such collection just gone in flames. That's exacly the situation with GPL-licensed code, CDDL-licensed Makefiles and "collection of stories" called binary. This "collection" includes works of two authors who "hate each others guts" (GPL-code and CDDL-Makefiles) and this means you can not publish and distribute such collection.

Can you distribute the GPL-licensed source code ? Sure! Can you distribute CDDL-licensed Makefiles ? Of course! What about binary ? Oops. No, you can not distribute binary - you don't have permission.

So the new version of cdrecord will be Ok for Gentoo (they do not distribute binaries) - but it's not Ok for Debian or RedHat. And it's not Ok for Schilling either (he's distributing binaries, right?) - but only Eric Yougdale (and few others who hold copyrights for parts of cdrecord) can sue him. If this is fortunate or unfortunate is interesting question...

cdrtools - a tale of two licenses

Posted Aug 13, 2006 12:53 UTC (Sun) by dmantione (guest, #4640) [Link] (17 responses)

No, in this case a binary cannot be considered a collection of "stories",
because no code in the resulting binary comes from the Makefile.

You are confusing this with two incompatibly licensed libraries, where
the result is that the binary cannot be redistributed.

Note that it would be different if Schilling would have removed Makefiles
from source he does not own copyrights to (this is where the GPL kicks
in), but as far as I read this has not been the case.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 13:58 UTC (Sun) by ewan (guest, #5533) [Link] (16 responses)

No, you're still missing the point. If a copyright holder is giving
someone a permission to distribute their work they can attach any
conditions they want. I can say that you may only distribute my work while
wearing a chicken costume, or that you may only distribute it on days
starting with a 'T', or more commonly, that you may only distribute it
after paying me an amount of money.

The copyright holders of some of the involved code have licenced it under
the GPL. One of the conditions that that imposes is that any scripts
required to build the binary must be included under GPL compatible terms.

As always, you don't have to accept the conditions, but if you don't, then
you don't have permission to distribute my work. In this case Jorg does
not accept the condition that required build scripts must be available
under GPL compatible terms, and therefore he does not have permission to
distribute the GPL code owned by other people.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 14:52 UTC (Sun) by dmantione (guest, #4640) [Link] (15 responses)

No, as I said before, the GPL doesn't say that you have to write a
Makefile if there isn't any. In fact, a lot of programming languages
don't need Makefiles. What doesn't exist does not have to be written by
people distributing binaries.

What it does say, is, if there is a Makefile, it is part of the source
code of the program and does need to be part of your source code
offer/distribution.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 15:29 UTC (Sun) by ewan (guest, #5533) [Link] (14 responses)

No, however, in this case there is a build system, required to build the binaries, and permission to distribute the GPLed code in those binaries is only granted if the build system used to generate them is also licenced under the GPL.

Another piece of software may or may not have build scripts, they may or may not be Makefiles. All that matters to this discussion is that Jorg's cdrtools binaries require the CDDL build system to generate them. What hypothetical other projects do or consist of is of no relevance to cdrtools.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 15:45 UTC (Sun) by dmantione (guest, #4640) [Link] (13 responses)

We're getting to the core of the matter. Schilling is claiming his build
system is independend. According to him there exists nothing in the GPL
part to build it.

As long as he can maintain that his build system is an independend work,
there is nothing in the GPL that forbids distributing binaries.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 17:28 UTC (Sun) by ewan (guest, #5533) [Link] (11 responses)

No, he can't. The 'independence' or otherwise of the build system has nothing to do with it. You are still clinging to the 'derived work' idea.

Jorg's binaries are built with his CDDL build system. Jorg's binaries contain other people's GPL code. Jorg cannot distribute that code in his binaries without the permission of those other people. Those other people (by means of the GPL) give him the necessary permission if, and only if, the build system used to build the binaries is available under GPL compatible terms.

And it isn't.

The only way 'independence' of the two code bases would be sufficient division would be if Jorg had GPLed cdrtools, and a CDDL build system, and he did not use the latter to build the binaries of the former. As it stand the build system may well be independent of the cdrtools source - but it is not separate from the cdrtools binaries because they are built with it. The cdrtools source is also not indepentent of the CDDL build system if there is no other feasable way to build it.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 19:55 UTC (Sun) by dmantione (guest, #4640) [Link] (10 responses)

Did the other people contribute Makefiles? Then he is not distributing
the other people their code without their Makefiles, and is not violating
their copyrights.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 20:17 UTC (Sun) by k8to (guest, #15413) [Link] (4 responses)

The code of the other people present in the main work, that is cdrecord, mkisofs, is sufficient to keep it under the GPL as it was when they contributed the code.

The fact that the code is under GPL is sufficient to require that the Makefiles be placed under GPL for distribution of the code.

End of discussion.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 20:30 UTC (Sun) by dmantione (guest, #4640) [Link] (3 responses)

No, of course not. If others haven't contributed source code including
Makefiles, they cannot claims those Makefiles are part of their source
code and enforce the GPL.

You guys are reading the GPL as "it is forbidden to distribute without
(GPL'ed) Makefiles", but it says "any Makefile is part of the source
code" which is there to prevent people circumventing the GPL by removing
all Makefiles from it.

But it is not really worth it to have a flame war over this as I don't
question that Schilling is playing games with the GPL... The guy hates
Linux and likes Solaris and is trying power tricks. I only fear that he
very well knows what he is doing :(

cdrtools - a tale of two licenses

Posted Aug 13, 2006 21:39 UTC (Sun) by k8to (guest, #15413) [Link] (2 responses)

My comments apply whether or not the Makefiles are part of the source. Where do you see that being mentioned in the quite simple argument?

The GPL says that it is forbidden to distribute without a similarly avilable build system.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 13:42 UTC (Mon) by jond (subscriber, #37669) [Link] (1 responses)

"The GPL says that it is forbidden to distribute without a similarly avilable build system.".

Which GPL, and which clause? I've just read GPL-2 in its entirety and could find no such clause or anything similar.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 15:57 UTC (Mon) by bfields (subscriber, #19510) [Link]

Section 3 of GPL v2 contains the requirement that you must make the source code available for binaries that you distribute, and says that "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."

It doesn't matter whether or not the "scripts used to control compilation" are a derived work of somebody else's code or not. What matters is if the built executable is a derived work of that code. If so, then you need the copyright holders' permission to distribute the executable. If the only permission they've given you is the GPL'd code, then they've told you "fine, you can distribute compiled binaries derived from this, but only if you also distribute your makefiles." And they're perfectly within their rights to do that.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 20:42 UTC (Sun) by ewan (guest, #5533) [Link] (4 responses)

No, they contributed code to the main body of the program. They did so
under the GPL, which requires the build scripts to be made available
under the same terms. Unless the distributor complies with that condition
the permission to distribute the covered work is taken away.

You're still hanging onto this idea that the only thing that counts is
copyright law itself, and that the terms of the licence mean nothing. The
point of copyright in this situation is to say that you can't distribute
someone else's work without their permission. It has nothing to say about
what you have to do to get their permission. In this case you have to
distribute the build system under the same terms, or you don't get their
permission.

It really is that simple.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 20:52 UTC (Sun) by dmantione (guest, #4640) [Link] (3 responses)

Ok, my last attempt to make it clear.

Let's say I contribute a patch. I put the patch under GPL and give it to
you.

You now have permission to distribute it. But my patch does not contain a
Makefile. So, *my* source (the part I own copyright) does not contain a
Makefile.

So, if you distribute binaries and source, you are distributing the code
*I* own. But *I* did not include anything to build it, so I cannot force
you write such a build tool. There was no Makefile in my source, so I
cannot enforce the GPL onto you to distribute such a Makefile.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 21:33 UTC (Sun) by ewan (guest, #5533) [Link]

Yes, you can, if the total work that your code is included in requires
such a Makefile to build. If I include your code in a project with no
Makefile, then I'm OK, if I include it in a project that relies on a
Makefile, then that Makefile must be GPLed, as must everything else that
makes up the project.

You can't force me to add anything to your code, or make any
modifications to it at all, however, if I chose to do so then you can
force me to make those additions or modifications available under the GPL
(assuming of course that I'm distributing it).

Look at it from the point of view of an end user receiving the binary -
because of the GPL licence they have the right to modify the program.
They cannot do that if they cannot build their modified source because
they don't have the Makefile.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 22:03 UTC (Sun) by HenrikH (subscriber, #31152) [Link]

But still the whole source is put under the GPL and since there is no added clause that sais that the makefile requirement is void, the requirement is still there in the license.

If you send a patch under the GPL to this project without having written a makefile for your patch in question changes nothing since you still only give the distributor the rights to distribute your patch if he follows the GPL requirements (that is including the makefiles used to build the binary), if the distributer chooses not to include the makefiles in a GPL compatible way, then he has no rights to distribute your patch and he has to remove it from the source in order to be able to distribute the binary!

You still seam to think that this has something to do with the "viral"-propery of the GPL, but as others already has pointed out on several occasions there is nothing here that makes the makefiles automatically become GPLed.

Instead the thing is that the only thing that is allowing you to distribute the cdrtools binary is the GPL, and since the GPL requires you to also distribute the makefiles used to build the binary you have to do so or lose the rights to distribute the binary.

If you somehow can manage to build the cdrtools binary without the makefiles then you are of course free to distribute the resulting binary without the makefiles since you didn't use them in order to build it.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 16:12 UTC (Mon) by bfields (subscriber, #19510) [Link]

"Ok, my last attempt to make it clear."

Oh, you're clear enough; it's just that you're also wrong:

"Let's say I contribute a patch. I put the patch under GPL and give it to
you.

"You now have permission to distribute it."

Assuming the patch is nontrivial, I only have permission to distribute it if I meet the requirements of the GPL.

"But my patch does not contain a Makefile. So, *my* source (the part I own copyright) does not contain a Makefile."

That's correct. In particular, the Makefile is not automatically covered by the GPL.

"So, if you distribute binaries and source, you are distributing the code
*I* own. But *I* did not include anything to build it, so I cannot force
you write such a build tool."

If I distribute binaries, presumably I built them somehow. Since the binaries are now a derived work of your patch, I am required to get your permission before I can distribute the binaries. By giving me the patch only under the GPL, you've said that you only give your permission if I also tell people how to build those binaries. So I'm required to give out any makefiles I used, regardless of whether those makefiles are a derived work or not.

There's nothing in copyright law to prevent you from making a requirement like that, even though that requirement in part affects the distribution of a work you didn't write yourself. People need your permission to distribute your code, so you can make them do pretty arbitrary things to get that permission.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 12:55 UTC (Mon) by dwmw2 (subscriber, #2063) [Link]

" As long as he can maintain that his build system is an independend work, there is nothing in the GPL that forbids distributing binaries."

If identifiable sections of that work are not derived from the [GPL'd parts], and can be reasonably considered independent and separate works in themselves, then [the GPL], and its terms, do not apply to those sections when you distribute them as separate works.

But when you distribute the same sections as part of a whole which is a work based on [the GPL parts], the distribution of the whole must be on the terms of [the GPL], whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

(GPL, section 2)

One cannot sensibly argue that the combination of build scripts with the source code that they build is 'mere aggregation on a volume of a storage or distribution medium'. It is a collective work, and the GPL applies to all parts of it -- even those parts which would be considered independent and separate works if distributed on their own.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 5:06 UTC (Mon) by MortenSickel (subscriber, #3238) [Link] (4 responses)

And so? as far as I can see, you are claiming that Schilling's work cannot be distributed in the US with the current licencing terms. I am in Europe so I don't care much, but all distribution with a global scope definiately have to care.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 6:41 UTC (Mon) by dmantione (guest, #4640) [Link] (3 responses)

No, for copyright issues the jurisdiction of the author counts. So, if it
would be legal in Germany it would be legal world wide.

However, the fact that there is doubt about these viral clauses, does of
course not mean you can safely assume it is legal in Europe to link
GPL'ed and not GPL'ed code.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 14:44 UTC (Mon) by climent (guest, #7232) [Link]

No, for copyright issues the jurisdiction of the author counts. So, if it would be legal in Germany it would be legal world wide.

That would mean Opera code can be reverse-engineered in US, even if protected with an encryption device (read DMCA), because in Norway reverse engineering is fine?

cdrtools - a tale of two licenses

Posted Aug 18, 2006 16:02 UTC (Fri) by giraffedata (guest, #1954) [Link] (1 responses)

A good point, but note that the cdrecord controversy has nothing to do with linking GPL'ed and not GPL'ed code. It has to do with another clause of GPL that says in order to have permission to distribute a binary (derived from the copyright owner's source), you must make available the scripts used to make that binary.

And from what I hear, Schilling doesn't even dispute that. He just says that his make files aren't scripts.

Linking

Posted Aug 18, 2006 16:25 UTC (Fri) by corbet (editor, #1) [Link]

Actually, with the current version, linking GPL and non-GPL-compatible code is part of the controversy. mkisofs is GPL-licensed, but libscg, which it uses, is now under the CDDL.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 17:25 UTC (Sun) by JoeF (guest, #4486) [Link] (2 responses)

Joerg's ubiquitious reference to the German copyright law is always a bit funny. Last I looked, he is not a lawyer...
Anyway, pointing to the German copyright law is of course just a smokescreen, since most people don't understand German. He actually never points to the exact section that would support his claims (there isn't any.)

cdrtools - a tale of two licenses

Posted Aug 13, 2006 21:05 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

not to mention that Harald Weite has been extremely sucessful in enforcing the GPL in Germany, so any claims that the GPLv2 is somehow flawed under german law and unenforceable if ignoring a substantial amount of legal happenings.

cdrtools - a tale of two licenses

Posted Aug 14, 2006 8:43 UTC (Mon) by nix (subscriber, #2304) [Link]

(That's Welte, btw.)

cdrtools - a tale of two licenses

Posted Aug 15, 2006 1:25 UTC (Tue) by Ross (guest, #4065) [Link]

The GPL isn't acting on his Makefiles. He's releasing them in a bundle that says it's under the GPL.

So he's saying two incompatible things: they are under the GPL and they are not under the GPL. It isn't permitted to use the license granted by the GPL at the same time as violating it so it isn't clear what permissions are really being granted.

cdrtools - a tale of two licenses

Posted Aug 13, 2006 10:38 UTC (Sun) by ganneff (subscriber, #7069) [Link]

The point now is that its not only the build system which is CDDL. JS contacted many authors of tools included in cdrtools, like mkisofs and got them to accept a relicensing under CDDL. Having half of the source CDDL linking against the other half, GPL, wont work.

We pointed out, multiple times, that this does not work and the two licenses are indeed intended to be incompatible, but even having a video[1] with one of those initially working on CDDL (Danese Cooper) saying that "the CDDL is modelled after the MPL *because* of the incompatibility between MPL and GPL" just got him to deny this fact. (Simon looked angry, you know).

*I* personally would really prefer if we could keep cdrtools original from JS, but currently I believe this isnt possible and started another road. Removal of cdrtools from Debian, reintroducing a (differently named to avoid complaints) fork of the last free version (replacing the build system is not that hard to do).

[1] http://meetings-archive.debian.net/pub/debian-meetings/20...

bye Joerg

cdrtools - a tale of two licenses

Posted Aug 15, 2006 4:55 UTC (Tue) by kirkengaard (guest, #15022) [Link]

From the nine-point-plan:
"7) Finally: learn that I am spending a lot time on cdrtools and on my other OSS activities.

Understand that I am neither willing to waste my time with useless discussions with Debian people nor being forced to give up useful ways of defending me against malicious users or distributors of my code.

Believe me that it does not sound serious when reading again and again silly things like "we need to fork cdrecord...". I am now working for 10 years on cdrecord, I am now working for exactly 20 years on libscg and I am working for 24 years on star. Many people did claim to start a fork on my tools, nobody did yet even come to a serious first step in this direction not speaking about serious work on extensions..."

Defending his code against malicious users or distributors? This would be fine if he were talking about license violations, but for his (until now) GPL code, he wants protections not available under that license. He doesn't think in GPL terms. The only modifications he considers authorized are his own. His is truly a proprietary mind. If you have a problem running cdrecord &co. as he distributes them, the rest of your system needs to be fixed to comply. God help you if you fix cdrecord to work sensibly within the design of a Linux system, even if you do so in utter GPL compliance. Joerg sure won't. See point 9:

"Help me with defending against silly artificial limitations in the Linux kernel that makes life on Linux hard."

Save me from the moving target, eh?

cdrtools - a tale of two licenses

Posted Aug 20, 2006 21:10 UTC (Sun) by stock (guest, #5849) [Link]

This is Nonsense!

cdrtools as one downloadable from ftp.berlios.de is GPL Version 2. My patch to add DVD Burning support, OSS DVD Extensions for cdrtools, in short ossdvd,

http://freshmeat.net/projects/ossdvd/
http://crashrecovery.org/oss-dvd.html

is also GPL version 2. The combined result is also GPLv2. which can burn DVD-R, DVD-RW, DVD+RW and DVD+R DL and works with all 2.6.x Linux kernels without any problems. (S)RPM downloads are to be found for :

centos4/                16-Jun-2005 14:44      -    
fc1/                    30-May-2004 23:01      -       
fc2/                    30-May-2004 22:58      -       
fc4/                    08-Jul-2006 12:33      -       
fc5/                    08-Jul-2006 14:44      -       
mdk100/                 27-Aug-2004 22:12      -       
mdk101/                 16-Jun-2005 11:18      -       
mdk102/                 18-Jun-2005 08:45      -       
mdk91/                  31-May-2004 04:15      -       
mdk92/                  28-Feb-2004 01:04      -       
mdv20060/               02-Feb-2006 05:30      -       
rh73/                   31-May-2004 04:16      -       
rh80/                   31-May-2004 04:17      -       
rh9/                    31-May-2004 04:17      -       
suse82/                 31-May-2004 04:16      -       
suse90/                 25-May-2004 08:36      -       
suse93/                 22-Apr-2006 09:02      -

Regards,

Robert M. Stockmann