From: unruh on
On 2010-02-07, Paul Martin <pm(a)> wrote:
> In article <slrnhm8rm1.hd6.unruh(a)>,
> 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
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

> "Touch black, no swaps back."
From: unruh on
On 2010-02-07, Paul Martin <pm(a)> wrote:
> In article <slrnhmbepi.jm9.unruh(a)>,
> 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
On 7 Feb 2010, unruh(a) outgrape:

> On 2010-02-07, Paul Martin <pm(a)> 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
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.)

> 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

>> 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
On 7 Feb 2010, unruh(a) said:

> On 2010-02-07, Paul Martin <pm(a)> wrote:
>> 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.)