RFC: "Native -XCPP" Proposal

Fri May 29 01:35:31 UTC 2015

Well said.

However, until Someone finds the time to write something with a nicer
license, that's a cross we'll have to bear. Otoh, the shelling out approach
for cpp in the mean time has zero issues vs linking to a lgpl or gpl
library.  Unless those are organizations that done use Linux or gcc
anywhere.

On Thursday, May 28, 2015, RodLogic <dev at rodlogic.net> wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','ghc-devs at haskell.org');>
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> <javascript:_e(%7B%7D,'cvml','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/f18015d1/attachment-0001.html>