Loui Chang wrote:

If there are outstanding licensing or legal issues they may decide to avoid that particular software.

This would be a reason to avoid cdrkit. Cdrkit is in a clear conflict with the Copyright law and I as the owner of the rights on the software did already inform the creators of this fork that I may sue them in case that they continue to ignore the law.

The issue isn't really about bugs vs. no bugs. So let's stay on topic. It's more about licenses and the legal ramifications that may come with improper usage. I think Arch followed Debian because they seem to know a lot more than we do. On the other hand, maybe we should be using debs rather than .pkg.tar.gz if that's the case. (hah)

This is a social issue. A hostile Debian packager did spread untrue claims on a OSS project and Debian (and others) have become a victim of these claims. If Debian really would know a lot about licensing, they did not believe the claims of the hostile packager. All decent legal systems require people who claim that others are in conflict wit the law or in conflict with contracts (like the GPL) to prove their claims. It is not the attacked people who need to defend against unsubstancial claims. Now It would be intersting why parts of the OSS community did leave the base of every decent legal system, believe in unsubstancial attacks from a hostile person and ask me to defend.... This is a serious attack against the ethics in OSS and we need to find a way to deal with similar attacks in future. As long as things like the attack against cdrtools may be successful, the OSS eco system is not yet stable enough to withstand attacks from outside.

It is important to respect the caution that the devs are taking. Personally, if it was my decision, I'd encourage any Arch dev or TU who is interested in maintaining cdrtools to go ahead with it. I don't have the same faith in Debian that a lot of others might.

Anyways, this package could easily be made available in an unofficial repository until everyone is comfortable with the licensing. Don't rely on the devs to do everything for you.

From my understanding, what Arch Linux does is a matter of how Arch Linux likes to deal with it's users. If Arch Linux does not care about the users, nbothing needs to change. In the other case, a change seems to be important in order to get rid of the bugs in the fork.

I can just point to the fact that the original software has no known bugs and that bugs in the original software are typically fixed within a few hours. Becoming a packet maintainer for cdrtools thus takes a lot less effort than doing the same for "cdrkit". 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 Tue, Jan 26, 2010 at 12:12 PM, Kitty wrote:

Well, if nothing else, I've learned a couple of things from this thread:

1) FUD works, especially if the FUDer is with a notable distro. 2) AUR is my friend.

Well, if nothing else, I've learned that having patience is not common place... Yeesh man, do you expect things to change overnight?

Joerg, The only thing that will definitely change our minds with regards to this is actually seeing a copy of the report saying the linking performed with cdrtools is not an issue due to license restrictions. Until that time, this discussion is going nowhere and makes you appear trollish with your replies. Maybe we will move to GNU mkisofs/isofsmk as development appears to have started there (I can troll too...). Allan

Johann Peter Dirichlet wrote:

Just burning the question: what about other operating systems (yes, FreeBSD and family) about it? It appears to be the cdrtools VS cdrkit issue doesn't affect them, and in fact FreeBSD guys keep cdrtools as precompiled package but hold cdrkit as a source-only port.

Cdrkit did replace a working original build system by something strange. As a result, the fork only compiles on a few platforms and runs on even fewer platforms. Wodim e.g. compiles on Solaris but the binary just dumps core on every even call. As a result, the fork mainly infected Linux. Other platforms dis stay with a working and maintained software. 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

Thomas Bächler wrote:

I disagree. It seems that most of the mkisofs code was actually written by Jörg himself or written while the package was under Jörg's maintainership (only a small portion is from the original author, who has no interest in it anymore), so I would consider him the defacto copyright holder on mkisofs, which means he is the only one who could sue us if linking the GPL-code against a CDDL library would in fact violate the GPL. Now as he is the one who claims that this is NOT a problem, he won't do that. This is a non-issue, nothing will happen to us, nobody will be pissed, nobody will sue us, everything will just be better and the world will be a happier place.

Thank you! You did find a very good phrase that is hard to find by an affected person. It seems that you hit the nail on the head. 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

Johann Peter Dirichlet wrote:

Well, after thinking about it (and talk with some friends, none lawyer), I just vote for "community cdrtools and dump cdrkit".

I always think about supporting other operating systems, mainly FreeBSD and NetBSD, before taking place in disputes like this. "If the software can be ported to more platforms, then it is better mantained" was always a lemma from me (and many folks of NetBSD team :) ). So cdrtools is better quality software in my humble opinion.

Cdrtools is actively checked for compilation and functionality on many platforms on a regular base on: SunOS 4.x add 5.x Linux AIX FreeBSD NetBSD OpenBSD DragonFly BSD HP-UX 10.x and 11.x Max OS X IRIX MS-WIN (Cygwin) Haiku SCO UnixWare and Openserver Syllable There is support for many more platforms but I do not have access to all of them. 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

Let us all remember that Arch Linux is not a for-profit company out to make a dollar on the backs of free software developers. It is likely that anyone making a license claim against Arch Linux would simply ask us to remove the offending package and leave it at that. The real risk is quite minimal and most companies I've worked for would do this without much fear until someone challenged the legality in a more official capacity. Even then, such a challenge requires money and years of time. So, I would say that putting cdrtools back in extra would be less risky than running Windows or using a credit card at a restaurant (which is how many numbers are stolen). We always have AUR or maybe the archlinux.fr guys would be willing to host it. On Jan 27, 2010 8:15 AM, "Emmanuel Benisty" wrote: On Wed, Jan 27, 2010 at 4:58 PM, Thomas Bächler wrote: > It seems that most o... If this is true, can't Joerg just issue an official statement that he will not sue Arch and we can close this case. or can any other party sue you when violating the GPL ?

