Should we require licenseUrl?

Coordinator
Jan 18, 2011 at 8:13 PM

We've been discussing the idea of whether we should require licenseUrl when you upload a package to the NuGet gallery. The main reason is it makes it easier for a person to understand whether or not he can use the packages in their project without having to track down the author of each package.

This adds a bit of friction when uploading packages to the Gallery, but I think it's a good thing to require. What are your thoughts? This would mean that if you have an existing package without a license, it would stay in the feed, but you wouldn't be able to update it until you chose a license.

Jan 18, 2011 at 8:24 PM
I think it's fair to require it. It would help prospective customers.
Jan 18, 2011 at 8:36 PM

If you leave it empty, does that meet the requirement?

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

On Jan 18, 2011 2:24 PM, "dcazzulino" <notifications@codeplex.com> wrote:
Coordinator
Jan 18, 2011 at 11:02 PM

No, we’d require you specify something. Users need to know what the license is, even if it’s “© Me Fools!”.


Phil

Jan 25, 2011 at 11:23 PM

Not only should it be required, NuGet should also prominently display the license in its GUI and console shells. Prominent here doesn't mean using an in-the-face approach like forcing to accept the license before downloading. Instead, it should be sufficient to display the license (hyperlinked to an online version), including copyright notice (which could be inferred from assembly information by nuget.exe during packaging), under the package name and version.

Right now, I see there's an option to require license acceptance, but I think what's even more important is to download those licenses and add them to the project. It goes a long way to help people exercise the minimum and correct practice of carrying licenses notices as required by most open source licenses. In fact, if you're adding a package to a project and that package has other dependencies, each of which comes with a different (and hopefully compatible) license, then it is important to include all of those as well. It's a small price to pay for freedom while enjoying all the free beer. :) It's even a smaller price if tools can help.

It would also be helpful to give the user the choice to accept a license for good, for a project. For example, if the APL 2.0 is acceptable for one package, why wouldn't it be acceptable for another in the same project? It would certainly help where dependencies share the same license!

Finally, what's often forgotten is that most open source licenses are primarily concerned with modification and redistribution rights, terms & conditions. In that respsect, downloading in object form and using in a project is one thing. Download of sources, modification and redistribution of derivative works is another. The annotated Open Source Definition, for example, expresses what's at stake (see rationales) and therefore being protected by the OSI-approved set of licenses. The problem with prompting for agreement to a license is that it creates a false impression of accepting an “end-user license.” If it can mislead then why not remove it altogether? Instead, once a package has been added, what NuGet should list is the accompanying license(s) that was/were also added and which should be reviewed.

- Atif

Coordinator
Jan 26, 2011 at 12:09 AM

We already do display it prominently in the dialog. If you specify a license URL, we display it in the details pane. Our convention is to include the license.txt within the package contents. What we'd like to do is make it so that package authors can include a license.txt file in their package and have the gallery automatically extract it and provide a URL to that license.

You are right that the EULA and OSS license aren't necessarily the same thing, but they are often used by OSS authors in both capacities since the rights to the object files are often the same (aka they allow distribution of the compiled files).

Jan 26, 2011 at 10:34 PM

The license is shown in the dialog indeed. It just so happens that just about every package I sampled didn't have a license URL defined. The NuGet command-line interface, on the other hand, doesn't seem to show the license, even with the -v option on the list command.

What would be helpful is to recognize certain well-known license URLs and instead show their full name instead. For example, if someone sets the license URL to http://www.apache.org/licenses/LICENSE-2.0 exactly, then why not display Apache License Version 2.0 in all displays? It's just more human. :)

Coordinator
Jan 27, 2011 at 2:32 AM
Log an issue for each thing please. We'd like to make it more human friendly :)

Sent from my mobile phone

On Jan 26, 2011, at 2:35 PM, "atifaziz" <notifications@codeplex.com> wrote:

From: atifaziz

The license is shown in the dialog indeed. It just so happens that just about every package I sampled didn't have a license URL defined. The NuGet command-line interface, on the other hand, doesn't seem to show the license, even with the -v option on the list command.

What would be helpful is to recognize certain well-known license URLs and instead show their full name instead. For example, if someone sets the license URL to http://www.apache.org/licenses/LICENSE-2.0 exactly, then why not display Apache License Version 2.0 in all displays? It's just more human. :)

Jan 29, 2011 at 6:00 PM

Done: