Proposal: get rid of license

[vitorgalvao]

The license stanza was thought out in the context of fonts and is nothing but a curiosity for apps (especially we not being about discoverability, and all).

license is (at the time of this writing) missing from just 284 casks in the main repo (from a total of 2937).

Rationally, though, there’s no context in which we currently use its information, nor is any real context really planned, nor is anyone eager to do it. license is just there, it exists. However, I argue the license stanza is worse than useless, it’s actively harmful. For one, it is required, which makes absolutely no sense for user taps (which I believe we should encourage and have many times been vocal in thinking it is one of the best features of homebrew), but it also delays submissions, as users not filling it up/filling it up wrongly it’s a frequent point of friction for contributions.

Pinging @caskroom/maintainers, and I’ll specifically ping @victorpopkov and @Amorymeltzer as they both did a bunch of these.

[adidalal]

No strong opinion on the matter - we could compromise by just making it optional, but that leads quickly to the path of decay and uselessness, so a firm decision one way or another is better.

[victorpopkov]

I actually really like the idea of removing the license stanza. Having those just makes the cask maintainment more complicated and there is no gain of having those. So I'm good with proposal of removing them.

[Amorymeltzer]

Came here to defend the stanza but couldn't come up with a reasonable use case.[1] I agree wholeheartedly that it was weird for it to be required, especially with the unknown and todo workarounds. I'll miss it — a curiosity is of course interesting, plus I like the information — but there's probably not the utility so I'm fine with the removal. Some follow-up musings (since I seem to be into lists these days):

1. Going off the idea of not removing functionality, wouldn't the actual result here amount to not making them required, removing it from all casks, but allowing the functionality to remain?
2. I suppose one idea would be to revamp the concept of license to merely gratis, freemium, commercial and the like[2]; that would allow users to audit software know what they're getting into with a cask without being too onerous.[3]
3. One potential advantage I suppose, since we blindly accept licensing agreements, was offering some auditable idea of what you would be agreeing to by installing. If licenses are to be done away with entirely (i.e. not item 2 above) we would likely be making available much the same information, but in a very different manner and only after you'd gone through the process of downloading and attempting an install (aka failing late rather than early).

---

1: It's helpful for users auditing casks and likely very beneficial for users maintaining large systems with specific requirements, but the former doesn't really happen and the latter is really specific and not something they'd rely 100% on hbc for.
2: Fairly certain I've argued against this in the past.
3: That leans the way of discoverability, but as a side effect and not a goal, which is okay; arguably discontinued, depends_on, and MacOS.release allow for discoverability. Auditing is useful, see point 3 above.

[vitorgalvao]

@Amorymeltzer To address your points:

1. Not quite. We would yes not make it required and remove it from all casks, but not allow functionality to remain. Instead, it should actively inform the user the option is deprecated.
2. gratis, freemium, commercial would still be too much (even with those I see confusion). If they were just closed, oss, other, then perhaps it’d be manageable. They wouldn’t be that much useful, though. And again, since the stanza was introduced because of fonts, limiting it would make it useless in that sense as well. As for footnote 3, those options do indeed allow for discoverability, but as an unavoidable side-effect to something else useful. Not so with license.
3. We don’t want to blindly accept those, though, and to consider this it’s useful to think of the system as how we want it to work, not how it currently does (“skate where the puck is going to be” and all that razzmatazz). Either way, the licenses you’d need to know about the most (closed), are the ones we actually can tell you about the least just by giving you a symbol, as they will all be specific to their own software.

[Amorymeltzer]

What about fonts, though? I don't bother with them, but is this something that never really materialized to an issue on that front, or...?

[vitorgalvao]

Since license isn’t really usable anywhere, it never really made a difference there as well. To submissions there, they’re usually just the same amount of hassle. Sometimes even more, since it’s not uncommon for fonts to have no license other than the author mentioning in passing on the website “you can use it in personal and commercial projects”, or many times having nothing at all.

That’s another big issue of license. In some places it defines the code, the innards of what you’re getting (software), how you can modify it, while in others it defines usage (fonts), in which context you can use it.

We also were always straightforward about licenses being simply a guideline (i.e. “we’re not lawyers and make no promises to the accuracy of these, you should still check them for yourself”), and not intended to be accurate to the point of minutia (different GPL licenses, despite having so widely different versions they fiercely divide proponents in different camps, are all bundled in :gpl).

[Amorymeltzer]

(i.e. “we’re not lawyers and make no promises to the accuracy of these, you should still check them for yourself”)

Indeed. Much as I may enjoy license, after zap it's probably the most likely stanza to be erroneous, and at least zap is still useful in a partial form.

[adidalal]

Going to change my stance on this - license is nice, and it doesn't really kill us to have in terms of overhead. I would propose making it optional, though, to account for user taps, and then just encourage it to be filled out in Casks submitted to the main repo (as is already done with the comment, no need for more changes there).

[vitorgalvao]

it doesn't really kill us to have in terms of overhead.

Speaking strictly for myself, yes it does. To me personally, it is a major pain. And I do mean major. It’s not fun going to a repo of something I’ve never heard of and have no interest in using to grill the developer on the license. Or asking a user “is this a free app that works indefinitely but with limitations that can be removed by paying?” (freemium apps are frequently only gratis), or having to check an :oss license to make it more specific.

As for making it optional and encourage it on the main repo, I’m strongly against that. It’d be akin to making name optional, except the stanza would be even more useless. Why would anyone ever fill a field that has no real use and isn’t mandatory? It’d fall in disuse, and having it half-assed is the worse possible outcome. That’s what :unknown is for.

I say we either keep it as is, or get rid of it. Compromising is not a good solution in this case.

[vitorgalvao]

#17155, #17156, #17157, #17158 have examples of the (as I see it, useless and harmful) back and forth license causes. @jawshooah had to check the actual license, initiate a discussion with @sirdap to confirm why that license was picked, ask for it to be rectified, and explain our reasoning (that is on the documentation, even).

[vitorgalvao]

Another point against license, it being wrong or outdated and being likely the last stanza to ever be fixed (since it doesn’t affect usage at all).

@jawshooah Do you have an opinion on this issue as a whole?

[jawshooah]

Sorry, haven't responded so far as I have no strong feelings one way or the other. I do see the value in removing them though, and not much in keeping them around. As long as we just deprecate the core DSL methods associated with license, rather than removing them entirely, I'm fine.

[vitorgalvao]

Closing in favour of #17437.