Well said. <div><br></div><div>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. <span></span><br><br>On Thursday, May 28, 2015, RodLogic <<a href="mailto:dev@rodlogic.net">dev@rodlogic.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>Having said that, in both occasions, the LGPL dependencies were, ultimately, not an impediment to continuing negotiations. They were definitely a friction, though.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 5:41 PM, Lars Kuhtz <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','haskell@kuhtz.eu');" target="_blank">haskell@kuhtz.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div><br></div><div>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.</div><div><br></div><div>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.<div><div><br><div><br><div><blockquote type="cite"><div>On May 27, 2015, at 2:00 PM, Carter Schonwald <<a href="javascript:_e(%7B%7D,'cvml','carter.schonwald@gmail.com');" target="_blank">carter.schonwald@gmail.com</a>> wrote:</div><br><div><div dir="ltr">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!<div><br></div><div>was using GCC an issue at this organization too? because that would be a real problem! 'cause tis GPLV3 rather than LGPL! :) </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 4:21 PM, Lars Kuhtz <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','haskell@kuhtz.eu');" target="_blank">haskell@kuhtz.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><span><font color="#888888"><div><br></div><div>Lars</div></font></span><div><div><br><div><blockquote type="cite"><div>On May 27, 2015, at 12:11 PM, Carter Schonwald <<a href="javascript:_e(%7B%7D,'cvml','carter.schonwald@gmail.com');" target="_blank">carter.schonwald@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Lars,<div>which users have an issue? could you please be concrete? Because I frankly think you are being a bit vague.</div><div><br></div><div>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 )</div><div><br></div><div>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. </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','haskell@kuhtz.eu');" target="_blank">haskell@kuhtz.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 21/05/15 19:07, Herbert Valerio Riedel wrote:<br>
</span><span>>> Don't you still have to support -pgmF?<br>
><br>
> I guess so, unfortunately... so we'd have to keep a legacy code-path for<br>
> external cpp processing around, at least in the short run...<br>
<br>
<br>
</span>I think it’s unfortunate if industrial usage of GHC is supported only through legacy code-paths.<br>
<br>
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.<br>
<br>
The gmp dependency is causing already enough trouble for industrial users. Let’s not just add another licensing issue.<br>
<span><font color="#888888"><br>
Lars<br>
</font></span><div><div><br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','ghc-devs@haskell.org');" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></div><br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','ghc-devs@haskell.org');" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>
</blockquote></div>