On Wed, 12 Jun 2002, Joerg Schilling wrote:

> Interesting to see that you are not completely unwilling to communicate....

I'm not - I just end up being unresponsive occasionally because I'm 
overworked (and receiving around 1500 mails a day doesn't help).

> For this reason I am the original Author of cdrecord and _do_ have the right to 
> publish it with any Licence I like.

I'm not a lawyer, so I'm not going to debate it, though I think it's 
questionable because you can assume the patches you applied were 
implicitly placed under the GPL.
Even if it happens to be legal, it is ethically wrong IMO; you have abused 
the contributors' trust and used their work in ways they (or at least some 
of them) don't agree with.
This is precisely the reason why I've forked it. I don't want to see any 
of my code used in proprietary software, and I'm sure many others feel the 
same way.

> For the parts that are not critical code
> because the know how is widely spread, I choosed the GPL and for the parts where
> I am on the leading edge (cdrecord_ProDVD was the 3rd DVD-recording application
> world wide in February 1998) I keep the sources secret.

If you don't use other people's code, that's your choice of course.
It's my choice to dislike this sort of thing enough to do something about 
it.

> Cdrecord-ProDVD is a legal DVDD writing program what is your problem?

1. I believed it's illegal because of a GPL violation (and I'm still
   not 100% convinced it isn't one)
2. Even if it is legal, it's proprietary software, and therefore
   shouldn't be used.


> >You can claim it's not really independant because it doesn't contain all 
> >that many changes to the cdrtools code, and you'd be somewhat right - 
> >I just added DVD support and "fixed up" [IMO -- see below] the build 
> >system.
> 
> You did not fix it but you destroy the build system. You replaced a completely
> automated build system that allows you to compile on far more than 30 different OS
> by something worse. Why?

Because I (and many others) like it better. Better/worse are rather 
subjective terms.

My main arguments for preferring using the GNU build tools are:
- It's the standard way of doing things.
  Therefore, other people can read it and immediately know
  what it means without having to read up on loads of different
  makefiles.
- It makes life easier for packagers because it supports
  stuff like make install DESTDIR=/foo
- It makes life easier for people trying to compile from source.
  ./configure --help |less ; ./configure --whatever
  is much easier than having to read a number of makefiles in
  different directories and editing them by hand, especially for
  non-programmers.
- It automatically adapts to new OSes and OS versions rather than
  hardcoding "Linux does things that way" (assumptions which may not
  even be true on all Linux systems) the way your build system does
  in a few places.

I'm sure you have a couple of good reasons to prefer your system as well.
Let's just agree to disagree on this one, it's really another "vi vs. 
emacs, Linux vs. GNU/Linux or Open Source vs. Free
Software" flamewar topics.


> >If it ever becomes necessary, it can become a truly independant fork, 
> >though. I just hope it won't get that far.
> 
> ???

Just in case all of cdrecord gets under an unacceptable license at some 
point. I hope it doesn't happen, but if it does, I'm prepared to run a 
truly independant fork without any code merges.

> >It is true that I haven't released many updates lately. This is mostly 
> >because I'm busy with other work, and because the current version works 
> >perfectly for me.
> 
> Let us call it this way: After you fixed the worse bugs in YOUR build system
> that caused cdrecord to dump core you stopped working on it.

This is plain not true. I just decided to do some other things first when 
I had it in a working state.
I already work about 15 hours/day, 7 days/week, so I admittedly can't do 
as much as I'd like to.

> >I will release a newer version once I either have some spare time, or once 
> >I find a serious problem in the current version.
> 
> You name it! You are a person who did make useless changes on the build system
> for unknown reasons

s/useless/useful/, reasons see above.

> and your only motivation was to have a private copy of 
> cdrecord running for your A03.

Wrong. If that had been my motivation, I would have built a copy for 
myself without putting it on the net.
Yes, I wanted to have my A03 running without using proprietary software.
Then I put it on the net to help people in similar situations, and to 
encourage people with different hardware to extend it so it works with 
that.

> This way we never will get good and powerfull free software.

This is wrong.
Remember how Linux started out?
Linus wanted a unixlike OS that worked on his 386. He put it on the net, 
and the rest is history.

You can get good and powerful free software by putting stuff in "works for 
me" state on the net.
You can NOT get good and powerful free software by putting a binary on the 
net and then wondering why nobody contributes.

