Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Henk-Jan van Tuyl]

On Thu, 13 Dec 2012 11:41:14 +0100, Petr P  wrote:


For each package, gather the list
of the licenses of everything it depends on. I think this would help
considerably people who don't want or can't use software licensed under a
particular license (most often (L)GPL). In particular, we can have a BSD
package that depends on a LGPL package, and this is fine for FOSS
developers. But for a commercial developer, this can be a serious issue
that is not apparent until one examines *every* transitive dependency.

This idea is a bit vague, because a dependency is actually a range of
packages, which in theory could have different licenses. But I suppose  
this

will rarely happen in practice, so it'd be safe just to take the last
package in the range (or maybe take all licences of the packages in the
range).



cab[0] can do that, for installed packages:
  cab deps -i -r -a vector
will generate a list of licenses for the packages that vector depends  
upon, like this:


base 4.3.1.0 BSD3 ""
ghc-prim 0.2.0.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
integer-gmp 0.2.0.3 BSD3 ""
ghc-prim 0.2.0.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
primitive 0.4.0.1 BSD3 "Roman Leshchinskiy "
base 4.3.1.0 BSD3 ""
ghc-prim 0.2.0.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
integer-gmp 0.2.0.3 BSD3 ""
ghc-prim 0.2.0.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
ghc-prim 0.2.0.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""


Regards,
Henk-Jan van Tuyl

[0] http://hackage.haskell.org/package/cab


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

I think that's a great idea. I just implemented this on PackDeps:

http://packdeps.haskellers.com/licenses

As with all features on that site, I'll be happy to deprecate it as soon as
Hackage incorporates the feature in the future.

Michael


On Thu, Dec 13, 2012 at 12:41 PM, Petr P  wrote:

>   Dear Haskellers,
>
> following up the recent discussion about copyleft licenses, I'd suggest a
> (hopefully minor) improvement of Hackage: For each package, gather the list
> of the licenses of everything it depends on. I think this would help
> considerably people who don't want or can't use software licensed under a
> particular license (most often (L)GPL). In particular, we can have a BSD
> package that depends on a LGPL package, and this is fine for FOSS
> developers. But for a commercial developer, this can be a serious issue
> that is not apparent until one examines *every* transitive dependency.
>
> This idea is a bit vague, because a dependency is actually a range of
> packages, which in theory could have different licenses. But I suppose this
> will rarely happen in practice, so it'd be safe just to take the last
> package in the range (or maybe take all licences of the packages in the
> range).
>
>   Best regards,
>   Petr
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Vincent Hanquez]

On 12/13/2012 12:51 PM, Michael Snoyman wrote:

I think that's a great idea. I just implemented this on PackDeps:

http://packdeps.haskellers.com/licenses

As with all features on that site, I'll be happy to deprecate it as 
soon as Hackage incorporates the feature in the future.


awesome Michael !

However i think ithis shouldn't take dependencies from tests and benchmarks.
This doesn't make differences for the "overall" license that the library 
"exposes".


--
Vincent

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez  wrote:

> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
>
>> I think that's a great idea. I just implemented this on PackDeps:
>>
>> http://packdeps.haskellers.**com/licenses
>>
>> As with all features on that site, I'll be happy to deprecate it as soon
>> as Hackage incorporates the feature in the future.
>>
>
> awesome Michael !
>
> However i think ithis shouldn't take dependencies from tests and
> benchmarks.
> This doesn't make differences for the "overall" license that the library
> "exposes".
>
> --
> Vincent
>

Hmm, that's a good point. I'll admit I hadn't really thought this through,
but I can actually see an argument going both ways on this:

* Viral licenses won't actually affect you if they're just used for test
suites.
* But company lawyers will probably be nervous about it anyway.

Nonetheless, I think you have the right of it. Unless people say otherwise,
I'm going to implement Vincent's change.

Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Felipe Almeida Lessa]

While you're at it, maybe whitelisting cpphs would be nice as well =).

