GPL3 encumbrance

[GoogleCodeExporter]

trunk distcc now depends on libiberty (binutils), which is GPL3-licensed.  
Unfortunately that makes it ineligible for use in my work (my employer limits 
any use of GPL3 software to personal use and requires prior approval).  Would 
you consider an option to remove that dependency?

Original issue reported on code.google.com by dave@boostpro.com on 27 Feb 2014 at 10:26

[GoogleCodeExporter]

Yes. The licensing effect of that change was not considered and is not what I 
would have intended.

Original comment by fer...@google.com on 27 Feb 2014 at 11:45

[GoogleCodeExporter]

Oh, that’s great news.  As noted earlier, it would be a stretch for me to 
make any such contribution myself, but I’ll watch this issue eagerly so I can 
start using distcc again when it’s resolved.

Thanks!

Original comment by dave@boostpro.com on 28 Feb 2014 at 5:26

[GoogleCodeExporter]

Distcc must process @FILE arguments the same way as gcc.  This means either 
using libiberty, or more-or-less copying the code directly from there and 
keeping it in sync.

Libiberty as a distinct component is GPL2+ according to its own header files 
and information in (libiberty)/debian/copyright.  On Debian it is now packaged 
separately from binutils.

GCC is already GPLv3, are you using distcc with a different compiler?  Are you 
not using ld from binutils?

Original comment by mand...@gmail.com on 3 Mar 2014 at 6:09

[GoogleCodeExporter]

I’m using clang.  I’m pretty sure coding up expandargv is pretty trivial 
and certainly doesn’t need ongoing maintenance.  The libiberty source 
contains both GPL2 and GPL3 license files at the top level of its source tree.  
Even if libiberty is only GPL2 in some circumstances, the situation is murky 
enough to be impractical for me.

Original comment by dave@boostpro.com on 3 Mar 2014 at 7:21

[GoogleCodeExporter]

A previous attempt did not do so well, and had a subtle difference
that was difficult to spot manually.  See discussion of issue 85 for
details.  You are welcome to submit your own original patch.  Please
consider how to demonstrate its (ongoing) correctness without
referring to implementation details of expandargv (which may introduce
"murky" licensing issues).

Leading to another instance of "distcc produces different output to
no-distcc" when expandargv is perhaps changed subtly in the future.

Elsewhere it was suggested to make libiberty optional, and disable
@FILE argument handling if it was absent.  Also welcome to submit
patch for this, preferably with a proper error message if distcc is
invoked with the unsupported arguments.

Original comment by mand...@gmail.com on 3 Mar 2014 at 9:48

[GoogleCodeExporter]

As noted in https://code.google.com/p/distcc/issues/detail?id=138#c6, I’m 
unable to make FOSS contributions right now, but I can suggest a way to deal 
with the maintenance issue: instead of trying to keep up with GCC, let Clang do 
that.  It’s already in their mission statement: 
http://clang.llvm.org/docs/DriverInternals.html#gcc-compatibility

If I had to guess what distcc needs to do, I would bet that the clang driver 
would be useful to this project in many ways.

Original comment by dave@boostpro.com on 4 Mar 2014 at 8:23

[GoogleCodeExporter]

I would be happy even to be able to have a --without-libiberty flag to 
configure (and lose the @FILE capability when it’s used).  I tried to do that 
myself, but I’m too incompetent with autoconf to figure out how :-(.

Original comment by dave@boostpro.com on 23 Mar 2014 at 3:53

[GoogleCodeExporter]

Success!  Here’s a patch that worked for me

Original comment by dave@boostpro.com on 1 Apr 2014 at 9:57

Attachments:

• without-libiberty.patch

[GoogleCodeExporter]

Thanks.  Fixed in revision 791.

Original comment by fergus.h...@gmail.com on 2 Apr 2014 at 11:23

• Changed state: Fixed