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

[RodLogic]

Based on two different occasions with two different companies (one related
to an acquisition and one to an OEM agreement), my experience is exactly as
laid out by Lars. A LGPL license will raise concerns by the legal team and
it will delay the process because it comes with a certain level of risk
that they may or may not want to take. And good luck trying to find a
precise reason why LGPL is fine or it isn't in all cases: the reality is a
bit more complicated and with a few more shades of grey.

Having said that, in both occasions, the LGPL dependencies were,
ultimately, not an impediment to continuing negotiations. They were
definitely a friction, though.


On Wed, May 27, 2015 at 5:41 PM, Lars Kuhtz <haskell at kuhtz.eu> wrote:

> The issue that GMP is LGPL licensed came up a couple of times in
> discussions at PivotCloud. Before each product release developers were
> requested to provided a list of all third party dependencies along with
> their licenses. This was given to the folks who deal with the legal stuff.
> If they spoted anything with (L)GPL in it, they had general concerns. Also
> someone also had heard some rumors on the web about issues with GMP and GHC
> (like for instance this thread in the mailing list archives :-) ) adding to
> the uncertainty. Some time back I was even asked to build GHC without GMP,
> which, at least at that time, wasn’t fun to do; though we never used that
> build.
>
> As a more general and not directly related remark: when I was working at
> Microsoft there were rules how to deal with open source software based on
> the style of the license. At least in my group anything with (L)GPL was
> simply a no-go without any further discussion about details.
>
> From this experience I think that if we want to make adaption of Haskell
> easy we may avoid (L)GPL when possible. If we can’t avoid it, well,
> probably it wouldn’t be a disaster neither.
>
>
> On May 27, 2015, at 2:00 PM, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> could you be concrete about the specific challenges and experiences you've
> had, and with what organizations? Its very hard to evaluate the veracity of
> what youre saying otherwise!
>
> was using GCC an issue at this organization too? because that would be a
> real problem! 'cause tis GPLV3 rather than LGPL! :)
>
> On Wed, May 27, 2015 at 4:21 PM, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150528/7e748bf2/attachment-0001.html>