On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman  wrote:
>
>
>
> On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez  wrote:
>>
>> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
>>>
>>> I think that's a great idea. I just implemented this on PackDeps:
>>>
>>> http://packdeps.haskellers.com/licenses
>>>
>>> As with all features on that site, I'll be happy to deprecate it as soon
>>> as Hackage incorporates the feature in the future.
>>
>>
>> awesome Michael !
>>
>> However i think ithis shouldn't take dependencies from tests and
>> benchmarks.
>> This doesn't make differences for the "overall" license that the library
>> "exposes".
>>
>> --
>> Vincent
>
>
> Hmm, that's a good point. I'll admit I hadn't really thought this through,
> but I can actually see an argument going both ways on this:
>
> * Viral licenses won't actually affect you if they're just used for test
> suites.
> * But company lawyers will probably be nervous about it anyway.
>
> Nonetheless, I think you have the right of it. Unless people say otherwise,
> I'm going to implement Vincent's change.
>
> Michael
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Felipe.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

Are you referring to:

http://code.haskell.org/cpphs/LICENCE-commercial

If the package is dual-licensed BSD3 and LGPL, maybe Malcolm could change
the cabal file to mention the BSD3 so that its package description is less
intimidating?


On Thu, Dec 13, 2012 at 4:12 PM, Felipe Almeida Lessa <
felipe.le...@gmail.com> wrote:

> While you're at it, maybe whitelisting cpphs would be nice as well =).
>
> On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman 
> wrote:
> >
> >
> >
> > On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez  wrote:
> >>
> >> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
> >>>
> >>> I think that's a great idea. I just implemented this on PackDeps:
> >>>
> >>> http://packdeps.haskellers.com/licenses
> >>>
> >>> As with all features on that site, I'll be happy to deprecate it as
> soon
> >>> as Hackage incorporates the feature in the future.
> >>
> >>
> >> awesome Michael !
> >>
> >> However i think ithis shouldn't take dependencies from tests and
> >> benchmarks.
> >> This doesn't make differences for the "overall" license that the library
> >> "exposes".
> >>
> >> --
> >> Vincent
> >
> >
> > Hmm, that's a good point. I'll admit I hadn't really thought this
> through,
> > but I can actually see an argument going both ways on this:
> >
> > * Viral licenses won't actually affect you if they're just used for test
> > suites.
> > * But company lawyers will probably be nervous about it anyway.
> >
> > Nonetheless, I think you have the right of it. Unless people say
> otherwise,
> > I'm going to implement Vincent's change.
> >
> > Michael
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> Felipe.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Felipe Almeida Lessa]

>From [1] I gather that its license really is LGPL/GPL.  However, when
used as a preprocessor its license doesn't really matter.  Many
packages on that list have a LGPL "taint" because one of its deps use
cpphs.  So the whitelist of cpphs would be stating that nobody is
using cpphs as a library (which may be false, but is mostly true ;).

[1] http://code.haskell.org/cpphs/README

On Thu, Dec 13, 2012 at 1:08 PM, Michael Snoyman  wrote:
> Are you referring to:
>
> http://code.haskell.org/cpphs/LICENCE-commercial
>
> If the package is dual-licensed BSD3 and LGPL, maybe Malcolm could change
> the cabal file to mention the BSD3 so that its package description is less
> intimidating?
>
>
> On Thu, Dec 13, 2012 at 4:12 PM, Felipe Almeida Lessa
>  wrote:
>>
>> While you're at it, maybe whitelisting cpphs would be nice as well =).
>>
>> On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman 
>> wrote:
>> >
>> >
>> >
>> > On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez  wrote:
>> >>
>> >> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
>> >>>
>> >>> I think that's a great idea. I just implemented this on PackDeps:
>> >>>
>> >>> http://packdeps.haskellers.com/licenses
>> >>>
>> >>> As with all features on that site, I'll be happy to deprecate it as
>> >>> soon
>> >>> as Hackage incorporates the feature in the future.
>> >>
>> >>
>> >> awesome Michael !
>> >>
>> >> However i think ithis shouldn't take dependencies from tests and
>> >> benchmarks.
>> >> This doesn't make differences for the "overall" license that the
>> >> library
>> >> "exposes".
>> >>
>> >> --
>> >> Vincent
>> >
>> >
>> > Hmm, that's a good point. I'll admit I hadn't really thought this
>> > through,
>> > but I can actually see an argument going both ways on this:
>> >
>> > * Viral licenses won't actually affect you if they're just used for test
>> > suites.
>> > * But company lawyers will probably be nervous about it anyway.
>> >
>> > Nonetheless, I think you have the right of it. Unless people say
>> > otherwise,
>> > I'm going to implement Vincent's change.
>> >
>> > Michael
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>>
>>
>>
>> --
>> Felipe.
>
>



