Licenses in Formulae

[DomT4]

I tried to find a prior discussion on this subject, but I couldn't. The fact I was searching the words "license" and "formula" only meant I was getting several hundred unrelated results each time, so it's entirely possible I missed something relevant underneath all the keywords.

In essence, I'd like to kick off a discussion about adding each package's license inside the formula itself. Slowly, I add; I'm not proposing anyone sit down and go through each and every formula we offer and in long session find and add licenses to them all, That'd probably kill someone. Proposing we handle it on a per-formula-update basis.

It would be structured like this inside the formulae:

  homepage "https://gcc.gnu.org"
  url "http://ftpmirror.gnu.org/gcc/gcc-4.9.2/gcc-4.9.2.tar.bz2"
  mirror "ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.9.2/gcc-4.9.2.tar.bz2"
  sha1 "79dbcb09f44232822460d80b033c962c0237c6d8"
  license "GPLv3"

And it would be included in brew info.

Ubuntu, Debian, Arch, Fink and MacPorts all do this sort of thing with their packages.

Homebrew doesn't, and this may not be a bad thing. Some downsides to such a feature:

• How many end users actually check such things? Would this be extremely niche?
• People disagree on which license applies to which projects more than people do on whether Pepsi or Coca-Cola is the more authentic Coke taste. Even when explicitly announced like GCC people still display that license differently, some simply call it GPLv3, some label it GPLv3 Permissive, Arch label it under a whole variety of things.
• It could potentially lead to more complication. MacPorts for example allows users to download non-free elements into free-packages, or only GPLv2, or GPLv3. This can be particularly explicitly seen in their ffmpeg package. It's a pretty clunky system, and makes reading their portfiles a bit of a nightmare.
• Although we don't display the licenses in formulae, we do ship LICENSE files where available into the main formula prefix where people can find and browse them easily.

Some upsides:

• Homebrew is increasingly popular in commercial/corporate environments, and there may be situations where building against or including aspects of a particular tool or code could "contaminate" their product with an enforced particular license. This possibly applies to all and any developers as well.
• It doesn't need to be clunky, necessarily. There is potential for "feature-creep" on things like this, but a simple one-line amendment to formulae and the brew info readout is relatively simple and light in terms of maintenance and adoption.
• On the flipside, "feature-creep" could be useful. Homebrew could move later onto enabling users to export commands such as export HOMEBREW_NO_GPLv3 in their bash_profile or zshrc, etc where their Brew installation would red-flag any attempts to install GPLv3 software, or any other particular license desired.
• It follows the accepted trend of package manager behaviour, something Homebrew tries to "obey" where practical. Principle of least surprise, etc etc etc, wibble.

Technically this belongs on the mailing list, but the mailing list seems to hate me and it's hard to structure lengthy discussion on, for better or worse. If one of the maintainers has had this discussion before and goes "Oh hell no. Not this again" please feel free to close and lock, no offence taken 😉.

[adamv]

I'm not opposed to this on principle, but I personally wouldn't want to have people expecting me to stay up-to-date in cases where a project changes its license.

[tdsmith]

Some package managers have ideological reasons for conveying license information which might be less interesting to Apple users, heh. To the extent that Homebrew is redistributing software when we offer bottles, there might be a business case for documenting licenses. How do package managers that track licenses use or expose that data and are there realistic examples of that data being used?

The Debian debian/copyright guide illustrates some of the complexities in encoding license information consistently and correctly. There's probably a good argument that some use cases don't need to be as particular as others; how correct is correct enough?

[DomT4]

To the extent that Homebrew is redistributing software when we offer bottles, there might be a business case for documenting licenses.

I actually hadn't pondered this particular point too deeply, but it raises a question in my head I wanted to throw out at the risk of looking silly, which I accept:

• If Homebrew distributes something which is GPLv3, which it does, and generates a bottle from it, is that bottle then licensed under GPLv3 or does the Bottle remain under Homebrew's BSD license? The copyleft element of GPLv3 is what some consider to be one of the more toxic elements of the license, and is often interpreted as forcing itself onto the binary products generated.

How do package managers that track licenses use or expose that data and are there realistic examples of that data being used?

I discussed some of the MacPorts stuff in my initial post, which is the most active use of the licensing display and active options you can exercise against that, but Debian displays the license on the package's page, but interestingly don't ship a LICENSE file with a lot of their precompiled debs.

Technically, because they offer the copyright file on the website not shipping the LICENSE file doesn't actually violate GPLv3, and they're also protected by shipping all the common licenses in /usr/share/common-licenses and linking most things to that file internally. So that's Debian's way of doing this fun little dance. AFAIK though, there's no actual use case for those licenses on the system, other than checking the necessary legal tickboxes.

how correct is correct enough?

My opinion here links back to a lot of what Homebrew does, in "check Debian if unsure". IMO, If Debian labels something a particular license, I'm happy to defer to them unless there's a strong case for not doing so.

[tdsmith]

If Homebrew distributes something which is GPLv3, which it does, and generates a bottle from it, is that bottle then licensed under GPLv3 or does the Bottle remain under Homebrew's BSD license?

Generally the most restrictive terms will apply; the GPL obliges distributors (Homebrew) to make GPL'd software available under the GPL's terms.

"check Debian if unsure"

I think the format of the debian/copyright file suggests that there are at least some edge cases that are difficult to represent by applying a single string from an enum to an entire package, so either this needs a more complex representation like Debian's or it will at least sometimes be less correct than Debian. I think the latter is probably not a big loss but that depends on how it's intended to be used.

[DomT4]

Generally the most restrictive terms will apply; the GPL obliges distributors (Homebrew) to make GPL'd software available under the GPL's terms.

So the bottles created from GPLv3 software are very probably enforced under the GPLv3 license? That's a minor irritant.

I think the format of the debian/copyright file suggests that there are at least some edge cases

Ah, yes, there is that implication there. The Debian copyright guide is hefty enough to suggest they have probably had to deal with those cases before, so it's fair to imply it's a hoop we need to decide where to jump through and why.

I guess the core question then is if we proceed with this as an idea, do we draw the line on only displaying the license in formula or do we leave the option open to possibly allowing people to one day specify something like export HOMEBREW_NO_GPLv3 or similar? The former gives us less problems, but may limit a feature that some of the maintainers see potential or use for. That particular question is a tennis ball I leave in the maintainer's court 😉

[MikeMcQuaid]

I'm probably 👎 on this; there will need to be a lot of up-front work like descriptions but with the added complication of having to try and keep up-to-date with projects (as @adamv mentioned). I wouldn't want to say something was BSD licensed and through mistake or changes over time it's actually GPLv3. My take on software license compliance: if you're shipping a proprietary product you should be checking all these things yourselves.

Relatedly, we generally only include things with open-source licenses in Homebrew core but I don't know how strict that is.

[DomT4]

I'm happy to move in either direction on this. If there's a desire to see it in and we can agree a path to that point I'm happy, but equally if there's a relatively niche use case and the level of work required doesn't match the usefulness of the end result I'm happy to see us remain as we are. The subject was just something hovering on my mind for a while and I wanted to see what the consensus was on the subject, essentially. Clarification as much as any great desire to move in either direction.

[tdsmith]

This was fun to take a look at but I don't have a strong belief that this will be useful.

[DomT4]

Agreed. Happy to have had the discussion, and pleased we did so, but unless something drastic changes the status quo covers Homebrew legally and minimises the amount of work placed on the maintainer's shoulders.