Allan McRae wrote:

The only thing that will definitely change our minds with regards to this is actually seeing a copy of the report saying the linking performed with cdrtools is not an issue due to license restrictions. Until that time, this discussion is going nowhere and makes you appear trollish with your replies.

I am sorry to see you again trolling :-( Other people in this mailing list have been able to send useful discussion contributions but you seem to insist in legal nonsense. There was nothing but a social attack from a hostile person. Please show me a report from a single lawyer that proves that there is a legal problem with the original software. Plese do not point me to the FSF Web site, it was not made by a lawyer, it is not secific to cdrtools and I even have a private mail from Eben Moglen that is is made with general incorrect claims regarding the GPL on it. I don't know in what legal system you are living but in the legal system I live, you are just supporting a hostile person that is doing libel attacks against OSS. Why do you support this hostile downstream? He is not even doing any "work" anymore since May 6th 2007. As long as you ignore legal principles, a discussion with you will lead us to nowhere.

Maybe we will move to GNU mkisofs/isofsmk as development appears to have started there (I can troll too...).

It seems that you are childish. First note that since more than 11 years, I am the official mkisofs maintainer. For this reason, other entities cannot legally use the name "mkisofs". Second: some funny people did take a mkisofs source from early 1999 that is missing all important features and that is full of bugs. Given the fact that Debian was not able to find people to support their fork, do you really believe that RMS will find someone? The person who started to work on this outdated source already came up with a lot of wrong claims. Let me explain reality... mkisofs-1.212b5 misses: - support for large files - working Rock Ridge Support - ISO-9660:1999 support - UTF-8 support - Any file name coding abstraction support - Working Eltorito boot support - Boot support for various other platforms (i.e. Sparc) - Support for Apple extensions via HFS - UDF support - Built in find(1) support (made in mkisofs via libfind). - .... It however creates ISO images with lots of structural bugs. The current mkisofs is 5x as much as software you got in early 1999. If you like to live in the past, congratulations! I have seen a lot of encouraging mails from other people. I hope that Arch Linux will finally come back to OSS principles. 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

2010/1/27 Allan McRae :

On 27/01/10 20:02, Joerg Schilling wrote:

...

There was nothing but a social attack from a hostile person. Please show me a report from a single lawyer that proves that there is a legal problem with the original software.

Please provide a report from a single laywer showing that there is not.  This has been repeatedly asked of you

You claim that you are allowed to distribute a tarball containing GPL code and that the needed build scripts are not required to be GPL because the build scripts are a separate project. You claim to have legal advise that your interpretation of the GPL allowing this is valid, but refuse to supply any evidence of that advise so that we can assess the outcome of the legal review ourselves.

...

Plese do not point me to the FSF Web site, it was not made by a lawyer, it is not secific to cdrtools and I even have a private mail from Eben Moglen that is is made with general incorrect claims regarding the GPL on it.

Great.  More evidence from your side that you cannot produce for anyone else to see. Can you actually produce anything backing your claims?

...

As long as you ignore legal principles, a discussion with you will lead us to nowhere.

As long as you ignore the request to supply evidence that your claim is correct, a discussion with you will lead us nowhere.

As the situation currently stands, there are claims that distributing GPL code with non-GPL build scripts is a violation of the GPL. This may or may not be correct (again, supply us some evidence that it is not), and because the GPL requires us to distribute the code, we would be in a legally dubious situation.

I'd be more than happy for Arch to distribute cdrtools if the issue of whether the required distributing the source is legal is resolved. The technical merits certainly appear to warrant this.  That resolution requires some actual evidence be supplied...

Well, there are some lawyer we can just consult to put a thombstone on this discussion? It will going to nowhere if we can't do this single "clearing" of legal issues. In fact, this is the only hurdle to put cdrtools in [community] repo (well, someone needs to adopt it, too).

Allan

Jan de Groot wrote:

On Wed, 2010-01-27 at 10:29 -0200, Johann Peter Dirichlet wrote:

...

Well, there are some lawyer we can just consult to put a thombstone on this discussion? It will going to nowhere if we can't do this single "clearing" of legal issues. In fact, this is the only hurdle to put cdrtools in [community] repo (well, someone needs to adopt it, too).

Seems that won't happen, because: - this discussion comes up now and then, I've seen exactly the same discussion on the fedora-legal lists without outcome - the anti-cdrtools people state that CDDL and GPL are incompatible, some have lawyers who back that statement

Just to make it clear: There is not a single claim from a lawyer that confirms the claims from the hostile downstram packager. 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

Jan de Groot wrote:

On Wed, 2010-01-27 at 15:45 +0100, Joerg Schilling wrote:

...

Just to make it clear:

There is not a single claim from a lawyer that confirms the claims from the hostile downstram packager.

Looking through the thread on the fedora list they claim there's lawyers confirmed it, but in the same thread you say they're not lawyers.

I did, but there was not a single legally valid statement made by a lawyer. 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 Wed, Jan 27, 2010 at 10:51 AM, Aaron Griffin wrote:

On Wed, Jan 27, 2010 at 8:48 AM, Jan de Groot wrote:

...

On Wed, 2010-01-27 at 15:45 +0100, Joerg Schilling wrote:

...

Just to make it clear:

There is not a single claim from a lawyer that confirms the claims from the hostile downstram packager.

Looking through the thread on the fedora list they claim there's lawyers confirmed it, but in the same thread you say they're not lawyers.

Point is, the situation is unclear and all that is done is flaming. People flame you for your weird license, you flame other people for forking your software.

Mr Schilling reminds me quite a bit of that Ion guy who was overly hostile and trollish. That clears up the situation just fine for me.

What I'm seeing here is that Jörg is being his usual self, combative but mostly correct. Allan is pissed off at him. Aaron is cautious and heading towards angry. A couple of other people are a little bit cautious. The rest of the participants, which is most of them, are in favor of switching back from cdrkit to cdrtools. Let me also add my support for putting cdrtools into [extra] (probably [community] is not good enough as I think there are deps in [extra] on cdrkit right now.

2010/1/27 Xavier Chantry :

On Wed, Jan 27, 2010 at 4:51 PM, Aaron Griffin wrote:

...

On Wed, Jan 27, 2010 at 8:48 AM, Jan de Groot wrote:

...

On Wed, 2010-01-27 at 15:45 +0100, Joerg Schilling wrote:

...

Just to make it clear:

There is not a single claim from a lawyer that confirms the claims from the hostile downstram packager.

Looking through the thread on the fedora list they claim there's lawyers confirmed it, but in the same thread you say they're not lawyers.

Point is, the situation is unclear and all that is done is flaming. People flame you for your weird license, you flame other people for forking your software.

Mr Schilling reminds me quite a bit of that Ion guy who was overly hostile and trollish. That clears up the situation just fine for me.

Well I thought about that too, and I believe there is one huge difference : tuomov explicitly imposed a lot of restrictions in packaging, and apparently didn't want or didn't care at all if Arch packaged it or not. If it is packaged, it has to be under his terms. If it isn't, who cares. His interest seemed to not have it packaged, as he believes that would mean less problems and less bug reports for him.

Sorry about the dumb question, but can you post a link for the tuomov restrictions? This is about cdrtools or cdrkit?

Joerg on the other hand seems to care a lot about the inclusion of his software in the official Arch repository. Actually, I really wonder like pyther : "What is in this for him?". The software is already in AUR, which every Arch users know and use. According to him, wodim is completely broken, so surely the majority of Arch users either notice it themselves or are told by other people, and will switch to AUR cdrecord.

This is about mainstream maintaining. Why the buggy software is actively maintained, precompiled with binaries for i686 and x86_64, and the good software is tagged as "unmaintained"?

Even if that's not the case (2 possibilities : wodim is not as broken as Joerg pretends, or arch users are clueless), is Arch really noticeable compared to the big distrib ?

Well, Archlinux is a good distro with a very active crew, and it is a growing distro indeed. And now the maintainer of a big and famous piece of software is actively endorsing your software in that list! I think Archlinux is a noticeable distro indeed.

I am curious to know if anyone has pointers to estimates of linux distribution userbase, but I doubt Arch would matter.

And seriously, if the goal is world domination, making Debian/Ubuntu an enemy is a very efficient way for failing.

On 01/27/2010 11:19 AM, Xavier Chantry wrote:

Joerg on the other hand seems to care a lot about the inclusion of his software in the official Arch repository. Actually, I really wonder like pyther : "What is in this for him?". The software is already in AUR, which every Arch users know and use. According to him, wodim is completely broken, so surely the majority of Arch users either notice it themselves or are told by other people, and will switch to AUR cdrecord.

Perhaps he's annoyed because he wrote a big important piece of software and everyone refuses to use it because of BS claims that he's going to sue them. Wouldn't it make you angry if you went to the trouble to write something like this and everyone ditched it over claims by someone who just wants to make their shitty fork popular? Or maybe he doesn't like making things a huge pain in the ass for his users. Installing cdrtools from the AUR isn't exactly obvious or easy. Even if you do learn about this (like I did from this thread), yaourt -S cdrtools doesn't work (it automatically installs cdrkit instead). -Brendan Long

...

Perhaps he's annoyed because he wrote a big important piece of software and everyone refuses to use it because of BS claims that he's going to sue them. Wouldn't it make you angry if you went to the trouble to write something like this and everyone ditched it over claims by someone who just wants to make their shitty fork popular?

Not to sound trite, but if I was in this situation, I would attempt to provide as much factual evidence as possible, rather than call people names, rant a lot, and never provide anything more than hearsay. Science: it works, bitches

I've read a lot of threads where Jörg is always the same. Jörg, please, please, please ... I trust you that your software is supperior but try to be less insulting to other people. I'm sure you don't see your attitude as difficult, but it is (we can never see our own failings). There was a very simple suggestion some message ago, why not dual-license the CDDL parts of cdrtools and be done with any and all the FUD (from any side), all the anomisity, and trolling. please... how is that harder than taking part in 1000 fruitless dicussions on the internet? -- damjan

Denis A. Altoé Falqueto wrote:

On Wed, Jan 27, 2010 at 8:05 PM, Damjan Georgievski wrote:

...

There was a very simple suggestion some message ago, why not dual-license the CDDL parts of cdrtools and be done with any and all the FUD (from any side), all the anomisity, and trolling.

Or the other way around: put mkisofs under CDDL, so the package has a homogeneous license?

I could proably rightfully do this if I did stop supporting Apple HFS (well we have Apple specific UDF support since 2007). This would be based on being able to drop sinle entity contributions below 5-10% ofh the whole code. Would it be worth to do so? I am not convinced. The GPL was intentionally opened against any kind of libraries after it turned out that the first GCC version was legally unusable. I was part of this discussion and thus I know about this fact. The project "mkisofs" just uses independent libraries under CDDL and this is explicitely permitted for GPLd programs. 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

Damjan Georgievski wrote:

...

Would it be worth to do so? I am not convinced. The GPL was intentionally opened against any kind of libraries after it turned out that the first GCC version was legally unusable. I was part of this discussion and thus I know about this fact. The project "mkisofs" just uses independent libraries under CDDL and this is explicitely permitted for GPLd programs.

You can always dual-license it... GPL for the stupid people* and CDDL for the smart ones.

Dual licensing in general is a bad idea. For a period of time that is intended for a migration it may help in our case.

The Apple HFS stuff would be then CDDL only, and distros could disable it.

Apple HFS stuff is for Mac OS 9. For current Apple releases, UDF + Apple extensions (implemented in the original mkisofs) is better. For the next final version that is expected very soon (I just need to implement support for writing hidden audio tracks automated from *.inf files and do some BluRay tests) there will definitely support for Apple HFS in mkisofs. For the time that follows cdrtools-3.0-final, things may change. 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

Allan McRae wrote:

On 27/01/10 20:02, Joerg Schilling wrote:

...

There was nothing but a social attack from a hostile person. Please show me a report from a single lawyer that proves that there is a legal problem with the original software.

Please provide a report from a single laywer showing that there is not.

In the legal system I live and in case you live in the USA for you too, _you_ would first need to prove that there is a legal problem with the original software. Either do this or stay quiet. 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

Allan McRae wrote:

On 27/01/10 22:40, Joerg Schilling wrote:

...

Allan McRae wrote:

...

On 27/01/10 20:02, Joerg Schilling wrote:

...

There was nothing but a social attack from a hostile person. Please show me a report from a single lawyer that proves that there is a legal problem with the original software.

Please provide a report from a single laywer showing that there is not.

In the legal system I live and in case you live in the USA for you too, _you_ would first need to prove that there is a legal problem with the original software.

Nice avoidance yet again of the request to provide some legal backing to your assertion that it is legal to distribute cdrtools.

You still did not prove that it is illegal. I sit back and relax unless you can prove your claims.

In the legal system I live in, if you have a suspicion that doing something is illegal, then you do not do it. If someone tells you that it is fine with no evidence of legal backing for that assertion and you decide to take their advise, you are legally responsible for your decision.

Well, it seems that you decided to use a model that is highly vulnerable for FUD and you are even in conflict with your own statements: Did you remove cdrkit from Arch Linux? 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

Allan McRae wrote:

...

...

Nice avoidance yet again of the request to provide some legal backing to your assertion that it is legal to distribute cdrtools.

You still did not prove that it is illegal. I sit back and relax unless you can prove your claims.

Yes you can... and equally so can we and not package cdrtools unless you can prove yours. Even if you can prove your claim, we still can relax and do nothing. Although, as I said before, the technical merits of your project warrant it replacing cdrkit if this is ever resolved. Unfortunately, that will likely never be the case given the conclusions that can be drawn from all "evidence" that has been presented out so far.

I am sorry that you do not accept our legal rules and that you are vulnerable for FUD from a single person (in this case Eduard Bloch). The fact that other people have also become a victim of attacks from this person does not count as Bloch never has been able to show a confirmation for his attacks. Unless you start following common rules, it seems that you just like to play a game with me. It does not seem to bring us anywhere and replying to future mail from you looks like wasted time unless you accept to follow common legal rules. 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 Wed, 2010-01-27 at 16:39 +0100, Heiko Baums wrote:

2. Jörg as the author and seeming copyright holder of both software cdrecord and mkisofs has already stated that he has no problem with the release of cdrtools (linking cdrecord against mkisofs) and won't sue you.

If he would be the full copyright holder of mkisofs, he would have re-licensed it to CDDL also, solving the whole problem.

Le 27/01/2010 15:12, Joerg Schilling a écrit :

Well, it seems that you decided to use a model that is highly vulnerable for FUD and you are even in conflict with your own statements:

Just a (not so) funny thought about "FUD from hostile people" and stuff:

Did you remove cdrkit from Arch Linux?

Did you prove it to be illegal?

You still did not prove that it is illegal. I sit back and relax unless you can prove your claims.

-- Thomas/Schnouki

Le 27/01/2010 15:56, Joerg Schilling a écrit :

Thomas Jost wrote:

...

Le 27/01/2010 15:12, Joerg Schilling a écrit :

...

Well, it seems that you decided to use a model that is highly vulnerable for FUD and you are even in conflict with your own statements:

Just a (not so) funny thought about "FUD from hostile people" and stuff:

...

Did you remove cdrkit from Arch Linux?

Did you prove it to be illegal?

Well, someone in this list just told me that the rules for Arch Linux are that someone from Cdrkit would need to prove that there is no legal problem with cdrkit.

Could we agree on a unique method for dealing with claims please?

Jörg

You said earlier that "_you_ would first need to prove that there is a legal problem with the original software". You are telling cdrkit is illegal. Follow your own rule. Prove cdrkit to be illegal. If you can't, there's no point in continuing this discussion. -- Thomas/Schnouki

On 01/27/2010 08:00 AM, Thomas Jost wrote:

Le 27/01/2010 15:56, Joerg Schilling a écrit :

...

Thomas Jost wrote:

...

[snip] Well, someone in this list just told me that the rules for Arch Linux are that someone from Cdrkit would need to prove that there is no legal problem with cdrkit.

Could we agree on a unique method for dealing with claims please?

Jörg

You said earlier that "_you_ would first need to prove that there is a legal problem with the original software".

You are telling cdrkit is illegal.

Follow your own rule. Prove cdrkit to be illegal.

If you can't, there's no point in continuing this discussion.

Wait so if someone says that cdrtools is illegal, he has to prove that it's not, but if someone says that cdrkit is illegal, he has to prove that it is? Will you be my lawyer?

Pierre Schmitz wrote:

The point is that nobody of us can proof for sure if it's legal or not. So it's quite pointless to continue arguing here.

We will not be able to advance in case that a single person insists in applying rules that are in conflict with legal basics. Do you really like OSS to become vulnerable against FUD from hostile people?

Personally I have no objections against having a cdrtools package in our repository if someone wants to maintain it.

Licenses are important, but one shouldn't be too picky about it. If I remember correctly the initial question was if it is legal to distribute a GPL licensed software build with CCDL licenses build system. Both licenses are 100% free and both parts have the same author.

Well as written many times in the past already, this is a question that is extremely easy to answer: The GPL claims to be a valid OSS license. In order to become a valid OSS license, a license must not only follow the weak rules from the FSF but also follow the more stringent rules from the OpenSource initiative: http://www.opensource.org/docs/definition.php The OSI did mark the GPL as a non-free license some years ago because some people from the FSF did write strange claims about the GPL. As a reaction, the FSF replied that the GPL has to be interpreted in a way that makes it compliant to: http://www.opensource.org/docs/definition.php We for this reason may safely asume that the GPL of course allows to publish two independent OSS projects in a single archive. See OSS definition paragraph 9. See the comment from the OSI in http://www.opensource.org/docs/definition.php Note that I did also send a pointer to the interpretation of the GPL made by Lawrence Rosen (the legal counsellor of the OSI) http://www.rosenlaw.com/Rosen_Ch06.pdf I also have a private mail from Eben Moglen that confirms that a claim that a GPL project may not use a build system under a diffeent license ist just nonsense. How many proofs do you like to get? 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

Allan McRae wrote:

On 28/01/10 00:31, Joerg Schilling wrote:

...

The GPL claims to be a valid OSS license.

In order to become a valid OSS license, a license must not only follow the weak rules from the FSF but also follow the more stringent rules from the OpenSource initiative:

http://www.opensource.org/docs/definition.php

The OSI did mark the GPL as a non-free license some years ago because some people from the FSF did write strange claims about the GPL. As a reaction, the FSF replied that the GPL has to be interpreted in a way that makes it compliant to: http://www.opensource.org/docs/definition.php

We for this reason may safely asume that the GPL of course allows to publish two independent OSS projects in a single archive. See OSS definition paragraph 9.

This is where your argument fails and it has been the stumbling block in all previous debates on this issue.

The GPL may allow separate projects to be distributed in the one tarball, but it considers scripts necessary to build a project part of the same project. This is the issue.

You claim they are separate projects; others claim the GPL does not allow that. Your evidence that this is allowable is a mysterious private email that apparently says all is OK...

That is almost insurmountable. If a lawyer provided a statement saying that it was legal and was prepared provide a defense in case of any issues, then we may be able to talk about this again.

Until that point, nothing productive can be achieved discussing this issue, so I will not continue reading this thread.

Allan

Attila wrote:

Sorry ,if i makes you angry because this is NOT my intention. But what i really miss during this most useless discussion about a software for linux is that no one of both sides hire a laywer and see what happens in reality inf front of a court instead of voting. This would be better for everybody of us than this kind of confrontation.

I am in contact with several lawyers but if you don't pay a lawyer, you get help but not the permission to publish the statements. 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

It started off with a simple cautious question: evidence, please? So then, the cdrtools guy says..well, he ignores the evidence part and says something else, says it doesn't matter because you must first prove to him that he needs to show you evidence. So then, it's recursive. But then, he only wants us all to kick cdrkit and the Debian guys in their arses, probably because they spoiled it all. When you adopt something, then you disown it, and then someone tells you to adopt it again, you would definitely want to know why. You grow more and more uneasy if the answer isn't coming as simple and simply as it is claimed to be.

Hi, Leaving all the licenses and legal issues aside, Q) Which is better out of the two? please respond purely on technical basis. Regards, Gaurish Sharma www.gaurishsharma.com

Hi, Atleast, you have my vote, I building cdrtools from AUR as we speak. there is no point of using unmaintned software. Anyone, How can we setup cdrtools to completely replace cdrkit so that other programs like k3b can use seamlessly ? Any guides, I didn't find anything on ArchLinux Wiki which is kinda strange. One more thing cdrtools required it to be run as root, isn't that dangerous. any method by which we give the required permissions to normal user? Regards, Gaurish Sharma www.gaurishsharma.com On Thu, Jan 28, 2010 at 4:29 AM, Joerg Schilling wrote:

Gaurish Sharma wrote:

...

Hi, Leaving all the licenses and legal issues aside,

Q) Which is better out of the two?

please respond purely on technical basis.

Everything has been said, you just need to read it.

Users demand working software and thus request cdrtools.

It is up to the distros to follow the demands of their users or to ignore it.

BTW: I have been asked by people from Arch Linux to help with this discussion. I was not prepared that one or two people act extremely stubborn and that I do not get help from the marority that seems to prefer the original software.

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

Pressing for legal info may be the natural reflex, but associated subjects are best dealt with caution. Maybe he's not in a position were he can divulge this, and is now eating the words he said when publishing details would've been unproblematic. You're getting a first hand response that it's ok to use it. Andres

2010/1/27 Joerg Schilling :

Gaurish Sharma wrote:

...

One more thing cdrtools required it to be run as root, isn't that dangerous. any method by which we give the required permissions to normal user?

There are two possible solutions:

1)      Look at the turkish Linux distro that delivers a complete        uncastrated Linux, create a linux distro that includes the        needed features (make sure that these features cannot be        unconfigured) and send me a version so I can start implementing        support for fine grained privileges on Linux into cdrtools.

2)      Continue to deliver a reduced Linux that does not give you the        choice for a different solution and live with the consequences        that force you to install cdrecord/readcd/cdda2wav suid root        in order to gain the needed privileges.

It is a Linux kernel issue (make menuconfig)? Or just a "install this package in order to fine control cdrtools privileges"?

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

At Donnerstag, 28. Januar 2010 00:14 Gaurish Sharma wrote:

Anyone, How can we setup cdrtools to completely replace cdrkit so that other programs like k3b can use seamlessly ? Any guides, I didn't find anything on ArchLinux Wiki which is kinda strange.

The hard way only for your system: pkgname=cdrecord _pkgname=cdrtools ... conflicts=('cdrkit' 'cdrtools') provides=('cdrkit') ... I have no cdrkit here because i don't need it and i don't need the sysmlinks inside of the package.

One more thing cdrtools required it to be run as root, isn't that dangerous. any method by which we give the required permissions to normal user?