-- 
Felipe.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

I'm not quite certain what to make of:

If you have a commercial use for cpphs, and feel the terms of the (L)GPL
are too onerous, you have the option of distributing unmodified binaries
(only, not sources) under the terms of a different licence (see
LICENCE-commercial).

It seems like that's saying "if you really want to, use the BSD license
instead." But I'm not sure what the legal meaning of "If you have a
commercial use" is. Malcolm: could you clarify what the meaning is?


On Thu, Dec 13, 2012 at 6:37 PM, Felipe Almeida Lessa <
felipe.le...@gmail.com> wrote:

> From [1] I gather that its license really is LGPL/GPL.  However, when
> used as a preprocessor its license doesn't really matter.  Many
> packages on that list have a LGPL "taint" because one of its deps use
> cpphs.  So the whitelist of cpphs would be stating that nobody is
> using cpphs as a library (which may be false, but is mostly true ;).
>
> [1] http://code.haskell.org/cpphs/README
>
> On Thu, Dec 13, 2012 at 1:08 PM, Michael Snoyman 
> wrote:
> > Are you referring to:
> >
> > http://code.haskell.org/cpphs/LICENCE-commercial
> >
> > If the package is dual-licensed BSD3 and LGPL, maybe Malcolm could change
> > the cabal file to mention the BSD3 so that its package description is
> less
> > intimidating?
> >
> >
> > On Thu, Dec 13, 2012 at 4:12 PM, Felipe Almeida Lessa
> >  wrote:
> >>
> >> While you're at it, maybe whitelisting cpphs would be nice as well =).
> >>
> >> On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman 
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez 
> wrote:
> >> >>
> >> >> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
> >> >>>
> >> >>> I think that's a great idea. I just implemented this on PackDeps:
> >> >>>
> >> >>> http://packdeps.haskellers.com/licenses
> >> >>>
> >> >>> As with all features on that site, I'll be happy to deprecate it as
> >> >>> soon
> >> >>> as Hackage incorporates the feature in the future.
> >> >>
> >> >>
> >> >> awesome Michael !
> >> >>
> >> >> However i think ithis shouldn't take dependencies from tests and
> >> >> benchmarks.
> >> >> This doesn't make differences for the "overall" license that the
> >> >> library
> >> >> "exposes".
> >> >>
> >> >> --
> >> >> Vincent
> >> >
> >> >
> >> > Hmm, that's a good point. I'll admit I hadn't really thought this
> >> > through,
> >> > but I can actually see an argument going both ways on this:
> >> >
> >> > * Viral licenses won't actually affect you if they're just used for
> test
> >> > suites.
> >> > * But company lawyers will probably be nervous about it anyway.
> >> >
> >> > Nonetheless, I think you have the right of it. Unless people say
> >> > otherwise,
> >> > I'm going to implement Vincent's change.
> >> >
> >> > Michael
> >> >
> >> > ___
> >> > Haskell-Cafe mailing list
> >> > Haskell-Cafe@haskell.org
> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >
> >>
> >>
> >>
> >> --
> >> Felipe.
> >
> >
>
>
>
> --
> Felipe.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Daniel Trstenjak]

On Thu, Dec 13, 2012 at 08:40:09PM +0200, Michael Snoyman wrote:
> If you have a commercial use for cpphs, and feel the terms of the (L)GPL
> are too onerous, you have the option of distributing unmodified binaries
> (only, not sources) under the terms of a different licence (see
> LICENCE-commercial).

I think that depedencies to binaries, like cpphs, should be treated
differently than depedencies to libraries, because using a (L)GPL-ed
binary mostly hasn't any implications for a "commercial" user and
also for the output of a (L)GPL-ed binary usually the (L)GPL doesn't apply.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

On Thu, Dec 13, 2012 at 9:51 PM, Daniel Trstenjak <
daniel.trsten...@gmail.com> wrote:

>
> On Thu, Dec 13, 2012 at 08:40:09PM +0200, Michael Snoyman wrote:
> > If you have a commercial use for cpphs, and feel the terms of the (L)GPL
> > are too onerous, you have the option of distributing unmodified binaries
> > (only, not sources) under the terms of a different licence (see
> > LICENCE-commercial).
>
> I think that depedencies to binaries, like cpphs, should be treated
> differently than depedencies to libraries, because using a (L)GPL-ed
> binary mostly hasn't any implications for a "commercial" user and
> also for the output of a (L)GPL-ed binary usually the (L)GPL doesn't apply.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

In the case of cpphs, there's no way to determine that we're using it as a
library or an executable, since it's just listed in the build-depends.

Michael
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Petr P]

This is strange, I thought that cpphs should be specified in
"build-tools:", not in "build-depends:".
<
http://www.haskell.org/cabal/users-guide/developing-packages.html#build-information
>

Best regards,
Petr


2012/12/13 Michael Snoyman 

>
>
>
> On Thu, Dec 13, 2012 at 9:51 PM, Daniel Trstenjak <
> daniel.trsten...@gmail.com> wrote:
>
>>
>> On Thu, Dec 13, 2012 at 08:40:09PM +0200, Michael Snoyman wrote:
>> > If you have a commercial use for cpphs, and feel the terms of the (L)GPL
>> > are too onerous, you have the option of distributing unmodified binaries
>> > (only, not sources) under the terms of a different licence (see
>> > LICENCE-commercial).
>>
>> I think that depedencies to binaries, like cpphs, should be treated
>> differently than depedencies to libraries, because using a (L)GPL-ed
>> binary mostly hasn't any implications for a "commercial" user and
>> also for the output of a (L)GPL-ed binary usually the (L)GPL doesn't
>> apply.
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> In the case of cpphs, there's no way to determine that we're using it as a
> library or an executable, since it's just listed in the build-depends.
>
> Michael
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Brent Yorgey]

On Sat, Dec 15, 2012 at 08:13:44AM +0100, Petr P wrote:
> This is strange, I thought that cpphs should be specified in
> "build-tools:", not in "build-depends:".
> <
> http://www.haskell.org/cabal/users-guide/developing-packages.html#build-information
> >
> 
> Best regards,
> Petr

Presumably the reason to list it in build-depends instead of
build-tools is that in the latter case cabal will not automatically
install it as a dependency.  But you are right that this is a strange
situation, since if it is being used only as a preprocessor,
semantically it ought to be listed in build-tools.

-Brent

> 2012/12/13 Michael Snoyman 
> 
> >
> >
> >
> > On Thu, Dec 13, 2012 at 9:51 PM, Daniel Trstenjak <
> > daniel.trsten...@gmail.com> wrote:
> >
> >>
> >> On Thu, Dec 13, 2012 at 08:40:09PM +0200, Michael Snoyman wrote:
> >> > If you have a commercial use for cpphs, and feel the terms of the (L)GPL
> >> > are too onerous, you have the option of distributing unmodified binaries
> >> > (only, not sources) under the terms of a different licence (see
> >> > LICENCE-commercial).
> >>
> >> I think that depedencies to binaries, like cpphs, should be treated
> >> differently than depedencies to libraries, because using a (L)GPL-ed
> >> binary mostly hasn't any implications for a "commercial" user and
> >> also for the output of a (L)GPL-ed binary usually the (L)GPL doesn't
> >> apply.
> >>
> >> ___
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>
> >
> > In the case of cpphs, there's no way to determine that we're using it as a
> > library or an executable, since it's just listed in the build-depends.
> >
> > Michael
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >

> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Petr P]

2012/12/15 Brent Yorgey 

> On Sat, Dec 15, 2012 at 08:13:44AM +0100, Petr P wrote:
> > This is strange, I thought that cpphs should be specified in
> > "build-tools:", not in "build-depends:".
> > <
> >
> http://www.haskell.org/cabal/users-guide/developing-packages.html#build-information
> > >
> >
> > Best regards,
> > Petr
>
> Presumably the reason to list it in build-depends instead of
> build-tools is that in the latter case cabal will not automatically
> install it as a dependency.  But you are right that this is a strange
> situation, since if it is being used only as a preprocessor,
> semantically it ought to be listed in build-tools.
>
>
So if I put cpphs into build-tools and I don't have it installed, the build
will fail? Is this a desired behavior, or a bug?

Best regards,
Petr
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Malcolm Wallace]

On 13 Dec 2012, at 18:40, Michael Snoyman wrote:

> I'm not quite certain what to make of:
> 
> If you have a commercial use for cpphs, and feel the terms of the (L)GPL
> are too onerous, you have the option of distributing unmodified binaries
> (only, not sources) under the terms of a different licence (see
> LICENCE-commercial).
> 
> It seems like that's saying "if you really want to, use the BSD license 
> instead." But I'm not sure what the legal meaning of "If you have a 
> commercial use" is. Malcolm: could you clarify what the meaning is?

No, the LICENCE-commercial is not BSD.  Read it more carefully. :-)

So, I dual-licensed cpphs (which was originally only LGPL as a library, GPL as 
a binary), in response to a request from a developer (working for a company) 
who wished to use it as a library linked into their own software (rather than a 
standalone executable), but who was unable to convince his boss that LGPL would 
be acceptable.  IIRC, the software was going to end up in some gadget to be 
sold (and therefore the code was being distributed, indirectly).  The 
commercial licence I provided for him was intended to uphold the spirit of the 
LGPL, without going as far as BSD in laxity.  So, if you simply want to use 
cpphs in a distributed product (but not modify it), it is very easy.  The 
moment you want to distribute a modified version, you must abide by the LGPL, 
which to me essentially means that you contribute back your changes to the 
community.

Regards,
Malcolm

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Malcolm Wallace]

On 13 Dec 2012, at 10:41, Petr P wrote:

> In particular, we can have a BSD package that depends on a LGPL package, and 
> this is fine for FOSS developers. But for a commercial developer, this can be 
> a serious issue that is not apparent until one examines *every* transitive 
> dependency.

This might a good time to remind everyone that every single program compiled by 
a standard GHC is linked against an LGPL library (the Gnu multi-precision 
integer library) - unless you take care first to build your own copy of the 
compiler against the integer-simple package instead of integer-gmp.  As far as 
I know, there are no ready-packaged binary installers for GHC that avoid this 
LGPL'd dependency.

http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes

Just saying.

Regards,
Malcolm

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Brandon Allbery]

On Sat, Dec 15, 2012 at 9:01 AM, Petr P  wrote:

> So if I put cpphs into build-tools and I don't have it installed, the
> build will fail? Is this a desired behavior, or a bug?
>

Shortcoming of cabal; it only "knows about" libraries because it is really
just a front-end for ghc-pkg, so can't really figure dependencies involving
only executables and not libraries.  The same thing comes up with happy,
alex, and gtk2hsc2hs.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

On Sat, Dec 15, 2012 at 4:25 PM, Malcolm Wallace wrote:

