cpphs (was Re: Haskell on Red Hat Enterprise...)

[Malcolm Wallace]

Andy Moran <moran at galois.com> writes:

> I notice that cpphs understands CPP stringification (if invoked with 
> --hashes). Most of the gcc 3.4 failures (in fact, all of that I've seen) 
> have to do with fooling -traditional into turning macro constants into 
> Haskell strings, which can more readily be done with the #-operator. So, 
> would using cpphs mean we could do away with the string gap hack?

Without seeing the examples in question, I can't say for definite, but
cpphs /does/ preserve string gaps in source code in all cases.  In
addition, you can paste symbol values into strings using either the
ANSI stringification operator (#) or the traditional behaviour of
expansion within quotes ("SYMBOL").

> What implications does the LGPL have for a GHC binary that was built 
> using  cpphs, if the GHC binary were used solely within an organization 
> (i.e. not distributed)?

Both the GPL and LGPL lay obligations on the user of the code only if
they re-distribute it - it has no impact on internal use if there is no
re-distribution.

> What if cpphs were distributed with such a GHC 
> binary as an executable?

If cpphs is distributed as a stand-alone binary, then you must respect
the conditions of the GPL with regard to that program (only), i.e.
permit re-distribution, publish modified source code etc.  This by itself
does not place any further restrictions on any of your own software you
distribute with it.  In GPL terms, this is "mere aggregation", which is
non-infective.  Your own GHC-produced binary can have any licence you like.

It is only if you were to re-use the code from cpphs as a library linked
into your own software, that restrictions would apply to your software.
In the case of the LGPL, the end user must be given the right to remove
cpphs and replace it with a newer version, which tends to imply that you
need to link it dynamically rather than statically.  However, I expect very
few people would need to incorporate cpphs as a library - the stand-alone
executable situation is far more likely.

Regards,
    Malcolm