Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit
Heiko Baums wrote:
I don't know anything about the technical differences between cdrkit and cdrtools but http://cdrkit.org says: News 2009/10/11 Cdrkit 1.1.10 has been released.
So the last stable release was not a year but only three months ago. This looks like an active development for me.
Please have a closer look on _what_ was changed in this "release". This have been mainly single char typo corrections but the > 100 well known bugs that exist as long as the fork exists have never been fixed. On the original software, you see more changes (enhancements and fixes) in a lazy week than the "cdrkit project" did get since May 6th 2007 in total. In the fork, problems are ignored. In the original software, problems are fixed very soon; typically within hours. This is why there are no known problems in the original software. The fork did not publish a single version that was known to be without bugs at the time of publishing. The original cdrtools project did publish more than 70 releases in the same time and more than 60 of them did have not a single bug when they have been published. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Mon 25 Jan 2010 16:28 +0100, Joerg Schilling wrote:
Heiko Baums wrote:
I don't know anything about the technical differences between cdrkit and cdrtools but http://cdrkit.org says: News 2009/10/11 Cdrkit 1.1.10 has been released.
So the last stable release was not a year but only three months ago. This looks like an active development for me.
Please have a closer look on _what_ was changed in this "release". This have been mainly single char typo corrections but the > 100 well known bugs that exist as long as the fork exists have never been fixed.
On the original software, you see more changes (enhancements and fixes) in a lazy week than the "cdrkit project" did get since May 6th 2007 in total.
In the fork, problems are ignored. In the original software, problems are fixed very soon; typically within hours. This is why there are no known problems in the original software.
The fork did not publish a single version that was known to be without bugs at the time of publishing. The original cdrtools project did publish more than 70 releases in the same time and more than 60 of them did have not a single bug when they have been published.
Maintainers of packages in Arch Linux may decide to package any software whether it's a fork of an existing package or not. If there are outstanding licensing or legal issues they may decide to avoid that particular software. The issue isn't really about bugs vs. no bugs. So let's stay on topic. It's more about licenses and the legal ramifications that may come with improper usage. I think Arch followed Debian because they seem to know a lot more than we do. On the other hand, maybe we should be using debs rather than .pkg.tar.gz if that's the case. (hah) It is important to respect the caution that the devs are taking. Personally, if it was my decision, I'd encourage any Arch dev or TU who is interested in maintaining cdrtools to go ahead with it. I don't have the same faith in Debian that a lot of others might. Anyways, this package could easily be made available in an unofficial repository until everyone is comfortable with the licensing. Don't rely on the devs to do everything for you.
Loui Chang <louipc.ist@gmail.com> wrote:
If there are outstanding licensing or legal issues they may decide to avoid that particular software.
This would be a reason to avoid cdrkit. Cdrkit is in a clear conflict with the Copyright law and I as the owner of the rights on the software did already inform the creators of this fork that I may sue them in case that they continue to ignore the law.
The issue isn't really about bugs vs. no bugs. So let's stay on topic. It's more about licenses and the legal ramifications that may come with improper usage. I think Arch followed Debian because they seem to know a lot more than we do. On the other hand, maybe we should be using debs rather than .pkg.tar.gz if that's the case. (hah)
This is a social issue. A hostile Debian packager did spread untrue claims on a OSS project and Debian (and others) have become a victim of these claims. If Debian really would know a lot about licensing, they did not believe the claims of the hostile packager. All decent legal systems require people who claim that others are in conflict wit the law or in conflict with contracts (like the GPL) to prove their claims. It is not the attacked people who need to defend against unsubstancial claims. Now It would be intersting why parts of the OSS community did leave the base of every decent legal system, believe in unsubstancial attacks from a hostile person and ask me to defend.... This is a serious attack against the ethics in OSS and we need to find a way to deal with similar attacks in future. As long as things like the attack against cdrtools may be successful, the OSS eco system is not yet stable enough to withstand attacks from outside.
It is important to respect the caution that the devs are taking. Personally, if it was my decision, I'd encourage any Arch dev or TU who is interested in maintaining cdrtools to go ahead with it. I don't have the same faith in Debian that a lot of others might.
Anyways, this package could easily be made available in an unofficial repository until everyone is comfortable with the licensing. Don't rely on the devs to do everything for you.
From my understanding, what Arch Linux does is a matter of how Arch Linux likes to deal with it's users. If Arch Linux does not care about the users, nbothing needs to change. In the other case, a change seems to be important in order to get rid of the bugs in the fork.
I can just point to the fact that the original software has no known bugs and that bugs in the original software are typically fixed within a few hours. Becoming a packet maintainer for cdrtools thus takes a lot less effort than doing the same for "cdrkit". Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
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. -- Kitty
On Tue, Jan 26, 2010 at 12:12 PM, Kitty <secacat@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?
Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Tue, Jan 26, 2010 at 12:12 PM, Kitty <secacat@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
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
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 <allan@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
Johann Peter Dirichlet <peterdirichlet.freesoftware@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
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 "maybe"s are in there? This is the typical Debian license paranoia, which Arch has never had, and hopefully won't get it anytime soon.
Thomas Bächler <thomas@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
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.
Johann Peter Dirichlet <peterdirichlet.freesoftware@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Jan 27, 2010 at 4:58 PM, Thomas Bächler <thomas@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 ?
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" <benisty.e@gmail.com> wrote: On Wed, Jan 27, 2010 at 4:58 PM, Thomas Bächler <thomas@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 ?
Am Wed, 27 Jan 2010 20:15:14 +0700 schrieb Emmanuel Benisty <benisty.e@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
Allan McRae <allan@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 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
2010/1/27 Allan McRae <allan@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
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.
Jan de Groot <jan@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Wed, 2010-01-27 at 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.
Jan de Groot <jan@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Jan 27, 2010 at 8:48 AM, Jan de Groot <jan@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.
On Wed, Jan 27, 2010 at 10:51 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Jan 27, 2010 at 8:48 AM, Jan de Groot <jan@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.
What I'm seeing here is that Jörg is being his usual self, combative but mostly correct. Allan is pissed off at him. Aaron is cautious and heading towards angry. A couple of other people are a little bit cautious. The rest of the participants, which is most of them, are in favor of switching back from cdrkit to cdrtools. Let me also add my support for putting cdrtools into [extra] (probably [community] is not good enough as I think there are deps in [extra] on cdrkit right now.
On Wed, Jan 27, 2010 at 4:51 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Jan 27, 2010 at 8:48 AM, Jan de Groot <jan@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.
Well I thought about that too, and I believe there is one huge difference : tuomov explicitly imposed a lot of restrictions in packaging, and apparently didn't want or didn't care at all if Arch packaged it or not. If it is packaged, it has to be under his terms. If it isn't, who cares. His interest seemed to not have it packaged, as he believes that would mean less problems and less bug reports for him. Joerg on the other hand seems to care a lot about the inclusion of his software in the official Arch repository. Actually, I really wonder like pyther : "What is in this for him?". The software is already in AUR, which every Arch users know and use. According to him, wodim is completely broken, so surely the majority of Arch users either notice it themselves or are told by other people, and will switch to AUR cdrecord. Even if that's not the case (2 possibilities : wodim is not as broken as Joerg pretends, or arch users are clueless), is Arch really noticeable compared to the big distrib ? I am curious to know if anyone has pointers to estimates of linux distribution userbase, but I doubt Arch would matter. And seriously, if the goal is world domination, making Debian/Ubuntu an enemy is a very efficient way for failing.
2010/1/27 Xavier Chantry <chantry.xavier@gmail.com>:
On Wed, Jan 27, 2010 at 4:51 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Jan 27, 2010 at 8:48 AM, Jan de Groot <jan@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.
Well I thought about that too, and I believe there is one huge difference : tuomov explicitly imposed a lot of restrictions in packaging, and apparently didn't want or didn't care at all if Arch packaged it or not. If it is packaged, it has to be under his terms. If it isn't, who cares. His interest seemed to not have it packaged, as he believes that would mean less problems and less bug reports for him.
Sorry about the dumb question, but can you post a link for the tuomov restrictions? This is about cdrtools or cdrkit?
Joerg on the other hand seems to care a lot about the inclusion of his software in the official Arch repository. Actually, I really wonder like pyther : "What is in this for him?". The software is already in AUR, which every Arch users know and use. According to him, wodim is completely broken, so surely the majority of Arch users either notice it themselves or are told by other people, and will switch to AUR cdrecord.
This is about mainstream maintaining. Why the buggy software is actively maintained, precompiled with binaries for i686 and x86_64, and the good software is tagged as "unmaintained"?
Even if that's not the case (2 possibilities : wodim is not as broken as Joerg pretends, or arch users are clueless), is Arch really noticeable compared to the big distrib ?
Well, Archlinux is a good distro with a very active crew, and it is a growing distro indeed. And now the maintainer of a big and famous piece of software is actively endorsing your software in that list! I think Archlinux is a noticeable distro indeed.
I am curious to know if anyone has pointers to estimates of linux distribution userbase, but I doubt Arch would matter.
And seriously, if the goal is world domination, making Debian/Ubuntu an enemy is a very efficient way for failing.
Xavier Chantry <chantry.xavier@gmail.com> wrote:
Joerg on the other hand seems to care a lot about the inclusion of his software in the official Arch repository. Actually, I really wonder like pyther : "What is in this for him?". The software is already in AUR, which every Arch users know and use. According to him, wodim is completely broken, so surely the majority of Arch users either notice it themselves or are told by other people, and will switch to AUR cdrecord. Even if that's not the case (2 possibilities : wodim is not as broken as Joerg pretends, or arch users are clueless), is Arch really
If you believe the fork is not broken, then you don't seem to use it. wodim does not deal with hald and has many other problems including missing DVD support. genisoimage does not support UTF-8 and large files and creates filesystem images with lots of bugs. If you don't notice, well.... Wait until you like to read the filesystem from a OS that does nto tolerate the bugs from genisoimage ;-) Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 01/27/2010 11:19 AM, Xavier Chantry wrote:
Joerg on the other hand seems to care a lot about the inclusion of his software in the official Arch repository. Actually, I really wonder like pyther : "What is in this for him?". The software is already in AUR, which every Arch users know and use. According to him, wodim is completely broken, so surely the majority of Arch users either notice it themselves or are told by other people, and will switch to AUR cdrecord.
Perhaps he's annoyed because he wrote a big important piece of software and everyone refuses to use it because of BS claims that he's going to sue them. Wouldn't it make you angry if you went to the trouble to write something like this and everyone ditched it over claims by someone who just wants to make their shitty fork popular? Or maybe he doesn't like making things a huge pain in the ass for his users. Installing cdrtools from the AUR isn't exactly obvious or easy. Even if you do learn about this (like I did from this thread), yaourt -S cdrtools doesn't work (it automatically installs cdrkit instead). -Brendan Long
On Wed, Jan 27, 2010 at 2:30 PM, Brendan Long <korin43@gmail.com> wrote:
On 01/27/2010 11:19 AM, Xavier Chantry wrote:
Joerg on the other hand seems to care a lot about the inclusion of his software in the official Arch repository. Actually, I really wonder like pyther : "What is in this for him?". The software is already in AUR, which every Arch users know and use. According to him, wodim is completely broken, so surely the majority of Arch users either notice it themselves or are told by other people, and will switch to AUR cdrecord.
Perhaps he's annoyed because he wrote a big important piece of software and everyone refuses to use it because of BS claims that he's going to sue them. Wouldn't it make you angry if you went to the trouble to write something like this and everyone ditched it over claims by someone who just wants to make their shitty fork popular?
Not to sound trite, but if I was in this situation, I would attempt to provide as much factual evidence as possible, rather than call people names, rant a lot, and never provide anything more than hearsay. Science: it works, bitches
Perhaps he's annoyed because he wrote a big important piece of software and everyone refuses to use it because of BS claims that he's going to sue them. Wouldn't it make you angry if you went to the trouble to write something like this and everyone ditched it over claims by someone who just wants to make their shitty fork popular?
Not to sound trite, but if I was in this situation, I would attempt to provide as much factual evidence as possible, rather than call people names, rant a lot, and never provide anything more than hearsay. Science: it works, bitches
I've read a lot of threads where Jörg is always the same. Jörg, please, please, please ... I trust you that your software is supperior but try to be less insulting to other people. I'm sure you don't see your attitude as difficult, but it is (we can never see our own failings). There was a very simple suggestion some message ago, why not dual-license the CDDL parts of cdrtools and be done with any and all the FUD (from any side), all the anomisity, and trolling. please... how is that harder than taking part in 1000 fruitless dicussions on the internet? -- damjan
On Wed, Jan 27, 2010 at 8:05 PM, Damjan Georgievski <gdamjan@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? -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Wed, Jan 27, 2010 at 8:05 PM, Damjan Georgievski <gdamjan@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
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
Damjan Georgievski <gdamjan@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
- 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
Allan McRae <allan@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 27/01/10 22:40, Joerg Schilling wrote:
Allan McRae<allan@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
Allan McRae <allan@archlinux.org> wrote:
On 27/01/10 22:40, Joerg Schilling wrote:
Allan McRae<allan@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 28/01/10 00:12, Joerg Schilling wrote:
Allan McRae<allan@archlinux.org> wrote:
On 27/01/10 22:40, Joerg Schilling wrote:
Allan McRae<allan@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
Allan McRae <allan@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Am Thu, 28 Jan 2010 00:43:27 +1000 schrieb Allan McRae <allan@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
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.
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
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
Thomas Jost <thomas.jost@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Le 27/01/2010 15:56, Joerg Schilling a écrit :
Thomas Jost <thomas.jost@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
Thomas Jost <thomas.jost@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 01/27/2010 08:00 AM, Thomas Jost wrote:
Le 27/01/2010 15:56, Joerg Schilling a écrit :
Thomas Jost<thomas.jost@gmail.com> wrote:
[snip] Well, someone in this list just told me that the rules for Arch Linux are that someone from Cdrkit would need to prove that there is no legal problem with cdrkit.
Could we agree on a unique method for dealing with claims please?
Jörg
You said earlier that "_you_ would first need to prove that there is a legal problem with the original software".
You are telling cdrkit is illegal.
Follow your own rule. Prove cdrkit to be illegal.
If you can't, there's no point in continuing this discussion.
Wait so if someone says that cdrtools is illegal, he has to prove that it's not, but if someone says that cdrkit is illegal, he has to prove that it is? Will you be my lawyer?
Am Mittwoch, 27. Januar 2010 13:40:08 schrieb Joerg Schilling:
Allan McRae <allan@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
Pierre Schmitz <pierre@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 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
Allan McRae <allan@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
At Mittwoch, 27. Januar 2010 12:51 Allan McRae wrote:
Please provide a report from a single laywer showing that there is not. This has been repeatedly asked of you
I'm with you because it would be very nice to have this report but because in life all have two sides in the most cases i have to ask you for the same: Where is the report from a single laywer which supports the arguments of debian? Sorry ,if i makes you angry because this is NOT my intention. But what i really miss during this most useless discussion about a software for linux is that no one of both sides hire a laywer and see what happens in reality inf front of a court instead of voting. This would be better for everybody of us than this kind of confrontation. See you, Attila
Attila <vodoo0904@sonnenkinder.org> wrote:
Sorry ,if i makes you angry because this is NOT my intention. But what i really miss during this most useless discussion about a software for linux is that no one of both sides hire a laywer and see what happens in reality inf front of a court instead of voting. This would be better for everybody of us than this kind of confrontation.
I am in contact with several lawyers but if you don't pay a lawyer, you get help but not the permission to publish the statements. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
At Mittwoch, 27. Januar 2010 20:59 Joerg Schilling wrote:
I am in contact with several lawyers but if you don't pay a lawyer, you get help but not the permission to publish the statements.
Good luck for it and i hope this story could find his end. And i want to take the opportunity to thank you for cdrtools which i use now under linux and in the past under OS/2. See you, Attila
It started off with a simple cautious question: evidence, please? So then, the cdrtools guy says..well, he ignores the evidence part and says something else, says it doesn't matter because you must first prove to him that he needs to show you evidence. So then, it's recursive. But then, he only wants us all to kick cdrkit and the Debian guys in their arses, probably because they spoiled it all. When you adopt something, then you disown it, and then someone tells you to adopt it again, you would definitely want to know why. You grow more and more uneasy if the answer isn't coming as simple and simply as it is claimed to be.
At Mittwoch, 27. Januar 2010 22:47 Ray Rashif wrote:
It started off with a simple cautious question: evidence, please? ...
Was it right that you answer to my comment? For me the story is over and i wish Joerg the best to get statements from a laywer which he can publish. One of the biggest advantage of archlinux is that you can easy create your own package and therefore i'm not interested for statements like "the archdevs have to do this and this". It would be very nice if cdrtools comes back but this is not my decision and this thread shows that it seems not easy to decide. Until than i do the same as everyone and use my personal favorite. See you, Attila
Hi, Leaving all the licenses and legal issues aside, Q) Which is better out of the two? please respond purely on technical basis. Regards, Gaurish Sharma www.gaurishsharma.com
Gaurish Sharma <contact@gaurishsharma.com> wrote:
Hi, Leaving all the licenses and legal issues aside,
Q) Which is better out of the two?
please respond purely on technical basis.
Everything has been said, you just need to read it. Users demand working software and thus request cdrtools. It is up to the distros to follow the demands of their users or to ignore it. BTW: I have been asked by people from Arch Linux to help with this discussion. I was not prepared that one or two people act extremely stubborn and that I do not get help from the marority that seems to prefer the original software. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Hi, Atleast, you have my vote, I building cdrtools from AUR as we speak. there is no point of using unmaintned software. Anyone, How can we setup cdrtools to completely replace cdrkit so that other programs like k3b can use seamlessly ? Any guides, I didn't find anything on ArchLinux Wiki which is kinda strange. One more thing cdrtools required it to be run as root, isn't that dangerous. any method by which we give the required permissions to normal user? Regards, Gaurish Sharma www.gaurishsharma.com On Thu, Jan 28, 2010 at 4:29 AM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
Gaurish Sharma <contact@gaurishsharma.com> wrote:
Hi, Leaving all the licenses and legal issues aside,
Q) Which is better out of the two?
please respond purely on technical basis.
Everything has been said, you just need to read it.
Users demand working software and thus request cdrtools.
It is up to the distros to follow the demands of their users or to ignore it.
BTW: I have been asked by people from Arch Linux to help with this discussion. I was not prepared that one or two people act extremely stubborn and that I do not get help from the marority that seems to prefer the original software.
Jörg
-- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Gaurish Sharma <contact@gaurishsharma.com> wrote:
One more thing cdrtools required it to be run as root, isn't that dangerous. any method by which we give the required permissions to normal user?
There are two possible solutions: 1) Look at the turkish Linux distro that delivers a complete uncastrated Linux, create a linux distro that includes the needed features (make sure that these features cannot be unconfigured) and send me a version so I can start implementing support for fine grained privileges on Linux into cdrtools. 2) Continue to deliver a reduced Linux that does not give you the choice for a different solution and live with the consequences that force you to install cdrecord/readcd/cdda2wav suid root in order to gain the needed privileges. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Pressing for legal info may be the natural reflex, but associated subjects are best dealt with caution. Maybe he's not in a position were he can divulge this, and is now eating the words he said when publishing details would've been unproblematic. You're getting a first hand response that it's ok to use it. Andres
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
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). 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
2010/1/27 Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>:
Gaurish Sharma <contact@gaurishsharma.com> wrote:
One more thing cdrtools required it to be run as root, isn't that dangerous. any method by which we give the required permissions to normal user?
There are two possible solutions:
1) Look at the turkish Linux distro that delivers a complete uncastrated Linux, create a linux distro that includes the needed features (make sure that these features cannot be unconfigured) and send me a version so I can start implementing support for fine grained privileges on Linux into cdrtools.
2) Continue to deliver a reduced Linux that does not give you the choice for a different solution and live with the consequences that force you to install cdrecord/readcd/cdda2wav suid root in order to gain the needed privileges.
It is a Linux kernel issue (make menuconfig)? Or just a "install this package in order to fine control cdrtools privileges"?
Jörg
-- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Johann Peter Dirichlet <peterdirichlet.freesoftware@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
At Donnerstag, 28. Januar 2010 00:14 Gaurish Sharma wrote:
Anyone, How can we setup cdrtools to completely replace cdrkit so that other programs like k3b can use seamlessly ? Any guides, I didn't find anything on ArchLinux Wiki which is kinda strange.
The hard way only for your system: pkgname=cdrecord _pkgname=cdrtools ... conflicts=('cdrkit' 'cdrtools') provides=('cdrkit') ... I have no cdrkit here because i don't need it and i don't need the sysmlinks inside of the package.
One more thing cdrtools required it to be run as root, isn't that dangerous. any method by which we give the required permissions to normal user?
I change the permissions in the install file in this way: /bin/echo "Change Owner, Group and Permission to root.optical (4710) ..." for n in /usr/bin/cdrecord \ /usr/bin/readcd \ /usr/bin/cdda2wav; do /bin/chown -v root:optical $n && /bin/chmod -v 4710 $n; done /bin/echo "done. Than the user has only to be in the group optical. It works but perhaps a expert should say if this is okay. See you, Attila
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 ;) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Gerardo Exequiel Pozzi <vmlinuz386@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_privaddr Allow ports < 1024, needed for RSCSI Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
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_privaddr Allow ports < 1024, needed for RSCSI cap_net_bind_service
Is it really such a problem to stay with "chmod 4710"? See you, Attila
Attila <vodoo0904@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_privaddr Allow ports < 1024, needed for RSCSI cap_net_bind_service
Looks correct.
Is it really such a problem to stay with "chmod 4710"?
As long as there is no support code in Linux distros to set capabilities without making the target program suid root anyway, I see no other possibility than to stay with chown root cdrecord cdda2wav readcd chmod 4711 cdrecord cdda2wav readcd Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Fri, Jan 29, 2010 at 8:39 AM, Joerg Schilling <Joerg.Schilling@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.
Paulo Matias <matias@archlinux-br.org> wrote:
On Fri, Jan 29, 2010 at 8:39 AM, Joerg Schilling <Joerg.Schilling@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 -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Am Freitag, 29. Januar 2010 11:58:12 schrieb Joerg Schilling:
Paulo Matias <matias@archlinux-br.org> wrote:
On Fri, Jan 29, 2010 at 8:39 AM, Joerg Schilling
<Joerg.Schilling@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
Pierre Schmitz <pierre@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
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.
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
Pierre Schmitz <pierre@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) wrote:
This might be related: http://code.google.com/p/libarchive/wiki/TarPosix1eACLs
This does just describe what I defined 10 years ago ;-)
I forgot, the complete documentation is here: http://cdrecord.berlios.de/private/man/star/star.4.html Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Le Fri, 29 Jan 2010 17:58:42 +0100, Jan de Groot <jan@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
Le Fri, 29 Jan 2010 17:36:58 +0000, Pierre Chapuis <catwell@archlinux.us> a écrit :
Le Fri, 29 Jan 2010 17:58:42 +0100, Jan de Groot <jan@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
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/
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
Nice informations, thanks. 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
On Fri, Jan 29, 2010 at 2:10 PM, Pierre Schmitz <pierre@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/
In general this should work fine. The only problem is that bsdtar did not support storing those information (don't know if future versions support this) so one has to use install scripts to adjust the permissions after install.
When I looked into that a few months ago, it stored just fine when creating the archive. But it did not restore them when extracting. This got fixed in trunk, so it will probably be in the next major release (2.8 ?). http://code.google.com/p/libarchive/source/detail?r=1590# xps-m1530:~> bsdtar --version bsdtar 2.7.902a - libarchive 2.7.902a 2.7 release does not work, at least on my system. The development version is required. xps-m1530:~> setcap cap_net_raw=ep ./ping unable to set CAP_SETFCAP effective capability: Operation not permitted xps-m1530:~> sudo setcap cap_net_raw=ep ./ping xps-m1530:~> getcap ping ping = cap_net_raw+ep setcap needs root. xps-m1530:~> bsdtar cvf ping.tar.gz ping a ping compress normally. xps-m1530:~> bsdtar xvf ping.tar.gz -C /tmp x ping xps-m1530:~> bsdtar xvf ping.tar.gz -C /tmp x ping xps-m1530:~> getcap /tmp/ping By default, it is not restored. "p" is needed. xps-m1530:~> bsdtar xvpf ping.tar.gz -C /tmp x ping: Failed to set extended attribute bsdtar: Error exit delayed from previous errors. xps-m1530:~> sudo bsdtar xvpf ping.tar.gz -C /tmp x ping xps-m1530:~> getcap /tmp/ping /tmp/ping = cap_net_raw+ep root is of course still needed again for setcap, and it works !
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
At Freitag, 29. Januar 2010 11:39 Joerg Schilling wrote: Thanks for your nice informations and with this line for setcap cap_dac_override,cap_sys_rawio,cap_ipc_lock,cap_sys_nice,cap_net_bind_service+ep a "cdrecord --scanbus" works as normal user without a problem.
As long as there is no support code in Linux distros to set capabilities without making the target program suid root anyway, I see no other possibility than to stay with
chown root cdrecord cdda2wav readcd chmod 4711 cdrecord cdda2wav readcd
This is definitive easier and there is no risk if something will changes for capabilities. There is only one thing which i find better and it is that i prefer "chmod 4710" with a special group to not allow everyone to run cdrecord. Okay, i'm not an expert but this looks safe enough for me ... provide that i have to look every time at the manpage of capabilities.-) See you, Attila
Attila <vodoo0904@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
At 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
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
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
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
Attila <vodoo0904@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 28 January 2010 00:14, Gaurish Sharma <contact@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
Gaurish Sharma wrote:
Hi, Leaving all the licenses and legal issues aside,
Q) Which is better out of the two?
please respond purely on technical basis.
A) cdrtools, period. Especially if you try to burn DVDs with long, non- ascii (read 'utf8') filenames, labels and other "weird" stuff. I had lost quite a few DVDs in the past before I remembered that it was cdrkit the burner and not cdrtools. But, the developer of cdrtools... that's another story. In this thread alone, he's been asked at least twice why he doesn't dual-license cdrtools and he conveniently ignored it. Herr Schilling, why don't you dual-license (or, best, single-license to GPL) cdrtools? -- X.
Christos Nouskas <nous@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 01/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
2010/1/27 Gaurish Sharma <contact@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
ludovic coues <couesl@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) wrote:
ludovic coues <couesl@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:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 01/27/2010 04:31 AM, Allan McRae wrote:
Joerg,
The only thing that will definitely change our minds with regards to this is actually seeing a copy of the report saying the linking performed with cdrtools is not an issue due to license restrictions. Until that time, this discussion is going nowhere and makes you appear trollish with your replies.
Maybe we will move to GNU mkisofs/isofsmk as development appears to have started there (I can troll too...).
Allan Joerg,
What is in this for you? By that, I mean, why are you fighting so hard to get this pushed into the official repos? It is in aur with 130 votes and likely there are hundreds more users. http://aur.archlinux.org/packages.php?ID=323 There is one thing with Arch that I think you are missing. The arch devs do what they want. They include software only that they use/want to maintain. In the past they have included software in which licensing wasn't quite clear. As it has been stated many times none of the devs are lawyers. These software programs were a much lower risk to include compared to cdrtools. Said programs did not have the arguments and possible legal issues that cdrtools is currently faced with. Granted if a suite was to be brought against arch, specifically the dev hosting it and the owner of the project (Aaron), they would likely be asked to remove it. I find this risk relatively low and I'd give +1 to add it to the repos (from a users prospective). Look at the high-profile case of cdrtools vs cdrkit, though; it is huge. You stated that sun spent 3 months looking into it. If for some odd reason someone decide to sue the arch project there is a big risk for Aaron and the maintainer of the package. At the very least they would likely have to consult a lawyer and possibly show up in court. This becomes a big time commitment and financial burden as the donations from this project are fairly minimal (at least compared to the hiring of a lawyer). Lets face it, everyone on this project is unpaid and has a real life. It seems as if a few of the main devs have decided they don't want to take the "risk." Why don't you create a repo with cdrtools for arch? It isn't hard to do. That way anyone who wants to use cdrtools would have an easy way to obtain updates, etc... pyther
Am Wed, 27 Jan 2010 10:17:01 -0500 schrieb pyther <pyther@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
On 01/27/2010 09:49 AM, Heiko Baums wrote:
Am Wed, 27 Jan 2010 10:17:01 -0500 schrieb pyther <pyther@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
here's a proposal for the future of this discussion: 1) Joerg is no longer allowed to participate in the the discourse unless directly questioned. 2) Allan: ditto. 3) All other participants work toward creating a formal proposal and then debating and resolving reservations about that proposal, each in turn. 4) Aaron, as overlord, set a sunset clause on the discussion period, act as moderator (or delegate if he's sick of this shit), and maintain final approval/veto over the proposal that emerges. Anyone? -kludge
On 01/27/2010 11:18 AM, kludge wrote:
On 01/27/2010 09:49 AM, Heiko Baums wrote:
Am Wed, 27 Jan 2010 10:17:01 -0500 schrieb pyther<pyther@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
here's a proposal for the future of this discussion:
1) Joerg is no longer allowed to participate in the the discourse unless directly questioned.
2) Allan: ditto.
3) All other participants work toward creating a formal proposal and then debating and resolving reservations about that proposal, each in turn.
4) Aaron, as overlord, set a sunset clause on the discussion period, act as moderator (or delegate if he's sick of this shit), and maintain final approval/veto over the proposal that emerges.
Anyone?
-kludge
I disagree. Allan should be able to participate because he is a core developer. However, I think this needs to go to arch-dev-public or maybe better yet arch-dev-private (if this issue isn't already there). From that point the developers can talk among themselves what they want to do as it is their project. Then if they choice they can let use know the results. This isn't a democracy, it is a dictatorship. Luckily the dictators are nice and listen to the community every now and then. ~pyther
By the way, why Joerg ask that Allan do the jobs about legal stuff ? That Joerg that want that cdrkit go to official repo. Not Allan. I'm not right ?
2010/1/27 kludge <drkludge@rat-patrol.org>:
On 01/27/2010 09:49 AM, Heiko Baums wrote:
Am Wed, 27 Jan 2010 10:17:01 -0500 schrieb pyther <pyther@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
here's a proposal for the future of this discussion:
1) Joerg is no longer allowed to participate in the the discourse unless directly questioned.
2) Allan: ditto.
3) All other participants work toward creating a formal proposal and then debating and resolving reservations about that proposal, each in turn.
4) Aaron, as overlord, set a sunset clause on the discussion period, act as moderator (or delegate if he's sick of this shit), and maintain final approval/veto over the proposal that emerges.
Anyone?
-kludge
I agree! :) except the first and second clauses. Just completing my reasoning... In my opinion, the problem is not the fork attitude, but the bad quality of fork. An example: OpenBSD is a fork from NetBSD, it was a history of strong "ego combat" too, but it is a good quality fork, a so good fork that many operating systems (BSDs and Linux, also some others) and even software maintainers look at it as an example of stability and security. That is not the case for cdrkit. It has a lower quality than the original software. In fact, I lost some DVD discs with wodim :( but it is just with me (many people say that cdrkit is buggy, many people say that is good). Shilly is a very energic person, and sometimes it reinforces their own opinions in a little polite way sometimes. It makes this comments sound But, talking outspoken, to hell with this frakkin' licensing way! That is not the problem here. cdrkit is a badly maintained software, cdrtools is far well updated and maintained, and both are free softwares. So, dump or AUR cdrkit, and if some day someone would complain with cdrtools, simply put cdrkit back (or create a fork of it again :D)
Johann Peter Dirichlet <peterdirichlet.freesoftware@gmail.com> wrote:
That is not the case for cdrkit. It has a lower quality than the original software. In fact, I lost some DVD discs with wodim :( but it is just with me (many people say that cdrkit is buggy, many people say that is good).
There is a simple reason for this problem: I added DVD support to cdrecord in February 1998. The original DVD support code is (as you can see) 12 years old and I would call it mature. Wodim dumped the original DVD support code and replaced it by some half baken code written by a guy from Mandriva. This code does not even read the media parameters from the blank media (as you can prove by calling cdrecord -atip vs. wodim -atip). Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On 01/27/2010 09:43 AM, Johann Peter Dirichlet wrote:
cdrkit is a badly maintained software, cdrtools is far well updated and maintained, and both are free softwares. So, dump or AUR cdrkit, and if some day someone would complain with cdrtools, simply put cdrkit back (or create a fork of it again :D)
This seems like the obvious solution. Can anyone explain what the problem with this is? You could always ask the guy who's been maintaining it on the AUR to maintain it in the official repos. -Brendan Long
participants (33)
-
Aaron Griffin
-
Allan McRae
-
Andres Perera
-
Arvid Picciani
-
Attila
-
Brendan Long
-
Byron Clark
-
Christos Nouskas
-
Damjan Georgievski
-
Denis A. Altoé Falqueto
-
Emmanuel Benisty
-
Gaurish Sharma
-
Gerardo Exequiel Pozzi
-
Heiko Baums
-
Jan de Groot
-
Joerg.Schilling＠fokus.fraunhofer.de
-
Johann Peter Dirichlet
-
Kitty
-
kludge
-
Loui Chang
-
ludovic coues
-
Lukáš Jirkovský
-
Paulo Matias
-
Pierre Chapuis
-
Pierre Schmitz
-
pyther
-
Ray Kohler
-
Ray Rashif
-
Robert Howard
-
Thomas Bächler
-
Thomas Jost
-
Tom
-
Xavier Chantry