To clarify my point more concretely: <div><br></div><div>Adding cpphs the cli tool to ghc build process / bin dist has no more licensing implications than does using gcc as a compiler / assembler. Ie NONE</div><div><br></div><div>Using cpphs as a library is Another discussion. But I don't think it's the one we're having today. <span></span></div><div><br></div><div><br><br>On Friday, May 8, 2015, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Indeed. This is also how we use gcc and the llvm tooling.  <div><br></div><div>If we want the cpp tooling to be available as a library, that's a whole nother set of needs.  </div><div><br></div><div>Gmp lgpl I can brush under the rug at work because there's the various integer simple options, this gets a bit more squirrelly otherwise. </div><div><br></div><div>Maybe it'd be simpler for two people to sit down for a weekend, one only narrating the cpphs code, the other only listening and paraphrasing it into a new program.  Copyright on text only covers literal copying.  Nontrivial rephrasing of everything plus some rejiggering of non local structure is not prevented by copyright law, and I doubt there are any patents in play. </div><div><br></div><div><span></span><br><br>On Friday, May 8, 2015, Mathieu Boespflug <<a href="javascript:_e(%7B%7D,'cvml','mboes@tweag.net');" target="_blank">mboes@tweag.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Gah, wrong From: email address given the list subscriptions, sorry<br>
for the duplicates.]<br>
<br>
I'm unclear why cpphs needs to be made a dependency of the GHC API and<br>
included as a lib. Could you elaborate? (in the wiki page possibly)<br>
<br>
Currently, GHC uses the system preprocessor, as a separate process.<br>
Couldn't we for GHC 7.12 keep to exactly that, save for the fact that<br>
by default GHC would call the cpphs binary for preprocessing, and have<br>
the cpphs binary be available in GHC's install dir somewhere?<br>
<br>
fork()/execvce() is cheap. Certainly cheaper than the cost of<br>
compiling a single Haskell module. Can't we keep to this<br>
separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep<br>
most license tainting concerns that way.<br>
<br>
<br>
On 8 May 2015 at 11:39, Herbert Valerio Riedel <<a>hvriedel@gmail.com</a>> wrote:<br>
> Hello,<br>
><br>
> On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote:<br>
>> If the intention is to use cpphs as a library, won't the license<br>
>> affect every program built with the GHC API? That seems to be a high<br>
>> price to pay.<br>
><br>
> Yes, every program linking the `ghc` package would be affected by<br>
> LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page:<br>
><br>
> | - As a practical consequence of the //LGPL with static-linking-exception//<br>
> |   (LGPL+SLE), **if no modifications are made to the `cpphs`-parts**<br>
> |   (i.e. the LGPL+SLE covered modules) of the GHC code-base,<br>
> |   **then there is no requirement to ship (or make available) any source code**<br>
> |   together with the binaries, even if other parts of the GHC code-base<br>
> |   were modified.<br>
><br>
> However, don't forget we already have this issue w/ integer-gmp, and<br>
> with that the LGPL is in full effect (i.e. w/o a static-linkage-exception!)<br>
><br>
> In that context, the suggestion was made[1] to handle the cpphs-code<br>
> like the GMP code, i.e. allow a compile-time configuration in the GHC<br>
> build-system to build a cpphs-free (and/or GMP-free) GHC for those<br>
> parties that need to avoid any LGPL-ish code whatsoever in their<br>
> toolchain.<br>
><br>
> Would that address this concern?<br>
><br>
><br>
>  [1]: <a href="http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb" target="_blank">http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb</a><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a>Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a>ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
</blockquote></div>