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 <d...@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 <hask...@kuhtz.eu > <javascript:_e(%7B%7D,'cvml','hask...@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.schonw...@gmail.com >> <javascript:_e(%7B%7D,'cvml','carter.schonw...@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 <hask...@kuhtz.eu >> <javascript:_e(%7B%7D,'cvml','hask...@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.schonw...@gmail.com >>> <javascript:_e(%7B%7D,'cvml','carter.schonw...@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 <hask...@kuhtz.eu >>> <javascript:_e(%7B%7D,'cvml','hask...@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@haskell.org >>>> <javascript:_e(%7B%7D,'cvml','ghc-devs@haskell.org');> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >>> >>> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> <javascript:_e(%7B%7D,'cvml','ghc-devs@haskell.org');> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
