Modularization mailing list and initial strawman proposal

[Adam Jackson]

On Thursday 24 March 2005 20:50, Jeremy C. Reed wrote:
> On Fri, 25 Mar 2005, Roland Mainz wrote:
> > This is the part which I fear a lot: The autotools pick up dependices to
> > things they find on the system regardless whether this is usefull or
> > not. I have VERY bad experiences with this kind of autodetection and
> > it's one of the things which forced people to have seperate, clean build
> > machines just to make release builds of Mozilla/Firefox/etc. on some
> > platforms (or use an chroot'ed environment (which was a pain in the past
> > as some stuff as the license manager stuff in the Sun Workshop 5 days
> > was very allergic against chroot'ed environments when you had a
> > node-specific license)).
>
> And speaking of licenses ... the license of the X code has helped it
> propogate. The build tools (imake etc.) were same licensed. Moving to
> autoconf/libtool/automake will make the X.org depend more on code that is
> less free license and maybe discourage people from helping on the build
> tools for Xorg.
>
> (Maybe I should rephrase that: s/less free/a different/).
>
> What about building an alternative to automake/autoconf/libtool that has
> our same license?
>
> (I have heard many discuss that an improvement is needed.)
>
> buildtool is one alternative that could be worked on.
>
> Where is the document/URL about the negatives of continuing with imake?
>
> I'd personally prefer that the Xorg team didn't dedicate time to improving
> the GNU tools ...

If this is seriously an issue - major "if" there - I would strongly prefer 
that we simply adopt one of the other MIT-ish licensed build systems:

http://www.scons.org/
http://www.perforce.com/jam/jam.html
http://www.cmake.org/HTML/About.html
...

Because I'm in no mood to write one myself, and I think it's way outside the 
scope of X.org.  This is why imake has no maintainer.

However, I think this is a _really_ weak argument.  The GPL covers only the 
autotools scripts themselves.  It does not cover the input that you feed 
them, and it does not cover the output they generate.  So fixing the 
automakefiles in X does not require touching any GPL-licensed code.

It's a matter of what incentive model you're after.  Yes, the MIT license 
helped X get traction in the form of commercial adoption, but it also means 
that there's millions of lines of code that build on X that will never see 
the light of day.  All the engineering effort that went into Xsun, Xsgi, Xhp, 
etc?  Gone.  Kiss it goodbye.  [1]

Also note that the GPL only says you have to provide the source to your 
modifications if you distribute your modifications.  If your X-based 
product's build system really needs an extended automake, and that modified 
automake is never distributed to customers and never leaves the corporate 
network, then you're clear.

We want X everywhere, right?  That means we want a build system that works 
everywhere.  The share-alike clause of the GPL acts to actively spread 
autotools' support to more platforms.  Take as an example QNX, where 
apparently the autotools support is poor.  If we depend on autotools, and 
someone wants X on QNX, then the effort expended on fixing autotools for QNX 
also enables thousands of other packages on that platform.  Conversely, if 
someone wants the GNU binutils on QNX badly enough to fix autotools, we get 
autotools ported to QNX essentially for free.

There's no such hook in an MIT-licensed build system.  And the license really 
doesn't affect us at an engineering level simply because we really don't need 
to change anything about autotools.  As a practical matter, the autotools 
work everywhere we support, and they have all the features we need.  Don't 
want to work on autotools?  Fine, don't.  Someone else will, and you can 
coast on their effort.

Now granted, this is an education problem.  There are lots of managers out 
there for whom the very whisper of the letters "GPL" is enough to cause 
cardiac arrythmia.  That's fine; they need to display some adaptability, and 
we need to make sure our marketing and documentation reflects facts and not 
FUD.

If anyone can come up with a scenario where there is a solid technical reason 
why requiring some GPL-licensed build tools will hinder our adoption, I'm all 
ears.  But if the concerns are limited to undereducation or purity of 
essence, then I'm not going to give those arguments a whole lot of weight.

- ajax

[1] - Promises of code delivery from these beasts are wonderful, and Sun in 
particular has done a decent job of this.  Actual delivery is more important, 
and the ratio of code contributed versus code behind bars is reeeal lopsided.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-modular/attachments/20050324/5c34f854/attachment.pgp