On 04/04/12 14:24, Alex Rønne Petersen wrote:
GPL extends to the build system? This is news to me... that seems a little
overzealous... (or maybe I'm interpreting it incorrectly)
But point taken. If that's how the GPL works, then that's how it is.
From Section 1 of the GPL:
The “Corresponding Source” for a work in object code form means all the
source code needed to generate, install, and (for an executable work) run
the object code and to modify the work, including scripts to control those
activities.
To see why it matters, imagine a corporate entity releasing a large, complex
piece of software where the code was under a free licence but the build system
was proprietary and internal to the company. It'd be a major block to
practically enjoying the licence freedoms.
I just don't think I'm seeing where the problem arises, since Waf's license is
very permissive. But IANAL, etc. ;)
IANALE, but I think the essential point is that the GPL requires source code to
be provided in the appropriate form for editing. Again from Section 1:
The “source code” for a work means the preferred form of the work for making
modifications to it.
The fact that part of the Waf script is zipped up and therefore not immediately
available to read might in principle be a violation here -- it's certainly a
problem for Debian who view it as imposing an unreasonably hard burden on anyone
wishing to tweak the build system e.g. to fix bugs.
However, what really got the Debian guys going is that what's in the zipped file
has been processed to remove comments, whitespace etc., so it doesn't actually
correspond to the GPL definition of the "source code". Further, the code is a
subset of what's provided in the Waf git repo.
It follows that there is no availability of adequate source code (in the GPL
sense of "preferred form for making modifications") corresponding to what's in
the Waf script. So, there is almost certainly a GPL violation if Waf is being
distributed as the build script for GPL (or AGPL, or LGPL) licensed software.
It's a shame, because this doesn't seem like a technically insurmountable
problem; it's almost certainly down to lack of appreciation of these legal
issues on the part of the Waf devs. That's one reason why I was so concerned
over the docs licensing -- it's such an obviously nasty thing to do where FOSS
is concerned.
Oh, don't worry - most discussions on the D newsgroups in general often branch
into rather tangential discussions; people don't really mind this at all.
Thank you :-) I'm always conscious about kicking up such discussions as a new
and non-contributing party to a product. Just so long as it is valuable ... :-)
Not at all. This discussion has been enlightening to me as well.
Excellent. :-)
All this being said, I don't know of any other good build tool for D (and GDC in
particular) at the moment. You may have to resort to using Make and/or
Autotools. :/
I don't mind working with the GNU Autotools at all -- I've used them for other
projects -- but I'm concerned about the extent of their support for D. As you
probably know when you're setting up a configure.ac file, you usually call
various macros checking e.g. for the presence of the language and corresponding
compiler, and so on. I'm not sure whether the Autotools currently have the
macros needed to work with gdc.
I actually looked into this a few years back and exchanged a few emails with the
autoconf/automake devs about putting those macros in place, but I quickly
realized that the m4 scripting required was beyond me, or at least beyond the
practical time commitment I could put in. :-(
