- cabal-devel - Haskell.org

patch applied (cabal-install): fix a comment typo of 'according'
by Duncan Coutts 14 Feb '11

14 Feb '11

Sat Jan 22 05:53:39 PST 2011 Jens Petersen <petersen(a)haskell.org> * fix a comment typo of 'according' M ./Distribution/Client/Dependency/TopDown.hs -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-install;a=darcs_commi…

1 0

Re: [Hackage] #645: confusing interface: cabal "install" subcommand has two clashing meanings
by Hackage 11 Feb '11

11 Feb '11

#645: confusing interface: cabal "install" subcommand has two clashing meanings ---------------------------------+------------------------------------------ Reporter: StefanK | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): See also #802 about consequences of people using `cabal copy` instead of `cabal install`. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/645#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Haskell-cafe] [Cabal-devel] Cabal && license combinations
by Antoine Latter 10 Feb '11

10 Feb '11

On Thu, Feb 10, 2011 at 10:04 AM, Chris Smith <cdsmith(a)gmail.com> wrote: > On Thu, 2011-02-10 at 08:59 +0100, Ketil Malde wrote: >> I disagree - the linked executable must, but not the wrapper by itself. >> It's source code, i.e. text, thus a creative work, and therefore >> covered by copyright - on its own. > > You're certainly right from a legal standpoint. But being right doesn't > actually matter. The instant anyone actually compiles an application > that uses your library, however indirectly, they are bound by the terms > of the underlying library as well. So your bindings are effectively > covered by the underlying license anyway (unless you're choosing a > license for the sake of people who will never produce any usable end > result...) > The vast majority of Open Source licenses in use only restrict the publication of the work or derived works, not compilation. So no, the instant of compilation is not when the transitive dependencies kick in, it is the publication of compiled binaries, which in my mind is a pretty specialized case. Antoine

2 1

patch applied (cabal-branches/cabal-1.10): "Fix HcPkg.dump for the case of an empty database"
by Duncan Coutts 10 Feb '11

10 Feb '11

Thu Feb 10 12:01:11 PST 2011 Duncan Coutts <duncan(a)community.haskell.org> * Fix HcPkg.dump for the case of an empty database Previously it returned the value [emptyInstalledPackageInfo] M ./Distribution/Simple/Program/HcPkg.hs -1 +7 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-branches/cabal-1.10;a…

1 0

patch applied (cabal): "Fix HcPkg.dump for the case of an empty database" and 1 others
by Duncan Coutts 10 Feb '11

10 Feb '11

Thu Feb 10 12:01:11 PST 2011 Duncan Coutts <duncan(a)community.haskell.org> * Fix HcPkg.dump for the case of an empty database Previously it returned the value [emptyInstalledPackageInfo] M ./Distribution/Simple/Program/HcPkg.hs -1 +7 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=… Thu Feb 10 12:06:03 PST 2011 Duncan Coutts <duncan(a)community.haskell.org> * Always use verbosity slient when calling hc-pkg dump We don't want to contaminate the hc-pkg output with info/debug messages. Coincidentally the messages that current ghc-pkg versions produce at -v2 verbosity level do not cause a problem. There's no reason to expect future versions to work that way however. M ./Distribution/Simple/Program/HcPkg.hs -2 +4 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

Re: [Haskell-cafe] [Cabal-devel] Cabal && license combinations
by Duncan Coutts 10 Feb '11

10 Feb '11

On Thu, 2011-02-10 at 12:44 +0100, Stefan Kersten wrote: > On 10.02.11 12:12, Duncan Coutts wrote: > > We are already working on a feature that will show the full set of > > licenses that the end user must comply with (a patch has been submitted > > and it's been through one round of review so far). In your example that > > would mean you expect the set to be {BSD} but the tool will show you > > that it is in fact {BSD, GPL}. You can then use that as your warning > > that the set of licenses is not what you expected. > > that would be quite useful for those who want to distribute executables! > > may i also suggest the following feature: collect all the copyright notices and > license files from each dependency (many licenses require those to be displayed > and distributed along with the executable) and optionally bundle them with the > applicaton's data-files? i briefly looked into this, but couldn't find a way to > retrieve the installed License-File from ~/.cabal using Cabal. doing this by > hand turns out to be quite tedious when there are many dependencies ... Right, that feature was also in the patch. From experience I know that this would indeed be very useful (I've also had to do it manually). Duncan

