[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: xcdroast does no longer work with wodim: Who to blame?

On Monday 02 March 2009 19:59:00 Bill Unruh wrote:
> Agreed, both sides have to come to the conclusion that they are operating
> legally. On the plus side, Schilling would like to have his software
> distributed in the distros. He is also strongly of the opinion that there
> is no legal impediment to that happening. Debian is of the opinion that
> there IS an impediment. It is not that Schilling recognizes the impediment
> and refuses to clear it, it is that he does not believe that there is one.

Obviously Schilling is not Debian, so the distributor's rules apply... and 
Debian is not alone in that a decision.

> Thus both sides are to a large extent on the same page (wanting to
> distribute and to do so without legal impediment). Now the question is, is
> there some way of clearing out the underbrush so that both sides agree that
> there is no impediment. (Note that the chances of any legal action being
> taken by anyone with respect to cdrtools is miniscule. So it is not fear
> that stands in the way, but a "legal quibble".

I see only one way out: talk to Schilling to revert that GPL+CDDL license 
mixture, and it is all done, and it is cheap and easy.

> >>> original is just undistributable and therefore the fork is the only
> >>> option, no matter how bad it is (and it works for me [tm]).
> >>
> >> Sorry, that is how it works. He has reported a bug. Here. If what he
> >> says is right, namely it does not work with SCSI it is a bug which
> >> should have been caught before it ever went out the door
> >
> > Will you buy the maintainer all kinds of scsi burners so they can test
> > each? I myself and several others have used debians cdrecord with scsi
> > just fine so the bug must be some quirk of that specific config. You
> > can never forsee all those quirks.
> Look I never said that maintaining is easy. It is not. And
> Schilling has proven himself willing to do it, to buy "all kinds of scsi
> burners" or get ahold of them, and make it work. That is worth a HUGE
> amount.

Very nice, but do you really believe it? Don't answer me ;-)

> >>> As such dear authors keep your spirits high. Your efforts are highly
> >>> valued and not wasted.
> >>
> >> Well, really they are. There is this piece of software which does
> >> everything they want it to do, and they are tinkering with an old
> >> version of that same software, trying to keep up, and not really wanting
> >> to do so.
> >>   This whole thing would be a farce if it were not a tragedy.
> >> Maybe it is impossible to bring Schilling and Debian together. Sometimes
> >> tragedies do occur, but that is where the efforts should go.
> >
> > And here we have to disagree. I don't see Schilling moving one iota
> > from his position and trying to compromise with someone so set in
> > stone is just wasted.
> Well, I think there is the problem. This has come down to personal issues,
> not legal or technical. Everyone is so dug into their positions that they
> simply spend time lobbing grenades at each other, rather then trying to
> work through the problem. Yes, Schilling is "difficult" but by now, so is
> Debian.

I don't think that Debian is treating cdrtoos in any specific way, just normal 
rules apply as usual. And quite frankly I don't see any good reasons why 
Debian should compromise its principles in the name of cdrtools licensing 
games. And it is not that there are no good alternatives like dvd+rw-tools, 
cdrskin, xorriso, xfburn, and finally decent libs like libburn, libisofs, 
libisoburn so that anyone can benefit from; but I'm not going to beg you 
using them like Schilling does. For me, cdrtools turn to be the mostly 
useless pile of bits for the last three years, and it is no more interesting 
for me whether Schilling is wrong or rigth, but that is me. As we all know, 
monopoli is not so much a funny game when it is over, and I really wonder why 
this thread is still alive.

pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>

Reply to: