Wouter Verhelst <email@example.com> wrote:
> > You should better _read_ the GPL and try to understand it.
> Good plan.
Did you have some time to make your plan reality meanwhile?
> > GPL §2 defines what the "work" is and requres to publish the whole
> > work under the GPL in case that that work incorporates other
> > peoples work under GPL. (*)
> > The GPL allows to publish "the scripts used to control
> > compilation and installation of the executable." under _any_ license
> > as the scripts are not part of the "work".
> These scripts are referred to in GPL§3, not §2. So much for reading the
Wow, so it seems that you did read at least parts of the GPL...
> 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.
> Additionally, it defines "source code" as follows:
> The source code for a work means the preferred form of the work for
> making modifications to it. For an executable work, complete source
> code means all the source code for all modules it contains, plus any
> associated interface definition files, plus the scrips used to
> control compilation and installation of the executable.[...]
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".
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
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".
> I fail to see how your claim holds, given the above, but I'm willing to
> be educated.
You ned to carefully read the GPL as long as you need in order to understand
it by your own.
Do not read GPL FAQs, as most of them (including the one from FSF) are not
> > Note it is unclear whether the makefiles could be called "scripts"
> Unproven assertion.
> > and that in case of cdrtools, the build system is even a _different_
> > "work" that has been published _before_ the first cdrecord came out.
> If you're referring to smake here, then I cannot help but disagree with
It would help a lot if you did educate yourself about the problem _before_
you try to comment it...
> 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?
> In the same way, smake is indeed a different work, but the makefiles
> that are shipped with cdrecord are not.
> Am I missing something?
You did miss nearly everything of importance :-(
I encourage you to look at _cdrtools_ and not at any random other project.
While smake is of course older than GNU make, it is (currently) not needed
in order to compile cdrtools. This may change in future in case that I need
features that are not present with GNU make.
Note that smake could have died 10 years ago, but I needed to maintain
and enhance it in order to get a really portable make program.
GNU make is unmaintained since at least 7 years, it has many bugs that
make it extremely user-unfriendly when used together with "The Schily
Makefilesystem" and GNU make is far less prtable than smake. This is why
I recommend smake to compile my software.
It is obvious that it makes more sense to put effort in an own project than
wasting time with un-responsive GNU make maintainers.
smake is not part of cdrtools but another project I am working on:
"The Schily Makefilesystem"
is. This is definitely a project that is _separate_ from cdrtools but included
as a sub-project.
- This project ("The Schily Makefilesystem") contains > 300 kB of
- The "Makefile" that is e.g. part of the "mkisofs" project is
only 2477 bytes in size. Only 1243 Bytes in this file are specific
to mkisofs and not copied from a (project-independent) template.
- The "Makefile" that is e.g. part of the "mkisofs" project comes
with the _same_ license as "mkisofs" comes and _this_ file is of
course part of the sub-project "mkisofs". This _project-dependent_
file is much less than 1% of the project indepenent "The Schily
> > *) It does not even require to publish the whole work under the GPL
> > in case that you add code to a GPL project! In this case the added
> > code may under _any_ license (even Closed source).
> Could you quote the part of the GPL on which you base this assertion? It
> is not clear to me.
I did this already many times: GPL §2 (first sentence) and GPL § 2b)
> > AGAIN: If you like to understant/interpret a contract like the GPL,
> The GPL is a license, not a contract.
You should try to ask a lawyer in order to get some basic legal knowledge
before writing nonsense.
The GPL could be either taken as a "contract" or the "terms of business
conditions" (depending on the view of a judge). A license is not a separate
This is at least true for most parts of the world...
> > you need to read it carefully word by word and are not allowed to
> > add claims that are not written in the GPL.
Well as long as it stays your intention only but is not turned into
reality, it does not help....
So before answering again: read the GPL and try to understand it.
EMail:firstname.lastname@example.org (home) Jörg Schilling D-13353 Berlin
email@example.com (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily