On 05/20/2015 03:39 PM, Yitzchak Gale wrote: [--snip--]

Keeping the license as is seems to be important to Malcolm. So could we have an option to build GHC without cpphs and instead use it as a stand-alone external program? That would make the situation no worse than GMP.

I don't see any need for an option. Just bundle cpphs together with GHC and build/use it as an external program. AFAICT this has absolutely no licensing implications for GHC, derived from GHC or anything compiled with GHC. Regards,

Hi Yitzchak, On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote: [...]

Bardur Arantsson wrote:

...

I don't see any need for an option. Just bundle cpphs together with GHC and build/use it as an external program. AFAICT this has absolutely no licensing implications for GHC, derived from GHC or anything compiled with GHC.

Agreed, that would work. But I thought that the idea was that we wanted it actually integrated into GHC.

That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser. However, due to the, sadly, mostly non-technical issues brought up, it seems to me that isolating cpphs into a separate process (w/ the option to configure GHC to use some other cpp implementation at your own risk if you need to avoid the cpphs implementation at all costs) would be the compromise acceptable to everyone in the short run while addressing the primary goal to decouple the default-configuration of GHC from the fragile system-cpp semantics. NB: Nothing's been decided yet by GHC HQ PS: As an observation, http://packdeps.haskellers.com/reverse/cpphs shows that cpphs is already used by popular packages like hlint and haskell-src-exts (and thus an indirect build-dep of the haskell-suite project). Therefore, if LGPL+SLE is unacceptable in some work-environments, it may require some vigilance to keep track where cpphs may sneak into as a build-dependency... I'm surprised there's still such resistance given the ubiquity of Linux distributions made up of numerous (L)GPLed components, IMHO it's kinda like tilting at windmills... Cheers, hvr

On 2015-05-21 at 14:09:13 +0200, Yitzchak Gale wrote:

I wrote:

...

...

...I thought that the idea was that we wanted it actually integrated into GHC.

Herbert Valerio Riedel wrote:

...

That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser.

However, due to the, sadly, mostly non-technical issues brought up, it seems to me that isolating cpphs into a separate process (w/ the option to configure GHC to use some other cpp implementation at your own risk if you need to avoid the cpphs implementation at all costs) would be the compromise acceptable to everyone in the short run while addressing the primary goal to decouple the default-configuration of GHC from the fragile system-cpp semantics.

Correct me if I'm wrong:

GHC already supports using an external CPP processor as an option. And cpphs is already easily buildable as a stand-alone external CPP processor compatible with GHC.

Yes

So can't we incorporate cpphs into GHC as is, but also provide a build option to exclude it from a GHC build? In a non-cpphs build, CPP would only work if an external processor is provided.

Well, that's more or less the plan (I hinted at in what I wrote earlier) for cpphs-as-an-executable/isolated-process; Except that we may[1] not want to build a cpphs as you'd get if you simply 'cabal install cpphs' (as that would pull in more build-deps than desirable), but maybe implement a stripped down GHC-specific frontend to the cpphs library (while trying keep the original cpphs modules untouched, and/or contributing changes back to upstream so we don't diverge). In any case, the cpphs-ish tool bundled with GHC could be considered a GHC-specific fork of cpphs (and possibly with a GHC-tailored CLI) *and* you'd have the option as you suggest to exclude it from the GHC build, in order to create a GHC toolchain w/o any "cpphs" code (which uses e.g. the system-cpp as in the past).

That's even better than the GMP situation - it really would be simple and practical to create and use a non-cpphs GHC if needed. As opposed to a non-GMP build, which in reality is only a theoretical possibility to satisfy the lawyers.

[1]: I'm just thinking out loud here; it'll only become clear what's sensible once we have *actually* attempted to integrate cpphs into the GHC build-system, and have a working proof of concept (that'll need to be thrown at Hackage)

On 21 May 2015, at 15:54, Bardur Arantsson wrote:

fork/exec is almost certainly going to be negligable compared to the overall compile time anyway. It's not like GHC is fast enough for it to matter.

Don't count on it. On our Windows desktop machines, fork/exec costs approximately one third of a second, instead of the expected small number of milliseconds or less. The reasons are unknown, but we suspect a misconfigured anti-virus scanner (and for various company policy reasons we are prohibited from doing the investigation that could confirm or deny this hypothesis). This means that when ghc --make does lots of external things requiring a fork, such as preprocessing, a medium sized project (using many library packages) can take a surprisingly large amount of time (minutes instead of seconds), even for an incremental build where very little code has changed. We think an in-process cpphs could make some of our compilations literally hundreds of times faster. Regards, Malcolm

On 2015-05-21 at 16:54:11 +0200, Bardur Arantsson wrote: [...]

...

That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser.

fork/exec is almost certainly going to be negligable compared to the overall compile time anyway. It's not like GHC is fast enough for it to matter.

Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC with fork/exec, as opposed to simply calling into a native Haskell function and crossing process boundaries and having to deal with the various things that can go wrong with the additional moving parts you encounter when controlling an external process. So this would IMO simplify code paths, and moreover I'd expect opportunities to actually make the Haskell cpphs API richer (in case it isn't already) and more tailored to GHC's lexer/parser pipeline and error-reporting.

On 2015-05-21 at 18:02:57 +0200, Brandon Allbery wrote:

On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel

...

wrote:

...

Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC with fork/exec, as opposed to simply calling into a native Haskell function and crossing process boundaries and having to deal with the various things that can go wrong with the additional moving parts you encounter when controlling an external process. So this would IMO simplify code paths, and moreover I'd expect opportunities to actually make the Haskell cpphs API richer (in case it isn't already) and more tailored to GHC's lexer/parser pipeline and error-reporting.

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...

On 24 May 2015, at 14:15, Roman Cheplyaka 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...

It's not just about legacy; -pgmF is used for all sorts of awesome things; literate markdown is one example.

I think Herbert meant that -pgmP will also need to continue to be supported. Regards Malcolm

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 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

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 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 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 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

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 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 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 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@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 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

Hi Lars, I'm really not sure that the community has the resources to spare to reimplement non-trivial pieces of *standalone (non-library)* software to address perceived but ethereal "business problems" that are based on lack of understanding about how IP law works as both you and Carter point out. Especially if there are no strong technical reasons to shun the existing implementation, which is perfectly good quality. Does the above cited compromise...

...

it seems to me that isolating cpphs into a separate process (w/ the option to configure GHC to use some other cpp implementation at your own risk if you need to avoid the cpphs implementation at all costs) would be the compromise acceptable to everyone in the short run while addressing the primary goal to decouple the default-configuration of GHC from the fragile system-cpp semantics.

... sound fair to you? Best, Mathieu On 27 May 2015 at 22:21, Lars Kuhtz 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 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 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

LGPL is well-known and non-acceptable here. Show me some serious case law for Malcolm's customized LGPL and we can start talking. Other than that, explanations are not going to be helpful. Thanks, Yitz On Thu, May 21, 2015 at 4:51 AM, Howard B. Golden wrote:

Hi Yitzchak,

I believe there are good explanations of open source licenses aimed at lawyers and management. I don't think their fears are well-founded. If you work for a timid company that isn't willing to learn, you should consider going elsewhere. You may be happier in the long run.

Respectfully,

Howard

...

On May 20, 2015, at 7:39 AM, Yitzchak Gale wrote:

The license issue is a real concern for any company using GHC to develop a product whose binaries they distribute to customers. And it is concern for GHC itself, if we want GHC to continue to be viewed as a candidate for use in industry.

The real issue is not whether you can explain why this license is OK, or whether anyone is actually going to the trouble of building GHC without GMP.

The issue is the risk of a *potential* legal issue and its potential disastrous cost as *perceived* by lawyers and management. A potential future engineering cost, no matter how large and even if only marginally practical, is perceived as manageable and controllable, whereas a poorly understood potential future legal threat is perceived as an existential risk to the entire company.

With GMP, we do have an engineering workaround to side-step the legal problem entirely if needed. Whereas if cpphs were to be linked into GHC with its current license, I would be ethically obligated to report it to my superiors, and the response might very well be: Then never mind, let's do the simple and safe thing and just rewrite all of our applications in Java or C#.

Keeping the license as is seems to be important to Malcolm. So could we have an option to build GHC without cpphs and instead use it as a stand-alone external program? That would make the situation no worse than GMP.

Thanks, Yitz _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Malcolm Wallace wrote:

Interesting. I'm not completely clear, when you say that your company distributes binaries to third-parties: do you distribute ghc itself? Or just the product that has been built by ghc?

You're right. We only distribute binaries built by GHC. So whatever doesn't make it into the runtime is not a problem for us at the moment. But as Herbert pointed out, it may not be so simple for everyone. There is GHC API ; there are EDSLs; etc. Herbert Valerio Riedel wrote:

I'm surprised there's still such resistance given the ubiquity of Linux distributions made up of numerous (L)GPLed components, IMHO it's kinda like tilting at windmills...

A few years ago, people would have said that using open source in industry at all was like tilting at windmills. I'm very happy that's not the case anymore. Some companies - including some big ones - use GPL'ed code and thumb their noses at the license. I hope that GHC will support use in industry by companies that do respect open source licenses.