>
> On 13 Dec 2012, at 10:41, Petr P wrote:
>
> > In particular, we can have a BSD package that depends on a LGPL package,
> and this is fine for FOSS developers. But for a commercial developer, this
> can be a serious issue that is not apparent until one examines *every*
> transitive dependency.
>
> This might a good time to remind everyone that every single program
> compiled by a standard GHC is linked against an LGPL library (the Gnu
> multi-precision integer library) - unless you take care first to build your
> own copy of the compiler against the integer-simple package instead of
> integer-gmp.  As far as I know, there are no ready-packaged binary
> installers for GHC that avoid this LGPL'd dependency.
>
> http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
>
> Just saying.
>
>
The difference between a library being (L)GPLed and this GMP issue is that,
in the latter case, we have an escape route. I know of at least two
companies which are actively considering switching entirely to
simple-integer because of this issue. If a widely used package (e.g.,
cpphs) is not available under a permissive license, there's not such escape
route available to users. (And note that I'm not actually *happy* about the
GMP situation, but at least we have a possible solution.)

I would strongly recommend reconsidering the licensing decision of cpphs.
Even if the LICENSE-commercial is sufficient for non-source releases of
software to be protected[1], it introduces a very high overhead for
companies to need to analyze a brand new license. Many companies have
already decided BSD3, MIT, and a number of other licenses are acceptable.
It could be very difficult to explain to a company, "Yes, we use this
software which says it's LGPL, but it has this special extra license which,
if I'm reading it correctly, means you can't be sued, but since the author
of the package wrote it himself, I can't really guarantee what its meaning
would be in a court of law."

Looking at the list of reverse dependencies[2], I see some pretty heavy
hitters. Via haskell-src-exts[3] we end up with 75 more reverse
dependencies. I'd also like to point out that cpphs is the only
non-permissively-licensed dependency for a large number of packages.

I can give you more detailed information about my commercial experience
privately. But I can tell you that, in the currently situation, I have
created projects for clients for which Fay[4] would not be an option due to
the cpphs licensing issue.

Michael

[1] I'm not sure of that, since IANAL.
[2] http://packdeps.haskellers.com/reverse/cpphs
 [3] http://packdeps.haskellers.com/reverse/haskell-src-exts
[4] http://packdeps.haskellers.com/licenses/fay
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Brandon Allbery]

On Sat, Dec 15, 2012 at 9:25 AM, Malcolm Wallace wrote:

> This might a good time to remind everyone that every single program
> compiled by a standard GHC is linked against an LGPL library (the Gnu
> multi-precision integer library) - unless you take care first to build your
> own
>

This is less relevant though, because gmp is not a Haskell library so
linking against it doesn't pull significant chunks of its source code into
your program.  Indeed, many GHC distributions dynamic-link against it,
minimizing the legal concerns; and IIRC the gmp license explicitly allows
the use GHC makes of it as long as the gmp symbols are not re-exported as
part of its API (which they aren't).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Henk-Jan van Tuyl]

On Sat, 15 Dec 2012 16:14:59 +0100, Brandon Allbery   
wrote:



On Sat, Dec 15, 2012 at 9:01 AM, Petr P  wrote:


So if I put cpphs into build-tools and I don't have it installed, the
build will fail? Is this a desired behavior, or a bug?



Shortcoming of cabal; it only "knows about" libraries because it is  
really
just a front-end for ghc-pkg, so can't really figure dependencies  
involving

only executables and not libraries.  The same thing comes up with happy,
alex, and gtk2hsc2hs.



A work-around for this would be to add a dummy library to program-only  
packages.


Regards,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Brandon Allbery]

On Sat, Dec 15, 2012 at 4:38 PM, Henk-Jan van Tuyl wrote:

> On Sat, 15 Dec 2012 16:14:59 +0100, Brandon Allbery 
> wrote:
>
>> On Sat, Dec 15, 2012 at 9:01 AM, Petr P  wrote:
>>
>>> So if I put cpphs into build-tools and I don't have it installed, the
>>> build will fail? Is this a desired behavior, or a bug?
>>>
>>
>> Shortcoming of cabal; it only "knows about" libraries because it is really
>>
> A work-around for this would be to add a dummy library to program-only
> packages.
>

But then what do you do about the current case, where the library imports a
potentially dubious license dependency?

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Malcolm Wallace]

