Update terms to clarify distribution rights

spdustin commented 8 years ago

This proposed update further clarifies and makes formal the previously styled "special license" granted to npm, and clarifies language surrounding any licenses that may survive the removal of user generated content from the registry.

kemitchell commented 8 years ago

@spdustin: Thanks for this! Dropping a line to let you know both npm and I have seen your PR and are discussing it. As you might gather from the number of new posts on the npm blog of late, these are busy times for the folks behind the registry. Thanks for your patience!

In the meantime:

In case you don't already know, I am npm, Inc.'s attorney. They've made a special request that I participate in /policies issues to consider and respond to feedback from the community, especially proposed changes. I hope it goes without saying that you should rely on your own attorney on this if you need to, and that legal documents like terms of use are complicated legal critters. npm asked me to participate this way to make sure community feedback gets reflected in npm's terms, but I'm here representing npm, Inc.

You can see a bit of how that works in #34. That issue also addressed the license language you're concerned about. It's probably relevant reading, if you haven't seen it already.

It looks to me like the major substantive change proposed here is to replace the language about npm being able to share content that folks share on npm with other npm users. I think it's fair to say that your new language is more "traditional". It uses the style, and many of the same legal terms of art, used in contract-style open-source licenses like the Apache License, 2.0 and the Eclipse Public License, 1.0, as opposed to the more conversational, plain terms of MIT, the 2-clause BSD, or, say, GitHub's Term of Service. Please let me know if you agree.

As the lawyer, I'm generally in favor of more specificity, and I think that your changes would add a bit of technical clarity on a few points, such as what happens if npm changes legal form. At the same time, all the folks at npm have made very clear they'd like to keep their terms as readable by nonlawyers as possible, which often means leaning on what's legally or practically implied, rather than stating every fine point. I'm going to keep that in mind as I think about your proposal.

Thanks again for taking the time to send!

spdustin commented 8 years ago

I agree that this is more "traditional" than "conversational". Myself, I prefer the more conversational style, and have our counsel legally vet our more conversational contracts for enforceability. Language similar to the current terms use by npm has been flagged to us as being difficult to defend; implied licenses are enforceable, of course, but the lack of "styling" or framing the license in more obvious and direct terms open the door to various interpretations in court. Or so I'm told. :wink: I believe even referring to it as the Special License (capitalization intended), and clarifying that once you submit to the npm directory, npm, Inc. has the irrevocable right to distribute, analyze and archive your code.

The other point, that you mention, is that the current terms do not specify clearly that the "special license" may be transferable, should npm, Inc. cease to be, or it sells its business to another entity.

I'm personally interested in the outcome of this, as it relates to the terms to which npm's package contributors agree. I strongly believe that the correct terms here can serve the dual purpose of showing users that npm, Inc. cares about the spirit of open source, and protecting its right to potentially go against the wishes of those users.

spdustin commented 8 years ago

Additionally, this text (emphasis added)

The license lasts, for each piece of Your Content, _until the last copy disappears from npm's backups, caches, and other systems_, after you delete it from the Website or the Public Registry.

seems "weaselly". Without knowing policies and procedures of npm, how would a contributor know when backups might cease to include their package? Are perpetual backups the policy, which effectively makes the license permanent? What other systems? The Internet Archive may have a copy, an edge cache may retain a copy on disk. When you specify "npm's backups", are they stored on AWS or RackSpace or Azure? What if they have backups too, to enforce durability? Do they ever really delete anything?

These are all hypothetical, of course, but the wide open door that language like that seems to leave open seems to make folks wonder if they're being tricked. After all, how do they know how long backups last and what aging policies are on what caches? More direct (even if conversational) language makes it clear what you mean.

kemitchell commented 8 years ago

@spdustin, thanks again for some very good input. We're still shopping the specific changes in your PR in-house, but I'd like to go ahead and address some of the (very much on topic) side issues you've raised.

On "styling", contract style defined terms (hereinafter, "Defined Terms"), and more lawyerly language, I think I'd certainly agree with most counsel that lawyers are at least more comfortable in that mode. But I'm not convinced lawyer comfort is sufficient or necessary for the right effect in conflict, especially when fixed, consumer facing, and nonnegotiable terms of service are involved. I'd put npm's current terms somewhere between GitHub's almost folksy content license, which neither uses the term "license" nor mentions what GitHub, rather than users, can do, and the sterile, contract-like, "enterprisey" language of, say, Apache 2.0. I think that's where we want to be.

Your point on assignment or succession to the license is well taken. @izs and npm's public position on this license have always been that it should just spell out what was implied from users of npm before. If the license is coextensive with that natural understanding, neither broader nor narrower, there are many fewer misgivings to have about legal changes "under the hood".

You mentioned concern about "terms to which npm package contributors agree". I'd like to make sure I understand what you mean by that. Mind expanding a bit?

On "open source", as usual, things are complicated. Partly, that's because the term is severely overloaded. To some it means software released under an OSI-approved license with all the proper IP protocols and precautions. To others, it means what folks do on GitHub these days, in the main with nary a thought to licenses in or outbound. I'm not aware that npm, Inc. takes any particular stance on the the narrative, vocabulary, or politics involved, other than to promote people doing awesome with software generally.

Various parts of npm have publicly acknowledged that "Open Source" (in the OSD sense) has a special place in npm, Inc.'s collective heart. At the same time, neither the registry, the package.json spec, nor any number of other touch points require OSI-approved licensing. It's perfectly possible to mark a package "Unlicense", "WTFPL", or "CC0-1.0"---none of which are OSI-approved license terms---and also to publish to the public registry with no license information whatsoever.

Finally, on termination of the special license, I'll be reaching out to a few others for reactions, too. I really appreciate that you've shared your candid reading. At the same time, I want to lean toward letting language settle when it can. Especially when the concern is what may be read between lines, I need to be sure I've actually got a shot at improving perception by throwing more language at the problem.

Thanks again!

spdustin commented 8 years ago

You mentioned concern about "terms to which npm package contributors agree". I'd like to make sure I understand what you mean by that. Mind expanding a bit?

Sure; My original statement...

I'm personally interested in the outcome of this, as it relates to the terms to which npm's package contributors agree.

...was meant to show that, as a contributor to open source, I'm invested in the outcome of this discussion - it may come to pass that I wish to contribute a package to the npm registry, and I'm curious as to how the language will "settle", since it may affect the rights I have as a contributor should I include a license in my contribution, especially one that would seem to curtail npm's right to distribute such code in perpetuity. I say in perpetuity because in today's climate, where cynicism towards corporate entities seems to be growing each day (and disk space cheapens to the point of triviality), the "_until the last copy disappears from npm's backups, caches, and other systems_" portion of the terms would likely be seen as a de facto perpetual license.

I agree that there's a middle ground between "folksy" licenses where nothing is really asserted but warm fuzzy feelings, and "enterprisey" licenses, where every other phrase seems like a latin incantation. If npm, Inc. intends to affirmatively defend itself from backlash when it decides in the future to damn the torpedoes and continue to distribute code that the contributor intended to retract, I think that middle ground would need to lean a bit toward legalese.

Good feelings and folksy open source kind-heartedness are wonderful when they're in ample supply, until they're not. Know what I mean?

I hope the discussions being had around the terms are not too far removed from the harsh realities of such large and inclusive communities. There will be jerks, heathens, and assholes, in proportion to the laid back devs, free-as-in-beer-and-as-in-liberty hackers and shiny happy people. It only takes one particularly motivated scorned developer to make the nice guys regret being so nice. Hope for the best, and prepare for the worst, and all that.

Thanks for your response, Kyle. It is refreshing to see this kind of transparency, even though I suspect no change is forthcoming. Of course, you're not obligated to change the text of the agreement just because some random dude on the Internet suggested you should, and I don't have any expectations that you would. I'm happy to be part of the dialog, and to inject an additional viewpoint into the conversation you're having with npm, Inc.

spdustin commented 8 years ago

@kemitchell I'm curious what you think of this amendment, which aims to be more friendly in language and spirit, while still making it clear that npm, Inc. can keep distributing content even if the contributor changes their mind.

kemitchell commented 8 years ago

@spdustin Thanks so much for https://github.com/npm/policies/pull/45#issuecomment-204184152. I have no right to your time or thoughts, and I'm very grateful for so much of both in that comment. That kind of feedback is just so valuable.

As for the commits you've pushed, I'll make to fold them into the internal conversation on this PR. On a related note, though I don't think this is necessarily what you meant, I do have to make clear that I can't offer any personal assessments here, either as an attorney or as a man-about-open-source more generally. It's a freedom I gladly trade to assist as legal counsel, though it pains me especially here. I'd so like to pay your generosity back in kind.

As for hard results, I can't promise npm will land any part of this PR, and certainly can't promise that it will do so quickly, given how many new and unexpected development and other demands are bearing down on npm-folk right now. But I'd be very surprised if the language you've patched goes without further change for all time. I suspect future tweaks will sound both in the substance of your commits and in related discussion here.

Thanks again!

spdustin commented 8 years ago

On a related note, though I don't think this is necessarily what you meant, I do have to make clear that I can't offer any personal assessments here

Tone is hard to come by in text form, of course, but I was being conversational and not seeking legal advice. I do understand the ethical implications of offering such advice, and frankly just didn't think that far into it. Thanks for your time, @kemitchell. :smile: