Deprecate <requireLicenseAcceptance> from nuspec and VS

[anangaur]

@anangaur commented on Thu Oct 25 2018

This field adds little value and should be deprecated.

[nkolev92]

@anangaur Can you please add the priority on this.

[Entomy]

"This field adds little value" Spoken like someone who hasn't read much EULAs. By not prompting for license acceptance you get into a really grey legal area involving contractual entrapment and IP violations. Better to leave it in, and if someone doesn't care to use it they can leave the property false.

[karann-msft]

@Entomy but how do you know that the person who installed the package ever saw a license acceptance dialog? It is up to the client used to honor that property. Why do you think setting that property to true is legally binding?

[Entomy]

"Why do you think setting that property to true is legally binding?"

Do not put words in my mouth. I was only arguing that the property is required to implement those dialog boxes. Everything you mentioned is implementation details that are only possible if the aforementioned property exists. The debated topic is the property, not issues with people not utilizing the property properly; that's another matter entirely.

[karann-msft]

@Entomy - let me come at this from another angle. Do you know of a package that depends on that property to enforce a legally binding contract? How do you feel about leaving the property in but clients not respecting it?

[Entomy]

That's the black swan problem. Just because I don't know of a package which relies on it doesn't mean there isn't one. And as a user of this package manager, I'd feel much better approving package licenses before installing them, especially as with many EULA's, installation is defined as acceptance.

Although really, the questions you're asking are much better fitted for a lawyer, not a buncha devs on GitHub.

[karann-msft]

@Entomy what client do you use to install packages?

[Entomy]

As for clients not respecting the property, well, it's not like this is the only peice of software where that happens. Web sites still use bot files even though a malicious crawler doesn't have to obey anything in the file at all. Why bother using them then? Well it's because something is still better. Sure a stupidly written nuget client could ignore the property. But without the property there at all, a well written client simply can't require license acceptance at all.

Not everyone respects seat belts and speed limit laws. But we still keep those in place.

[Entomy]

@karann-msft I formerly used the "OneGet" commandlets. I say formerly, because with no license acceptance prompt, I'm left going to each website and reading the license, unless it's one I'm already familiar with. At that point, I might as well avoid using nuget at all and just download from the site I'm already at.

I run a business. Legal compliance is considerably more of a concern than just some random person downloading some software.

[tom-made]

I'm in agreement with others here around having this option still available.

While we could argue the fact that NuGet clients should provide functionality to read this and action it, the fact is, developers need to agree to licences if there are any before taking a dependency on the package.

[dotMorten]

We require this for our packages. It might be an annoying dialog for some but necessary evil for others. It might even come to the point that we can't support nuget any longer without this.

[anangaur]

I think the real question here is how easy and apparent it is to understand the licensing of the packages and if by popping up the accept license makes it 'more' legally binding than without the popup.

For making licensing clearer and easier to understand, we are taking the first step so that developers for most common licensing, should be required to go to an external link. We are coming up with a support for defining SPDX expressions. So instead of hosting your own license URLs, you can define an expression like MIT which would be visible on the client. @Entomy Isn't this something that will alleviate your concern(s)?

Coming to the requireLicenseAcceptance property, I do not think specifying this or not, makes the license less legally binding. We are getting legal experts' views on this currently. If the licensing is clear to the end developers before they consume the package, then I guess the purpose should be solved. Let me also add again that this is my hypothesis and the final confirmation should come from the legal experts who we are consulting for this.

@dotMorten, I would love to understand more on the benefits you get by the the extra popup. Irrespective of the popup, I think the consumers of your packages are bound by the packages' licenses.

[jamesmcroft]

@anangaur regarding your last comment to @dotMorten, the pop up provides a very clear decision by the user to accept that they are okay with using a licence for a package. I wouldn't want to install anything that was licenced without first reviewing it and that dialog is my indicator to go have a look. A consumer of a package may be able to find a link to a licence before installing but it's simply not enough.

It's almost like installing a piece of software without being prompted that you need to agree to some terms first.

[dotMorten]

I think the consumers of your packages are bound by the packages' licenses.

Well if you remove this tag, then what package license are you talking about? The fact is license acceptance is an integral part of nuget packages today. If you remove this, it's eroding the message that nuget packages can have licenses you must accept. After a while people will have all but forgot there's such a thing. The argument that some clients skips it is a moot point for me, just like we still have laws even though some people break them, or they aren't being strictly enforced everywhere. This license acceptance dialog is known to pretty much everyone, and most developers know that a package might require you to accept something, regardless of the client you use that particular day. We all know this because we've all seen this dialog before.

[anangaur]

@dotMorten What about educating the users to understand that they should abide by the licensing of the packages before using the packages and that the licenses of packages are different than the license of the tooling - irrespective of the requireLicenseAcceptance property? This can be done in various ways either by highlighting this information on the package Manager UI or have a consistent pop-up on every package install as a reminder or something better.

My argument is that all the users of packages should have the above understanding and from tooling we should make an effort on the education of it. Leaving the choice to package authors to enforce accepting (via the property) or not accepting a license does not seem (to me) to solve the issue of users' education on this matter.

[Entomy]

@anangaur SPDX extensions are certainly something that would make license management and compliance considerably easier. But even as you stated, this is for common licenses, and does nothing for the EULA. EULA's can be anything, and often have a clause stating that use of the software or library is considered acceptance of the terms of the license; this is why contractual entrapment is an issue. But it also is just generally required to make sure the license terms of the developer are respected. I don't feel at all comfortable releasing my work through a platform that says "license acceptance isn't a priority". Even if I generally license under very liberal terms.

"if by popping up the accept license makes it 'more' legally binding than without the popup." You keep doing this. You're (The three of you who incidentally all work for Microsoft who's well known for sketchy license terms) the only one talking about how "legally binding" it is or isn't. Everyone else is talking about it being a good thing for the sake of transparency.

No one is arguing against education of the users by any means. But let me ask you this, which requires less work? A requireLicenseAcceptance property and some basic advocation for its adoption. Or a large scale education campaign trying to reach all developers who use and potentially will use nuget?

"by highlighting this information on the package Manager UI or have a consistent pop-up on every package install as a reminder or something better." This is good thinking.