On 15 Dec 2012, at 16:54, Michael Snoyman wrote:

> I would strongly recommend reconsidering the licensing decision of cpphs. 
> Even if the LICENSE-commercial is sufficient for non-source releases of 
> software to be protected[1], it introduces a very high overhead for companies 
> to need to analyze a brand new license. Many companies have already decided 
> BSD3, MIT, and a number of other licenses are acceptable.

Well, if a company is concerned enough to make an internal policy on open 
source licences at all, one might hope that they would perform due diligence on 
them too.  For instance, the FSF have lawyers, and have done enough legal work 
to be able to classify 48 licences as both "free" and GPL-compatible, a further 
39 licences as "free" but non-GPL-compatible, and 27 open source licences that 
are neither "free" nor GPL-compatible.  This kind of understanding is what 
lawyers are supposed to be for.  Making them look at another (short) licence is 
not really a big deal, especially when it closely resembles BSD, which they 
have already supposedly decided is good.

My suspicion, though, is that most of the companies who even think about this 
question are small, do not have their own lawyers, and are making policy on the 
hoof, motivated purely by fear.  I also suspect that they do not even have the 
resources to read the licence for each library in its entirety, to determine 
whether it is in fact BSD3 or MIT, as claimed, or whether someone has subtly 
altered it.  Also, I think I could be pretty confident that there are many 
shipping products that contain genuine BSD-licensed code, but which do not 
comply with its terms.

> It could be very difficult to explain to a company, "Yes, we use this 
> software which says it's LGPL, but it has this special extra license which, 
> if I'm reading it correctly, means you can't be sued, but since the author of 
> the package wrote it himself, I can't really guarantee what its meaning would 
> be in a court of law."

Like I say, if someone claims the software to be BSD-licensed, someone has to 
read the licence text itself anyway, to determine whether the claim is true.  
Pretty much every copy of the BSD licence text differs anyway, at least by the 
insertion of the authors' names in various places, and sometimes there are 
varying numbers of clauses.

> Looking at the list of reverse dependencies[2], I see some pretty heavy 
> hitters. Via haskell-src-exts[3] we end up with 75 more reverse dependencies. 
> I'd also like to point out that cpphs is the only non-permissively-licensed 
> dependency for a large number of packages.

I'm glad that cpphs is widely used.  I'm also glad that it remains free, and I 
disagree with you that its dual-licence model is non-permissive.

I would like to encourage more Haskell developers to adopt free licensing.  
Don't be bullied by BSD evangelists!  BSD is not the only way to a good citizen 
of the community!  Your libraries can be delivered to clients as products, 
without you having to give up all rights in them!

It's not like I'm saying to companies "if you make money out of my code, you 
have to pay me a fee".  All I'm saying, to everyone, is "if you notice a bug in 
my code and fix it, tell me".  This is fully compatible with allowing people to 
release my code to their clients inside products.

> I can give you more detailed information about my commercial experience 
> privately. But I can tell you that, in the currently situation, I have 
> created projects for clients for which Fay[4] would not be an option due to 
> the cpphs licensing issue.

If you are complaining about the crazy policies that many companies adopt about 
the use of free software within their business, then I have plenty of sympathy 
for that too.  I know of one which has a policy of "no use of open source code 
whatsoever", but runs thousands of linux servers.  :-)  Also, many companies 
with large numbers of software engineers on staff apparently prefer to buy 
crappy commercial products and pay handsomely for non-existent support, instead 
of running high-quality open-source software with neither initial nor ongoing 
costs, and where bugfixes are often available the same day as you report the 
bug.  But hey ho.  Corporate policy is usually made by people with neither 
technical nor legal expertise.

As regards cpphs, if you don't want to use it because of its licences, that is 
your choice.  You can always use some other implementation of the C 
pre-processor if you wish.   GHC has always refused to distribute cpphs, on the 
basis of its GPL licence, and instead chose to distribute GNU's gcc on Windows. 
 :-)  (I hope you see the irony!)

Regards,
Malcolm



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe