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

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

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