LWN: Comments on "cdrtools - a tale of two licenses"

cdrtools - a tale of two licenses

lacostej — 2006-09-05T07:58:52+00:00

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.

growisofs is not just a front end

anton — 2006-08-26T09:01:14+00:00

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

stock — 2006-08-20T21:10:16+00:00

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

Linking

corbet — 2006-08-18T16:25:14+00:00

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

giraffedata — 2006-08-18T16:02:05+00:00

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.

cdrtools - a tale of an incompatible author

job — 2006-08-18T13:32:35+00:00

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

kenmoffat — 2006-08-17T13:52:12+00:00

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 alternatives sought. (cdrdao anyone?)

wookey — 2006-08-17T11:10:30+00:00

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 alternatives sought. (cdrdao anyone?)

bjornen — 2006-08-17T09:41:43+00:00

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

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

cdrtools - a tale of an incompatible author

nix — 2006-08-15T09:07:19+00:00

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 two licenses

kirkengaard — 2006-08-15T04:55:29+00:00

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 an incompatible author

kirkengaard — 2006-08-15T04:18:42+00:00

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 two licenses

Ross — 2006-08-15T01:25:05+00:00

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

drag — 2006-08-14T20:25:36+00:00

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.

Debian's role

dark — 2006-08-14T19:53:20+00:00

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

AJWM — 2006-08-14T17:24:38+00:00

>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.

cdrtools - a tale of two licenses

bfields — 2006-08-14T16:12:52+00:00

"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

bfields — 2006-08-14T15:57:59+00:00

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

climent — 2006-08-14T14:44:21+00:00

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

jond — 2006-08-14T13:42:25+00:00

"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

dwmw2 — 2006-08-14T12:55:26+00:00

" 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 an incompatible author

arafel — 2006-08-14T12:03:59+00:00

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 two licenses

nix — 2006-08-14T08:43:44+00:00

(That's Welte, btw.)

cdrtools - a tale of two licenses

nix — 2006-08-14T08:37:31+00:00

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

cdrtools - a tale of an incompatible author

nix — 2006-08-14T08:35:56+00:00

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 two licenses

dmantione — 2006-08-14T06:41:21+00:00

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

MortenSickel — 2006-08-14T05:06:33+00:00

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

HenrikH — 2006-08-13T22:03:11+00:00

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

k8to — 2006-08-13T21:39:57+00:00

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

ewan — 2006-08-13T21:33:19+00:00

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

dlang — 2006-08-13T21:05:58+00:00

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

dmantione — 2006-08-13T20:52:45+00:00

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

ewan — 2006-08-13T20:42:45+00:00

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

dmantione — 2006-08-13T20:30:25+00:00

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

k8to — 2006-08-13T20:17:16+00:00

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

dmantione — 2006-08-13T19:55:31+00:00

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

tetromino — 2006-08-13T19:17:34+00:00

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 - a tale of two licenses

ewan — 2006-08-13T17:28:20+00:00

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

JoeF — 2006-08-13T17:25:01+00:00

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

JoeF — 2006-08-13T17:00:01+00:00

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