How to handle DMG agreements?

[phinze]

Over in #452 the issue came up that with our current implementation, when a DMG with a required license agreement is opened by homebrew-cask, all you get is a contextless Agree? (Y/N) prompt.

One question was whether we have a legal requirement to display said license before the prompt. IANAL (I'd love to have one chime in!) but I'm actually inclined to go the other direction entirely and do the work necessary to skip all required user interaction. As I've mentioned before, I am strongly in favor of supporting unattended/automated operation of homebrew-cask as much as we can.

Here's what I propose as far as behavior goes:

• Extract the EULA and store it alongside the installed application in the Caskroom
• Display a notification that by using this particular Cask, you are agreeing to the thing stored at $PATH
• Provide an option for more conservative users like --prompt-for-dmg-agreements.

The more research I do on this, the more I find consensus that if an app really wants a license agreement to be accepted, the place to do so is at app launch, not in the package manager. Of course we can't control the way people are going to distribute their apps, but I think it's perfectly reasonable to automate away the prompt and notify the user that on this particular Cask they are responsible for reviewing and accepting the license agreement that we've conveniently pointed them to.

If this strategy makes people squeamish, I'm willing to discuss flipping the default and having the optional behavior be skip and the default behavior be prompt. But this is where I'm at - we'll see what other people say.

[vitorgalvao]

I agree that the best option is to have a way to show the agreement and the Y/N prompt, and another to bypass that altogether. I’d like to have more opinions regarding the default behaviour, though.

I’d say we can safely assume that an overwhelming majority of users do not read EULAs. There are some reasons why this happens, the main probably being that they’re usually (certainly not always) a thick wall of “lawyer speak”. The fact is they’re still there, and they’re still binding (whether this has real consequences or not, is another matter).

I think, then, that we shouldn’t be making that kind of decision on behalf of (unsuspecting) users. I’d argue (this is speculation, as I don’t have any numbers) that the users that read/care about EULAs are also the ones that would most likely know how to search for and disable a show option. This may seem somewhat contradictory, but I believe that’s actually how it should be — it acknowledges you do know what you’re doing and it was your decision, hence the responsibility is yours.

I agree that the optimal experience would be to not show by default (or to not have EULAs at all, but that’s not really in our control, in this case), and you do mention showing a warning that you’re automatically accepting the EULA, but I’m also not sure how effective that’d be (a user may not see it because it was lost on a long stream of commands, for example).

I’d say that since this concerns the users’ rights, we should show by default, leaving less room for mistakes (it’s also the default behaviour of hdiutil), but like I said, I’d like to see more opinions on this — I’m not completely sold either way, specially since we have HOMEBREW_CASK_OPTS that could take care of the users’ preferences in a straightforward manner. However, I believe the users that’d set this option there are the same I mentioned two paragraphs ago, so the argument stands as the reason why I think this is the approach we should take.

[tjluoma]

There are any number of warnings, etc that users might not see when they install a command using brew, including things like "This command may not work like you expect unless you do XYZ".

All you can do is explain it, and it's up the user whether or not they do anything about it.

OTOH, pausing to show the EULA (or even ask the user to agree with) it will break things. (What happens when the user has setup to install updates via launchd?)

I would suggest that the default should be that cask will automatically accept them, and if they WANT to see them, they can set something like

export HOMEBREW_CASK_OPTS="--prompt-for-dmg-agreements"

My 'mountdmg' script which I have used for ages does:

echo -n "Y" | hdid -plist "$FILENAME"

Which is basically automating what 99.9999% of the population does anyway: "agree" to the EULA without reading it.

(There is a way to bypass the EULA in a DMG by converting it to a different kind of disk image, so there's no way to actually prove that someone accepted your EULA anyway, but that's another issue.)

[vitorgalvao]

What happens when the user has setup to install updates via launchd?

You’ve answered it yourself

export HOMEBREW_CASK_OPTS="--prompt-for-dmg-agreements"

When a user wants to setup auto updates, they give the option to not show agreements to that script. Your point works for both cases, it is in no way a relevant argument for or against.

If a user chooses to not read the agreement or consciously bypasses the EULA by converting it to a different disk image, that is their issue. My concern is that if we’re making not show the default, we’re making a legal decision on their behalf; meaning they’re probably now in violation of the agreement, since most say “if you agree, you may use this, if you don’t, you may not”, and they never agreed to it.

I don’t have any formal education as a lawyer, but we’d probably not only be in violation of the law (by accepting a legal agreement on behalf of someone that has no idea it exists), we would possibly be dragging the user as well (by using a software she could only use after accepting the agreement, which she did not). Now, would this really have serious consequences? Realistically, I don’t see that happening (at least in the way things stand now), but can anyone guarantee us that? Until someone does, why should we be picking not show as the default, if it can be easily disabled? We could even show that message (“Do you agree? Y/N. If you don’t want to see this again, set this option”).

Most users don’t read the EULA, and most users won’t know how to activate the option to show, if the default is not show — those who choose to and are capable of setting the option from show to not show, are showing that they understand what they are doing, and want to go through with that decision anyway. Defaults do matter, but those should give a good experience, while providing an alternative, not provide a good experience by taking rights away.

[tjluoma]

Today I ran brew install wkhtmltopdf and saw this:

==> Installing wkhtmltopdf dependency: qt
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/qt-4.8.5.mountain_lion.bottle.1.tar.gz
==> Pouring qt-4.8.5.mountain_lion.bottle.1.tar.gz
==> Caveats
We agreed to the Qt opensource license for you.
If this is unacceptable you should uninstall.

I see no difference between agreeing to one kind of a license vs another, so if brew can accept the Qt opensource license for me, there's no reason why cask can't agree to the EULA to mount a DMG for me.

[vitorgalvao]

We’ve already asserted that there’s no technical reason why it can’t be done, and that not show is better in a usability kind of way; that is not the issue at hand, we’ve already agreed on that. Just because homebrew does it a certain way, it does not mean it is the correct course of action — if you can find a/the issue where they discussed this matter, where we can read their reasoning and opinions, maybe we’ll have more arguments either way, otherwise mentioning them does not really lead us closer to a resolution.

It’s also worth noting that they compile from source, meaning users will be accepting standard open-source licenses most (all?) of the time. That is not the case at all with homebrew-cask, as a lot (most?) of the applications that show an agreement, even the free ones, have commercial licenses. What’s right for them is not necessarily right for us; different projects, different goals, different needs.

[phinze]

All that being said, this is still valuable information @tjluoma - we often do end up analyzing papa homebrew and following suit. There's probably more divergence than normal in this particular issue, since they largely deal in Free and we largely deal in non-Free software. But nevertheless it's useful to know the homebrew behavior here.

[MattiSG]

I'd be in favor of defaulting to showing EULA and blocking until explicit user agreement.

Reason 1 is legal safety. It seems no one here (me included) has any real idea of the consequences of breaching a binding agreement, nor whether such consequences could fall on a software doing automatic agreement on behalf of a user.
Beyond agreement between the vendor and the final user, for which it seems indeed unlikely that a small software shop would hunt down, remember that many licenses (the Apache for one) and any US-based shop, are bound by national embargoes & restrictions. We're once again talking only about small software, but the players in the EULA game are not only small actors, big governments may also play a role.
Could it be possible that the software distributor be targeted for having its software distributed in an embargoed country through brew cask? Could the Homebrew Cask maintainers be? Could a user who installed DRM-breaking software (in countries such as France who make it illegal to circumvent DRM), such as VLC (yes, it's a French-based software), defend in court that it was all brew cask's fault? Am I completely off and don't understand a thing in these legal matters?
Anyway, it's complicated and until we can get actual advice instead of speculation, I'd rather err on the safe side with that stuff.

Reason 2 is awareness. Not reading stuff that's binding because it's annoying is problematic.
It puts all of us software users in a grey zone where we kind of agree tools to collect private data on us without really knowing how far it goes, etc. Initiatives such as ToSDR are emblematic.
But I don't think the solution to end such madness is to simply hide the problem. We should be remembered that we are all agreeing to possibly bad stuff simply because we're too lazy to act. And “acting” should not be “reading the EULA” but helping to reform them. (sorry, that one was a bit more philosophical)

I guess we all agree an “unattended” version of installation would be great. I'd definitely include a --blindly-accept-license option, but still default to blocking, just like today, with the added display of the EULA.

[vitorgalvao]

This issue has been open for a long time, and @caskroom/maintainers has suffered many changes since. I’d like those fresh eyes on it, so we can decide to do something about it or close it finally. There are many long points here, I realise, but I still ask that you try to go through at least the first comments.

More than licenses, I believe this to be important to keep users informed of their rights and limitations when installing a piece of software. @claui, I’ll mention your interest in UX again to request your comment on this (it should become clear why UX is a point when reading the arguments). I’m also pinging @rolandwalker and @ndr-qef specifically, since you’ve been enduring many of this boring decisions with me, especially as of late, for which I thank you. I’m also pinging you @Amorymeltzer, as this seems to be something you might have a well formed opinion on.

[rolandwalker]

I'm glad you brought this back – my general plan was to capture them into the .metadata directory.

[vitorgalvao]

I see how saving them is useful for later reading, but what about showing them on install time, with the added option to never show them? Basically @MattiSG’s last sentence.

I'd definitely include a --blindly-accept-license option, but still default to blocking, just like today, with the added display of the EULA.

Are we in agreement on that?

[MattiSG]

Come on, say it, my other sentences were noise :P

After re-reading the thread, I back my own proposal. Importantly, including the option name.

[tjluoma]

FWIW I think the --blindly-accept-license is probably the best way to go too, rather than defaulting to accepting them.

(This is a change of my previous position.)

The reason for my change is that I have since remembered reading stories online about EULAs being enforceable even if people claim not to have read them, and IIRC the judge's comments came down to "Whether you read it or not was your decision but you still said you agreed to it." So keeping homebrew-cask out of the "decision making" part of it is probably for the best, from a legal standpoint. (Insert standard Internet IANAL disclaimer here.)

To merge this new position back into my previous suggestion for an environmental variable, I'll add that I hope there is an option for people to do something like this:

export HOMEBREW_CASK_OPTS="--blindly-accept-license"

in their shell init files so users don't have to use it every time.

Then, in the output of the install command it could show something similar to what brew does for Qt:

Per your request we have blindly accepted the EULA for {App Name Here}

If possible, it would be nice to direct the user to where they can see the EULA that they have agreed to:

If you would actually like to read it, it can be found {here}

but I have no idea if that is feasible or not.

[MattiSG]

Yes, as @phinze put it:

Extract the EULA and store it alongside the installed application in the Caskroom

would be nice.

We probably can have access to the EULA contents, since we're talking about DMG/PKG metadata.

An additional possibility is to output the EULA even with --blindly-accept-license. The main use-case for this trigger being unattended installation, logging what was done both technically and legally seems logical.

[claui]

A few thoughts on this:

• IANAL but I agree that it’s a good thing to block/ask by default and introduce a CLI option as suggested. I also agree that UX-wise, it would be nice to output the content of the EULA in any case like @phinze and @MattiSG have suggested.

• As to the wording of the new CLI option, we might want to consider --accept-eula (example 1 2 3), --eula-agree (example), or --eula-agreed (example).

• @MattiSG @tjluoma Do you see a reason to include the word blindly? To preserve the neutral tone that one would expect from a package manager, I suggest that we drop the blindly part unless we strongly feel a reason to include it from a legal or UX point of view.

• I figure that at present, a lot of scripts in the wild are relying on brew cask install not blocking. Some of those are going to break but I feel we should be fine with that, given authors can simply add the option if they feel like it.

• I am still NAL, though I feel like rewording Per your request we have blindly accepted the EULA, just to make it clear it’s not us who are accepting the EULA in the sense of making any decision on the user’s behalf. After all, we’re just relaying a decision already made by the user, or by whoever configured brew cask. I suggest rewording it to something like this:

  You have opted to accept the EULA for {App Name Here} without having homebrew-cask present it to you.

• As a possible future enhancement, we might want to change the workflow of both brew cask install (given multiple Casks) and the upcoming brew cask upgrade. The idea would be to present the EULA content of affected Casks all at once, and as early as possible in the installation process. This would resemble a bit what the App Store already does when it upgrades multiple apps, which I think is very user-friendly. From a technical standpoint, we might want to teach the installer how to fetch just the affected packages up front. I feel like opening a separate issue to discuss this.

[Amorymeltzer]

Coming in late but I absolutely agree with the above. Nearly everyone will --blindy-accept-license in HOMEBREW_CASK_OPTS (and that's okay) but it is indeed better to default to the safer position.

I'd support having the option to show the EULA even if blindly accepting it, but I think that should be a separate option, --force-show-eula or something. That's more of a power-user/logging operation that doesn't need to further-encumber users when the whole point is nobody reads these things anyway.

Since I had a hard time figuring out the various stances, here's mine:
Store it as @rolandwalker said, and

• No OPTS: Print EULA, ask [Y]/n (default to yes, because let's be honest)
• --blindly-accept-license: Print output à la @tjluoma and @claui informing users where what they agreed to can be found.
• --bal and --force-show-eula: Accept EULA, print text thereof.

[MattiSG]

Do you see a reason to include the word blindly?

Yes: education. I gave more details in my longer comment above, but the gist of it is:

I don't think the solution to end such madness is to simply hide the problem. We should be remembered that we are all agreeing to possibly bad stuff simply because we're too lazy to act.

This is the same reason why JSX has a dangerouslySetInnerHtml method: you are doing something that may be bad. Better be aware of it, with no ambiguity.

To preserve the neutral tone that one would expect from a package manager

Well, I don't expect my open-source, dev-friendly package manager to have a neutral tone. I expect it to have commands such as doctor or zap rather than the corporately neutral check or erase :) Also: subversive documentation FTW!

Are we sure brew cask install doesn't block at the moment? It's been a while since I tried it, but last year I was saying it did (I could have been wrong though).

The idea would be to present the EULA content of affected Casks all at once, and as early as possible in the installation process.

To me, the main use case is automated installation and upgrades. If I'm installing stuff manually, I'm doing it app by app, so no need to group EULAs. If I'm doing it automatically, I don't care how they are presented, I just want them not to block.
This indeed sounds like a separate issue.

I'd support having the option to show the EULA even if blindly accepting it, but I think that should be a separate option

Then it would probably be best from the UX standpoint to have switches in the same direction: default to full legal compliance, add options to opt-out from it. That means, for example: --blindly-accept-license --dont-even-read-it (might find a better name for that one though).

(finishing off quickly, don't hesitate to ask for rephrasing)

[phinze]

Hey folks!

Glad to see this discussion picking back up. Just updating with my latest thoughts on the issue.

• I still think that DMG agreements are a poor place for an application to acquire EULA acceptance.
• I'm now less invested in pushing this project to take a controversial position. We're bigger and more legit now.
• Given this, while I still hate the idea of interrupt-by-default, it's probably the safest move.

If we can include super-clear instructions about how to configure auto-accept every time we prompt, then I will be happy. 😀

[claui]

@MattiSG Apologies for verbosity. I’m going to post multiple comments to make my answers a bit easier to read.

Yes: education.

I agree that it’s a good thing to prevent the user from doing harmful things to themselves. In my books, this is part of good UX. But then again, I like the philosophy that goes: software programs should do one thing and do it well.

Would you say educating the user is a part of the mission of this project? Maybe it is. I don’t know but I wouldn’t personally embrace it as a goal. I’d rather have software do one job really well than have it pursue many. But your mileage may vary. ☺️

[claui]

Well, I don't expect my open-source, dev-friendly package manager to have a neutral tone.

Good point. Thinking about it, I wouldn’t actually mind if my package manager had a tongue-in-cheek tone or rather an ultra serious, an enterprisey, a hipster, or a happy-go-lucky one.

What I do expect from my package manager though is that it’s friendly and unobtrusive, and that it prefers yes over no.

I expect it to have commands such as doctor or zap rather than the corporately neutral check or erase :)

Yes, I agree that doctor and zap are fine. They’re also super easy to remember.

However, for some users, could the message Per your request we have blindly accepted the EULA appear on every brew cask upgrade come across a bit biased? I can only speak for myself, but some might prefer their package manager rather not tell them how it feels about their choice of command-line options.

[claui]

Are we sure brew cask install doesn't block at the moment? It's been a while since I tried it, but last year I was saying it did (I could have been wrong though).

I see. Looks like auto-accept has been reintroduced only recently (be4cec1).
I just double-checked by brew cask installing sketchup and no-ip-duc. In both cases, it auto-accepted.

[Amorymeltzer]

Then it would probably be best from the UX standpoint to have switches in the same direction

I suppose I agree @MattiSG, but since we're thinking that close to 100% of users prefer the current schema, every single HOMEBREW_CASK_OPTS will be set to at least --blindly-accept-eula --dont-even-read-it which starts to get unwieldy to (re)achieve what is currently a vanilla install. And, FWIW, blindly itself implies we didn't even read it... ;)

[claui]

If I'm installing stuff manually, I'm doing it app by app, so no need to group EULAs.

@MattiSG As you have suggested, I’m going to comment this in another issue in a bit more detail, and propose a few scenarios to explain why grouping EULAs might be a good idea.

[MattiSG]

But then again, I like the philosophy that goes: software programs should do one thing and do it well.
Would you say educating the user is a part of the mission of this project?

Sure, that's the appropriate question.

I don't know if it is part of the mission of this project. What I know is that something is terribly wrong with the way intellectual property works ATM, that FOSS is part of the solution, and that I personally do use whatever I can to improve the situation. If you've ever signed or felt concerned about an EFF petition, for example, then I think you should wonder why you would do something with as little leverage as signing and delegating to someone else to build pressure, and why you wouldn't use the freedom you have to use the phrasing of a large FOSS to build that same pressure.

Being neutral means offering a proper, functional solution in a dysfunctional system that makes you feel as if everything was right. It is a good thing if we consider the software only, and it definitely is what should be done in the case of a commercial software.
Being tongue-in-cheek means offering a functional solution that doesn't help you forget that the very reason why you have to --blindly-accept-license is bad. It reminds you that something is broken, and will nudge you towards changing it the next time you have an opportunity.

Now I will stop rephrasing and writing huge messages ;) I hope I've made my point, let's decide.

[MattiSG]

Looks like auto-accept has been reintroduced only recently

This changes the hypotheses that were made one year ago. We might be breaking stuff with this (probably not too bad, just a matter of adding options to scripts) and making users angry (depends on how much auto-accept has been publicized).

[vitorgalvao]

If auto-accept has been reintroduced, I say removing it is a priority. Since we have absolutely no qualifications to understand the ramifications of accepting legal agreements on behalf of users, that could easily be taken as a breach of trust.

In the end, we’re talking about one simple command that can even be set only once, and one we all seem to be agreeing is now a necessity.

[tapeinosyne]

I appreciate the preference for treading lightly in the legalistic haze of EULAs, but lightly is not how we can take the decision to make brew cask install a blocking operation.

Such a change would break all scripts relying on our default behavior, the presence of which is not a conjecture: a naïve search yields thousands such scripts on public GitHub repositories alone.

(I should also like to mention that, for a unixy tool, blocking by default is rather unsavory. This would not be problematic, had we not described and advertised the project as “unixy” since its inception; by now, we have shaped expectations.)

In terms of UX, scripts would again be my primary consideration. With the assumption that:

• the brew cask command is only used occasionally, and thus
• users do not follow the project closely,

I would wager that:

• users expect a stable interface;
• users may not upgrade brew-cask often, and thus
• users may not notice breaking changes for a long time.

(This guess is corroborated by the version numbers of brew-cask being weeks or months old in many bug reports.)

The first point would be a minor inconvenience: users who first encounter the breaking change at the CLI would be required to read about it and reconfigure their Cask options.

The last point, however, means that there may be users who launch hours-long OS X setup scripts, blissfully unaware that brew cask install is now blocking.

[MattiSG]

a naïve search yields thousands such scripts on public GitHub repositories alone

Just for the grain of salt: I would show up in your search and I would be fine with adding HOMEBREW_OPTS=--blindly-accept-license somewhere, just like I already have to add --appdir /Applications.

I am quite curious about the evolution of brew cask behavior on this EULA auto-accept stuff. It seems one year ago we didn't have it, @claui says it's been recently re-introduced…

If we don't feel at ease with the proposed change, I see two relevant sets of metrics:

1. Evolution of auto-accept, number of open issues relating to said evolution, delay between change and first open issue.
2. Total number of casks with an EULA, and installation frequency of said casks.

---

Please note that even if we can gather more information, my personal opinion is that no matter what is currently the case, when comparing the unmeasurable legal risk versus the measured inconvenience of adding an option once in a script, I strongly support taking the safe path.

[rolandwalker]

There has been no recent change in behavior with regard to DMG EULAs. The bugfix @claui linked to is from October 2013.

[vitorgalvao]

Closed in favour of #13593.