Use of gnu build tools for Unix environments relicenses the code as LGPL

[GoogleCodeExporter]

If you don't see this as a problem, then feel free to close this issue, but
please read through the issue first before making a decision. Personally, I
never quite thought of this as a problem until recently, but this could
potentially serve as a problem if someone compiles the library through
their build tools and they decide to make a proprietary application. CMake
being BSD licensed probably works around this well enough, but I think that
any build library which might potentially lock in users to a specific
license other than BSD probably should get discontinued, in order to make
sure that anything you provide doesn't lock them into a license that they
might not want to use.

However, you could use BSDBuild instead (which can be found at
http://hypertriton.com/bsdbuild/) and have the whole process be invisible
to Linux users. Best part of that solution though is that BSDBuild offers
something that the gnu build tools don't, and that's that it can generate
project files for various IDE's like CodeBlocks or Visual Studio. Don't
take this so much as trying to push this specific build system, just that I
think that when distributing build files, they shouldn't lock in the user
more than the BSD license.

Thoughts on this issue?

Original issue reported on code.google.com by irar...@gmail.com on 8 Jun 2009 at 5:24

[GoogleCodeExporter]

What makes you think the license of the build tool would affect the project? 
Guichan
is not based on a build tool, it just ships with one. Neither the GPL nor the 
LGPL
affect other software bundled in the same distribution.

That said, I'm all for going with one build tool instead of two. CMake is 
probably
the one that works better overall. I'm currently still using autoconf though.

Original comment by b.lindeijer on 9 Jun 2009 at 10:11

[GoogleCodeExporter]

Björn, you once told me - when I wanted to switch build system - that it's a 
good
idea to have autotools as most Linux distributions are familiar with autotools, 
and I
think that's a good point.

Personally I don't like autotools at all, and I would much rather just use 
CMake. I
once started to work on a switch to CMake, but at the moment non of the 
examples are
built, which is a pity.

I think we should switch to CMake, but still keep the autotools stuff as it is,
perhaps update them when required or simply let users of autotools update it.

I don't know much about BSDBuild, but judging from their site I think CMake is 
better.

Original comment by olof.nae...@gmail.com on 10 Jun 2009 at 11:31

[GoogleCodeExporter]

Ok, I mainly mentioned it because you can still run ./configure, make, and make
install through it just like you can with the GNOME tools, so to the user, it 
would
remain invisible. The biggest difference is just the license for the build 
tools.

Original comment by irar...@gmail.com on 10 Jun 2009 at 4:09

[GoogleCodeExporter]

Perhaps I phrased it poorly, Bjorn, but what I meant is that the default way of
compiling GUIChan right now (gnu build tools) makes it so that the code is 
relicensed
as LGPL whether that was the intention of the person compiling it or not. The 
issue
here isn't that the user shouldn't be able to do that if they don't want to, 
just
that I don't think that any of the build solutions should impose a particular 
license
on the user other than BSD, hence why I think that it should be dropped. And 
like I
said in the previous post here, I was suggesting something like BSDBuild as a
replacement solely because it would remain invisible to the person compiling the
project on linux while keeping the standard make sequence that users on Linux 
expect.
I'm sure there are other BSD solutions which might work as well, and CMake alone
might be alright, but it would be nice if a change to this was made as 
invisible as
possible to any maintainers who are packaging this in a Linux distro, as well as
keeping everything BSD compatible unless a user overrides that themselves, 
instead of
having the license addition imposed on them.

Personally, I'd like to continue to be able to run ./configure, make, and make
install as is, since I do use Linux and don't like to think a lot about special
compile instructions any time I need to rebuild a new package, and if that 
means that
I'm submitting new build scripts in order to be able to have that convenience, 
then I
suppose that's what I'll need to do. But I would like to be able to see the 
GUIChan
library as a whole be usable as pure BSD through any of the build scripts, 
since I
think that using gnu build tools breaks that.

Also, I don't know of any BSD project that uses the gnu build tools as well, 
which is
what got me thinking about this in the first place.

Original comment by irar...@gmail.com on 10 Jun 2009 at 6:00

[GoogleCodeExporter]

I think I explained well enough that the license of the build tool does not 
spread
out to Guichan, since they are two separate things that are not even based on 
each
other. Building Guichan using GNU make does not cause the license of GNU make to
apply to Guichan. Just like you can edit images in GIMP without suddenly having 
to
license them under the GPL.

Olof, maybe my opinion was stronger in the past, but if CMake can replace the
autotools completely then I think this isn't a bad idea. The one thing I am 
missing
with CMake is the 'make dist' target, however I don't think you need this with 
CMake
since you could probably just use 'git archive' to make the distribution too. 
As for
easy to build, to a distribution this really shouldn't matter. All of KDE is 
based on
CMake too, so they should already be familiar with it. And there is nothing more
complicated about running 'cmake .' instead of './configure'.

Original comment by b.lindeijer on 10 Jun 2009 at 9:37

[GoogleCodeExporter]

Then I guess we switch to CMake.

Original comment by olof.nae...@gmail.com on 11 Jun 2009 at 6:27