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> 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> > 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> 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> 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> 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 >>> 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 > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