1 0

[Haskell-cafe][Cabal-devel] Cabal && license combinations
by Dan Knapp 10 Feb '11

10 Feb '11

I haven't heard anyone mention this yet, and it's a biggie, so I guess I'd better de-lurk and explain it. The issue is this: There is a legal distinction between static and dynamic linking, or at least some licenses (the GPL is the one I'm aware of) believe that there is. In particular, they assert that you are legally creating a "derived work" if you statically link with their library, and that your library, even if it's just a thin bindings wrapper, must therefore comply by their license terms. They make no such claim for dynamic linking. Of course, Haskell on most platforms and default configurations links everything statically! So I believe this means that you have to comply by the licenses of all your dependencies! Now, there's a difference between complying by those licenses and being under them yourself, but for example I believe this means that if we have a package named "hs-save-the-whales" that is under the GPL, and a front-end package "hs-redeem-them-for-valuable-cash-prizes" which makes use of the functionality in hs-save-the-whales, the front-end MUST be offered under the GPL, and, additionally, CANNOT be offered under BSD (I think). I think it would be a very useful and valuable thing for Cabal to detect this situation and warn appropriately! Contamination by undesired licenses is a serious flaw in the packaging of a package; it just happens to be a legal flaw rather than a technical one. Indeed, I would argue that this is far more important than any hypothetical per-file licensing. -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

2 1

Re: Cabal && license combinations
by Vivian McPhail 10 Feb '11

10 Feb '11

> On Mon, 2011-02-07 at 14:42 +0000, Malcolm Wallace wrote: > > > It seems then that a package should be the least restrictive > > > combination of all the licenses in all the contained modules. > > > > Omit the words "least restrictive" and I think you are correct. > OK. > > > > To combine licences, just aggregate them. There is no lattice of > > subsumption; no "more" or "less" restrictive ordering. It's simple: > > you must obey all of them. Some aggregations introduce a > > contradiction of terms, so you cannot legally aggregate those modules > > without breaking some term. But if the terms of the aggregated > > licences are compatible rather than contradictory, then all is good. > > Right, so the effect of per-file/mixed licenses could be achieved by > letting packages specify a list of licenses: > > license: Foo, Bar > Could this be computed automatically from the source files by Cabal? > > Meaning you may copy/distribute provided you comply with all these > licenses. > > Note that this does not cover dual licensing, e.g. Foo or Bar at > distributor's choice. > > Duncan > Looking specifically at hmatrix, there are three kinds of modules i) bindings to GSL GPL ii) bindings to LAPACK BSD iii) pure Haskell hmatrix author's choice 1) Am I correct in thinking that even the bindings modules (the Haskell parts, not the C files) can be under any licence, FOO, chosen by the author, but the binary _linked_ to, say, GSL has to comply with FOO and GPL? 2) If someone uses hmatrix but no GSL functions (hence there are no GSL functions in the linked binary) can they get away with not complying with the GSL requirement? Cheers, Vivian

2 1

Cabal && license combinations
by Vivian McPhail 08 Feb '11

08 Feb '11

Dear All, There was recently a discussion on haskell-cafe ( http://www.mail-archive.com/haskell-cafe@haskell.org/msg86472.html) about licenses of libraries such as hmatrix and the combination of various different licences. One question was about per-package versus by-file licenses: In Haskell the compilation unit is the module, and the per-file cabal header allows for a license field. It seems then that a package should be the least restrictive combination of all the licenses in all the contained modules. If this has to become a hand-coded fancy function of various GPLx, BSDy, OpenSource, and other licenses then so be it. That is the legal reality. And use of a BSD3 module in hmatrix that does not depend upon GPL'd GSL modules would be acceptable. In short, I argue for a per-file(module) license regime. Vivian

3 2

Re: [Hackage] #600: Cabal should have an option to dynamically link executables
by Hackage 03 Feb '11

03 Feb '11

#600: Cabal should have an option to dynamically link executables ----------------------------------+----------------------------------------- Reporter: juhp | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.10 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.12.3 Platform: Linux | ----------------------------------+----------------------------------------- Comment(by juhp): Thanks, Duncan for applying the patch to HEAD. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/600#comment:18> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0