I change the permissions in the install file in this way: /bin/echo "Change Owner, Group and Permission to root.optical (4710) ..." for n in /usr/bin/cdrecord \ /usr/bin/readcd \ /usr/bin/cdda2wav; do /bin/chown -v root:optical $n && /bin/chmod -v 4710 $n; done /bin/echo "done. Than the user has only to be in the group optical. It works but perhaps a expert should say if this is okay. See you, Attila

Gerardo Exequiel Pozzi wrote:

On 01/28/2010 03:48 AM, Attila wrote:

...

I change the permissions in the install file in this way: /bin/echo "Change Owner, Group and Permission to root.optical (4710) ..."

Hi, don't need all root privileges/capabilities. Only cap_sys_admin, cap_sys_rawio for some special SCSI commands and cap_sys_resource for incresing resource limits.

setcap cap_sys_admin,cap_sys_rawio,cap_sys_resource+ep /usr/bin/cdrecord

thats all ;)

Mostly correct, but most Linux distros do not include the needed features that would allow to set these privileges. Cdrecord needs on Solaris: privs=file_dac_read,sys_devices,proc_lock_memory,proc_priocntl,net_privaddr It would need the same on Linux and in addition the permission to send _any_ SCSI commands. Readcd needs: privs=file_dac_read,sys_devices,net_privaddr Cdda2wav needs: privs=file_dac_read,sys_devices,proc_priocntl,net_privaddr Once there is support in more than a turkish Linux distro, I will add support for the Linux fine grained privileges. So what gives on Linux: file_dac_read Permission to open any device file sys_devices Permission to send anc SCSI command proc_lock_memory Lock into memory proc_priocntl Increase priority net_privaddr Allow ports < 1024, needed for RSCSI 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

Attila wrote:

At Donnerstag, 28. Januar 2010 10:22 Joerg Schilling wrote:

I don't find the most of your sugestions in "man 7 capabilities".

...

file_dac_read Permission to open any device file = cap_dac_readsearch ??

Most likely CAP_DAC_OVERRIDE

...

sys_devices Permission to send anc SCSI command Nothing found.

Most likely at least CAP_SYS_RAWIO I am nowever not sur whether this is sufficient.

...

proc_lock_memory Lock into memory = cap_ipc_lock

Looks correct.

...

proc_priocntl Increase priority Nothing found.

Most likely CAP_SYS_NICE

...

net_privaddr Allow ports < 1024, needed for RSCSI cap_net_bind_service

Looks correct.

Is it really such a problem to stay with "chmod 4710"?

As long as there is no support code in Linux distros to set capabilities without making the target program suid root anyway, I see no other possibility than to stay with chown root cdrecord cdda2wav readcd chmod 4711 cdrecord cdda2wav readcd 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

Paulo Matias wrote:

On Fri, Jan 29, 2010 at 8:39 AM, Joerg Schilling wrote:

...

As long as there is no support code in Linux distros to set capabilities without making the target program suid root anyway,

Don't be afraid, Arch Linux has support for that :)

How? Is there support for mandatory ACLs? 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

Pierre Schmitz wrote:

Finally some interesting discussion came out of this. I am not an expert on linux capability support, but Thomas has posted two blog entries about this in Arch: http://archlinux.me/brain0/2009/07/28/using-posix-capabilities-in-linux- part-one/ and http://archlinux.me/brain0/2010/01/05/using-posix-capabilities- in-linux-part-two/

I'll have a loot at it.

In general this should work fine. The only problem is that bsdtar did not support storing those information (don't know if future versions support this) so one has to use install scripts to adjust the permissions after install.

I am not sure whether this is the best solution. I recommend to use star as star is the oldest free tar implementation and as it supports ACLs since 10 years already. Adding more meta data is relatively simple. e~A

Am Freitag, 29. Januar 2010 17:58:42 schrieb Jan de Groot:

On Fri, 2010-01-29 at 14:35 +0100, Joerg Schilling wrote:

...

I am not sure whether this is the best solution. I recommend to use star as star is the oldest free tar implementation and as it supports ACLs since 10 years already. Adding more meta data is relatively simple.

Implementing it in star has no use, as our package manager doesn't use star but libarchive, the library that bsdtar is based on.

This might be related: http://code.google.com/p/libarchive/wiki/TarPosix1eACLs -- Pierre Schmitz, https://users.archlinux.de/~pierre

Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) wrote:

