Slashdot Mirror
Debian Kicks Jörg Schilling
An anonymous reader writes "Debian's cdrecord maintainers announced that they have had enough of Jörg Schilling and kicked his program suite cdrtools out of Debian, introducing a free fork of his no longer free cdrtools." I've put the message below, along with some other links.
So, why the fork? CD/DVD burning is a complicated business that needs a lot of knowledge, so forking such a big collection isn't a step to be taken lightly. It requires a lot of development effort that could be put to better use elsewhere.
In the past, we, the Debian maintainers of cdrtools, had a good and mutually cooperative relationship with Jörg Schilling. He even commented on Debian bug reports, which is one of the best things an upstream maintainer can do. Naturally, there were occasionally disagreements, but this is normal.
Unfortunately Sun then developed the CDDL and Jörg Schilling released parts of recent versions of cdrtools under this license. The CDDL is incompatible with the GPL. The FSF itself says that this is the case as do people who helped draft the CDDL. One current and one former Sun employee visited the annual Debian conference in Mexico in 2006. Danese Cooper clearly stated there that the CDDL was intentionally modelled on the MPL in order to make it GPL- incompatible. For everyone who wants to hear this first-hand, we have video from that talk available.
Here is the FSF position about the CDDL. This thread contains statements on the issue made by Debian people; for more context also see the other mails in that thread. In short -- the CDDL has extra restrictions, which the GPL does not allow. Jörg has a different opinion about this and has repeatedly stated that the CDDL is not incompatible, interpreting a facial expression in the above-mentioned video, calling us liars and generally appearing unwilling to consider our concerns (he never replied to the parts where we explained why it is incompatible). As he has basically ignored what we have said, we have no choice but to fork. While the CDDL *may* be a free license, we never questioned if it is free or not, as it is not our place to decide this as the Debian cdrtools maintainers. However, having been approved by OSI doesn't mean it's ok for any usage, as Jörg unfortunately seems to assume. There are several OSI-approved licenses that are GPL-incompatible and CDDL is one of them. That is and always was our point.
For our fork we used the last GPL-licensed version of the program code and killed the incompatibly licensed build system. It is now replaced by a cmake system, and the whole source we distribute should be free of other incompatibilities, as to the best of our current knowledge.
Anyone who wants to help with this fork, particularly developers of other distributions, is welcome to join our efforts. You can contact us on IRC, server irc.oftc.net, channel #debburn, or via mail at debburn-devel@lists.alioth.debian.org. Here is our svn repository.
In the past, we, the Debian maintainers of cdrtools, had a good and mutually cooperative relationship with Jörg Schilling. He even commented on Debian bug reports, which is one of the best things an upstream maintainer can do. Naturally, there were occasionally disagreements, but this is normal.
Unfortunately Sun then developed the CDDL and Jörg Schilling released parts of recent versions of cdrtools under this license. The CDDL is incompatible with the GPL. The FSF itself says that this is the case as do people who helped draft the CDDL. One current and one former Sun employee visited the annual Debian conference in Mexico in 2006. Danese Cooper clearly stated there that the CDDL was intentionally modelled on the MPL in order to make it GPL- incompatible. For everyone who wants to hear this first-hand, we have video from that talk available.
Here is the FSF position about the CDDL. This thread contains statements on the issue made by Debian people; for more context also see the other mails in that thread. In short -- the CDDL has extra restrictions, which the GPL does not allow. Jörg has a different opinion about this and has repeatedly stated that the CDDL is not incompatible, interpreting a facial expression in the above-mentioned video, calling us liars and generally appearing unwilling to consider our concerns (he never replied to the parts where we explained why it is incompatible). As he has basically ignored what we have said, we have no choice but to fork. While the CDDL *may* be a free license, we never questioned if it is free or not, as it is not our place to decide this as the Debian cdrtools maintainers. However, having been approved by OSI doesn't mean it's ok for any usage, as Jörg unfortunately seems to assume. There are several OSI-approved licenses that are GPL-incompatible and CDDL is one of them. That is and always was our point.
For our fork we used the last GPL-licensed version of the program code and killed the incompatibly licensed build system. It is now replaced by a cmake system, and the whole source we distribute should be free of other incompatibilities, as to the best of our current knowledge.
Anyone who wants to help with this fork, particularly developers of other distributions, is welcome to join our efforts. You can contact us on IRC, server irc.oftc.net, channel #debburn, or via mail at debburn-devel@lists.alioth.debian.org. Here is our svn repository.
Not according to the FSF themselves, who list it under the heading 'The following licenses are free software licenses, but are not compatible with the GNU GPL'.
There are some software that say or 'gpl v2 or any later version' but if even 1 package (ie: the kernel) doesn't say that, then the whole distro can forget it.
What are you talking about? A distro is "mere aggregation" which is allowed by the GPL. Debian includes software with GPL-incompatible licenses, such as Apache.
Yours Sincerely, Michael.
I understand that, but why is it grounds for a package to be removed from Debian?
Debian includes plenty of GPL-incompatible software. (Apache, anyone?) Incompatibility is not in and of itself an issue.
The issue is that part of cdrecord is GPL and part of it is CDDL. The GPL requires the entire package to be GPL-compatible; thus the license is self-contradictory, and Debian refuses to distribute it under these conditions. THAT is why they are forking.
Combining previously contributed 3rd-party GPLed code with your own (recently-relicensed-to) CCDL code is quite certainly a way to end up with a combined product which isn't legally redistributable.
I understand that, but why is it grounds for a package to be removed from Debian?
Because the package, according to the discussion linked to from the summary, contains both code that is licensed under the GPL and code that is licensed under the CDDL.
If all of its code was licensed under one or the other (or under licenses that are compatible with one another) then that would be fine. But according to the discussion, that isn't the case.
As of now, Sun's Common Development and Distribution License is not accepted under the Debian Free Software Guidelines.
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
"If that's all it was, then why has no one else been able to create an equivalent tool to Joerg's?"
/dev/cd or /dev/dvd (they dropped the SCSI hack).
I don't know about most of the CDRTools, but Linux 2.6 doesn't need cdrecord; you can just dd an ISO file to
Meanwhile, I've been working on an ISO editing lib for the Slax team. The requirements for the project are that 1) it creates no temporary files, 2) it uses no hard drive space other than the destination file (and swap space if the OS deems it), 3) it can add, delete, extract and duplicate files from the VFS to/from the ISO, 4) It can do this directly to a CD-RW.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
I think they forgot to mention all the other bullshit as well. The upstream cdrecord had many problems which lived on for a time in Debian's patched version, including;
- Not being able to burn via device node. You have to specify some cryptic sequence of numbers.
- Not being able to burn as a non-root user. WTF?
- Lot's of FUD in the program output about how you should use Solaris instead of Linux.
Any bug reports relating to this on Debian's bugtracker usually incited Joerg to long fits of counterproductive trolling. Hopefully they'll see sense and ban him from similarly messing up the cdrkit bugtracker.
Yep, MPL==Mozilla Public License. The MPL is incompatible with the GPL because MPL'd code can be combined with proprietary code. FSF says that MPL has "some complex restrictions that make it incompatible with the GNU GPL." To get around this potential problem, Mozilla licenses all of their code under the MPL, GPL and LGPL (a so called tri-license).
See MPL for more details.
I wonder why Schilling doesn't just dual-license? (I did RFTA)
Rankmaniac 2010
and worse off, a GPL software cannot be dependent on non-GPL software. The GPL requires that all components of the program are to be Free - you can't legally build a GPL'd frontend to a proprietary or otherwise non-GPL-compatibile backend.
Therefore all these thousands of the cd tools depending on cdrecord would either have to change the license (and abandonning GPL is not easy and in many cases just impossible) or be stuck with the old (last GPL'd) version of cdrecord.
Anagram("United States of America") == "Dine out, taste a Mac, fries"
> Linux 2.6 doesn't need cdrecord
--I beg to differ. Cdrecord has the ability to:
o Access remote SCSI devices
o Blank CDRW media
o Write "cloned" images created from ' readcd -clone '
o Write multi-session CDs
o Write Audio CDs
o Write using "burnfree" buffer-underrun technology
o Set different Write speeds
o Overburn
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
And Debian is based on releasing only GPL'd or GPL-compatibly-licensed softwares.
Er, no. Debian is based on releasing only software which conforms to the debian free-software guidelines. Says nothing about the GPL in there, other than that the GPL conforms to these guidelines. They also release software under the artistic license, which isn't even free software, according to the FSF's definition, let alone GPL-compatible.
As FreeBSD user, I don't care much about Debian's specific decisions; but regarding cdrtools, I fully agree. The latest versions have become annoyingly FUD-dy and kind of ads for Joerg's commercial version. Fortunately, burncd (for CD) and growisofs (for DVD) work just as fine here. cdrkit will be a welcome addition to FreeBSD's ports system as well.
It's not the first time some developer's stubborn-ness resulted in a fork. That's the beauty of OSS (GPL and other OSS-compatible licenses): control freaks can't get away with it. Now let's hope some brave soul would adopt cdrkit and keep it up to date with the newest burning technology.
cpghost at Cordula's Web.
Reread the parent. He said that a project that has both code licensed only under the GPL and code only licensed with {a license incompatible with the GPL} cannot be in Debian, because it would be illegal to distribute.
This isn't about putting Apache and GNU C in the same distribution. It's about putting filemanager.c and documentview.c in the same binary when filemanager.c is licensed under the XGL, and documentview.c is licensed under the XGL-incompatible YGL. That's the core of the problem here.
You are not alone. This is not normal. None of this is normal.
Amen to that. It was a great day when Linus implimented device node recording after years of Schilling's backbiting.
... Standards and Practices !
PenGun
Do What Now ???
The copyright for the old GPL-licensed version which they've turned into "cdrkit" is still with Schilling (unless he specifically assigned it to the FSF, which is unlikely), so if he wants to, Schilling can tell Debian to "fork off" too, ie. deny them the right to distribute it as part of the distro. I doubt that he will though.
It's the copyright holder's right to allow or deny any specific distribution of his code. The GPL licensing merely says that if it is distributed, then its source code must accompany it, or be made available subsequently. It doesn't override the copyright holder's wishes in any other respect.
Yup.
http://packages.debian.org/unstable/otherosfs/k3b
"I don't know, therefore Aliens" Wafflebox1
There are a number of copyright holders; see http://svn.debian.org/wsvn/debburn/nonameyet/trunk /debian/copyright?op=file&rev=0&sc=0
It works like this: The CDDL is incompatible with the GPL. Schilling doesn't want to believe it is, but both the CDDL and GPL writers (and anyone with half a brain) say otherwise. So while he's perfectly within his rights to distribute source code that combines CDDL & GPL code (as he is doing now), as soon as you build that source code and distribute the result (as any binary distribution does), you've just violated the GPL's 'no additional restrictions' clause.
Have you ever read an email by Mr Schilling? Try this thread on lkml, and tell me who is being the most annoying. He drags himself through the mud by alienating people with his attitude.
None of this means that he is evil or incompetant, but it does give the impression of someone who is insistently idiosyncratic. I can easily imagine that he'd be difficult to deal with.
Heh. He also has his own make version for some reason. Also, IIRC cdrecord doesn't (or didn't) support DVD recording except through a propietary program made by schilling. You needed to pay him money in order to get a license and a key. People had to code opens-source DVD extensions, and distros had to patch the cdrecord source with those extensions.
And then, there's the dev= issue. Schilling insist that the "right way" of using your burner is by passing the dev=1,2,3 argument, instead of dev=/dev/foo, and that the "right thing" to do is not to use a kernel interface to use the burner, but to let cdrecord internal libraries to access directly to the IDE/SCSI bus, like in the good old DOS days. When Suse patched their cdrecord version to use dev=/dev/foo directly, he wrote a linuxcheck() function that printks a warning when you're using a 2.6 kernel, and he "sub-licensed" that function with a GPL-incompatible statement: "you can't remove this function", just to try to force Suse and Redhat to include it.
IANAL nor a Debian Developer, but as a Debian user I seem to remember that Debian has a non-free "tree" of packages, since "main" has to be DFSG-compatible. In fact, no package can be in main if its dependencies are non-DFSG. The DFSG's restrictions reads in many ways like cliff notes of someone reading the GPL(the GPL seems longer and more legalese), and explicitly approve the artistic, BSD and GPL licenses. I'm thinking the CDDL isn't just GPL-incompatible, but is also violates the DFSG, but again IANAL(although I read the thread linked from the article and they seem to agree with me). Back on your question about how licensing would make things incompatible, it only matters when, like Debian, you distribute the whole thing, with a charter and/or some agreement that all the licenses meet a specific set of criteria. It wouldn't stop say, Novell or Mandriva, which, I believe, operate under no licensing restrictions other than the licenses themselves.
IANAL, but you can take GPLv2 stuff into any GPLv3 project, but not the other way around.
As the GPLv2 has already an upward compability clause, as it says something like "You may use this software at your opinion with any newer GPL version.
The only exception are software packages where the author add an addendum that you do not have this freedom of free GPL "upgrades". (linux kernel e.g., since they didn't want to give the FSF the power to freely alter the license out of their powerrange.)
--
Karma 50, and all I got was this lousy T-Shirt.
It's not really a similar situation at all. Joerg was SELLING dvdrecord-pro, as a commercial app, with no open source equivalent. To get free DVD-burning, there was little choice but to take cdrecord/mkisofs and extend it to DVDs.
dvdrtools was branched off a while ago, and the most recent changes have not been merged from cdrtools.
Last I checked, dvdrtools wasn't as good as cdrtools in specific cases, like burning from bin/cue files.
dvdrtools is very similar, but isn't a 100% compatible, drop-in replacement for users, and applications that use it, as this debian fork is meant to be.
Besides, this fork may just be a short-term measure, which seems likely, as they are planning on integrating it immediately.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I don't have access to much posting history. (didn't pay) I'm certainly not the only "r00t" on the net; I have no reason to believe "eviltypeguy" is unique either. Not even CmdrTaco is unique. Based on the English, I started to suspect that you might not be Joerg. About the only other person who agrees with Joerg is the xcdrecord author, so I figure that there is a good chance you wrote cdrecord.
But OK. I suppose I can believe Joerg has more than one fan. You're #2.
From personal experience, I know that taking over a project is quite a lot of work. (if you run Linux, you almost certainly run my code every day) Taking over a project involving lots of poorly-documented hardware is nearly insane. I've considered it though!
Lots of people have wanted to fork cdrecord. I pretty much did, but never made the first release. Cleaning up the crud would be horribly painful. Joerg has rolled many other projects into cdrecord, including mkisofs. So you can't just maintain the one program. If you drop the others, then you aren't providing a full replacement. Joerg keeps critical info in his head. The source does not include enough comments to tell why certain odd things are being done. You'd have to just make mistakes, pissing users off with ruined media. Since cdrecord does not provide a sane interface for wrapper programs, you have to maintain the old crap right down to the very last space character. You'd have to burn lots of media, which is like burning dollars. Grab a few dollars out of your wallet and set them on fire. Now do it again. Again, and again, and again...
"OpenSolaris however _is_ a real threat for Linux. OpenSolaris gives more freedom than Linux, it gives new impressing features and there is marketing.
It seems that the reason for the FUD against OpenSolaris published by Linux people is caused by the fact that product of value and freedom found in Linux is smaller than the product of value and freedom available with OpenSolaris."
Among other humourous things.
Just a guess, based on that last huge run-on sentence
That wasn't a run-on sentence those are when two separate sentences are run together, not when a single complex sentence grows to inordinate length or could usefully be provided with more punctuation to clarify its structure.
ABOUT!!!
EFFFING!!!
TIME!!!
I have DESPISED this man's code since the day I saw it. His BONEHEADED insistence on doing things the Solaris way in Linux, his apparent INABILITY to use a standard build system, and the INSUFFERABLE ARROGANCE he displays through absolutely everything he does are completely INFURIATING.
Think I'm spewing flamebait? Nonsense. Read this bug report about cdrtools. He starts by insisting his misinterpretation of the GPL is correct, goes on to threaten defamation(slander) lawsuits in german courts against Debian, and finishes up calling most the people in the discussion thread "convinced liars". The man is unusable as an open source contributor, and I am ecstatic that more people actually realize this now.
Just another "DOJ fascist authoritarian totalitarian bootlicker" -- Zeio
That's clearly untrue, as the FSF explicitly state that public domain code, (modified-)BSD-licensed code, X11-licensed code, and code released under various other licenses that can be combined with proprietary code is GPL-compatible.
This is why, and nothing more.
K3B explictly added support for dvdrtools. Try an old version of K3B, before dvdrtools was released, and see how that works out. You can't expect all other applications to be rewritten in a short period of time.
That's quite a bit too vague to draw any conclusion from. For all I know, you could have had a buggy package of cdrtools, or similar one-off problems.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Not to worry. Firefox is available under GPL. MPL was never widely used outside of Mozilla, and that chiefly in the period before Mozilla was widely used. At that, it's a better license than the CDDL. The CDDL specificly allows distribution of binaries that depend on proprietary licenses of various forms. One of the forms would make the source code visible, and not clearly warn users that it was dependant on having licensed certain software patents...i.e., that the end-users were liable if they didn't properly license the patents required to use the software, and the company could know about it and not warn you.
The MPL protected against that. The CDDL removed that protection. So, I ask myself, *why* would Sun make such a change? (I asked Sun, too. They never responded...which doesn't prove anything.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Has anyone here ever tried to buy a ProDVD license? I have, on behalf of a former employer, and the result (by email) was always no reply. Every year or so our production system would stop working until someone realized that another "free" key had gone bad.
So not only does Jörg keep his software non-free - he doesn't take money for it either. I concluded a long time ago that his thought processes are not standard issue.
"Joerg Schilling is doing excellent work. But as some others have commented there seem to be personal issues. So it is a shame that they had to use such a lame excuse to boot him. I am pretty sure the fork will go nowhere or at best use patches from Joerg Schilling proving that there never were incompatible licences."
It is not only Debian that has problems with cdrtools. Fedora forked cdrtools over two weeks ago because the latest versions of cdrtools are not distributable due license violations in the cdrtools package.
Check the thread starting with buildsys report: https://www.redhat.com/archives/fedora-devel-list/ 2006-August/msg00644.html
More information in this message: https://www.redhat.com/archives/fedora-devel-list/ 2006-August/msg00652.html
stefan@nano:~$ dd if=/home/stefan/debian-31r0a-i386-netinst.iso of=/dev/dvd dd: opening `/dev/dvd': Read-only file system stefan@nano:~$ uname -a Linux nano 2.6.17.9 #1 PREEMPT Mon Aug 21 11:16:59 CEST 2006 i686 GNU/Linux Does not work here.
Life is just nature's way of keeping meat fresh.
I mean, I of course see the point of removing Jörg Schilling from the equation, but the guys from ark linux have already made a clean fork a few months ago called dvdrtools ( http://www.arklinux.org/projects/dvdrtools ) ( server seems to be down at the moment ).
Malike Bamiyi wanted my assistance.
Yeah, and how he claims that because they weren't instantly accepted that it is evidence that the kernel is unmaintained!
cdrtools should have been forked years ago purely based on the technical issues. If you try to run it on a modern system it bleats that you should "upgrade" to Solaris or Linux 2.4!
Maybe now Joerg will admit that the Linux port of cdrecord is unmaintained and he will finally drop it. I wish.
I think this is pretty much the file you forgot:
/ 4/en/os/i386/SRPMS/sg3_utils-1.06-3.src.rpm
http://ftp.redhat.com/pub/redhat/linux/enterprise
That is an SRPM. Red Hat doesn't seem to provide binary RPM files
for ES4. You should have an rpmbuild command that will build that
into a regular rpm. The rpm command itself used to be able to build
from source; probably the ability still exists in RHEL ES4.
Debian certainly provides sg_scan.
As for ifconfig: that is kind of obsolete now. It's a compatibility
hack that uses a sort of BSD emulation layer. Getting to know the
more-powerful native tools (the ip command) would be a good idea.
personally I think Debian should be looking at it that way instead of saying that if it isn't GPL it is the wrong licence.
That's not the issue. Debian is not making a stance regarding GPL. The issue here is that Debian cannot legally distribute code that within itself mixes two incompatible licenses. This was the case with newer versions of cdrtools. It directly mixed together code under both GPL and CDDL licenses. (as opposed to using libraries or other means of clean separation) GPL and CDDL licenses say you can't mix their code, but the author of cdrtools did it anyhow -- even after being alerted by Debian's legal team.
Other distributions will be forced to fork the cdrtools code as well, unless they want to risk being sued. This issue has nothing to do with Debian being "political" or "favoring GPL" or any other such nonsense.
I was on the fence as to whether to hold the parent's opinion (which is that some projects have NIH issues that come out like this), or the general opinion that Joerg Schilling is seriously messed up. So I did some research. Read through these threads and I believe you will come to a point of view that is balanced and based on primary sources of evidence. You can also read my commentary, however it would be considered a secondary source of evidence.
0 113.html
http://lists.debian.org/debian-devel/2006/08/msg0
There is a LOT of material here, I'll break down my impressions:
- Some instances of misunderstood word usage (ie CDDL is no longer acceptable to the Debian project in what appears to be a new bylaw or whatever they use)
- as a result Joerg Schilling accuses the project of being 'untrustworthy' and 'suspect.' IMO Far too strong terms to use for what could at worst be described as inconsistency. And I'm stretching that definition.
- REFUSED a request to move legal discussion to more appropriate mailing lists and claimed that personal accusations/attacks were made upon him on debian-devel and pointed out his own feelings that he should defend himself on debian-devel (This seems like such a breach of decorum after a civil if difficult debate/raging argument)
- Interpreting the GPL Preamble as word of law (after failing several other dubious GPL interpretations and basically accusing the FSF GPL FAQ maintainers of not knowing how to do their job)
- Having finally been pegged to a request for a name change in the event of a fork, tries to lay claim to the name 'dvdrecord' despite having dubious ability to claim ownership of a generic trademark like 'cdrecord' in the first place.
On the whole debian-devel participants displayed an AMAZING sense of decorum and civility in the face of nonsensical diatribes and difficult debate. Props to them.
There is a more technical debate dated around February on LKML regarding libsgc and cdrecord. (no link simply because I'm having trouble finding the head of the discussion, search LKML Jorg to find.) Here it appears that Joerg Schilling simply appears to be unwilling to compromise functionality and code in order to make his software work properly (or sanely) under Linux. This is closely tied into a unique view on how to make his code cross-platform and the fact that libsgc is meant to integrate with a far greater generalization of SCSI components than just CD drivers.
I don't understand the technical intricacies but it appears that over time the SCSI and IDE interface has changed dramatically. As a result he believes the kernel should change to accomodate his software. That wasn't received very well at which point it might have been appropriate to chalk it up to simple disagreement and walk away, however it degenerated into a variety of other semi-related discussions that were far too personal. (Keep an eye open for 'smake' and the 'Schily Makefile System,' I kid you not.)