The value of middlemen
Users may not fully appreciate another role filled by Linux distributors, however: they serve as middlemen between the producers and consumers of free software. This work goes beyond packaging programs and feeding back bug reports; Linux distributors also serve as crucial advocates for their users. When developers fail to act in the interest of the people using their software, the distributors can come in with their advocacy and patching skills to improve the situation.
A good example of how this process works was brought to light via a long and unpleasant linux-kernel discussion involving Jörg Schilling, the maintainer of the much-used cdrecord program. For the curious, the thread starts with this message. There are several issues discussed, but much of it comes down to some fundamental disagreements between Mr. Schilling and the Linux distributors on how cdrecord should work.
For example: in the 2.6 kernel the preferred way of performing raw SCSI operations on a device (which is how CD burning is done) is to simply open the device directly and issue the right ioctl() calls. So, if your drive is /dev/hdc (or, better, /dev/cdwriter), you run cdrecord with dev=/dev/cdwriter and be done with it. Mr. Schilling swears that the only proper way to specify the output device is via SCSI bus, target, and unit numbers - despite the fact that most of these devices do not sit on a SCSI bus and have no such numbers. And despite the fact that figuring out that, say, dev=0,2,0 is the right magic sequence to type is not something many users want to do. So cdrecord issues a set of scary warnings with the "open by device" mode is used, despite the fact that it is the best way to do things.
Another example: some users have a strange idea that they might actually like to write DVDs on their DVD-capable drives. The official version of cdrecord has no such capability, and Mr. Schilling has refused to add it. Some of the more cynical observers have noted that the fact that Mr. Schilling offers a proprietary version of cdrecord with DVD support may have something to do with this refusal.
Users of cdrecord could try to address these issues directly with its author. Experience has shown, however, that this can be an unpleasant and unrewarding process.
This is where the distributors step in. A quick check in the latest Fedora source RPM for cdrtools shows a good dozen patches; these vary from small documentation tweaks through to DVD support and the removal of unnecessary, scary warnings. Other distributors have done similar things. The end result is that users get a version of cdrecord which works as they would expect, while the distributors take the heat (and there is some heat) for the changes that they make.
Mr. Schilling has given us a true gift: the cdrecord program embodies a
great deal of knowledge of just what is required to make a wide variety of
CD writers work on numerous operating systems. We get to make use of that
knowledge because Mr. Schilling has released his work under the GPL.
Before criticizing him too much, it is good to reflect on the value of that
gift. But this is also a good place to appreciate the extra value added by
the Linux distributors. Sometimes a middleman is just what is needed to
make the whole process work.
Posted Aug 12, 2004 5:37 UTC (Thu)
by Duncan (guest, #6647)
[Link] (2 responses)
Posted Aug 12, 2004 7:14 UTC (Thu)
by jwharmanny (guest, #971)
[Link]
Posted Aug 12, 2004 12:07 UTC (Thu)
by corbet (editor, #1)
[Link]
Posted Aug 12, 2004 8:01 UTC (Thu)
by mbp (subscriber, #2737)
[Link] (5 responses)
Posted Aug 12, 2004 11:15 UTC (Thu)
by wookey (guest, #5501)
[Link] (4 responses)
There are good reasons why Red Hat and Debian (for example) are not identical. Nevertheless they are highly compatible and you can generally use either if all you want is a 'linux system'. Choice is not a bad thing - it's good, and choice is not incompatible with interoperability.
Which one, overweening, system would you have us all use?
Posted Aug 12, 2004 12:14 UTC (Thu)
by ewan (guest, #5533)
[Link] (2 responses)
There are good reasons why Red Hat and Debian (for example) are
not identical. [...] Which one, overweening, system would you have
us all use?
Posted Aug 13, 2004 0:42 UTC (Fri)
by bignose (subscriber, #40)
[Link] (1 responses)
A case in point for the confusion caused by saying "Linux" when one means "GNU".
Posted Aug 13, 2004 2:44 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
This is a rare case where the relevant characteristic of the systems in question is a matter of the Linux kernel. One of the issues is the way the user identifies the CDROM drive and how the program accesses it. That's pure Linux kernel.
Neither that nor the other issue -- DVD writing -- seem to have any connection to GNU software.
Posted Aug 17, 2004 5:08 UTC (Tue)
by mbp (subscriber, #2737)
[Link]
When, as is apparently the case here, the upstream developer simply will not take patches that almost everyone else agrees is a good idea, then it's time to fork. There *is* a time and a place for forking.
(If it turns out that the author was right, the patches were a bad idea, and nobody uses them... well, that's life. But I don't think that would be the case here.)
It would hardly be the first time. Somebody else mentioned XFree86. An even more relevant example is OpenSSH: when the original maintainer went off into a proprietary development, a fork arose and all the distributions adopted it.
If somebody forked cdrecord into a free version that could record DVDs I think that would be great too.
The choice here is not between zero forks and one fork. It is between one open fork, or alternatively every distribution applying different random patches.
>> Which one, overweening, system would you have us all use?
The one which allows you to say "cdrecord dev=/dev/cdrw". Is that so unreasonable?
Posted Aug 12, 2004 15:24 UTC (Thu)
by jre (guest, #2807)
[Link]
Posted Aug 12, 2004 15:52 UTC (Thu)
by garloff (subscriber, #319)
[Link] (16 responses)
So he has added this GPL incompatible clause to 2.0a36:
Does he own the complete copyrights for cdrecord? Did contributors
assign the copyright to him? Or has nobody succeeded to work with him
and sent him patches?
Posted Aug 12, 2004 16:34 UTC (Thu)
by gerv (guest, #3376)
[Link]
1) When Jorg distributes the current version of cdrecord, he is violating the GPL license *on those parts he does not own the copyright on* - because the copyright holders of those parts have not given permission for their code to be linked with non-free code.
This would allow anyone with code in cdrecord to sue him for copyright infringement.
2) Anyone who receives the code receives it under two conflicting license provisions. That means, according to section 7 of the GPL, that they may not re-redistribute the code at all, because they cannot simultaneously satisfy the GPL and the other conditions (allow unlimited freedom to modify, and stop modification of that section.)
So any Linux distributor or other party distributing 2.0a36 or above is violating the GPL, and could be sued by copyright infringement by any contributor, including Jorg.
Gerv
Posted Aug 12, 2004 17:20 UTC (Thu)
by gerv (guest, #3376)
[Link] (2 responses)
BTW, thanks for the tip-off. I've blogged further about this. Gerv
Posted Aug 12, 2004 22:29 UTC (Thu)
by Soruk (guest, #2722)
[Link] (1 responses)
Posted Aug 12, 2004 23:43 UTC (Thu)
by gerv (guest, #3376)
[Link]
Gerv
Posted Aug 12, 2004 18:39 UTC (Thu)
by oak (guest, #2786)
[Link]
At least he cannot say it's GPL anymore. GPL as license is copyrighted too, so that people cannot claim as GPL (+ modifications) something which doesn't anymore have the same intent as GPL...
Posted Aug 12, 2004 18:55 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (2 responses)
I find it odd that his claims about section 2c of the GPL are not, in fact, correct, though; he seems to think that if you distribute a modified version, you must include a notice that it is modified. In fact, you must include (2c) "an appropriate copyright notice and a notice that there is no warranty". If you don't claim copyright on your modifications, there's no way for an end user who doesn't read the (section 2a) "modified files" to tell that they have a modified version.
It seems to me that he would actually be perfectly happy if distros were actually really acting completely as middlemen; his issue is that users contact him when they have problems rather than contacting the distributors who could actually be helpful.
Posted Aug 12, 2004 19:32 UTC (Thu)
by mongre26 (guest, #4224)
[Link] (1 responses)
I dubious of Mr. Schilling's claim that Suse is in violation of the GPL as the result of the actions of users. Namely contacting Mr. Schilling. Particularly when the GPL itself says there is no warranty.
I have to investigate this more in depth, but I am gathering that there is more here than just people contacting Mr. Schilling for support for versions that are patched by Suse. More specifically that the distributors have had to apply patches (like DVD burning) to their cdrecord because the author has refused to do so himself.
Given it is mentioned in the article that Mr. Schilling actually sells a commercial Linux DVD burning tool based on cdrecord I see a definite conflict of interest here.
GPL and Open Source software is a two way street. Authors produce works, people write patches and submit them back. The system works best when there is two way movement of code. What it looks like from here is that Mr. Schilling has set up a roadblock and only allows those pieces of code to be applied to his version of cdrecord that do not conflict with the functionality of his commerical proprietary cdrecord version. What Mr. Schilling aparently did not realize is that Opensource has a way of routing around roadblocks and this is exactly what has happened with Suse and other distributors.
Since Mr. Schilling was not able to or willing to accept key patches from others to add DVD functionality, nor was he willing to add it himself distributors like Suse acted in a way that is not only acceptable, but is exactly how the GPL is intended to work. Suse modified and distributed their own non-warrantied version under the GPL with improved usability and functionality, or at least as far as they are concerned. Relative evaluations of whether Suse cdrecord is better than vanilla cdrecord is not relevant.
Mr. Schilling is trying to exert a level of control he does not have under the GPL and as someone said in an old movie I saw once "The more you tighten your grip... the more...will slip through your fingers.".
If Mr. Schilling really wants to he can make version 2.0a37 and place it under "All Rights Reserved". His contributions to cdrecord from the communities perspective will cease and the fork will be official.
Even without closing future cdrecord versions though Mr. Schilling has still put out notice that while he may say cdrecord is GPL it is only GPL on his terms. I think he needs to realize it does not work like that. The GPL gives rights to users that you do not usually see with most copyrighted works. That inevitably takes some rights away from authors. This is a key intent of GPL to give these rights to distributors and users, to ensure the software remains free.
Mr. Schillings addition certainly violates the spirit of the GPL, and if there is code in cdrecord he does not hold copyright on he may be violating the letter as well.
In any case I think it is prudent to assume that cdrecord 2.0a36 is not under any license for Mr. Schillings code and may have additional encumbrances. cdrecord 2.0a36 should be avoided.
Posted Aug 12, 2004 19:34 UTC (Thu)
by mongre26 (guest, #4224)
[Link]
Posted Aug 12, 2004 20:27 UTC (Thu)
by droberge (guest, #10852)
[Link] (5 responses)
It would appear that the text in the GPL that Mr. Schilling is referring to is:
It would appear that to some extent SUSE is in fact violating this, but it wouldn't actually be a violation of the GPL since the Preamble isn't actually prescriptive. (IANAL) I am not sure how one could completely comply with this without purging the original author's name from the program which is a clear GPL violation.
Posted Aug 12, 2004 20:35 UTC (Thu)
by corbet (editor, #1)
[Link] (4 responses)
Posted Aug 12, 2004 22:39 UTC (Thu)
by Soruk (guest, #2722)
[Link]
Posted Aug 13, 2004 0:34 UTC (Fri)
by droberge (guest, #10852)
[Link]
Posted Aug 13, 2004 6:46 UTC (Fri)
by garloff (subscriber, #319)
[Link]
garloff@tpkurt:~ [0]$ cdrecord --version
That should be clear enough. And that notice has been put there to avoid
conflicts with Mr. Schilling.
Posted Aug 27, 2004 12:36 UTC (Fri)
by sinnerbofh (guest, #24303)
[Link]
$ cdrecord --version
Cdrecord-Clone 2.01a27-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling
Salut,
Posted Aug 13, 2004 6:52 UTC (Fri)
by garloff (subscriber, #319)
[Link]
Posted Aug 19, 2004 2:45 UTC (Thu)
by mbp (subscriber, #2737)
[Link]
What he may be doing here is refusing to licence future versions under the GPL. If he owns all the copyrights, then that is his right. Of course someone else can fork a previous version.
Posted Aug 16, 2004 0:21 UTC (Mon)
by stock (guest, #5849)
[Link] (1 responses)
Posted Aug 19, 2004 19:17 UTC (Thu)
by AJWM (guest, #15888)
[Link]
Posted Aug 28, 2004 1:19 UTC (Sat)
by rabnud (guest, #2839)
[Link] (1 responses)
Well, sometimes collaborative effort is shunnedby a mind that is not accustomed to collaborative efforts. Not for nothing, but what is the real issue here - the method of addressing the device? Or is it the lack of clear 'Anglicised' thinking on the part of Jorg?? How about the amount of time he has evidently spent 'hacking' (in an unfavored sense) the core code (which was evidently SCSI oriented), just to accommodate the 'johnny come lately' ATAPI based devices which are not as familiar to Jorg??
In his mind, I believe, the concept exists that the SCSI orientation has been the focus and maybe he is a little uncertain of the ATAPI patches, and hence is possibly a little resentful of the compromises made to accommodate ATAPI.
I, for one, could see this discussion as alienating a valuable Linux contributor, all over the matter of him being a] not a native english thinker (and thus using english words in a less than accurate fashion), and b] possibly he is a little concerned that people (who are already critical of his software) are scrutinizing this software, as dozens of development fronts ask him questions regarding compromises that have been made to a core software in order to accomplish the existing software... maybe Jorg is a tad concerned over the people that always jump on others and scream 'I could have done better!'??
I've only skimmed the thread, and I suspect the matter is misinterpreted.
Posted Oct 9, 2004 6:26 UTC (Sat)
by jamincollins (guest, #17470)
[Link]
The following is rather minor, and it's obvious upon second look what was Minor error
intended, but it DID cause me to stop, go back and reparse the sentence to
see why it didn't make sense the first time thru.
> So, if your drive is /dev/hdc (or, better, /dev/cdwriter),
> you run cdrecord with dev=/dev/cdrom [...]
Where'd /dev/cdrom come from? <g> The hypothetical up to that point was
discussing /dev/hdc, with a parenthetical comment that /dev/cdwriter would
be more appropriate. Nothing at all about /dev/cdrom, until it's pulled
out of thin air, at a point where the reader would expect a reference to
something earlier.
Not that I did well in composition (I didn't), or have any room to
criticise as a writer, but just as an initially confused reader..
The article /does/ make a very valid point, however, one that isn't
commonly emphasized in the community, and that deserves more attention
than it often gets. Distribution developers put a lot of at times very
hard work into their product, taking a lot of heat at times in the
process, and deserve a lot more credit than they sometimes get.
Duncan
/dev/cdrom is a symlink to /dev/hdc in most cases.Minor error
Yesterday was a long day...fixed now...
Minor error
It might be nice if the Linux distributors made a single Linux fork, rather than making every version a bit different...The value of middlemen
No it wouldn't. And I don't think you mean 'fork' either - distributors try hard not to actually fork things.The value of middlemen
No it wouldn't. And I don't think you mean 'fork' either -
distributors try hard not to actually fork things.
The value of middlemen
Most of the time, but sometimes it's necessary, as it was with the
XFree86 - X.org change.
One shared linux friendly fork of cdrecord, not one version
of linux. It would be silly if everybody was independently patching
cdrecord to fix the same problems, but I don't think that actually
happens too much since they can all lift patches from each other.
That said it's possible that the pain of a full-blown fork might be
less than the pain of dealing with Jörg....
> > There are good reasons why Red Hat and Debian (for example) are notThe value of middlemen
> > identical. [...] Which one, overweening, system would you have us all
> > use?
> > One shared linux friendly fork of cdrecord, not one version of linux.
I don't think this is a case in that point.
special "Linux" version
I actually do mean "fork".The value of middlemen
I encountered the same problems as everyone else when I first tried to burn a DVD under Linux. In searching for the right patches, I found that Jörg Schilling had set up a weird system in which his GPLed CD-writing tools coexisted with a proprietary DVD-burning application, for which non-commercial users could get a time-limited key. The whole thing made my head spin. Then I discovered K3B, and my troubles were over.
The value of middlemen
I admire Jörg Schilling for the superb work he's done in creating the suite of CD-writing tools we all use. I respect his right to license his own work under whatever license he wishes. But, as a practical matter, I wish he would stick with the (correct) decision he made initially, and GPL every tool he releases. Trying to have it both ways just causes a lot of heartache and confusion and -- given the availability of alternative tools -- probably does not benefit him much, either.
Mr. Schilling seems to disagree about the value of middlemen.
He seems to have a special issue with SUSE, maybe because it was Jens
being very patient trying to explain to him, why some of his statements
do not really convince the community.
The value of middlemen
/*
* You are not allowed to modify or remove the following code.
* I am sorry that I am forced to do things like this, but defective
* versions of cdrecord cause a lot of work load to me and it seems
* to be impossible to otherwise convince SuSE to cooperate.
* As people contact me and bother me with the related problems,
* it is obvious that SuSE is violating subsection 6 in the preamble of
* the GPL.
*
* Note that although the SuSE test is effective only for SuSE, the
* intention to have non bastardized versions out is not limited
* to SuSE. It is bad to see that in special in the "Linux" business,
* companies prefer a model with many proprietary differing programs
* instead of cooperating with the program authors.
*/
I wonder whether he has the right to revoke the GPL license, though.
That clause makes the code it refers to non-free; this is an extra restriction which violates section 6 of the GPL. This has several ramifications:The value of middlemen
The value of middlemen
You refer to "2.01a36" in your blog entry. Is this intentional?The value of middlemen
Yep - according to ftp://ftp.berlios.de/pub/cdrecord/alpha/ , cdrtools-2.01a36 is the latest version. I compared it against 2.01a35 and noted that this comment had been added.The value of middlemen
"wonder whether he has the right to revoke the GPL license, though"The value of middlemen
At the beginning of the file (at least in a35), it says "This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version." As far as I can tell, this grants permission to redistribute it and/or modify it under the GPL, and contradictory comments elsewhere in the file are not actual license terms.The value of middlemen
It is not Suse's fault that cdrecord users contact the author instead of him. The value of middlemen
Sorry iabervon I was not specifically replying to you, hit the wrong link.The value of middlemen
The value of middlemen
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
which is the sixth paragraph in the Preamble to the GPL.
Don't know about the SUSE version, but Fedora's cdrecord starts by printing a four-line warning that the program has been modified and the original author should not be bothered. Seems like that should suffice.
Notification of modification
The DVD patch I got from Florent (Warly) Villard's CDRtools DVD patch also puts up such a message. I have no problem with this - indeed it makes perfect sense.
Notification of modification
The version on my Debian system also displays such a notice; I guess I spoke in haste. Notification of modification
On my SUSE Linux 9.1: Notification of modification
cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler
cdrecord: Permission denied. WARNING: Cannot set priority using
setpriority().
cdrecord: WARNING: This causes a high risk for buffer underruns.
Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004
Jörg Schilling
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to
http://www.suse.de/feedback
Note: The author of cdrecord should not be bothered with problems in this
version.
But apparently on some old release (on SL82?), there was no such clear
warning. He complains about that, despite it's been fixed long since
then. I wonder whether that's what really bothers him, though.
Same kind of warning in MandrakeLinux 10.0:Notification of modification
Note: This version is an unofficial (modified) version with DVD support
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to <warly@mandrakesoft.com>.
Note: The author of cdrecord should not be bothered with problems in this version.
Sinner
> So he has added this GPL incompatible clause to 2.0a36: The value of middlemen
2.01a36, sorry for being unprecise.
I don't think that implies a "revocation" -- that term means that you are no longer allowed to use or redistribute previously-obtained copies. The GPL wouldn't allow that except in particular circumstances. The value of middlemen
The value of middlemen
maybe checkout OSS DVD at http://crashrecovery.org/oss-dvd.html
Robert
For simply burning a DVD from an ISO, "growisofs" has, er, grown on me. It will burn from an existing ISO, although the command line argument syntax for that is a bit odd (ie something like "growisofs /dev/dvd=foo.iso").The value of middlemen
"Sometimes a middleman is just what is needed to make the whole process work."The value of middlemen ... or less impassioned criticisers
Oh, I have a feeling if you read the entire thread in depth (I did a while back) you'll find that Jorg is just being a stubborn fool. This is just my opinion, but I lost a lot of respect for him over that flame fest.The value of middlemen ... or less impassioned criticisers