>From [EMAIL PROTECTED] Wed Jun 12 21:56:49 2002
>> 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).
Well I did expect that you start such a commnication because it sweems that
you like to know something about the cdrecord-ProDVD status.
You definitely did not...
>> 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.
So you definitely make false assumptions! The German/European
Copyright/Authorship righs law only protects a "work" and no code fragments.
Code fragments are not worth to be protected from our law.
>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.
You missinterpret what happens. The reallity is:
All contributed code is freely available under GPL.
What I am doing is simply a second legal type of use. I am the original Author
and have the right to make a second publication under a different license.
The whole ethic background of the GPL (giving the user unlimited access and
right to use the source) is retained this way.
>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.
1) It seems that you missinterpret the meaning of proprietary software
2) publishing under GPL definitely does not prevent your code from being
used by non GPLd software.
>> 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)
It definitely does neither violate GPL nor the German/European Copyrights
>2. Even if it is legal, it's proprietary software, and therefore
> shouldn't be used.
Again, it seems that you use proprietary software like GNU tar and others.
So what is your problem?
>> 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.
And you seem not to understand that there are many important things that just
work more simple and more smoothly than what FSF programs usually do.
>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.
Sorry your definition of the word "standard" seems to be broken the same way as
it is when used by M$ people. Why do so many FSF followers behave the same
way as their putative worst enemy does?
A standard is something that has been aggreed on by an independant gremium.
This is definitely not true for M$ or FSF products.
>- It makes life easier for packagers because it supports
> stuff like make install DESTDIR=/foo
YOu should READ documentation!
It is even simpler with my build system.
Your problem is that you once heavily struggled to understand how the
non-standard GNU build system works and now obviously regret to learn that
there are other (better) solution and that you need to read some documentaion
the same way as it was needed for the GNU way.
>- 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.
Now you are catched! In reallity it is exactly the other way round:
- Programs that use the GNU build system only compile on platforms the
mantainers of autoconf are aware of.
- The Schily makefile system compiles even on unknown platforms
if they are similar enough to other known systems.
Of course, this property is only available if you use my 'smake' instead of the
broken GNU make. This does work since January 2001 when I received my MacOS X
box with the first official "Darwin" version which has been significaltly
different in ID strings from all betas before.
>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.
Yes: I use it because it is easier to use and more portable than what the GNU
build system is.
>> >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.
Why should I (being one of the strongest Open Source advocates) revert to
a non free license for the main stream version of cdrecord?
I'd wish that GNU software from the FSF would be enhanced so much as cdrtools
and e.g star are. Look at GNU tar, in 2002 it does not even implement the
POSIX.1-1988 standard while star supports POSIX.1-2001 since august 2001.
The incremental backup mode of GNU tar is close to unusable and 100%
unmainatined while star will imlement "true incremental dumps" this year.....
>> 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 cannot verify this, I do however know what I do for Free Software....
>> >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.
Tell me anything that has been improved! - nothing.
In fact the large file support is broken with your build system.
>> 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.
??? Why then didn't you contribute to improve the code?
>> 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 are wrong - sorry. It takes more than 4 full days at CeBIT to cultivate
old relationships with manufacturers and to get new ones. People like you most
likely don't do this. The fact that there is something that (even though falsely)
claims to be more free than cdrecord may compromise such relationships
and thus cause the real cdrecord developent to slow down.
Unless there is a single (even minor) contribution to cdrtools from you, I cannot
really believe that you are interested in improving cdrecord and friends.
>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.
This is definitely wrong too:
Since I made cdrecord-ProDVD available as closed but (in contrary to your
"fork") maintained software did increase the contacts to people who are really
interested. Maybe that this would not happen if cdrecord was completely closed
source, but nowerdays a typical GNU SW user is not interested to conribute and
does not even make usable problem reports.
>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.
Defining things in a different way then usual does not change facts - sorry.
>Neither of your examples matches this description.
You are just not using terms correctly.
>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.
Of course it _does_, as the archives created by GNU tar have big compatility
problems if you try to extract them with real TAR implementations.
Again, you are using M$ methods - the only difference is that M$ takes money :-(
Try to understand what a real standard is and act according to usual term
definitions instead of FSF specific ones.
>> 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.
I don't need to explain. I can guess that one reason is RMS ....
>> 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.
So you still don't know what C99 is and what problems even GCC-3.1 has..
>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?).
???
I am using the official distribution and was forced to write as much m4 macro
stuff as originally included by autoconf. Some of the original macros (even
from recent versions) are still buggy. The man pages are bad and cause users
to write non-reusable code :-(
>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.
Atomake _is_ a step into the wrong direction is completely ignores
ideas of the 80's and 90's.
>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.
It cannot!
Just try to do ot to convinve me...
>> >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".
Which is not what "people from the street" will understand by proprietary..
So why do you use it this way?
>> 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.
WRONG: cdrecord heavily depends on thede bastardizing interfaces.
>> 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.
So your scope does include Solaris?
>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.
Linux is more than 5 years behind what the Solaris kernel does.
>I don't care about other OSes - proprietary software (say, Windows,
>Solaris, HPUX, AIX, ...) is evil and not work wasting time on.
You should try to be more consistent in your statement if you like other people
to take you for serious.
>> >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.
??? please give satements not enigmas
>> 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".
Well a typical GNU source is a source with "nearly no" indentation. What is the
difference?
>> You should educate yourself before if you don't understand the system in use.
>I understand it. I just don't like it.
If you would understand it you would prefer it.
Jörg
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