...

This might be related: http://code.google.com/p/libarchive/wiki/TarPosix1eACLs

This does just describe what I defined 10 years ago ;-)

I forgot, the complete documentation is here: http://cdrecord.berlios.de/private/man/star/star.4.html 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

Le Fri, 29 Jan 2010 17:36:58 +0000, Pierre Chapuis a écrit :

Le Fri, 29 Jan 2010 17:58:42 +0100, Jan de Groot a écrit :

...

Implementing it in star has no use, as our package manager doesn't use star but libarchive, the library that bsdtar is based on.

Technically the PKGBUILD could makedepends('star') and use it to extract the source with ACL support...

Ignore this, I just understood how stupid that is. The point is not to support ACLs for the source tarball but for the package itself. -- catwell

On Fri, Jan 29, 2010 at 2:10 PM, Pierre Schmitz wrote:

Finally some interesting discussion came out of this. I am not an expert on linux capability support, but Thomas has posted two blog entries about this in Arch: http://archlinux.me/brain0/2009/07/28/using-posix-capabilities-in-linux- part-one/ and http://archlinux.me/brain0/2010/01/05/using-posix-capabilities- in-linux-part-two/

In general this should work fine. The only problem is that bsdtar did not support storing those information (don't know if future versions support this) so one has to use install scripts to adjust the permissions after install.

When I looked into that a few months ago, it stored just fine when creating the archive. But it did not restore them when extracting. This got fixed in trunk, so it will probably be in the next major release (2.8 ?). http://code.google.com/p/libarchive/source/detail?r=1590# xps-m1530:~> bsdtar --version bsdtar 2.7.902a - libarchive 2.7.902a 2.7 release does not work, at least on my system. The development version is required. xps-m1530:~> setcap cap_net_raw=ep ./ping unable to set CAP_SETFCAP effective capability: Operation not permitted xps-m1530:~> sudo setcap cap_net_raw=ep ./ping xps-m1530:~> getcap ping ping = cap_net_raw+ep setcap needs root. xps-m1530:~> bsdtar cvf ping.tar.gz ping a ping compress normally. xps-m1530:~> bsdtar xvf ping.tar.gz -C /tmp x ping xps-m1530:~> bsdtar xvf ping.tar.gz -C /tmp x ping xps-m1530:~> getcap /tmp/ping By default, it is not restored. "p" is needed. xps-m1530:~> bsdtar xvpf ping.tar.gz -C /tmp x ping: Failed to set extended attribute bsdtar: Error exit delayed from previous errors. xps-m1530:~> sudo bsdtar xvpf ping.tar.gz -C /tmp x ping xps-m1530:~> getcap /tmp/ping /tmp/ping = cap_net_raw+ep root is of course still needed again for setcap, and it works !

At Freitag, 29. Januar 2010 11:39 Joerg Schilling wrote: Thanks for your nice informations and with this line for setcap cap_dac_override,cap_sys_rawio,cap_ipc_lock,cap_sys_nice,cap_net_bind_service+ep a "cdrecord --scanbus" works as normal user without a problem.

As long as there is no support code in Linux distros to set capabilities without making the target program suid root anyway, I see no other possibility than to stay with

chown root cdrecord cdda2wav readcd chmod 4711 cdrecord cdda2wav readcd

This is definitive easier and there is no risk if something will changes for capabilities. There is only one thing which i find better and it is that i prefer "chmod 4710" with a special group to not allow everyone to run cdrecord. Okay, i'm not an expert but this looks safe enough for me ... provide that i have to look every time at the manpage of capabilities.-) See you, Attila

At Freitag, 29. Januar 2010 18:55 Joerg Schilling wrote:

BTW: cdrecord in this mode is unsafe as it does not manages the fine grained privileges but would need to give up cap_dac_override before it tries to open other files. If you don't give up cap_dac_override, cdecord can read any local file.

Thanks for the warning that is unsafe but how longer we discuss about doing the same with capabilities how more i like to stay with the gold old solution.-) See you, Attila

On 01/28/2010 04:06 PM, Attila wrote:

At Donnerstag, 28. Januar 2010 08:35 Gerardo Exequiel Pozzi wrote:

...

Hi, don't need all root privileges/capabilities. Only cap_sys_admin, cap_sys_rawio for some special SCSI commands and cap_sys_resource for incresing resource limits.

setcap cap_sys_admin,cap_sys_rawio,cap_sys_resource+ep /usr/bin/cdrecord

If i do this than i cannot open '/dev/sg1' and therefore i will stay with my way instead it is obsolete.

Thanks for the hint, Attila

I did nothing about group, only root perms ;) Keep the group ;) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Attila wrote:

At Donnerstag, 28. Januar 2010 08:35 Gerardo Exequiel Pozzi wrote:

...

Hi, don't need all root privileges/capabilities. Only cap_sys_admin, cap_sys_rawio for some special SCSI commands and cap_sys_resource for incresing resource limits.

setcap cap_sys_admin,cap_sys_rawio,cap_sys_resource+ep /usr/bin/cdrecord

If i do this than i cannot open '/dev/sg1' and therefore i will stay with my way instead it is obsolete.

