On Wed, Aug 02, 2006 at 04:32:58PM +0200, Joerg Schilling wrote:
> 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?
I can quote major parts of it by heart since a few years, does that
> > 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.
> > 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".
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.
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
> 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".
You seem to have a very strange sense of English.
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".
> > 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.
My point exactly.
> > > Note it is unclear whether the makefiles could be called "scripts"
> > Unproven assertion.
> Unproven claim!
The point was: can you give me any sane description of "script" that
does not hold for Makefiles?
> > 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.
> 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?
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
I was being silly:
> it has many bugs that make it extremely user-unfriendly when used
> together with "The Schily Makefilesystem"
"Doctor, I have a headache when I drink coffee with the spoon still in
"Don't do that, then".
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
> 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
> _project-independent_ makefiles/rules.
> - 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
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.
> > > *) 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)
"You must cause any work that you distribute or publish, that in whole
or in part contains or is derived from the Program or any part thereof,
to be licensed as a whole at no charge to all third parties under the
terms of this License."
What part of "to be licensed as a whole (...) under the terms of this
License" do you not understand?
> > > 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.
This is not nonsense. In Belgium, the very definition of a "contract"
involves two parties putting their signature on a piece of paper.
This is the same in many jurisdictions.
(Even if the law has modernised and now recognizes digital signatures as
legally binding, you /still/ need to sign in order to make it a legal
> 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
> legal form.
"Terms" and/or "conditions" would work. "Contract" would not.
> So before answering again: read the GPL and try to understand it.
I did. Now it's your turn.
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
- Re: cdrtools
- From: Joerg Schilling <firstname.lastname@example.org>
- Re: cdrtools
- From: Joerg Schilling <email@example.com>