Updating the Copyright

[jasnell]

Back in the io.js days, the copyright attribution in the Node.js source code was changed from:

Copyright Joyent, Inc. and other Node contributors. All rights reserved.

to

Copyright Node.js contributors. All rights reserved.

The explicit licensing header information was also removed from each source file and moved into the LICENSE.

The change to the copyright notice was made without Joyent's approval and needs to be switched back.

I will be opening a PR that attaches the following statement to each *.js file in our source tree:

// Copyright Joyent, Inc. and other Node.js contributors.
// Current Licensing information for this software may be found in 
// the LICENSE file in the root of the source distribution or online at
// https://github.com/nodejs/node/blob/master/LICENSE

Because this Copyright statement explicitly includes the "and other Node.js contributors", there is no loss of Copyright assignment.

/cc @nodejs/tsc @nodejs/ctc

[williamkapke]

There were some in .h, .stp, .rc, & .cc files too.
It sounds like they need to be included too...?

[ljharb]

Why does the comment need to be in every file? Isn't that information redundant given the root-level license, and the git history?

[bnoordhuis]

What @ljharb said. It should only need an update to the LICENSE file, no need to bring the boilerplate back unless the Foundation's lawyers say so (and in that case I'd like to hear their argumentation.)

Also, "Copyright Joyent, Inc. and other Node contributors" - I don't think Joyent gets to make copyright claims to code they didn't author. Which is most code in the tree but especially new files.

[jasnell]

@mikeal can likely expand on this but the request from the legal committee as I understand it is to restore the copyright and license statements in the individual files. For now the PR that I am adding will add the header to every *.js, *.cc, and *.h file in benchmarks, lib, src, and test. We can pull the header back out of the files that are not appropriate.

Regarding the specific language in the updated header, I'm going to leave it to the lawyers to determine which wording is most appropriate.

[mikeal]

Here's the deal.

The terms of the MIT license state that you cannot modify the attribution. Guess what we did? Altered the attribution.

The attribution needs to be restored to the prior state. If we want to modify it later, like consolidating or reducing to an SPDX definition, we can but we need the consent of the copyright holders.

The files effected were authored by Ryan Dahl and/or contributors who operated under the prior CLA with Joyent so the notice containing Joyent, Inc is accurate. We do not need to add this notice to any other files than those that it was removed from a few years ago. New files or files that never contained the notice do not need to be modified.

[bnoordhuis]

The files effected were authored by Ryan Dahl and/or contributors who operated under the prior CLA with Joyent so the notice containing Joyent, Inc is accurate.

How so? The CLA didn't transfer copyright.

EDIT: To clarify, Ryan transferred his copyright to Joyent but no one else did and that wasn't part of the CLA.

[jasnell]

I have opened the PR. Without a doubt it includes files that do not need the attribution included. I will need help in identifying what files those are. @mikeal: please have the legal folk review the specific attribution to see if that meets the requirement or not.

[mikeal]

@bnoordhuis correct, it didn't transfer copyright but it gave a license for all relevant rights to Joyent.

[bnoordhuis]

I'm afraid I still don't understand. What are "all relevant rights"? My understanding when I was asked to retroactively sign the CLA was that it was an affirmation that I had been legally able to contribute the code; that my employer couldn't make claims to ownership, for example.

Also, who is asking for reinstatement of the attribution and why? Joyent, the Foundation, someone else? Names, please!

[jasnell]

@mikeal @bnoordhuis ... it would likely be worthwhile to add this to the agenda for either the TSC or CTC agendas. Given that the request is coming from the Legal Committee, it likely would need to fall under the private section but I'll leave that to @mikeal and @rvagg to decide.

[mikeal]

Let me be clear about something, we broke the terms of our own license.

It's something that needs to be fixed, there's not a lot of room for interpretation on that.

[bnoordhuis]

Nonsense. "all copies or substantial portions of the Software" - note the "or". Every source tarball has a LICENSE file in it and that satisfies the MIT license's attribution requirement.

If the Foundation's lawyers disagree, I would like to hear them explain why. If we are in violation, then so are a ton of other open source projects.

Can you answer my questions from #174 (comment)?

[mikeal]

Every person with legal expertise I've spoken to so far agrees we need to restore the attribution and copyright notice. That includes people inside the LF and counsel from member orgs.

If you want us to pay our high priced lawyer to argue with you about the law then you can request that the TSC send it to the board and that the board pay our lawyer to convince to you.

[bnoordhuis]

@nodejs/tsc Please see #174 (comment) and #174 (comment). I would like to get an official opinion from someone with a legal background. Let's put that allocated money to use!

Mikeal, I'll ask you nicely again: will you please answer my other questions?

[jasnell]

I've put this on the tsc-agenda for next week. Let's continue the discussion there. @mikeal, let's see if we can get one of the foundation's legal committee reps on the call during the private session.

[mikeal]

@jasnell could you invite Scott Nicholas from the Linux Foundation? I don't have write access to the calendar event.

[jasnell]

Will do

[trevnorris]

Since the copyright states contributors retain the right to their own code, isn't the "we need the consent of the copyright holders" just a tad unrealistic? i.e. say it does need to be restored to the top of the file, and consent of the copyright holders needs to be given to change that, then we're pretty much saying that the header must always be there unless we go chase down everyone that had contributed to the project by that point?

[mikeal]

@trevnorris yup. that's why re-licensing is so hard without a CLA. We're free to add notices though, or modify the copyright and/or notice of future contributions.

[bnoordhuis]

Node and libuv contain code that has been lifted wholesale from other projects, with attribution usually consisting of a comment saying // Copied from $project and sometimes a call-out in the LICENSE file.

By your reasoning, the full license boilerplate should have been included in the source? What about the LICENSE file?

[mikeal]

If the original files had full copyright and attribution then that probably should have come along with it (depends on the license, but most require it).

If the original source only had a LICENSE file in the project then you did the right thing.

There's an important distinction here: having the copyright in a LICENSE file or in the individual files doesn't make the code more or less owned by the owner or licensed under that license, it's just a difference in preference for expressing the license.

However, most licenses require that you respect the copyright owners preferences when copying or distributing the work. So while it may be your preference to express the license and terms differently from the author(s), most licenses require you to retain the author(s) preference for what you take from their work.

[trevnorris]

@mikeal Taking from earlier discussion, does this mean that all of src/env*.h don't need the copyright header since they were contributed by @bnoordhuis?

most licenses require that you respect the copyright owners preferences when copying or distributing the work.

But the "preference" isn't written into the copyright. All ours said is:

// The above copyright notice and this permission notice shall be included
// in all copies or substantial portions of the Software.

Are we to imply that because they included it at the top of every file their "preference" is to always have it included at the top of every file? This doesn't seem near explicit enough legally to for use to place it at the top of every file.

[mikeal]

Are we to imply that because they included it at the top of every file their "preference" is to always have it included at the top of every file? This doesn't seem near explicit enough legally to for use to place it at the top of every file.

I'm just re-iterating what I've been told by numerous people with real legal expertise. As we know, I'm not a lawyer, I'm just telling you what I understand based on hours and hours of listening to lawyers talk about this stuff.

Also keep in mind that the MIT license was written by engineers and not lawyers so the language is less than ideal. This is one reason a lot of lawyers prefer other licenses written by lawyers like Apache-2 :)

This is the best breakdown of the MIT license by a real lawyer I know of https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html .

Taking from earlier discussion, does this mean that all of src/env*.h don't need the copyright header since they were contributed by @bnoordhuis?

It's a good idea to have the SPDX reference in every file because of the DCO.

This gets a little tricky. The project is using the DCO and it states the contributor agrees to "the license in the file."

That means that we need at least a reference to the license in the file. This was why we settled on that SPDX shorthand for the license def and standardized language around "Copyright Node.js Contributors."

This is good hygiene for code auditing tools anyway and is only a single line or two.

[trevnorris]

@mikeal To clarify, I'm not disagreeing with what you're saying. It's that I have large discrepancies in understanding what I've been told and why that means we need to have those lines at the top of the file. The only reason I care is that by adding them back in, then removing them again, our git history will be less than ideal. (just had an idea, can we add it back on branch that isn't master and have that count?)

Do you mean this DCO? What node bound by that prior to braking off into io.js?

[mikeal]

Do you mean this DCO? What node bound by that prior to braking off into io.js?

Yup, that's it. We added it in the early io.js days and it was brought over during the merger. It's also referenced in the legal guidance we've gotten from the legal committee and in a bunch of other project documentation.

There's broad buy in from the legal resources at the LF, NF, and the NF Legal Committee on the DCO, so it's shouldn't be seen as just this thing we happened to merge when io.js came in though :)

[panuhorsmalahti]

Changing the copyright attribution back to one file (say, at the root level) is plausible, but I don't see what argument can be made that it needs to be added back to every file. Or can we add it back to every file, then remove it afterwards? How about after adding it back, can we merge two files and then only have a single attribution in the file, then separating them again but only retaining the attribution line in the other file?

[rvagg]

@mikeal @ TSC meeting today:

Board ratified decision to merge the first PR, second PR is still being discussed.

[jasnell]

I'll get the first pr ready to land with a target of getting it by end of week.

…

On Thu, Feb 23, 2017 at 12:23 PM Rod Vagg ***@***.***> wrote: @mikeal <https://github.com/mikeal> @ TSC meeting today: Board ratified decision to merge the first PR, second PR is still being discussed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#174 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAa2eRC1-XozTEwUJat3Ks03E0KRsTCmks5rferAgaJpZM4LFsMV> .

[jasnell]

Note: The PR restoring the original copyright header has landed.

[Trott]

@jasnell Is it OK to remove the ctc-agenda and we can put it back when there's something to report? (Or do we expect there to be something to report this upcoming week?)

[jasnell]

Yep!

…

On Fri, Mar 17, 2017 at 4:28 PM Rich Trott ***@***.***> wrote: @jasnell <https://github.com/jasnell> Is it OK to remove the ctc-agenda and we can put it back when there's something to report? (Or do we expect there to be something to report this upcoming week?) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#174 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAa2eRVX_HN9MMRGTGkXk4mQNXv_FOBDks5rmxcMgaJpZM4LFsMV> .

[Trott]

That's "Yep, it's OK to remove it" or "Yep, we expect there to be something to report this upcoming week"?

[jasnell]

Yep it's OK to remove. I'll update it if there's any change

…

On Fri, Mar 17, 2017 at 4:30 PM Rich Trott ***@***.***> wrote: That's "Yep, it's OK to remove it" or "Yep, we expect there to be something to report this upcoming week"? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#174 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAa2ecVCo8dVDrxdBxqVZK7kqgORaPNJks5rmxengaJpZM4LFsMV> .

[MylesBorins]

Do we have an update of the current status of this?

[jasnell]

Nope, not yet, but I also haven't pushed on it yet. My plan is to bring this up on the next board call.

[MylesBorins]

@jasnell is there still something actionable to bring up to the board?

[jasnell]

Not at this time.