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
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. 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. Regards, Malcolm
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.
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 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
On 2/7/11 9:42 AM, Malcolm Wallace wrote:
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.
In the event that my comments on the previous thread were a source of confusion, I agree with the first and last sentences though the middle one is a bit more ambiguous. Lawyers can argue about whether individual licenses as written (i.e., MIT, BSD3, GPL,...) have any interesting preorder (i.e., other than equality). But in practice distributors must adhere to sets of licenses, and these sets have the obvious lattice structure: namely Malcolm's last sentence. Again, whether this lattice has any interesting (i.e., non-free) equalities is best left up to lawyers. -- Live well, ~wren
It feels to me like a quite reasonable simplification that if someone wants to offer different bits of code, with the intent that the license terms of the eventual executable may be different depending on which bits you use, then they ought to do so in different packages. It's simple enough to do, and removes the need to do per-module license considerations. -- Chris Smith
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)
Dan Knapp
There is a legal distinction between static and dynamic linking,
Well, the obvious distinction is that a dynamically linked executable doesn't actually contain any code from its libraries, while a statically linked one does.
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.
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.
Of course, Haskell on most platforms and default configurations links everything statically!
So this may be a problem for distributions, which ship compiled and linked binaries. But generally not for authors, darcs repositories or Hackage, which only ship source code. I guess you could conceivably say that compiling downloaded source code constitutes copying, and is thus limited under copyright. But I think all the relevant licenses would be considered to allow this.
So I believe this means that you have to comply by the licenses of all your dependencies!
If, and only if, you wish to distribute the final executable.
I think it would be a very useful and valuable thing for Cabal to detect this situation and warn appropriately!
Yes. At least, it'd be nice if Cabal would tell you about the licenses involved. But I'd let people do their own interpretations, that's too much of a minefield. -k -- If I haven't seen further, it is by standing in the footprints of giants
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...) Sure you could attach yet another license; but unless you deliberately intend to be even more restrictive, there's no reason whatsoever to license the thin bindings layer differently from the library it is binding to. Doing so would just be potentially misleading people about the licenses they need to comply with, especially when the bindings are to libraries that are not packaged with Cabal and do not have a uniform place to record their license terms.
So this may be a problem for distributions, which ship compiled and linked binaries. But generally not for authors, darcs repositories or Hackage, which only ship source code.
Of course it is a concern for authors! Do you really think authors write libraries, and then just don't care whether potential users can actually use them? If you don't expect anyone to ever link a program, even indirectly, against your library, then you probably shouldn't have bothered distributing it; but if you do expect that, then you typically make choices when developing an application based on what rights you want *those* people to have. The reasonable expectation in Haskell is that they'll probably statically link; and you should read licenses of your dependencies, and carefully choose dependencies, accordingly. -- Chris Smith
On Thu, Feb 10, 2011 at 10:04 AM, Chris Smith
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
On 10 Feb 2011, at 17:38, Antoine Latter wrote:
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.
This is possibly the most important point to emphasise, of which many people seem unaware. If you expect to receive an open source application from someone else as source code, and build it yourself, then almost by the definition of Open Source, you are already in compliance with all licences. It is only those, comparatively few, people who build binaries and give them to other people *as binaries* who even need to think about licensing issues. Regards, Malcolm
Chris Smith
actually matter. The instant anyone actually compiles an application that uses your library, however indirectly, they are bound by the terms
There are other uses for code than compilation. Let's say I wrote a wrapper for a proprietary library that connects to Oracle databases. Any program using this would likely be undistributable. Still, having the wrapper free would allow porting it to a free database back end or using it for teaching, so there's always added value in added freedom.
So this may be a problem for distributions, which ship compiled and linked binaries. But generally not for authors, darcs repositories or Hackage, which only ship source code.
Of course it is a concern for authors!
I don't think you are contradicting me here. My point is that authors are not likely to be liable or bound by other's licenses - whether they are concerned or not, is up to them.
The reasonable expectation in Haskell is that they'll probably statically link; and you should read licenses of your dependencies, and carefully choose dependencies, accordingly.
I think usability goes way beyond redistributability, but I guess we should just agree to disagree on this. IMO, the important thing is that cabal avoids imposing legal straightjackets on authors, and that it avoids making legal interpretations. Echoing facts from cabal files is okay, but drawing legal conclusions based on these facts should be the responsibility (i.e. both obligation and liability) of the individual user. -k -- If I haven't seen further, it is by standing in the footprints of giants
On 9 February 2011 23:35, Dan Knapp
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).
If you incorporate GPL code into a binary you want to distribute you have to comply with the GPL. Static linking a GPL library will incorporate GPL code into your binary, ergo you have to comply with the GPL. If you write a client of a GPL library and you want to distribute it, your client can be any GPL compatible license - it does not have to be GPL. Should you distribute a compiled binary you have to comply with the GPL and any additional terms brought in by your GPL-compatible license. Its that simple - until there is a court ruling to decide otherwise.
On Wed, 2011-02-09 at 18:35 -0500, Dan Knapp wrote:
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.
I think you're in danger of adding confusion rather than removing it. The LGPL provides some alternative terms for dynamic linking but you still must comply with the license.
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!
You always have to do that.
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).
No, that is wrong. There is no difference between GPL code depending on BSD code and BSD code depending on GPL code. The direction of the dependency is irrelevant. In both cases the end user/distributor must comply with both licenses.
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.
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. The tool will not claim that {BSD, GPL} is wrong, because it isn't! What is wrong is expectations not matching reality, and hopefully that's what the tool can help with. Duncan
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 ... <sk>
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
Chris Smith schrieb:
It feels to me like a quite reasonable simplification that if someone wants to offer different bits of code, with the intent that the license terms of the eventual executable may be different depending on which bits you use, then they ought to do so in different packages. It's simple enough to do, and removes the need to do per-module license considerations.
I think separating bindings to GSL and LAPACK is a good idea anyway, and as far as I remember the author of hmatrix agrees to that, but he did not actually split the bindings due to lack of time.
participants (11)
-
Antoine Latter -
Chris Smith -
Dan Knapp -
Duncan Coutts -
Henning Thielemann -
Ketil Malde -
Malcolm Wallace -
Stefan Kersten -
Stephen Tetley -
Vivian McPhail -
wren ng thornton