Aha, now I see that it seems that Arch really may have the needed features. Did you try to also add CAP_DAC_OVERRIDE? 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

Gaurish Sharma wrote:

Hi, Leaving all the licenses and legal issues aside,

Q) Which is better out of the two?

please respond purely on technical basis.

A) cdrtools, period. Especially if you try to burn DVDs with long, non- ascii (read 'utf8') filenames, labels and other "weird" stuff. I had lost quite a few DVDs in the past before I remembered that it was cdrkit the burner and not cdrtools. But, the developer of cdrtools... that's another story. In this thread alone, he's been asked at least twice why he doesn't dual-license cdrtools and he conveniently ignored it. Herr Schilling, why don't you dual-license (or, best, single-license to GPL) cdrtools? -- X.

On 01/28/2010 10:15 AM, Joerg Schilling wrote:

I cannot use a license that is missinterpreted by too many people and that for this reason is used to attack the project.

like, .... the CDDL? Seriously, you should have seen that comming. Debian has a Master degree in Gnu zealotery and disinformation. Glad you're on the move to cluebat some people finally. -- Arvid

ludovic coues wrote:

Dev don't care about technical basis. They are ok with the fact that 13 releases per year is better than only one each single year.

During the past 4 years, the average was 176.5 releases per year ;-) 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 01/27/2010 04:31 AM, Allan McRae wrote:

Joerg,

The only thing that will definitely change our minds with regards to this is actually seeing a copy of the report saying the linking performed with cdrtools is not an issue due to license restrictions. Until that time, this discussion is going nowhere and makes you appear trollish with your replies.

Maybe we will move to GNU mkisofs/isofsmk as development appears to have started there (I can troll too...).

Allan Joerg,

What is in this for you? By that, I mean, why are you fighting so hard to get this pushed into the official repos? It is in aur with 130 votes and likely there are hundreds more users. http://aur.archlinux.org/packages.php?ID=323 There is one thing with Arch that I think you are missing. The arch devs do what they want. They include software only that they use/want to maintain. In the past they have included software in which licensing wasn't quite clear. As it has been stated many times none of the devs are lawyers. These software programs were a much lower risk to include compared to cdrtools. Said programs did not have the arguments and possible legal issues that cdrtools is currently faced with. Granted if a suite was to be brought against arch, specifically the dev hosting it and the owner of the project (Aaron), they would likely be asked to remove it. I find this risk relatively low and I'd give +1 to add it to the repos (from a users prospective). Look at the high-profile case of cdrtools vs cdrkit, though; it is huge. You stated that sun spent 3 months looking into it. If for some odd reason someone decide to sue the arch project there is a big risk for Aaron and the maintainer of the package. At the very least they would likely have to consult a lawyer and possibly show up in court. This becomes a big time commitment and financial burden as the donations from this project are fairly minimal (at least compared to the hiring of a lawyer). Lets face it, everyone on this project is unpaid and has a real life. It seems as if a few of the main devs have decided they don't want to take the "risk." Why don't you create a repo with cdrtools for arch? It isn't hard to do. That way anyone who wants to use cdrtools would have an easy way to obtain updates, etc... pyther

On 01/27/2010 09:49 AM, Heiko Baums wrote:

Am Wed, 27 Jan 2010 10:17:01 -0500 schrieb pyther :

...

Look at the high-profile case of cdrtools vs cdrkit, though; it is huge. You stated that sun spent 3 months looking into it. If for some odd reason someone decide to sue the arch project there is a big risk for Aaron and the maintainer of the package. At the very least they would likely have to consult a lawyer and possibly show up in court. This becomes a big time commitment and financial burden as the donations from this project are fairly minimal (at least compared to the hiring of a lawyer).

Lets face it, everyone on this project is unpaid and has a real life. It seems as if a few of the main devs have decided they don't want to take the "risk."

I doubt that someone will go directly to court. If someone sees licensing issues he most likely will first ask the Arch devs to remove cdrtools from the repos. If this will be the case, they can just remove it and revert to cdrkit. This won't cost anything.

If there really was such a legal issue I bet no other distribution would have cdrtools in its repos or many other distributions would have been sued already. So why should Arch Linux after many years the first distro to be sued?

And as I've already written I can't find the CDDL in the cdrtools source package. I can only find the GPLv2. So cdrecord and mkisofs are both licensed under the GPLv2.

Greetings, Heiko

here's a proposal for the future of this discussion: 1) Joerg is no longer allowed to participate in the the discourse unless directly questioned. 2) Allan: ditto. 3) All other participants work toward creating a formal proposal and then debating and resolving reservations about that proposal, each in turn. 4) Aaron, as overlord, set a sunset clause on the discussion period, act as moderator (or delegate if he's sick of this shit), and maintain final approval/veto over the proposal that emerges. Anyone? -kludge

By the way, why Joerg ask that Allan do the jobs about legal stuff ? That Joerg that want that cdrkit go to official repo. Not Allan. I'm not right ?

Johann Peter Dirichlet wrote:

That is not the case for cdrkit. It has a lower quality than the original software. In fact, I lost some DVD discs with wodim :( but it is just with me (many people say that cdrkit is buggy, many people say that is good).

There is a simple reason for this problem: I added DVD support to cdrecord in February 1998. The original DVD support code is (as you can see) 12 years old and I would call it mature. Wodim dumped the original DVD support code and replaced it by some half baken code written by a guy from Mandriva. This code does not even read the media parameters from the blank media (as you can prove by calling cdrecord -atip vs. wodim -atip). 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