Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal

Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote:
That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever).
On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace
wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm
On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote:
On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote:
[...]
Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements."
Fyi, Neil talked to him[1]:
| I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal.
[1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_prop...
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string "GPL" can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of "derived work", different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of "LGPL" (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote:
Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones.
Regards, Malcolm
On 7 May 2015, at 22:15, Tomas Carnecky wrote:
That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever).
On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace
wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm
On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote:
On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote:
[...]
Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements."
Fyi, Neil talked to him[1]:
| I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal.
[1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_prop...
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

I imagine your ghc build uses gcc to invoke the system assembler and linker
on your Linux servers, :-) and that's gplv3!
On Monday, May 18, 2015, Lars Kuhtz
I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side.
My experience is that any license that contains the string "GPL" can cause problems in an corporate context, no matter if it actually is a legal issue or not.
Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of "derived work", different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of "LGPL" (or similar) potentially causes overhead in the adaption.
Regards, Lars
On 5/7/15 11:10 PM, Malcolm Wallace wrote:
Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones.
Regards, Malcolm
On 7 May 2015, at 22:15, Tomas Carnecky wrote:
That doesn't mean those people don't exist. Maybe they do but are too
afraid to speak up (due to corporate policy or whatever).
On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace
wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm
On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote:
On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote:
[...]
Regarding licensing issues: perhaps we should simply ask Malcolm
Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements."
Fyi, Neil talked to him[1]:
| I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal.
[1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_prop...
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________ 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

On 05/19/2015 07:31 AM, Carter Schonwald wrote:
I imagine your ghc build uses gcc to invoke the system assembler and linker on your Linux servers, :-) and that's gplv3!
That is of no consequence licensing-wise since those are a) separate programs/executables, thus "derived work" doesn't enter into it at any level, except... b) if the output contains bits of of the programs themselves, but e.g. gcc (and one assumes the linker, etc.) have specific licensing exemptions for the output. (And this *is* something that you can quickly explain to the lawyerly types.)

On 05/19/2015 08:26 AM, Bardur Arantsson wrote:
On 05/19/2015 07:31 AM, Carter Schonwald wrote:
I imagine your ghc build uses gcc to invoke the system assembler and linker on your Linux servers, :-) and that's gplv3!
That is of no consequence licensing-wise since those are
a) separate programs/executables, thus "derived work" doesn't enter into it at any level, except...
b) if the output contains bits of of the programs themselves, but e.g. gcc (and one assumes the linker, etc.) have specific licensing exemptions for the output.
(And this *is* something that you can quickly explain to the lawyerly types.)
Oh, and it's also pretty well-established at this point, though I'm not aware of any specific cases that have gone to the courts.

On 19 May 2015 at 08:26, Bardur Arantsson
I imagine your ghc build uses gcc to invoke the system assembler and
On 05/19/2015 07:31 AM, Carter Schonwald wrote: linker
on your Linux servers, :-) and that's gplv3!
That is of no consequence licensing-wise since those are
a) separate programs/executables, thus "derived work" doesn't enter into it at any level, except...
b) if the output contains bits of of the programs themselves, but e.g. gcc (and one assumes the linker, etc.) have specific licensing exemptions for the output.
(And this *is* something that you can quickly explain to the lawyerly types.)
Both conditions likewise hold true for cpphs-as-an-external-process-bundled-with-GHC. So any particular remaining concern there?

On 05/19/2015 11:04 AM, Boespflug, Mathieu wrote:
On 19 May 2015 at 08:26, Bardur Arantsson
wrote: I imagine your ghc build uses gcc to invoke the system assembler and
On 05/19/2015 07:31 AM, Carter Schonwald wrote: linker
on your Linux servers, :-) and that's gplv3!
That is of no consequence licensing-wise since those are
a) separate programs/executables, thus "derived work" doesn't enter into it at any level, except...
b) if the output contains bits of of the programs themselves, but e.g. gcc (and one assumes the linker, etc.) have specific licensing exemptions for the output.
(And this *is* something that you can quickly explain to the lawyerly types.)
Both conditions likewise hold true for cpphs-as-an-external-process-bundled-with-GHC. So any particular remaining concern there?
Not from me, certainly. I was just trying to point out that the example given (Linux, gcc, ...) was invalid. I would be more worried about e.g. Linux distributions *if* cpphs were under some weird license, but since it's LGPL that shouldn't prompt any issues. (We're talking "mere aggregation" in the terms used in the GPL.) As always, IANAL and in particular I am not *your* or anybody else's lawyer :). Regards,
participants (5)
-
Bardur Arantsson
-
Boespflug, Mathieu
-
Carter Schonwald
-
Lars Kuhtz
-
Malcolm Wallace