[Haskell-cafe] RFC: "Native -XCPP" Proposal

[Boespflug, Mathieu]

Hi Lars,

I'm really not sure that the community has the resources to spare to
reimplement non-trivial pieces of *standalone (non-library)* software
to address perceived but ethereal "business problems" that are based
on lack of understanding about how IP law works as both you and Carter
point out. Especially if there are no strong technical reasons to shun
the existing implementation, which is perfectly good quality.

Does the above cited compromise...

>> it seems to me that isolating cpphs into a separate process (w/ the
>> option to configure GHC to use some other cpp implementation at your
>> own risk if you need to avoid the cpphs implementation at all costs)
>> would be the compromise acceptable to everyone in the short run while
>> addressing the primary goal to decouple the default-configuration of
>> GHC from the fragile system-cpp semantics.

... sound fair to you?

Best,

Mathieu


On 27 May 2015 at 22:21, Lars Kuhtz <haskell at kuhtz.eu> wrote:
> Carter, your explanation why the usage of LGPL is perfectly fine in most
> scenarios involves technical as well as legal details. My point is, that it
> is not a technical, probably not even a legal issue. I completely agree with
> you that it is a business problem. But it makes adaptation of GHC in a
> business more difficult if it creates business problems.
>
> Decisions are made most efficiently when there are rules of thumb. Such a
> rule is that BSD or MIT style licenses are not problematic. But if a GPL
> style license shows up some special treatment is needed. And a solution
> requires a detailed communication between two groups of persons who usually
> don't deal directly with each other and speak very different languages.
>
> This problem can be solved, and we actually solved it, and we use GHC. But
> it is annoying and it tends to come up again regularly.
>
> For a small company which considers adopting Haskell it would be best if
> that decision was a purely technical decision. With LGPL style libraries in
> the mix it isn’t a purely technical decision any more.
>
> Lars
>
> On May 27, 2015, at 12:11 PM, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> Lars,
> which users have an issue? could you please be concrete? Because I frankly
> think you are being a bit vague.
>
> gmp on linux platforms is dynamically linked, so it has absolutely zero
> implications there. For those wanting to deploy a proprietary appplication
> on windows or OSX, they merely need to either a) bundle the dylib with the
> application and suitable install scripting to adjust the load paths.  (or
> build the integer simple version of GHC and navigate choosing dependencies
> that depend on integer-gmp specifically being installed )
>
> any other problems with industrial usage and libgmp are artifacts of dealing
> with business or legal staff that have not been educated about how
> intellectual property law works. Which is business problem rather than a
> haskell problem.
>
>
>
> On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz <haskell at kuhtz.eu> wrote:
>>
>> On 21/05/15 19:07, Herbert Valerio Riedel wrote:
>> >> Don't you still have to support -pgmF?
>> >
>> > I guess so, unfortunately... so we'd have to keep a legacy code-path for
>> > external cpp processing around, at least in the short run...
>>
>>
>> I think it’s unfortunate if industrial usage of GHC is supported only
>> through legacy code-paths.
>>
>> I think non-technical arguments do matter here. It is about explanations.
>> Convincing a company to use Haskell can be already quite a challenge.
>> Additional legal issues don’t make that easier.
>>
>> The gmp dependency is causing already enough trouble for industrial users.
>> Let’s not just add another licensing issue.
>>
>> Lars
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>