Re: cdrtools
Wouter Verhelst <wouter@grep.be> wrote:
> I can quote major parts of it by heart since a few years, does that
> help?
If you like to discuss the GPL with other people, it is irrelevent whether
you know it "by heart" in case you did not understand it yet...
> [...]
> > > GPL§3 clearly says what you may do when you distribute binary versions
> > > of the Program, and gives you three options:
> >
> > But this is unrelated to the problem Debian seems to construct.
> > You should read the GPL more carefully.
>
> Actually, no. The main problem which Debian has with you and your
> relation to the GPL is related to GPL§3.
If you believe that there is a problem with GPL §3, why don't you explain this
"problem"? Instead of writing such acusations, _you_ should try to find
a non-prejudiced relation to software licenses...
What I am subjected to by Debian is a real bad calumniation campaign :-(
People repeatedly claim that there are problems with my but are unable to
explain where the problems should be. If the Debian Pproject does not like
to lose credibility, people from Debian should finally explain their problems
or _correcty_ admit that there is no problem.
As you still seem not to understand the GPL, let me give you a final
explanation of the relevent statements from GPL §2 and GPL §3:
- The GPL §2 talks about a "work", but does not give a definition
for the term "work". So I am free to decide (within reasonable
limits) where the work ends.
The GPL §2 requires the "work" to be put under GPL in case that
the work has been created by including other peoples GPLd work
in a new or bigger project.
The GPL §2 does _not_ mention a restriction in case that a GPLd
work is based on a NON-GPL work or includes parts from a NON-GPL
work. As the GPL gives a general permission to use the GPLd code,
this is the point where the GPL opens a way to combine CDDL code
with GPL code. This is the way I am going with mkisofs.
- The GPL §3 uses a definition about the "complete source" which
differs from the term "work" which is used in GPL §2.
If you publish binaries from a project, then the GPL §3 requires
that the "complete source" needs to be published but does not
name a license for the parts of the "complete source"
that are not covered by "the work" (as mentioned in GPL §2).
The file "COPYING" in the root directory of the cdrtools project
explains which _sub_projects_ are published with the cdrtools
project and lists the location where the various sub-projects
could be found in the directory structure.
The "schily makefile system" is definitely not part of the
mkisofs project. The "schily makefile system" is project independent
and it is _also_ published separately from any other project.
The "schily makefile system" is more than 100x as big as the
project specific makefile mkisofs/Makefile and the project specific
Makefiles are published under the same license as the related
project.
As the GPL allows "mere agregation", this is what I do
with the "schily makefile system". The "schily makefile system"
is under CDDL and the file mkisofs/Makefile is under GPL.
If people from the Debian project believe that the GPL is to interpreted
otherwise, then the Debian project would need to immediately mark all
GPLd projects "non-free" as the GPL then seems to violate DSFG §9.
> > In case you did read the GPL carfully enough you should know that
> > GPL §2 and GPL §3 speak about differnt things.
> >
> > GPL §3 speaks about "complete source", while GPL §2 speaks about "the work"
> > which from what GPL §3 sais is _less_ than the "complete source".
>
> They both speak about "the Program", though, which is what really
> matters. The license applies to "the Program", which is defined in §0.
> It does not apply to "the work" or anything remotely similar. That term
> is only used to define rules that you needt to follow /when modifying
> the Program/. These rules are outlined in §2.
If you did not understand what a "program" is in terms of the GPL, you should
read GPL §0. In addition, I encourage you to read GPL §2 and GPL §3 again until
you manage to understand in which relation the term "program" is used there.
It is obvious that the term "program" applies to parts of the source that
end up in iditificable parts of the binary. The GPL §2 talks about the
limitations in case you put other peoples GPLd source or parts from it
into your peoject.
> IOW, if you are creating an original work (as you are) instead of
> modifying an already existing work, then §2 /does not even apply to
> you/.
See above, you seem to start understanding GPL §2.
... but it would take some time for you to understand enough of the GPL
in order to be able to discuss things related to the GPL with me.
> > does not mean more than: "make 'the work' available under GPL (in case
> > 'the work' is a 'derived work' and make the rest for the 'complete source'
> > available under any license you like".
>
> You seem to have a very strange sense of English.
Sorry, it's _you_ who sem to have a very strange sense of English.
What I am doing is to carefully read the GPL word by word, sentence by sentence.
What you to do is really strange as you seem to create _new_ (own) definitions
from words scattered to the whole text of the GPL.
> You may copy and distribute the Program (or a work based on it (...) )
> (...) provided that you also do one of the following:
>
> a) Accompany it with the complete machine-readable source code (...)
>
> It says "the Program", not "the work". It says "the *complete*
> machine-readable source code" (emphasis mine), not "the source code of
> just the part of which you're providing binaries".
Are you trying to do deliberate demagogy?
THIS is a quotation from GPL §3, not GPL §2!
GPL §3 does not require that "the complete machine-readable source code" is
to be put under GPL, it only requires that is has to be published.
> > You ned to carefully read the GPL as long as you need in order to understand
> > it by your own.
>
> My point exactly.
So why don't you try to understand the GPL?
> > Unproven claim!
>
> The point was: can you give me any sane description of "script" that
> does not hold for Makefiles?
A "scipt" is a _series_ of _instructions_ in _algorithmic_ form.
If you look at a script, it is "easy" to understand what it will do
if you run it.
A "Makfile" is a program written in the language "make" which is a
non-algorithmic (but rather rule based) language.
If you look at a "makfile" it is usually hard to predict what "make"
will do after reading the rules from "Makefile". Even I as an author of
an advanced "make" program am regularily fooled by the behavior of make
because I cannot predict the effects of all rules in a specific makefile.
But this definition is irrelevent as the "Schily makefilesystem" is a separate
and program independent project that cannot be treaten as integral part of any
project that uses the "Schily makefilesystem" for compilation.
> [...]
> > > Surely automake, GNU make, bash, and so on, were written before most of
> > > the projects that use them. However, that does not mean that the build
> > > system is a totally different "work"; the particular version of
> > > configure.ac, Makefile.am/Makefile.in/Makefile, and any .sh scripts that
> > > are part of the source tarball are part of the build system, even if the
> > > interpreters that are used to run them are not.
> >
> > This is completely irelevent, why did you write it?
>
> Because they are also build systems that were written before projects
> that use them. It is not completely irrelevant; it works exactly the
> same way as your claim.
OK, but why do you like to treat this build system differently from the
"Schily makefilesystem"?
> [...]
> > GNU make is unmaintained since at least 7 years,
>
> GNU make has seen at least 227 updates since 2000 alone, some of which
> are *very* significant. How does that count as "unmaintained", other
> than "They do not incorporate Joerg Schilling's patches"? Would you
> incorporate any random patch for cdrecord which I would send your way,
> /even/ if it is not an evil patch that tries to circumvent whatever you
> try to do with cdrecord?
If the "Maintainer" of GNU make admits that there is a seriuos problem
in GNU make regarding to treating "include" files and tells me that it will
take some time to rewrite GNU make in order to fix this serious bug...
If you take into account that I did point him to the correct implementation
used in smake and allowed him to use this algorithm...
If you check 7 years !!!! later and you see that nothing happened, what
would you call GNU make?
If you send abug report for a problem in GNU make that causes GNU make
to dump core in case that the environment has a specific content and
it is less than 5 lines of code to change to fix this problem....
If you check 18 months later (after a "new" source has been oublished)
and this GNU make bug is still present, how would you call the state of
GNU make?
> You know, I knew about your reputation, but was willing to forget all
> about it, just for the remote chance that you might see the light for
> once.
>
> I was being silly:
If you know about my reputation, why do you behave so silly?
I am the author of a lot of OSS and you seem to be rather unknown
in the OSS community.
> I've been using GNU make for over six years now. I've never come into
> contact with a feature of which I thought "gee, this is terribly
> non-userfriendly".
This is childish :-(
> Right, so it would seem that in order to avoid GPL issues, you have
> three options then:
>
> * Distribute the "Schily Makefilesystem" under the GPL, so that there
> are no conflicts.
> * Distribute the "Schily Makefilesystem" under a different license, but
> in a separate package. This means it's not part of the cdrtools
> package, so does not /need/ to be GPL. If it's still a DFSG-free
> license, then cdrtools wouldn't even have to be moved to contrib
> (provided it's still under the GPL and not something non-free; I heard
> rumours to the contrary, but haven't checked the license myself)
> * Make sure the Makefile in the mkisofs package can somehow work without
> the "Schily Makefilesystem". Don't know whether this is feasible.
Are you really so inflexible to not try to understand the GPL first,
but parrot simple boilerplates that do not apply to our case?
I do not like to comment the rest of your mail as it is wrong and not worth
any further discussion as long as you fail to understand the basic rules of the
GPL.
I encourage you to read and understand the GPL and if you still find problems
with cdrtools, send an explanation based on _real_ quotations (that are not
used out of context) from the GPL.
As long as you quote the GPL out of context or as long as you try to create
statements that cannot be found in the GPL, let us asume that people from Debian
are on an unsubstancial calumniation campaign against my software.
For this reason, I ask you to mark the related entries in the BTS
as "resolved and closed"
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: