Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Gaurish Sharma cont...@gaurishsharma.com wrote: Hi, On the Wiki, Add a small note about cdrtools. proposing it as alternate over cdkit.so let the user decide: http://wiki.archlinux.org/index.php/CD_Burning_Tips Just a note: cdrecord has a more complete CDRWIN CUE support than cdrdao. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Armando M. Baratti ambaratti.lis...@gmail.com wrote: Strange, I have had the opposite experience. Trying to burn some CDs with cdrkit (on CentOS) give some problem with not being able to generate Joliet system and I have had trouble with utf-8 too. First I thought I was making some stupid mistake, but changing to cdrtools (from sourceforge repository) fixed that. Well, it was in another distro, but by what I've read in this thread it seems to make sense now. There is nothing strange and this does not depend on the distro you are using. The fork does not handle UTF-8 correctly. BTW: the whole dispute with Debian started with an attempt from a Debian paketizer to make me integrate a non-working UTF-8 patch into mkisofs in May 2004. This patch was full of bugs and even if it did have no bugs, it would only handle 50% of the cases that need support for UTF-8. This broken patch is still in the fork, but in Summer 2006 I did implement working and complete UTF-8 support for mkisofs. There is however no cdrtools at Sourceforge, cdrtools is at Berlios ;-) Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
On 01-02-2010 06:17, Joerg Schilling wrote: Armando M. Barattiambaratti.lis...@gmail.com wrote: Strange, I have had the opposite experience. Trying to burn some CDs with cdrkit (on CentOS) give some problem with not being able to generate Joliet system and I have had trouble with utf-8 too. First I thought I was making some stupid mistake, but changing to cdrtools (from sourceforge repository) fixed that. Well, it was in another distro, but by what I've read in this thread it seems to make sense now. There is nothing strange and this does not depend on the distro you are using. The fork does not handle UTF-8 correctly. BTW: the whole dispute with Debian started with an attempt from a Debian paketizer to make me integrate a non-working UTF-8 patch into mkisofs in May 2004. This patch was full of bugs and even if it did have no bugs, it would only handle 50% of the cases that need support for UTF-8. This broken patch is still in the fork, but in Summer 2006 I did implement working and complete UTF-8 support for mkisofs. There is however no cdrtools at Sourceforge, cdrtools is at Berlios ;-) Jörg Excuse me I meant rpmforge repository. Armando
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Baho Utot baho-u...@columbus.rr.com wrote: I have preformed some tests and guess what cdrkit works! Imagine that. It burnt the iso's for Slackware distribution, and using md5sum to sum both a Slackware distribution disk burned by both cdrkit and cdrtools and they are the same, how did that happen? There is a 99,999% chance that you did never used cdrtools. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
virus_found vir.fo...@gmail.com wrote: Now you know about several of those cases, for I wasn't able to burn my CD on a modern device (Lenovo SL500's DVD device) with cdrtools (alpha67, IIRC), but I was able to do it with cdrkit without an issue. There is a 99.9% chance that you are not telling the truth. If you really had a problem, you could describe it and send a log. People who have problems have a name and send bug reports. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Joerg Schilling wrote: Baho Utot baho-u...@columbus.rr.com wrote: I have preformed some tests and guess what cdrkit works! Imagine that. It burnt the iso's for Slackware distribution, and using md5sum to sum both a Slackware distribution disk burned by both cdrkit and cdrtools and they are the same, how did that happen? There is a 99,999% chance that you did never used cdrtools. Jörg Please show me the evidence to support your position. Please what evidence do you have that I have never used cdrtools? As a user of Linux since 1995 your assertions are ridicules. Just being a user from 1995 proves your claim to be false. Yes that is before cdrkit was ever released. I have been a early beta tester for Turbolinux, would you like a copy of my beta/prerelease TurboLinux CDs from that period? I also have RedHat Linux official versions from 5.0 to 9.0 and non official release 4.2 which I ran oracle on, the oracle db required Red Hat 4.2 at that time, again you look it up. Please do this, download Slackware 12 or 13 _LOOK_ at what it being distributed. You _WILL_ find that it is cdrtools. One _HAS_ to remove it by choice as I did and build and install cdrkit. Would you like my build script for cdrkit? Here is the script I used to test cdrtools and cdrkit #!/bin/sh # $Id: burnt_iso_md5_check.sh,v 1.1 2008/03/22 16:51:22 root Exp root $ # Written 2008 by Eric Hameleers al...@slackware.com # # This command will check the md5sum of a cd (ignoring possible padding at # the end by only checking the same amount of bytes at the iso image) and # also check the md5sum of the ISO image. # Idea found at: # http://www.linuxquestions.org/questions/showthread.php?p=3077366#post3077366 # and expanded a bit. # if [ $1 ]; then isoFile=$1 else echo Usage: $0 iso-image cd-drive echo E.g. $0 /tmp/slackware-12.0.iso /dev/dvd exit 1 fi if [ $2 ]; then cdDrive=$2 else echo Usage: $0 iso-image cd-drive echo E.g. $0 /tmp/slackware-12.0.iso /dev/dvd exit 1 fi if [ ! -b $cdDrive ]; then echo ERROR. '$cdDrive' is not a block device. exit 1 fi if [ ! -r $isoFile ]; then echo ERROR. ISO image '$isoFile' does not exist. exit 1 else echo ** Verifying md5sums between $isoFile - $cdDrive dd if=$cdDrive | head -c $(stat --format=%s $isoFile) | md5sum \ md5sum $isoFile fi You have confirmed my position. You just want to argue your point. You can continue to claim the above, But you now have _ZERO_ credibility with me.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Sun, Jan 31, 2010 at 12:39:07PM +0100, joerg.schill...@fokus.fraunhofer.de wrote: virus_found vir.fo...@gmail.com wrote: Now you know about several of those cases, for I wasn't able to burn my CD on a modern device (Lenovo SL500's DVD device) with cdrtools (alpha67, IIRC), but I was able to do it with cdrkit without an issue. There is a 99.9% chance that you are not telling the truth. If you really had a problem, you could describe it and send a log. People who have problems have a name and send bug reports. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily Sometimes I really miss the topic close function on the mailing list. I known already enough, so I'll just ban this thread locally. Jaroslav (Dragonlord) Lichtblau Arch Linux Trusted User -- Der Wurf mag zuweilen nicht treffen, aber die Absicht verfehlt niemals ihr Ziel. -- Jean Jacques Rousseau (Träumereien eines einsamen Spaziergängers) pgpw2GqRAWPrR.pgp Description: PGP signature
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Hi, On the Wiki, Add a small note about cdrtools. proposing it as alternate over cdkit.so let the user decide: http://wiki.archlinux.org/index.php/CD_Burning_Tips Regards, Gaurish Sharma www.gaurishsharma.com
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Damjan Georgievski gdam...@gmail.com 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Baho Utot baho-u...@columbus.rr.com wrote: Joerg Schilling wrote: Baho Utot baho-u...@columbus.rr.com wrote: I have preformed some tests and guess what cdrkit works! Imagine that. It burnt the iso's for Slackware distribution, and using md5sum to sum both a Slackware distribution disk burned by both cdrkit and cdrtools and they are the same, how did that happen? There is a 99,999% chance that you did never used cdrtools. Jörg Please show me the evidence to support your position. mkisofs writes a record with it's current version number, so if you use cdrtools, the content _definitely_ differs. It is unfortunately people like you who do never prove any of their claims and who claim things with an extremely low probability that create the impression of groundless attacks and zero credibility. You may try to trick out other people, here you will not have success. As people with some basic skills know, just writing an _image_ with cdrecord and wodim and then then comparing results does not prove the absense of problems in wodim or cdrkit. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Gaurish Sharma cont...@gaurishsharma.com wrote: Hi, On the Wiki, Add a small note about cdrtools. proposing it as alternate over cdkit.so let the user decide: http://wiki.archlinux.org/index.php/CD_Burning_Tips This is of course better than doing nothing. Please note however that this discussion did not start because I like to include cdrtools into Arch linux but because Arch Linux users are interested to have cdrtools in arch linux by default instead of cdrkit. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
2010/1/31 Joerg Schilling joerg.schill...@fokus.fraunhofer.de: virus_found vir.fo...@gmail.com wrote: Now you know about several of those cases, for I wasn't able to burn my CD on a modern device (Lenovo SL500's DVD device) with cdrtools (alpha67, IIRC), but I was able to do it with cdrkit without an issue. There is a 99.9% chance that you are not telling the truth. If you really had a problem, you could describe it and send a log. People who have problems have a name and send bug reports. Ok, I didn't want to take part in this joke, but enough is enough. There is a 99.9% chance that you are not telling the truth. If you really had a relevant e-mail from Eben Moglen (or another lawyer, for the matter) that could really solve all of your problems with the cdrtools-vs-cdrkit querelle, you would have found a way to publish it and clear up the doubts. People who have problems have a name (ok, you have one) and send bug (law) reports. This is *your* argument. Do you think it is valuable? Ok, I'll just say I have *two* private e-mails from a very important lawyer that states that there *is* a legal problem with cdrtools. Now, how do you counter-argument *this*? Do you see how it makes no sense at all? You know what's the point? I had a deep respect for you, before I read this thread. Maybe you're the best coder in the world, but it's decades that code doesn't earn you respect. You are talking with *people* here, not pets. And your discussion is in no way technical as you required. «My software has legal issues? No, that's not true, trust me, I can't provide any proof but it's true.» «My software has technical issues? No, that's not true, I can't trust you and you must provide proof.» No, thanks. Corrado Primier
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
On 30-01-2010 12:58, Baho Utot wrote: I don't think you get it. First of all, I don't care what happened when the split or fork happened. It makes _ZERO_ difference to me. This is what I have done because of _your_ direct actions on this list and other actions by you on some news groups I read. On the computers I have that run Slackware -12.2/13.0 I have removed cdrtools and installed cdrkit. Note that Slackware distributes cdrtools. I don't care if cdrtools is better than the very best or that cdrkit is worst than the worst. It doesn't matter. I have preformed some tests and guess what cdrkit works! Imagine that. It burnt the iso's for Slackware distribution, and using md5sum to sum both a Slackware distribution disk burned by both cdrkit and cdrtools and they are the same, how did that happen? Going forward I will use cdrkit on any system that I have any responsibilities on. Thanks. PS. I agree and support Arch Linux to distribute cdrkit. Strange, I have had the opposite experience. Trying to burn some CDs with cdrkit (on CentOS) give some problem with not being able to generate Joliet system and I have had trouble with utf-8 too. First I thought I was making some stupid mistake, but changing to cdrtools (from sourceforge repository) fixed that. Well, it was in another distro, but by what I've read in this thread it seems to make sense now. Armando
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Sat, Jan 30, 2010 at 3:05 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: If you would give evidence, it would be easy to prove that your alleged problem is not related to cdrecord. You've made your point and I agree with you :) but please don't get yourself unsubscribed by being sarcastic... Andres
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
@Joerg Schilling This is not another attack against you so please to not try and make yourself appear as some kinda of victim here as well. I know it's none of my business replying here, but I feel I need to say something. It's not related to the original discussion, but your attitude. Now, I'll say it up front, I'm not a psychological professional, shrink or anyone qualified to discuss this, but I will put my foot in my mouth anyway. Over this entire thread, you have come off as very aggressive, maybe this has something to do with the language, maybe it's just your personality. You have, dare I say attacked others, presented others in a somewhat degraded light. You do all these things, as far as I can tell, without sufficient reason(e.g calling others hostile when that had nothing to do with the discussion, also see your comments about Arch as well...). Throughout, you have presented yourself as some sort of victim. This coupled with your defensive behaviour is not very good. It leads to you appearing as some kind of troll, or someone whose sole intent is to destroy cdrkit as opposed to getting cdrtools back into Arch. On 30/01/10 07:35, Joerg Schilling wrote: Steve Holmessteve.holme...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I don't know much about the licenses differences and all that crap but I experienced a problem with cdrecord several years ago where it would not work with my CD burner. I kept getting wiere I/O errors or some such. When I asked around,some people told me about wodim and when I went out and installed wodim, I've been able to burn CDs and DVDs flawlessly ever since. My time with wodim has transpired over Slackware, Debian, and now Arch. I don't know today if cdrecord would still cause me those errors or not but for me, the drkit has been doing me just fine. As you do not give any facts, this is obviously nonsense. No, that doesn't make it nonsense and along with your other favourite words (such as hostile, attacked, victim) your use of it is very appears needlessly aggressive. This kind of attitude leads to bad/buggy software. I know of not a single case where cdrecord fails but wodim succeeds. Obviously you do not because you haven't tested every possible combination of software and hardware here. I can give you a real-life example, NetworkManager, it works great until I attemp to play games, I get a very noticeable lag every so often than ruins online games for me. This issue does not exist, now nor has it ever existed with any other networking tool(netcfg, wicd) some time ago I read about it being blamed on buggy drivers, yet it exists only because of the way NetworkManager does a periodic background scan. You are being introduced to a potential new case here, don't blindly dismiss it. Wodim is nothing than an onl version of cdrecord with bugs added by it't creators that never have been in the original. At this moment in time, I cannot upgrade xorg-xinit from the old 1.1.1-1 to 1.2.0-1 because some scripts breaks and I haven't bothered to look into it. By your logic, this is obviusly nonsense because the newer, less buggy xorg-xinit has no such regressions. If you would give evidence, it would be easy to prove that your alleged problem is not related to cdrecord. Jörg Again, no-one likes a victim. Try not to be so defensive. Look at Pidgin's xfire/gfire plugin, it suffers from bugs and possible security issues because the developers exhibited similar defensive behavior towards me, today I upgrade and fix those bugs as I like without even bothering to report them. Attitude like this drives people away, people with potentially valuable input.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Nathan Wayde kum...@konnichi.com wrote: @Joerg Schilling This is not another attack against you so please to not try and make yourself appear as some kinda of victim here as well. Let me give some basic explanations: In German we have the word Streitkultur, there is no equlvalent in English - guess why... In Germany, it is possible to have a technically based discussion without attacking the other people. If you try to have the same using the English language, people often claim that they have been personally attacked and personally attack other people although they did reply on a text that clearly does not contain any personal attack. I am not personally atacking people and I hope that some people here learn Streitkultur. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
On Sat, Jan 30, 2010 at 06:48, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: In Germany, it is possible to have a technically based discussion without attacking the other people. If you try to have the same using the English language, people often claim that they have been personally attacked and personally attack other people although they did reply on a text that clearly does not contain any personal attack. I have been reading this mailing list for several years, and can think of maybe one or two discussions that got like this. The vast majority of them are quite civil technical discussions. Don't blame the language for your lack of competence. If you feel that English can't convey your ideas, that's not the fault of the language but a lack of fluency on your part. Stop trying to misdirect the discussion.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Am Sat, 30 Jan 2010 12:48:33 +0100 schrieb joerg.schill...@fokus.fraunhofer.de (Joerg Schilling): Let me give some basic explanations: In German we have the word Streitkultur, there is no equlvalent in English - guess why... And the word Streitkultur is the biggest misnomer (Unwort) ever. That's typically German. Look e.g. at German forums and English forums. English forums are usually much friendlier and much more competent. In German forums the most given answer without giving the answer to the asked question is: Use the search function. And if someone asks a question he first has to apologize with a bad conscience that he hasn't found anything with the search function and that one may excuse it if his question was already posted. In English forums you usually get the answer you have asked for. The search function is mentioned only in exceptional cases and in a sub-clause. And if it's really your intention to argue (streiten) then I don't know if this is the right attitude. Discussing is much better and effective than arguing. I mean I assume that you have a big technical knowledge. Otherwise you wouldn't be able to write such a program and build such an Open Solaris LiveCD. But I also can understand that some people feel being attacked by you. On the other hand I can understand that you like to see cdrtools in the repo instead of cdrkit since it is your and the original software. And I'd also vote for switching from cdrkit to cdrtools in the repos even if I generally don't mind with which program I burn my CDs as long as the CDs are burned correctly. In Germany, it is possible to have a technically based discussion without attacking the other people. If you try to have the same using the English language, people often claim that they have been personally attacked and personally attack other people although they did reply on a text that clearly does not contain any personal attack. No, it's usually exactly vice versa. If people claim that they have been personally attacked they either have been personally attacked or it's due to the language knowledge of the foreign speaker. I am not personally atacking people and I hope that some people here learn Streitkultur. I hope not. And I'm also German, but I hate the word Streitkultur. Greetings, Heiko
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Daenyth Blank daenyth+a...@gmail.com wrote: I have been reading this mailing list for several years, and can think of maybe one or two discussions that got like this. The vast majority of them are quite civil technical discussions. Don't blame the language for your lack of competence. If you feel that English can't convey your ideas, that's not the fault of the language but a lack of fluency on your part. Stop trying to misdirect the discussion. Good idea, it would help if you start to follow your own directions.. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Heiko Baums li...@baums-on-web.de wrote: I mean I assume that you have a big technical knowledge. Otherwise you wouldn't be able to write such a program and build such an Open Solaris LiveCD. But I also can understand that some people feel being attacked by you. On the other hand I can understand that you like to see cdrtools in the repo instead of cdrkit since it is your and the original software. And I'd also vote for switching from cdrkit to cdrtools in the repos even if I generally don't mind with which program I burn my CDs as long as the CDs are burned correctly. It seems that you also use this discussion to attack me. It would help a lot of you first try to understand what happened. A person did make a claim about an alleged problem without giving any proof for his claims. I asked him kindly to give enough information so in case there really was a problem, I am able to explain where it is located. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
On Sat, 2010-01-30 at 14:56 +0100, Joerg Schilling wrote: Heiko Baums li...@baums-on-web.de wrote: I mean I assume that you have a big technical knowledge. Otherwise you wouldn't be able to write such a program and build such an Open Solaris LiveCD. But I also can understand that some people feel being attacked by you. On the other hand I can understand that you like to see cdrtools in the repo instead of cdrkit since it is your and the original software. And I'd also vote for switching from cdrkit to cdrtools in the repos even if I generally don't mind with which program I burn my CDs as long as the CDs are burned correctly. It seems that you also use this discussion to attack me. It would help a lot of you first try to understand what happened. A person did make a claim about an alleged problem without giving any proof for his claims. I asked him kindly to give enough information so in case there really was a problem, I am able to explain where it is located. Jörg Joerg, I think most of us do see your points, but its difficult to take them seriously with the language you're using. It may merely be a translation issue, but the words you use, while perhaps not being an issue in German, are considered generally offensive and trollish in English. Unfortunately a bad messenger tends to taint the message.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
On 30/01/10 23:56, Joerg Schilling wrote: It would help a lot of you first try to understand what happened. A person did make a claim about an alleged problem without giving any proof for his claims. I asked him kindly to give enough information so in case there really was a problem, I am able to explain where it is located. Given where this part of the thread started, I assume this is about the message from Steve Holmes claiming he had issues with cdrtools in the past. That makes your definition of asking kindly quite weird. Calling a persons statements obviously nonsense does not sound kind to me. Especially when he said the bug was several years ago. That is a similar time to when cdrkit was forked and you claim that to be full of bugs. It is entirely plausible that one of the large number of bugs you fixed since that split is what he hit when he tried a long time ago. To call it obvious nonsense implies to me that you really think there were no bugs in cdrtools back when it was forked and so cdrkit should be bug free. Or were you just calling it nonsense because someone said something bad about your code? I'm surprised you have not sat back and thought why so many threads on mailing lists or bug trackers for various distributions end up with people being quite annoyed at you. You do really come off in a very aggressively defensive fashion (yeah, yeah, English speakers and their lack of Streitkultur) and that does very little to entreat people to your cause. This is probably the single biggest hurdle for people including your software in their distro, because they already have a bad impression of you and would rather not deal with you if ever they get a bug report for your code. As with all Arch development, a very long winded mailing list thread - 150+ messages and counting - will not decide what becomes part of the distribution. If it is ever decided for Arch to distribute cdrtools, it will be very much in spite of you and your attitude. Allan
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Am Sat, 30 Jan 2010 14:56:13 +0100 schrieb joerg.schill...@fokus.fraunhofer.de (Joerg Schilling): It seems that you also use this discussion to attack me. Where did I attack you? If you feel so easy being attacked, then you should indeed think about yourself. Greetings, Heiko
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
Joerg Schilling wrote: Heiko Baums li...@baums-on-web.de wrote: I mean I assume that you have a big technical knowledge. Otherwise you wouldn't be able to write such a program and build such an Open Solaris LiveCD. But I also can understand that some people feel being attacked by you. On the other hand I can understand that you like to see cdrtools in the repo instead of cdrkit since it is your and the original software. And I'd also vote for switching from cdrkit to cdrtools in the repos even if I generally don't mind with which program I burn my CDs as long as the CDs are burned correctly. It seems that you also use this discussion to attack me. It would help a lot of you first try to understand what happened. A person did make a claim about an alleged problem without giving any proof for his claims. I asked him kindly to give enough information so in case there really was a problem, I am able to explain where it is located. Jörg I don't think you get it. First of all, I don't care what happened when the split or fork happened. It makes _ZERO_ difference to me. This is what I have done because of _your_ direct actions on this list and other actions by you on some news groups I read. On the computers I have that run Slackware -12.2/13.0 I have removed cdrtools and installed cdrkit. Note that Slackware distributes cdrtools. I don't care if cdrtools is better than the very best or that cdrkit is worst than the worst. It doesn't matter. I have preformed some tests and guess what cdrkit works! Imagine that. It burnt the iso's for Slackware distribution, and using md5sum to sum both a Slackware distribution disk burned by both cdrkit and cdrtools and they are the same, how did that happen? Going forward I will use cdrkit on any system that I have any responsibilities on. Thanks. PS. I agree and support Arch Linux to distribute cdrkit.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Sat, Jan 30, 2010 at 08:35:38AM +0100, Joerg Schilling wrote: Steve Holmes steve.holme...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I don't know much about the licenses differences and all that crap but I experienced a problem with cdrecord several years ago where it would not work with my CD burner. I kept getting wiere I/O errors or some such. When I asked around,some people told me about wodim and when I went out and installed wodim, I've been able to burn CDs and DVDs flawlessly ever since. My time with wodim has transpired over Slackware, Debian, and now Arch. I don't know today if cdrecord would still cause me those errors or not but for me, the drkit has been doing me just fine. As you do not give any facts, this is obviously nonsense. I know of not a single case where cdrecord fails but wodim succeeds. Wodim is nothing than an onl version of cdrecord with bugs added by it't creators that never have been in the original. If you would give evidence, it would be easy to prove that your alleged problem is not related to cdrecord. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily Now you know about several of those cases, for I wasn't able to burn my CD on a modern device (Lenovo SL500's DVD device) with cdrtools (alpha67, IIRC), but I was able to do it with cdrkit without an issue.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit - tone it down
On Sat, Jan 30, 2010 at 09:58:19AM -0500, Baho Utot wrote: This is what I have done because of _your_ direct actions on this list and other actions by you on some news groups I read. ... Your post makes you look like a juvenile struggling with the first hormones. I don't care if cdrtools is better than the very best or that cdrkit is worst than the worst. It doesn't matter. If your choice of software is such an emotional thing then I must conclude that you can't be trusted to manage any system except your own, and that whatever you do or write on these matters is completely irrelevant. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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. You can always dual-license it... GPL for the stupid people* and CDDL for the smart ones. The Apple HFS stuff would be then CDDL only, and distros could disable it. * not my opinion, but for the sake of argument -- damjan
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Just some words from my point of view: Like some of you guys - most of you I guess.. - I don't really like Jörg's way to articulate. He has his arguments, which are really good ones, but it always becomes a discussion like this. I saw this in the german Ubuntu forums, before I switched to Archlinux. But he really makes me feel like he loves his software and wants to maintain it as active as possible, so it always stays free of known bugs and is as well written as he is able to. I'm no real coder, so I cannot confirm that, but I trust him in this point. Maybe we deal here with a guy, who isn't really good in expressing himself in writing. I have this problem as well, I'm a much better talker than writer, when I write stuff, people often misunderstand me. Maybe it's the same with Jörg (although his english is VERY good!). But is this really an argument wether to use someone's software or not? I mean, for example, many people think RMS is a real idiot, but still they use his utils, because they are good software. There could be thousands of other examples. Are the devs of Firefox nice guys? Who gives a shit about that? Nobody, right, because nobody needs to talk to them about such issues Jörg always has to discuss about. What I want to say is, don't focus on Jörg's writing style or the way he articulates, focus on the software and the license issues. And Jörg, PLEASE do yourself a favor and stay on topic, the people here want to be sure if it's legal to use your software, so provide every information you are able to provide and don't always just write stuff like I have a personal email of ... (too lazy right now to find your exact quote, this thread is very long already ;-) ) You want Arch to use cdrtools in its official repos? So do what has to be done. If Allan, a VERY important Arch Dev, wants something specific, you should provide everything you can. It doesn't help you at all to play a little crybaby with this whole They stole my software (again, no real quote) etc. I'd love to see cdrtools in Arch, simply because it's really superior to cdrkit. If it's illegal to provide it in the repos, we still have the AUR, but the repos are official, the AUR is not, so if it's possible, having it in the repos would be preferable. Hope to see this discussion come to a good end for both sides ... Yes I'm a dreamer ;-) Greetz Army
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Attila vodoo0...@sonnenkinder.org 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_privaddrAllow 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Fri, Jan 29, 2010 at 8:39 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de 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 :) BTW, congratulations and thanks for your software. I use cdrtools and it is a nice piece of very high quality software.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Attila vodoo0...@sonnenkinder.org 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
ludovic coues cou...@gmail.com 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Am Freitag, 29. Januar 2010 11:58:12 schrieb Joerg Schilling: Paulo Matias mat...@archlinux-br.org wrote: On Fri, Jan 29, 2010 at 8:39 AM, Joerg Schilling joerg.schill...@fokus.fraunhofer.de 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 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. Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) wrote: ludovic coues cou...@gmail.com 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 ;-) Sorry for the typo: should be 17.5 Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Pierre Schmitz pie...@archlinux.de 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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Pierre Schmitz pie...@archlinux.de wrote: 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 This does just describe what I defined 10 years ago ;-) Some notes: The POSIX.1e ACL draft was withdrawn in 1999. The current ACL standard is from NTFS and part of NVFv4 and ZFS Mandatory ACLs are something completely different. They are similar to extended file attributes - just that the kernel interprets them. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
joerg.schill...@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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Le Fri, 29 Jan 2010 17:58:42 +0100,
Jan de Groot j...@jgc.homeip.net 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...
--
catwell
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Le Fri, 29 Jan 2010 17:36:58 +,
Pierre Chapuis catw...@archlinux.us a écrit :
Le Fri, 29 Jan 2010 17:58:42 +0100,
Jan de Groot j...@jgc.homeip.net 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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Freitag, 29. Januar 2010 14:10 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/ Nice informations, thanks. 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 must say that using install scripts is from my view for permissions or setcap even the better way because than i don't need to be root to create a package. See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Attila vodoo0...@sonnenkinder.org wrote: 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. 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. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Am Freitag, 29. Januar 2010 18:47:55 schrieb Xavier Chantry: 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. This is good new; afaik 2.8 should be released soon. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
So, are we going to switch to cdrtools? Best regards, Luís Moreira.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Steve Holmes steve.holme...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I don't know much about the licenses differences and all that crap but I experienced a problem with cdrecord several years ago where it would not work with my CD burner. I kept getting wiere I/O errors or some such. When I asked around,some people told me about wodim and when I went out and installed wodim, I've been able to burn CDs and DVDs flawlessly ever since. My time with wodim has transpired over Slackware, Debian, and now Arch. I don't know today if cdrecord would still cause me those errors or not but for me, the drkit has been doing me just fine. As you do not give any facts, this is obviously nonsense. I know of not a single case where cdrecord fails but wodim succeeds. Wodim is nothing than an onl version of cdrecord with bugs added by it't creators that never have been in the original. If you would give evidence, it would be easy to prove that your alleged problem is not related to cdrecord. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On 28 January 2010 00:14, Gaurish Sharma cont...@gaurishsharma.com wrote: 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. I didn't have to make any changes and it works perfectly with k3b here. 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 never run them under root and it works… Regards, Gaurish Sharma www.gaurishsharma.com
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
This is my probably my very last reply to this thread. From last I know that discussing with Joerg is pointless. Although I'm not a lawyer I think I know GPL quite well. First, I took a look at cdrkit sources to test the claim they are against GPL. GPL section 2. a) is violated. I can't decide about 2. c) because I used cdrkit for about a week several years ago. Compared to the claims from Joerg's website: I agree about 2. a), I can't decide about 2. c). 3 is IMO wrong. Sources are here and are compilable. Unless you are taking it to extreme and wants to distribute it with all dependencies like libc (which almost nobody does). For that case there is some exception for system libraries like libc is (if there wasn't such exception it would actually disallow GPL software to exist on Windows or commercial Unix). About the copyright act. This is meaningless stuff which has nothing to do with GPL. What I mean is that if GPL and copyright act are against each other the copyright act has precedence and makes the license invalid (or some parts) in that country. I remember that here, in Czech Republic, the GPL was not applicable because copyright act didn't allow existence of licenses which would tune some of the rights. Did it mean that all over the world the GPL was null? Ad Preamble: I guess that cdrkit doesn't affect original author reputation nearly as much as his hostility and being trollish. Now let's take a look at cdrtools sources. - mkisofs – from GPL side it is OK (you can link GPL with non GPL libraries, but adding exception for this linking it advised). From CDDL side I'm not so sure. In 3.1 is said: Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License. This looks like violation because mkisofs links sources that are under CDDL. But later there is point 3.6. I think it doesn't apply here (if I understand it right it allows you to eg. distribute binary which is under CDDL and binary which is under GPL but NOT link GPL code into CDDL). I wonder why everyone is talking about violating GPL when it looks more like violating CDDL ;-) libhfs – it's not a problem because it's used only within mkisofs My conclusion: --- None of the tools is without problems so it's a matter of preference which one you select. I'd select cdrtools because they are far more superior than that useless cdrkit crap. From my point of view the best solution would be to relicense GPL code to CDDL. If original author doesn't allow it then rewrite the affected code (Joerg wrote somewhere that it's only around 7000 lines of code so it should be that problematic). regards, Lukas stativ Jirkovsky
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Xavier Chantry chantry.xav...@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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Christos Nouskas n...@archlinux.us wrote: Herr Schilling, why don't you dual-license (or, best, single-license to GPL) cdrtools? I thought you should be able to find this by your own. I cannot use a license that is extremely restrictive while most of the restrictions do not stand in court. I cannot use a license that is missinterpreted by too many people and that for this reason is used to attack the project. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar 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_privaddrAllow ports 1024, needed for RSCSI Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Johann Peter Dirichlet peterdirichlet.freesoftw...@gmail.com wrote: 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? A Linux distro that is feasible for a non-root cdrecord would need to include full support for fine grained privileges and the distro would need to make sure that this cannot be turned off later. This includes: - Kernel support for fine grained privs - Library support for above - Support for automated raising of privileges for specific user land programs. This can either be done by something like pfexec(1) that itself is very small (400 lines) and reads the databases in /etc/security like /etc/security/exec_attr Or it can be done by having a root filesystem that supports mandatory access controls that act similar to suid root but for fine grained privs. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Denis A. Altoé Falqueto denisfalqu...@gmail.com wrote: On Wed, Jan 27, 2010 at 8:05 PM, Damjan Georgievski gdam...@gmail.com 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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 ?? sys_devices Permission to send anc SCSI command Nothing found. proc_lock_memory Lock into memory = cap_ipc_lock proc_priocntl Increase priority Nothing found. net_privaddrAllow ports 1024, needed for RSCSI cap_net_bind_service Is it really such a problem to stay with chmod 4710? See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
At Donnerstag, 28. Januar 2010 20:38 Gerardo Exequiel Pozzi wrote: I did nothing about group, only root perms ;) Keep the group ;) Ah okay that is the difference. But is this really necessary because this way sounds like i have to know things what i never wants to know.-) See you, Attila
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
2010/1/27 Gaurish Sharma cont...@gaurishsharma.com please respond purely on technical basis. 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. The problem is that there is no legal stuff from lawers. I've seen two times people asking why cdrtools whole thing can't be under one single license. source and compiling stuff. This will put away the legal issue. In a far better way than getting paper from a lawers. -- Cordialement, Coues Ludovic 06 148 743 42 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Aaron Griffin aaronmgrif...@gmail.com wrote: On Tue, Jan 26, 2010 at 12:12 PM, Kitty seca...@gmail.com 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? The attacks from the hostile downstream packager started in May 2004. The buggy and unmaintained fork was created in September 2006. We now have the end of January 2010. I would not claim that things happened overnight BTW: when the fork was created, I was in hope that people would understand that it is a dead fake at the very latest within the following year. It is really amazing how much pain some users are willing to last. Do you like to run a Linux from September 2004 today? People who still use cdrkit do something very similar except that cdrkit added bugs to the old cdrtools version. Arch Linux is of course free not to decide to publish recent software. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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. 2010/1/27 Allan McRae al...@archlinux.org: 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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Am 27.01.2010 10:31, schrieb Allan McRae: 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. 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. +1 from me to dump cdrkit and to move back to cdrtools. The only reason this discussion ever started is because someone THOUGHT that this MIGHT become a problem, but wasn't even sure about it. As Jörg pointed out, it was never proven that the GPL and CDDL are incompatible in that way, some people just SUSPECTED it MIGHT be that way. Do you see how many maybes are in there? This is the typical Debian license paranoia, which Arch has never had, and hopefully won't get it anytime soon. signature.asc Description: OpenPGP digital signature
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Allan McRae al...@archlinux.org 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Johann Peter Dirichlet peterdirichlet.freesoftw...@gmail.com 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Thomas Bächler tho...@archlinux.org 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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. If the only reason to put it out of [community] repo is just a matter of FUD, then the only logical decision to take is to throw away the broken software. Arch shouldn't get carried by this type of rumours from no way.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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... Allan
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
2010/1/27 Allan McRae al...@archlinux.org: 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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Allan McRae al...@archlinux.org 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On 27/01/10 22:40, Joerg Schilling wrote: Allan McRaeal...@archlinux.org 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. 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. Hence the caution and continuously asking for you to provide some evidence that the often mentioned legal review actually says that it is fine to distribute cdrtools. Allan
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Am Mittwoch, 27. Januar 2010 13:40:08 schrieb Joerg Schilling: Allan McRae al...@archlinux.org 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 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. 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. In this case we only have a very theoretical problem which might be interesting for lawyers but has no real impact. Even if the licenses are not compatible there wont be any real consequences. However, I am still with Allan here. All this situation was initially caused by Jörg himself and talking about a proof but not actually providing it does not help. PS: I wonder if this discussion will come to a conclusion before optical discs are obsolete. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Wed, Jan 27, 2010 at 4:58 PM, Thomas Bächler tho...@archlinux.org wrote: 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. 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 ?
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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 - the pro-cdrtools guy states that the lawyers are wrong, backed by other statements from other lawyers So we're in a deadlock here. One says that CDDL+GPL in one package is illegal, the other states that statement is wrong, but no evidence of that is given. Without proof that it's legal to distribute a binary with impossible license combination, I prefer to keep cdrkit in extra until this has been cleared up with evidence. As for cdrkit being broken: it burns my cds fine, same for a lot of other users. People wishing to use cdrecord are free to do so.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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 benist...@gmail.com wrote: On Wed, Jan 27, 2010 at 4:58 PM, Thomas Bächler tho...@archlinux.org 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 ?
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Johann Peter Dirichlet peterdirichlet.freesoftw...@gmail.com 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Allan McRae al...@archlinux.org wrote: On 27/01/10 22:40, Joerg Schilling wrote: Allan McRaeal...@archlinux.org 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Pierre Schmitz pie...@archlinux.de 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On 28/01/10 00:12, Joerg Schilling wrote: Allan McRaeal...@archlinux.org wrote: On 27/01/10 22:40, Joerg Schilling wrote: Allan McRaeal...@archlinux.org 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. 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. 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? No, because the only reference I can see to cdrkit being an illegal fork is in comments made by you. In my searching, I could not find an actual reason given why you think that is the case. That is extreme FUD. FUD from a single source I can ignore. FUD debated by multiple sources might actually have a basis... And this has been debated in multiple places. That is the concern here. Allan
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Jan de Groot j...@jgc.homeip.net 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Allan McRae al...@archlinux.org 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Jan de Groot j...@jgc.homeip.net 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Thomas Jost thomas.j...@gmail.com 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 -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Allan McRae al...@archlinux.org 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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Le 27/01/2010 15:56, Joerg Schilling a écrit : Thomas Jost thomas.j...@gmail.com 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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Thomas Jost thomas.j...@gmail.com wrote: 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. Well Bloch was the first who claimed that there is a problem with the original software. If _you_ claim that there is a problem with the original software, _you_ need to prove this _first_. If we like to advance, _you_ need to follow common legal rules and do not base your behavior on FUD as it just has been shown by e.g. Allan McRae who completely ignores common rules and who just confirmed that he did not even read the GPL. BTW: I did of course prove my claims: http://cdrecord.berlios.de/private/linux-dist.html just read http://www.gesetze-im-internet.de/urhg/index.html I am really sorry to see that you we are running in circles because some people do not like to follow common rules for their decisions. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Wow, this thread got very hot very fast. I composed this about an hour ago, when things were much cooler. But the questions still seem worth raising. I understand Joerg's frustration about the burden of proof issue here, and I also understand Allan's and Phrakture's reluctance, in the light of our not having more solid evidence from disinterested parties. Apparently Joerg has seen more such evidence, but is not in a position to provide it. That's unfortunate, but understandable. People are getting alternately enthusiastic, and frustrated, and annoyed with each other, but that seems to be about where this stands. Aren't there two questions here, though? 1. Should we distribute binaries of cdrtools? 2. Should we distribute binaries of cdrkit? Setting 1 aside for the moment, it sounds to me---not based wholly on this thread, but this thread exhausts my recent reading on the issue---like there are possible legal issues with 2, and in fact it sounds to me like the case for that is rather stronger than the case for there being legal issues with 1. That impression survives even if the case against cdrkit does all trace back to claims made by Joerg---which I don't know to be so but which has been alleged here. There are technical reasons for thinking cdrtools is much preferable to cdrkit; however that leaves it open whether cdrkit is or isn't good enough for the needs that prompt us to distribute a binary of either of these packages. As I said I do understand the reasons given for hesitating about cdrtools. But it sounds to me like cdrkit survives equally careful scrutiny less well. So why isn't the decision tree: be most cautious legally, and distribute neither be moderately cautious legally, in which case although it's not obvious cdrtools is in the clear, the case against cdrkit seems stronger, so if one is to be distributed it should be cdrtools trust other distros, and decide we're clear to distribute either, in which case the technical merits again speak for cdrtools. -- Jim Pryor j...@jimpryor.net
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Am Thu, 28 Jan 2010 00:43:27 +1000 schrieb Allan McRae al...@archlinux.org: 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. ... No, because the only reference I can see to cdrkit being an illegal fork is in comments made by you. In my searching, I could not find an actual reason given why you think that is the case. That is extreme FUD. FUD from a single source I can ignore. FUD debated by multiple sources might actually have a basis... And this has been debated in multiple places. That is the concern here. Ok, people, can you, please, stop this stupid flame war? It's really boring, annoying and really stupid! Sorry to say that. Allan, what do you have against Jörg? Jörg, some of your comments are also not quite productive. This doesn't seem to be a legal issue but a pure personal one. 1. Both is free and opensource software so this shouldn't matter. Read what Robert Howard has written in this thread. 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. 3. Both programs are released in the same package cdrtools. So why should there be a legal issue? 4. In the package ftp://ftp.berlios.de/pub/cdrecord/cdrtools-2.01.tar.gz I can't find anything about the CDDL. I can only find the GPLv2 and a file with some - sorry Jörg - childish (the comment about the config path) or unnecessary (the comment about the copyright) restrictions of the GPL. So where is the legal licensing issue? What is technically better from an objective point of view, cdrtools or cdrkit? If cdrkit is better then keep cdrkit. If cdrtools is better then dump cdrkit and move cdrtools to [extra]. If someone thinks he needs to sue you then you still can revert to cdrkit. But, please, stop this pointless (personal) flame war! Greetings, Heiko
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Am Wed, 27 Jan 2010 10:17:01 -0500 schrieb pyther pyt...@pyther.net: 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
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Am Wed, 27 Jan 2010 20:15:14 +0700 schrieb Emmanuel Benisty benist...@gmail.com: 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 ? Jörg already did this in this thread. Greetings, Heiko
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Wed, Jan 27, 2010 at 8:48 AM, Jan de Groot j...@jgc.homeip.net 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.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On 01/25/2010 02:46 PM, Gerardo Exequiel Pozzi wrote: Hello, My question is: this is relevant in Arch Linux? I guess that in general there are no strong rules about license issues under Arch Linux. I remember well, that some time ago, I asked some things about some packages readline (GPL) and BSD license. One comment, if I remember correctly, is that strictly speaking there would be problems between OpenSSL and software that makes use of it. Finally the conclusion was something like: Why discuss this? Everything is free software!. So: Why is the opposition? Why comply with details in this particular case and in all other not? All is free software at all! PS: If there's one thing I love about Arch Linux is that it does not care about this great parody/paradox about licensing. Good day \forall The discussion continued in other branches and I quote my message that was ignored. I'd like to read the answers to these questions if they were so kind. So I think that discussions about compatibility of licenses are meaningless. Leaving aside what really matters is functionality. Thank you. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
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.
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
On Wed, Jan 27, 2010 at 04:39:13PM +0100, Heiko Baums wrote: 4. In the package ftp://ftp.berlios.de/pub/cdrecord/cdrtools-2.01.tar.gz I can't find anything about the CDDL. I can only find the GPLv2 and a file with some - sorry Jörg - childish (the comment about the config path) or unnecessary (the comment about the copyright) restrictions of the GPL. cdrtools-2.01 is from 2004. You'll want to look at something more recent: ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a73.tar.gz -- Byron Clark
Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
- the anti-cdrtools people state that CDDL and GPL are incompatible, some have lawyers who back that statement - the pro-cdrtools guy states that the lawyers are wrong, backed by other statements from other lawyers Hmm...lawyers, self-serving bunch if you ask me ;) But seriously, this whole thread ist ridiculous. Tom
