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
2012/12/15 Brent Yorgey byor...@seas.upenn.edu
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
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
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
On Sat, Dec 15, 2012 at 9:01 AM, Petr P petr@gmail.com 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,
On Sat, Dec 15, 2012 at 4:25 PM, Malcolm Wallace malcolm.wall...@me.comwrote:
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
On Sat, Dec 15, 2012 at 9:25 AM, Malcolm Wallace malcolm.wall...@me.comwrote:
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
On Sat, 15 Dec 2012 16:14:59 +0100, Brandon Allbery allber...@gmail.com
wrote:
On Sat, Dec 15, 2012 at 9:01 AM, Petr P petr@gmail.com 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
On Sat, Dec 15, 2012 at 4:38 PM, Henk-Jan van Tuyl hjgt...@chello.nlwrote:
On Sat, 15 Dec 2012 16:14:59 +0100, Brandon Allbery allber...@gmail.com
wrote:
On Sat, Dec 15, 2012 at 9:01 AM, Petr P petr@gmail.com wrote:
So if I put cpphs into build-tools and I don't have it installed, the
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
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 mich...@snoyman.com
On Thu, Dec 13, 2012 at 9:51 PM, Daniel
On Thu, 13 Dec 2012 11:41:14 +0100, Petr P petr@gmail.com 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
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
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
On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez t...@snarc.org 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/licenseshttp://packdeps.haskellers.com/licenses
As with all features on
While you're at it, maybe whitelisting cpphs would be nice as well =).
On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman mich...@snoyman.com wrote:
On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez t...@snarc.org wrote:
On 12/13/2012 12:51 PM, Michael Snoyman wrote:
I think that's a great
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
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
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
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
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
21 matches
Mail list logo