> >> that uses an add on which
> >> most likely has been created by reverse engineering cdrecord-ProDVD.
> 
> >For the record, it hasn't been. I believe proprietary software is evil, 
> >therefore I don't download it.
> 
> So you don't use CVS which us proprietary software because it uses a 
> non-standard archive format? 

Please check 
http://www.gnu.org/philosophy/categories.html#ProprietarySoftware
for the definition of proprietary software. This is the definition I go 
by, and I won't use any software matching this description.

Neither of your examples matches this description.

Even if an archive format happens to be non-standard, that doesn't make 
the application "proprietary" or "bad". As long as the application is free 
(as in "free software", not as in $0), everyone can handle the format.

> The GNU build system is extremely non-standard and uses techniques of the 70's

So something 90% of all software uses is non-standard? Explain.

> Read e.g.
>               ftp://ftp.fokus.gmd.de/pub/unix/smake/PortableSoftware.ps.gz


I've read it, and I disagree with what it says.

Reading that (in particular page 6) makes me believe you haven't seen any 
current versions of gcc.
gcc 3.1 is 100% ISO C99 and ISO C++98 compatible, and is very strict about 
its checking.
Some proprietary compilers don't respect these standards (some probably 
don't even do ANSI C yet). Those compilers should be avoided like the 
plague.
Your claim that GNU autoconf is only half-finished because it lacks 
important macros isn't exactly true anymore, either (I presume you're 
aware of ac-archive?).
Saying that GNU automake is a step in the wrong direction because it 
generates hard to maintain makefiles is not exactly right either - you are 
not supposed to edit the generated makefiles directly. Doing that is a bad 
idea because changes will get overwritten. And if you know how to write 
proper Makefile.am files, you don't need to edit generated makefiles.

The whole (IMO messy) stuff described in the document can be done better 
with GNU autoconf and automake, which is what I'm trying to do.

> >Maybe it doesn't work on some proprietary OSes - to be honest, I don't 
> >care (they should just use a free OS, or at least a compiler that 
> >works, like gcc) and if someone does care, he can send me a patch, and if 
> >it doesn't break anything, chances are I'll apply it.
> 
> Well Linux is a proprietary OS more than others.

Again, I use the GNU definition of "proprietary".

> It implements interfaces
> that are not all POSIX compliant and frequently change without notice 
> and a migration plan!

Interfaces you don't have to deal with unless you're working on the kernel 
itself or device drivers.

> If you only care Linux it shows that you are not really interested in good
> software quality.

Wrong. I'm interested in making good software for good operating systems.
I define a good operating system as an operating system that is Free 
Software and works well. At the moment the only operating systems matching 
this description IMO are Linux, FreeBSD, OpenBSD and NetBSD. Hurd has a 
chance to get there if/when it stabilizes.
I don't care about other OSes - proprietary software (say, Windows, 
Solaris, HPUX, AIX, ...) is evil and not work wasting time on.

> I would never use a software where the Author tells me that
> he only develops on Linux and pisses on other OS. Such opinion makes just a bas 
> Author :-(

Nobody forces you to use anything I write. I think that from time to time, 
it's necessary to dump legacy stuff (do you still want to write assembly 
code supporting an 8088 CPU?), and this includes broken compilers and 
non-free operating systems.

> >Actually I think my autoconf code is much nicer than cdrtools'.
> >Compare, for example, the align.h stuff. (46 lines in configure.in as 
> >opposed to exec'ing 674 lines of C code to generate a header).
> 
> Are you counting matches or do you like to discuss features?

Just an example to demonstrate your makefile system is overly complicated 
and the same things are doable in a much simpler way with the right tools.

> Being consequent with the "GNU coding style" would result in C sources without
> indentation and a make system that is completely shell script based.

http://www.gnu.org/prep/standards_23.html#SEC23 reads hardly like "sources 
without indentation".

I don't agree with everything the GNU coding style says, but its basics 
are sane.

> >Actually I never claimed all the credit. The readme file, the website, and 
> >dvdrecord --version all give credit to cdrtools/cdrecord.
> >I rightfully claim the credit for releasing a free version that can write 
> >to DVDs and that uses a standard build system.
> 
> Cdrtools come with a standard build system!

What other applications (aside from your own ones) use it?

> You should educate yourself before if you don't understand the system in use.

I understand it. I just don't like it.

LLaP
beor

-- 
This message is provided to you under the terms outlined at
http://www.bero.org/terms.html





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to