Burning music CDs
in [UK Linux]
|
From: unruh on 7 Feb 2010 14:47 On 2010-02-07, Paul Martin <pm(a)nowster.org.uk> wrote: > In article <slrnhm8rm1.hd6.unruh(a)wormhole.physics.ubc.ca>, > unruh wrote: > >> Certainly the original copyright owner retains that copyright. >> It is certainly a severe breach of ethics to hide the source of code >> that is being used. Whetehr it is illegal, I could not say, especially >> with the broad modification permission that the GPL gives. > > As long as the copyright is acknowledged (which it is), and the > modified code is distributed under the same licence, the original > copyright holder who released his code under GPLv2 has no recourse to > prevent distribution of the modified code. Once you've released > something under such a licence, you can't un-release it. It is assumed > under law that you understood the meaning of the licence you > voluntarily chose to release your program under. The GPL says essentially nothing about moral rights, basically because the concept is not a part of US law. It is a legal concept in most of the rest of the world. As I said, I do not know if the treatment violates moral rights, but the treatment of the author of the works does, in my opinion violate ethics. He, no matter how obnoxious he sometimes is, is the author of the work that cdrkit uses. The constant attacks on him, while using his work, I find pretty disgusting. A bit of modesty in the face of having received a pretty large gift would not be amiss. Over the past 10 years or so while people have continually badmouthed him while using his work, many other attempts to write cdwritting software have surfaced. And each year it is a different set, as people get tired, and realise that it is a more difficult task than they thought. Meanwhile Schilling keeps plugging on, improving his software, ensuring that it works with new systems. A bit of gratitude rather than snivelling and hiding behind the law and taking cheap potshots would be more becoming. > > "Touch black, no swaps back." >
From: unruh on 7 Feb 2010 14:53 On 2010-02-07, Paul Martin <pm(a)nowster.org.uk> wrote: > In article <slrnhmbepi.jm9.unruh(a)wormhole.physics.ubc.ca>, > unruh wrote: > >> No, you cannot "implicitly accept the terms". The law is not that >> stupid. To be bound you need to explicitly accept terms of a contract. > > Quote GPLv2: > > 5. You are not required to accept this License, since you have not > signed it. However, nothing else grants you permission to modify or > distribute the Program or its derivative works. These actions are > prohibited by law if you do not accept this License. Therefore, by > modifying or distributing the Program (or any work based on the > Program), you indicate your acceptance of this License to do so, and > all its terms and conditions for copying, distributing or modifying > the Program or works based on it. Read the "therefor". It is a non-sequitor, and it can only be used to bind the grantor of the license, not the licensee. The distribution does NOT indicate acceptance. It indicates distribution, which may or may not comply with the terms of the license. If it does not, the grantor of the license can sue. And the distributor can defend, including possibly demonstrating that the license has no force under law. The grantor cannot say "depite the fact that the license has no force under copyright law, the distributor agreed to the license and is thus bound by it under contract law". A copyright law license is not a contract, it is not something that is accepted by both parties, it is imposed by the grantor. > >
From: Nix on 8 Feb 2010 18:47 On 7 Feb 2010, unruh(a)wormhole.physics.ubc.ca outgrape: > On 2010-02-07, Paul Martin <pm(a)nowster.org.uk> wrote: >> And what about releasing something under the GPL? > > No idea what you are talking about. GPL is a license just like any > other. Even if he released it under GPL IT IS STILL HIS. He still owns > the copyright. Uh, he didn't write all of cdrtools, y'know. Eric Youngdale and others have copyright in it too.
From: Nix on 8 Feb 2010 18:53 On 7 Feb 2010, Paul Martin stated: > Nope. I've never needed real time priority to burn a CD on recent > CPUs. > > Burnproof (and similar) works. I know you don't think so, but it does. I can't be sure if it does. Even on an eight-year-old PIII under heavy load from a DoS attack I was *still* able to burn a CD without suffering any buffer underruns. (Maybe if the CD burner on there had been capable of writing at >4x this would not have been true: but machines with faster CD burners probably have faster CPUs and more RAM anyway, so are even *less* likely to need this.) > - CAP_NET_BIND_SERVICE > Bind a socket to Internet domain privileged ports (port numbers > less than 1024). > > What the heck does a CD recording program need that for?! rscsi. I have no idea why anyone would think it sane to burn a CD across the *network* via a remote SCSI protocol that is about as dead as rsh, but cdrtools purportedly supports it. I haven't tested it and would mourn not at all if it died tomorrow: yet this bizarre and almost wholly unused feature is Joerg's stated reason for e.g. not supporting proper device names, because they don't work with rscsi. (Why not support device names for local devices, and SCSI LUNs or whatever for rscsi? I have no idea.) >> As most recent Linux distros do not support features to set these privileges >> without first becomming root, it is still easier to just give root privileges >> to cdrecord. Cdrecord has been audited for being installed suid root. > > Never heard of libpam? Obviously not. I suspect Joerg has heard of libpam (it's a Solaris invention after all), but pam_cap is probably beyond his ken. Heck, libpam is almost archaic these days: the in thing now would be to set up a CD burning service via dbus and use PolicyKit to arbitrate access to it (probably using ConsoleKit to allow people on the console to burn CDs). (These newish systems are underdocumented and overly baroque, but they *do* let you express things you couldn't beforehand. And dbus services are a much nicer way to do privileged stuff than setuid *anything*, because you can more strictly control the unprivileged->privileged information channels.)
From: Nix on 8 Feb 2010 19:03
On 7 Feb 2010, unruh(a)wormhole.physics.ubc.ca said: > On 2010-02-07, Paul Martin <pm(a)nowster.org.uk> wrote: >> - CAP_SYS_RAWIO >> Perform I/O port operations (iopl(2) and ioperm(2)); access >> /proc/kcore. >> >> Nope, not needed for /dev/sr0 type access. Nobody in their right mind >> uses the /dev/sg0 interface nowadays. It doesn't exist with the IDE >> drivers, anyway. (I do know about the newer ATA drivers, thank you.) > > Again, you are generalising from a very peculiar personal situation. A system less than ten years old is peculiar? libata works with pretty much all of those. Maybe if you have an ST-506 or something you might need to use the old drivers still... essentially every Linux distro has switched by now. I switched in 2008 -- moving slowly verging on paranoiacally because of the strange old disk controllers I had in one machine at the time -- and had no problems whatsoever. (And why the hell would a CD burning program want to do I/O port operations anyway? Maybe it needs to do that on non-Linux systems, but accessing SCSI devices directly via I/O port access is horrifically dangerous on any modern Unix system, Solaris included. The kernel drivers have already bound to it: messing with its state directly is a recipe for disaster and, should you have fixed disks on the same controller, truly epochal data loss. Maybe it's not trying to do direct I/O port access to the SCSI controller, but to something else. cdrkit isn't doing it that I can tell, whatever it is. Accessing /proc/kcore for any reason other than debugging is utter madness. Most kernels don't even compile it in anymore.) |