Cabal: License conflict in dependencies?

[glguy]

cabal-install on the master branch is licensed BSD3, but now depends on resolv, which is GPL3. Isn't this an issue?

[23Skidoo]

/cc @hvr

[hvr]

Well, cabal-install also links to C libaries like GMP or GNU libc, which are LGPL; the support for DNS lookups is hidden behind a cabal flag; BSD3 and GPL licensed code are compatible w/ each other; the code in cabal-install remains BSD3, depending on a GPL library doesn't automatically relicense cabal's code-base to become GPL :-)

Moreover, the native DNS query support is controlled via a manual cabal flag; i.e.

Flag native-dns
  description:  Enable use of the [resolv](https://hackage.haskell.org/package/resolv) & [windns](https://hackage.haskell.org/package/windns) packages for performing DNS lookups
  default:      True
  manual:       True

executable cabal
    -- ...
    if flag(native-dns)
      if os(windows)
        build-depends: windns      >= 0.1.0 && < 0.2
      else
        build-depends: resolv      >= 0.1.1 && < 0.2

so if there's somebody who insists to have no GPL code whatsoever in their cabal-install executable (and I guess they also avoid using any normal Linux distribution if they dislike the GPL that much), they can simply build cabal-install with that flag disabled.

Btw, when we get SPDX support, we could consider integrating SPDX with the cabal solver, and have the solver allow SPDX constraints like --spdx-constraint 'not GPL' or something like...

[phadej]

Btw, why markdown markup in the flag's description, or is it valid haddock syntax too?

[hvr]

@phadej it's valid, see https://github.com/haskell/hackage-server/issues/585 and https://github.com/haskell/hackage-server/commit/8b4bf72cd3415b3ce35cbef2e72edbf6b4c5263f (and if you're referring the link-markup, yes, Haddock supports markdown-syntax for hyperlinks (with some minor limitations); but don't ask me since when, but see https://github.com/haskell/haddock/blob/master/doc/cheatsheet/haddocks.pdf)

[glguy]

I guess it just means that cabal-install can only be distributed under the GPL when built against this library. There doesn't actually appear to be that much in this FFI wrapper. Surely we could rewrite it to avoid this.

[23Skidoo]

Interesting point about license being dependent on flags, hence the license field potentially lying to you. I think we should make that flag disabled by default to avoid that situation, and add a comment that enabling it makes the package GPL-licensed. We probably still can distribute binaries built with -fnative-dns via our website; I'm not sure whether we need everyone who has ever contributed to cabal-install to consent to the package now being effectively dual-licensed (I'd really like to avoid that!).

[hvr]

Interesting point about license being dependent on flags, hence the license field potentially lying to you.

It's not really lying to you; it merely states what license the source distribution is under. IOW, the source-code of cabal-install still remains under the BSD3. It makes little sense for the licence field to reflect all transitive dependencies for various reasons (NB: you'd also have to include C FFI libraries, at which point virtually every Haskell program would become LGPL-licences on most Linux distributions!).

I think we should make that flag disabled by default to avoid that situation, and add a comment that enabling it makes the package GPL-licensed.

That's not really true; the package per se is still BSD3 licenced; I tried to say this already that combining BSD3 code and GPL code (while keeping it separate; and different packages are a very clear separation!) doesn't automatically (require to) relicence the BSD3 code, nor does this automatically relicence the GPL code into BSD3 code! ;-)

We probably still can distribute binaries built with -fnative-dns via our website;
I'm not sure whether we need everyone who has ever contributed to cabal-install to consent to the package now being effectively dual-licensed (I'd really like to avoid that!).

Why would you need that; as I stated above, nothing changes whatsoever in how cabal-install's code-base is licenced. Also, the term "dual licenced" denotes if you have code that carries a choice of 2 or more different licences, and the user is free to choose which one they want to comply with. But that's probably not what you wanted to say.

BSD3 and GPL code gets combined all the time in the OSS world (just take a look at any Linux distro), and you don't see maintainers going around asking contributors everytime the dependencies of a project change; if such level of bureaucracy was needed, that'd quickly kill the OSS movement before it even started... ;-)

Or lets take another example; let's say hackage-server wanted to started depending on the pandoc library for markup rendering; that still wouldn't turn hackage-server into a GPL licenced package; it'd still be BSD3.

The only thing that changes when you combine BSD3 and GPL code is that the compiled binaries (i.e. not the source-code!) must as a combined work adhere to all involved components' licences (NB: this also involves linked C FFI libraries!).

Note that even when you distribute binaries involving BSD3 licences you're required to satisfy some requirement (which I've seen often ignored when people merely offer a bare executable foo.exe for download):

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Distributing bianaries involving GPL code isn't that different; put very simply, the basic requirement is to be provided with the means to have access to all source code involved, so that a user is able to compile e.g. exe:cabal themselves (while being able to modify the GPL-covered code). IMO this isn't such a horrible thing to provide, unless you want to deliberately take that freedom away from your users... ;-)

[phadej]

For a wide-spread example see graphviz, it is under CPL-1.0. But you can (optionally) compile it with libglade which is GPL'd library (see other depednencies also).

[glguy]

I think that it's unnecessary that distribution of cabal-install should be complicated by an FFI wrapper where in the common case for full functionality it needs to be distributed under the GPL. The fact that libraries using LGPL are involved is a separate concern. I think it's unfortunate that this sort of license choice seems to have been snuck in without prior discussion.

[hvr]

where in the common case for full functionality it needs to be distributed under the GPL

To be fair, when -fnative-dns is not active, cabal is still fully functional; but it needs to call out to an external nslookup executable in those few occasions where there's a need to perform a DNS lookup (NB: this only occurs when hackage-security is bootstrapping).

I think it's unfortunate that this sort of license choice seems to have been snuck in without prior discussion.

Well, I didn't realise it would be a big issue tbh. What I still don't understand though: What is the concrete worry/concern/problem with cabal-executable being linked against non-BSD3-licenced libraries? Is this merely about binary distributions of cabal?

[23Skidoo]

@hvr @phadej Thanks for the explanation! So tl;dr basically is: If I use a GPL library in a BSD3 program, only the resulting binary is considered to be a "derivative work" for the purposes of GPL. The binary being GPL-licensed means that its full source code must be open source under a GPL-compatible license(s). Which is already the case for cabal-install.

There's also the issue of reproducing various copyright notices in the binary distribution which @hvr mentioned, but I think that we can comply with that requirement by adding a "Legal" appendix to the manual. Might even be worth it to add a command to cabal-install to auto-generate such legal boilerplate pages in HTML/ReST format.

[phadej]

Right term is combined work, not derivative (that would be, if we modify resolv - but we don't).

[phadej]

FWIW, the situation is in GPL FAQ:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLModuleLicense:

If I add a module to a GPL-covered program, do I have to use the GPL as the license for my module? (#GPLModuleLicense)

The GPL says that the whole combined program has to be released under the GPL. So your module has to be available for use under the GPL.

But you can give additional permission for the use of your code. You can, if you wish, release your module under a license which is more lax than the GPL but compatible with the GPL. The license list page gives a partial list of GPL-compatible licenses.

There program is resolv, and your module is cabal-install. BSD-3-Clause is GPL compatible.

[phadej]

Note that stackage disabled native-dns in https://github.com/commercialhaskell/stackage/pull/3903

There's also lib flag enabled. Though we clearly say:

Build cabal-install as a library. Please only use this if you are a cabal-install developer.

ping @hvr, @23Skidoo

EDIT: I think we don't need to do anything, just a thing to be aware of.

[bergmark]

(the lib flag is just a temp hack https://github.com/fpco/stackage-curator/issues/60)

[hvr]

@bergmark ...and what what about -fnative-dns? Is this yet another new Stack(age) bug you're workarounding there? ;-)