FS#12960 - Offer cdrtools as alternative to cdrkit

Attached to Project: Arch Linux
Opened by Rasmus Steinke (rasi) - Sunday, 25 January 2009, 10:58 GMT
Last edited by Roman Kyrylych (Romashka) - Friday, 12 June 2009, 17:48 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Alexander Fehr (pizzapunk)
Architecture All
Severity Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 14
Private No

Details

Description: the reason why cdrkit exists at all was the claim by debian developers that its license would not suffice "free software"

Last december a lawyer seemed to have given a statement to the situation and sees no problem.
(info will be published on cdrtools site)

The FSF also seems to think that the CDDL license is infact a free license.


Additional info:

The problem with cdrkit is, that it is based on a really old version of cdrtools and is now more or less unmaintained. Altho there are releases cdrkit doesnt seem to improve very much.
There are several reports by users that were not able to burn dvds or delete rewritable media with cdrkit, while they succeded with cdrtools.

The problem with cdrtools is that it has no releases marked as 'stable' - the author is highly convinced tho that his alpha releases in fact are stable.


What is the advantage of having cdrtools instead of cdrkit?

cdrtools is highly maintained. It has had more than 80 releases in the same time when cdrkit had less than 10.

It supports bluray, something that cdrkit cannot do at all.

It fully supports the way the kernel uses cd drives since 2.26.8, while cdrkit (as far as i know) still uses the old scsi emulation code.

It is "the original"

It seems to have less bugs.



In order to prove this last point ppl should leave their positive experiences in this feature request.
This task depends upon

Closed by  Roman Kyrylych (Romashka)
Friday, 12 June 2009, 17:48 GMT
Reason for closing:  Won't implement
Comment by Desmond Cox (pointone) - Sunday, 25 January 2009, 16:05 GMT
Seconded.

I've never had trouble with the 'original' cdrecord. I've only ever needed to 'cdrecord /path/to/iso' and it works like a charm!

With cdrkit, however, I've experienced the following problems:

a) Without specifying the 'driveropts=burnfree' option, cdrkit simply writes coasters. Gets about 2 seconds into burning and then fails. This has happened on about 50% of the systems I've used it on. I don't want to tell you how many CDs I've wasted by forgetting this option!
b) cdrkit can't find a drive to save its life. It's usually necessary to first '-scanbus', then run with 'dev=1,0,0' or what have you--even if there's only one CD drive in the system!

Finally: BLUE-RAY! WTF! That ought to be enough right there...

I understand that Joerg comes across as a dick in a lot of his posts, but (I think) I do see his point. He's become jaded after too many useless bug reports, and I can only bet he's gotten hundreds of emails from Debian users asking why cdrecord doesn't work--but they're using cdrkit! (Talk about rubbing salt in a wound!) Also, I simply think he has a very limited understanding of 'free as in speech' software, leading to the whole controversy. AFAIK, the CDDL is a free license, and Arch Linux should have no hangups about distributing it. It's just Debian's DFSG that complicates things.
Comment by Desmond Cox (pointone) - Sunday, 25 January 2009, 16:08 GMT
Sorry, I don't think I emphasized my first point enough.

I've never had trouble with the 'original' cdrecord. EVER. Not once. ;)

Carry on, please.
Comment by Greg (dolby) - Sunday, 25 January 2009, 17:04 GMT
The only experience i have to add to this is that i always take the side of the artist who writes the software.
The whole issue with cdrtools vs. cdrkit is in essence the linux community vs. 1 guy who writes software, mine is bigger than yours etc.
But the proven fact is the linux community cant develop a cd/dvd burning software just like its original author can.
Comment by Skottish (skottish) - Sunday, 25 January 2009, 19:05 GMT
I'd like to add that I've burnt many, many coasters with cdrkit. I've never had a failed burn with cdrtools. I can't prove that the different backend is the reason, but I do not trust cdrkit at all.
Comment by Michael Walker (Barrucadu) - Sunday, 25 January 2009, 19:51 GMT
I've never actually been able to burn a DVD with cdrkit, but cdrtools works great. An officially supported package would be a much better solution than it being in the AUR.
Comment by Xavier (shining) - Sunday, 25 January 2009, 20:54 GMT
This page is quite funny : http://cdrecord.berlios.de/private/linux-dist.html
It is claiming cdrtools is actually free software, and cdrkit is not and is violating the GPL for several reasons.
Also that cdrtools has much more features and is much more bug-free than cdrkit is.

Though this is all on cdrtools homepage so it could obviously be highly biased :)
Comment by Xavier (shining) - Sunday, 25 January 2009, 21:00 GMT
Well this has been requested before and was rejected, see  FS#9104 
I think it is worth mentioning that this new feature request started here : http://bbs.archlinux.org/viewtopic.php?id=49336
Comment by Greg (dolby) - Sunday, 25 January 2009, 22:22 GMT
I would like to request from all parts that participate in this feature request to leave out the debate the reasons the debian developers did the fork,
licensing issues (if they dont cause problems with distributing the software), GPL conmpliance of either one of the projects. Its been discussed to death.
It lead nowhere. See some of the links i posted in the bbs Xavier linked to.
Even 2,5 years later people still say the same things. The only thing thats different today is that the debian developer responsible
for the fork is no longer part of its development team it since early 2007.

The reason for this request is that cdrkit doesnt work for all users as its supposed to. While at the same time, cdrtools always does.
Also the previous FR (  FS#9104  ) i had made a year ago was about replacing the IMO not worthy of being part of any distributions repoitory, fork.
This one is about having BOTH packages in repos.
Comment by Attila (attila) - Monday, 26 January 2009, 16:23 GMT
I vote for it and as Barrucadu said my favorite is too that cdrtools comes back to extra or community instead of staying in AUR because than it will be easier to install for the most users. But i will respect every decision.
Comment by Martin Schmidt (Blind) - Monday, 26 January 2009, 17:39 GMT
I vote for it. The major argument here is support for BluRay.
Comment by Jan de Groot (JGC) - Wednesday, 11 February 2009, 19:18 GMT
Binary distribution of cdrtools is a violation of the GPL. GPL utilities like mkisofs cannot be linked to CDDL libraries, as their licenses are incompatible. The way the sources are distributed is actually a violation of the GPL (CDDL and GPL combined in one package), though the author of cdrtools uses a loophole in the GPL for that: he counts a tarball as distribution media, which allows to ship GPL software in combination with other GPL-incompatible licensed software (this same exception allows us to distribute non-free software on the same CD or DVD or ISO together with GPL'ed software).

http://www.gnu.org/licenses/license-list.html
About CDDL:
This is a free software license. It has a copyleft with a scope that's similar to the one in the Mozilla Public License, which makes it incompatible with the GNU GPL. This means a module covered by the GPL and a module covered by the CDDL cannot legally be linked together.

So then we take a look at the COPYING file of cdrecord:
mkisofs/
A ISO-9660/Rock-Ridge/Joliet/HFS/UDF filesystem formatter (GPL)
Note: uses libscg
See special GPL compatibility note below

libscg/
A local SCSI-generic transport lib (CDDL)
This code may only be used together with other
code that is under an approved OpenSource license,
see http://www.opensource.org/.

Note: In case of statical linking, the resulting "mkisofs binary" is a
combination of several projects under different licenses. If you combine code
from different licenses, you need to honor the legal implication from the
included GPL code and the other code.
Comment by Nezmer (Nezmer) - Saturday, 16 May 2009, 21:07 GMT
I never thought I would be a part of this discussion . Unfortunately , A cdrkit bug pushed me to it .

http://bbs.archlinux.org/viewtopic.php?id=72098
   . (0 KiB)
Comment by Roman Kyrylych (Romashka) - Friday, 12 June 2009, 17:47 GMT
There is dvdrtools in Extra ("A fork of cdrtools, with the primary goal of supporting writable DVD drives")
And cdrtools is in AUR (in Unsupported, not Community, see Jan's comment for reason)
And if there is a bug in cdrkit that does not exist in cdrtools - it should be reported to cdrkit devs so they are aware of it and can fix it.
Same if libburnia-based software does not work for you.
I think Jan explained clearly why we cannot distribute binary cdrtools linked with GPL software.
So I'm closing this.

Loading...