RFC: "Native -XCPP" Proposal
carter.schonwald at gmail.com
Fri May 29 01:35:31 UTC 2015
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
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
>> 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
>> 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
>> 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
>>> 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.
>>> On May 27, 2015, at 12:11 PM, Carter Schonwald <
>>> carter.schonwald at gmail.com
>>> 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
>>>> 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
>>>> > 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.
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>> ghc-devs mailing list
>> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs