[arch-general] An old, tiresome discussion: cdrtools vs cdrkit
I know this is a going to be a probably tiresome discussion revived but I'd like to get this over with. I've been meaning to do it for a while now. My issue is that the cdrtools substitute cdrkit that Arch currently officially provides is not actively developed (current to last stable was around a year) and is technically inferior to cdrtools. cdrkit still does not generate proper iso-level-3 file systems and has trouble with big file support. This makes proper blu-ray creation hard. My upstream bug report on their mailing list was completely ignored, for example [1]. I request using the original cdrtools in place of cdrkit. I know that it actually was that way once but it was changed due to uncertainty about licensing issues. It appears that these issues are now solved with the conclusion that there are non while cdrkit is actually the offender. I'm aware that I can get cdrtools from AUR. Even then, cdrkit uses "replaces" and that spells "don't use cdrtools" for me. We should not be using broken software in Arch when there are better alternatives available just because of FUD about the licensing. Let the fight begin. [1] http://lists.alioth.debian.org/pipermail/debburn-devel/2009-November/000687.... -- Sven-Hendrik
At Montag, 25. Januar 2010 03:55 Sven-Hendrik Haase wrote:
I know this is a going to be a probably tiresome discussion revived but I'd like to get this over with. I've been meaning to do it for a while now.
I support your opinion and use an own package for cdrtools but for me there was a realy showstoper what i have read in a discussion on the forum: There is no one who wants to maintain a cdrtools package. So for me everyone has the right to have his own opinion and if there is no dev who wants to maintain cdrtools than we risk to discuss a theoretic thing.
My issue is that the cdrtools substitute cdrkit that Arch currently officially provides is not actively developed (current to last stable was around a year) and is technically inferior to cdrtools. cdrkit still does not generate proper iso-level-3 file systems and has trouble with big file support. This makes proper blu-ray creation hard. My upstream bug report on their mailing list was completely ignored, for example [1].
This is another reason to stay with the original. Thanks for this information. See you, Attila
Am Mon, 25 Jan 2010 03:55:22 +0100 schrieb Sven-Hendrik Haase <sh@lutzhaase.com>:
My issue is that the cdrtools substitute cdrkit that Arch currently officially provides is not actively developed (current to last stable was around a year) and is technically inferior to cdrtools.
I don't know anything about the technical differences between cdrkit and cdrtools but http://cdrkit.org says: News 2009/10/11 Cdrkit 1.1.10 has been released. So the last stable release was not a year but only three months ago. This looks like an active development for me. Greetings, Heiko
On 01/25/2010 04:59 AM, Heiko Baums wrote:
Am Mon, 25 Jan 2010 03:55:22 +0100 schrieb Sven-Hendrik Haase<sh@lutzhaase.com>:
My issue is that the cdrtools substitute cdrkit that Arch currently officially provides is not actively developed (current to last stable was around a year) and is technically inferior to cdrtools.
I don't know anything about the technical differences between cdrkit and cdrtools but http://cdrkit.org says: News 2009/10/11 Cdrkit 1.1.10 has been released.
So the last stable release was not a year but only three months ago. This looks like an active development for me.
Greetings, Heiko
Hi cdrkit: 1.1.9 -> 1.1.10 (1 year), 1.1.6 -> 1.1.7 (another year). Only few changes in in each release in years. cdrtools: 13 releases in 2007, 20 in 2008, 16 in 2009, 3 in this month. Lots of changes in each release. The difference is really big. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Am Mon, 25 Jan 2010 14:01:24 -0300 schrieb Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
cdrkit: 1.1.9 -> 1.1.10 (1 year), 1.1.6 -> 1.1.7 (another year). Only few changes in in each release in years. cdrtools: 13 releases in 2007, 20 in 2008, 16 in 2009, 3 in this month. Lots of changes in each release.
The difference is really big.
I haven't looked at the details I only saw the last release date and this wasn't one year ago. I don't care if I'm using cdrtools or cdrkit. For me it's important that my CDs and DVDs are burned correctly. And I personally hadn't had any big issues with both of them except of a speed issue with the latest K3b release in conjunction with wodim. But that's not the point of this thread. Greetings, Heiko
Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
cdrkit: 1.1.9 -> 1.1.10 (1 year), 1.1.6 -> 1.1.7 (another year). Only few changes in in each release in years. cdrtools: 13 releases in 2007, 20 in 2008, 16 in 2009, 3 in this month. Lots of changes in each release.
The difference is really big.
For mkisofs, the difference is ~ 50% of the code. For cdda2wav, the difference is ~ 20% of the code. For cdrecord, the difference is ~ 30% of the code. This does not even count powerful new code like "libfind". The original project has a sustained average putback rate of ~ 3 putbacks per day. People who like to be in competition to the original cdrtools would need to be a lot more active in order to catch up with the progress in the original project. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Mon, 2010-01-25 at 03:55 +0100, Sven-Hendrik Haase wrote:
I request using the original cdrtools in place of cdrkit. I know that it actually was that way once but it was changed due to uncertainty about licensing issues. It appears that these issues are now solved with the conclusion that there are non while cdrkit is actually the offender.
Last time I checked, cdrtools was not distributable because of licensing issues. mkisofs is GPL, the lib it links to is CDDL. GPL can't link to CDDL while staying GPL, so the resulting binary is illegal. Unless Joerg got approval from all contributors and changed mkisofs to CDDL, or if the lib it links to was re-licensed to a GPL-compatible license, mkisofs is distributable, otherwise it's illegal to do so.
On Mon, 2010-01-25 at 09:37 +0100, Jan de Groot wrote:
On Mon, 2010-01-25 at 03:55 +0100, Sven-Hendrik Haase wrote:
I request using the original cdrtools in place of cdrkit. I know that it actually was that way once but it was changed due to uncertainty about licensing issues. It appears that these issues are now solved with the conclusion that there are non while cdrkit is actually the offender.
Last time I checked, cdrtools was not distributable because of licensing issues. mkisofs is GPL, the lib it links to is CDDL. GPL can't link to CDDL while staying GPL, so the resulting binary is illegal. Unless Joerg got approval from all contributors and changed mkisofs to CDDL, or if the lib it links to was re-licensed to a GPL-compatible license, mkisofs is distributable, otherwise it's illegal to do so.
Seems Joerg actually did some changes: he added an exception to the CDDL licensed libraries that allow creating a larger work as long as it's licensed under an OSI-approved license. Last time I checked this exception wasn't present.
-----Original Message-----
Date: Mon, 25 Jan 2010 09:45:42 +0100 Subject: Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit From: Jan de Groot <jan@jgc.homeip.net> To: General Discusson about Arch Linux <arch-general@archlinux.org>
On Mon, 2010-01-25 at 09:37 +0100, Jan de Groot wrote:
On Mon, 2010-01-25 at 03:55 +0100, Sven-Hendrik Haase wrote:
I request using the original cdrtools in place of cdrkit. I know that it actually was that way once but it was changed due to uncertainty about licensing issues. It appears that these issues are now solved with the conclusion that there are non while cdrkit is actually the offender.
Last time I checked, cdrtools was not distributable because of licensing issues. mkisofs is GPL, the lib it links to is CDDL. GPL can't link to CDDL while staying GPL, so the resulting binary is illegal. Unless Joerg got approval from all contributors and changed mkisofs to CDDL, or if the lib it links to was re-licensed to a GPL-compatible license, mkisofs is distributable, otherwise it's illegal to do so.
Seems Joerg actually did some changes: he added an exception to the CDDL licensed libraries that allow creating a larger work as long as it's licensed under an OSI-approved license. Last time I checked this exception wasn't present.
Hello, the only reason I did not move cdrtools to community was that license reason. So if that is no showstopper anymore, I can maintain it. Regards Stefan
On Mon, 2010-01-25 at 11:19 +0100, stefan-husmann@t-online.de wrote:
Hello,
the only reason I did not move cdrtools to community was that license reason. So if that is no showstopper anymore, I can maintain it.
Regards Stefan
I just checked alpha10, one of the first versions that was released as CDDL, that also has that exception. It seems that GPL and CDDL have some conflicting paragraphs, so even if CDDL allows linking to GPL with this exception, GPL doesn't allow the other way around. So no, releasing as binary is still not possible when it comes to mkisofs. mkisofs is still plain GPL without exceptions.
On Mon, Jan 25, 2010 at 11:40 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
On Mon, 2010-01-25 at 11:19 +0100, stefan-husmann@t-online.de wrote:
Hello,
the only reason I did not move cdrtools to community was that license reason. So if that is no showstopper anymore, I can maintain it.
Regards Stefan
I just checked alpha10, one of the first versions that was released as CDDL, that also has that exception.
It seems that GPL and CDDL have some conflicting paragraphs, so even if CDDL allows linking to GPL with this exception, GPL doesn't allow the other way around.
So no, releasing as binary is still not possible when it comes to mkisofs. mkisofs is still plain GPL without exceptions.
That could be the reason of this new project... https://savannah.gnu.org/forum/forum.php?forum_id=6137 The link in the announcement is broken, but it is easy to find in the same ftp, and the Download links in the top leads directly to it : http://ftp.gnu.org/gnu/isofsmk/ If mkisofs is the only doubtful part, why not replacing only mkisofs ? Wouldn't that be better than replacing everything ? Joerg already said that mkisofs received the most code changes, and that genisoimage was quite problematic : "genisoimage does not support UTF-8 and large files and creates filesystem images with lots of bugs." I am sure he will have plenty of nice things to say about isofsmk as well ! Anyway, if it was up to me, I would not replace anything, I would just provide everything, and give the power to the user. Either all as packages, or all as pkgbuilds in AUR, to not make anyone jealous.
2010/1/28 Xavier Chantry <chantry.xavier@gmail.com>:
Anyway, if it was up to me, I would not replace anything, I would just provide everything, and give the power to the user. Either all as packages, or all as pkgbuilds in AUR, to not make anyone jealous.
The latter sounds like the more probable solution :) -- GPG/PGP ID: B42DDCAD
Xavier Chantry <chantry.xavier@gmail.com> wrote:
That could be the reason of this new project... https://savannah.gnu.org/forum/forum.php?forum_id=6137
This is an attack against OpenSource. How do you judge on an entity that starts to publish source tar archives with names and revisions numbers from extremely old OSS packages but doing this with content that is not identical with the original? See: ftp://ftp.berlios.de/pub/cdrecord/mkisofs/old/mkisofs-1.13.tar.gz This is from July 2000.... And there was even already a mkisofs-1.14. As I am the official maintainer of mkisofs (selected by the original author), nobody can rightfully use the name "mkisofs" unless he used the original code. The permission to change the code (from the GPL) is a different thing but the GPL does not include more than the right to use and to change the code.
The link in the announcement is broken, but it is easy to find in the same ftp, and the Download links in the top leads directly to it : http://ftp.gnu.org/gnu/isofsmk/
and of you have a closer look at this, you see that they started with an extremely old version of mkisofs that misses all features that are important today and that is full of bugs. Not looking at things like libfind, that allows recent mkisofs to include the features of the find(1) command and not looking at the Apple HFS code, the current mkisofs is at least 5x more code than the source from y2000 and the new version has no known bugs. Now that you found it, I tell you an interesting aspect of the announcement: The FSF says "we cannot use it in GNU" but they do not say it's illegal. This is a confirmation that even the FSF believes that there is no problem with the original software. They just cannot legally integrate code pieces from cdrtools into their prijects..... Hey stop, they already did and for this reason the FSF currently is the biggest Copyright violator on code taken from cdrtools: The "GNU projects" vcdimager and libcdio are both based on code from cdrtools. The code that was taken by the FSF was never published under a license that would allow relicensing under GPLv3. So where is the "innocence" of the FSF?
If mkisofs is the only doubtful part, why not replacing only mkisofs ? Wouldn't that be better than replacing everything ?
This is simple: in contrary to others (e.g. Debian and the FSF) I honor license regulations by original authors as long as their contribution is still visible.
Joerg already said that mkisofs received the most code changes, and that genisoimage was quite problematic : "genisoimage does not support UTF-8 and large files and creates filesystem images with lots of bugs."
I am sure he will have plenty of nice things to say about isofsmk as well !
mkisofs-1.12b5 (this is what they are currently publishing) has the following issues: - No large file support - No working Rock Ridge support - No working graft points - It creates rotten directory entries - No Apple HFS - No UDF (needed for DVDs) - Well this implies no DVD-Video - Not yet working Joliet - No UTF-8 support - It eats big amounts of memory - .... there are many more issues, but I like to come to an end ;-) The only change (despite what they clame) was to start to translate texts. For me, correct code is more important than internationalization. For this reason, text translations are planned in the original for the development cycle past release 3.0. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
So, are we going to switch to cdrtools? Best regards, Luís Moreira.
Am Montag, 25. Januar 2010 03:55:22 schrieb Sven-Hendrik Haase:
I'm aware that I can get cdrtools from AUR. Even then, cdrkit uses "replaces" and that spells "don't use cdrtools" for me.
I don't see any replaces entry in our cdrkit PKGBUILD. So everybody should be free to replace cdrkit by cdrtools. Did anybody find a neutral and reliable statement about the license problem? I guess most of us are no lawyers. I don't see any problem in providing both if there are no licensing issues and we have maintainers for them. Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 25/01/10 21:09, Pierre Schmitz wrote:
Am Montag, 25. Januar 2010 03:55:22 schrieb Sven-Hendrik Haase:
I'm aware that I can get cdrtools from AUR. Even then, cdrkit uses "replaces" and that spells "don't use cdrtools" for me.
I don't see any replaces entry in our cdrkit PKGBUILD. So everybody should be free to replace cdrkit by cdrtools.
Did anybody find a neutral and reliable statement about the license problem? I guess most of us are no lawyers.
I don't see any problem in providing both if there are no licensing issues and we have maintainers for them.
Not anything recent: http://lwn.net/Articles/195167/ . Debian thinks about these things a lot more than we do so I usually would defer to them. But given they essentially created the cdrkit fork, I'm not sure they are ever going to reassess the situation. Allan
participants (12)
-
Allan McRae
-
Attila
-
Gerardo Exequiel Pozzi
-
Heiko Baums
-
Jan de Groot
-
Joerg.Schilling＠fokus.fraunhofer.de
-
Luís Moreira
-
Pierre Schmitz
-
Ray Rashif
-
stefan-husmann＠t-online.de
-
Sven-Hendrik Haase
-
Xavier Chantry