To clarify my point more concretely: 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
Using cpphs as a library is Another discussion. But I don't think it's the one we're having today. On Friday, May 8, 2015, Carter Schonwald <carter.schonw...@gmail.com> wrote: > Indeed. This is also how we use gcc and the llvm tooling. > > If we want the cpp tooling to be available as a library, that's a whole > nother set of needs. > > 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. > > 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. > > > > On Friday, May 8, 2015, Mathieu Boespflug <mb...@tweag.net > <javascript:_e(%7B%7D,'cvml','mb...@tweag.net');>> wrote: > >> [Gah, wrong From: email address given the list subscriptions, sorry >> for the duplicates.] >> >> I'm unclear why cpphs needs to be made a dependency of the GHC API and >> included as a lib. Could you elaborate? (in the wiki page possibly) >> >> Currently, GHC uses the system preprocessor, as a separate process. >> Couldn't we for GHC 7.12 keep to exactly that, save for the fact that >> by default GHC would call the cpphs binary for preprocessing, and have >> the cpphs binary be available in GHC's install dir somewhere? >> >> fork()/execvce() is cheap. Certainly cheaper than the cost of >> compiling a single Haskell module. Can't we keep to this >> separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep >> most license tainting concerns that way. >> >> >> On 8 May 2015 at 11:39, Herbert Valerio Riedel <hvrie...@gmail.com> >> wrote: >> > Hello, >> > >> > On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: >> >> If the intention is to use cpphs as a library, won't the license >> >> affect every program built with the GHC API? That seems to be a high >> >> price to pay. >> > >> > Yes, every program linking the `ghc` package would be affected by >> > LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: >> > >> > | - As a practical consequence of the //LGPL with >> static-linking-exception// >> > | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** >> > | (i.e. the LGPL+SLE covered modules) of the GHC code-base, >> > | **then there is no requirement to ship (or make available) any >> source code** >> > | together with the binaries, even if other parts of the GHC code-base >> > | were modified. >> > >> > However, don't forget we already have this issue w/ integer-gmp, and >> > with that the LGPL is in full effect (i.e. w/o a >> static-linkage-exception!) >> > >> > In that context, the suggestion was made[1] to handle the cpphs-code >> > like the GMP code, i.e. allow a compile-time configuration in the GHC >> > build-system to build a cpphs-free (and/or GMP-free) GHC for those >> > parties that need to avoid any LGPL-ish code whatsoever in their >> > toolchain. >> > >> > Would that address this concern? >> > >> > >> > [1]: >> http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > haskell-c...@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs