Closed nebrius closed 8 years ago
There's currently no license associated with this project, so I'm not sure how a DCO would apply.
All projects under the Foundation automatically inherit an MIT license unless the WG specifically chooses a different one.
The DCO specifically mentions "the license in the file" so we'll want a SPDX references to the license of each file. Something like this http://esr.ibiblio.org/?p=6867
Can you expand on how we would use SPDX references? I haven't used them before, and from my brief reading it looks like a file format, right?
Alternatively, would it be sufficient to do something like this?
## License
This repository is governed by the [Node.js project-wide license](https://github.com/nodejs/node/blob/master/LICENSE).
SPDX is what npm uses for licenses. it's just one of these: http://spdx.org/licenses/. we can just mention that we inherit MIT from the node repo. MIT being a valid SPDX that we can easily copy and paste into a LICENSE
file. then we simply add a header like this:
// Copyright 2016 by the Node.JS Inclusivity WG
// SPDX-License-Identifier: CC-BY-4.0
We should probably pick a version of Creative Commons as this is not code and MIT doesn't really make sense.
Oh yeah, I like the Creative Commons idea. Are there any concerns or roadblocks from the TSC or foundation with using CC?
This repository is governed by the Node.js project-wide license
This isn't gonna work. The DCO makes specific mention of "the license in the file" which means that we need a license reference in every file :(
Would change:
// Copyright 2016 by the Node.JS Inclusivity WG
To
// Copyright 2016 by the Node.js Inclusivity Contributors
We aren't doing a copyright re-assignment so the contributions are owned by the people who contribute them.
good call @mikeal i was being sloppy ;)
This is just me saying my own opinion, but I haven't seen a very compelling argument for using CC licenses in non-code work that is part of a technology project. If anything it creates a possible issue, or at least strange concerns, around distributing the work with the project. I think for artistic works it makes a huge amount of sense but I don't know what the argument is for it over the project license for docs and non-code materials distributed with the project.
SPDX
This is an effort, sponsored by the Linux Foundation, to normalize the identifiers for public licenses so that they might be more easily audit-able.
Let me know if this matches the SPDX license format for MIT properly! I added it to README and CONTRIBUTING.
I left it out of the meeting notes files, should I add the license there too?
can you squash the license additions into a single commit? after that i'll happily merge
heh, i just meant the last two, but this is fine. merging.
lol, that's what I get for rebasing before my morning tea
Copyright years are an interesting thing, but I think you want 2015 in the old meeting notes.
Copyright years are an interesting thing, but I think you want 2015 in the old meeting notes.
Good call. Off the top of your head, do you know if Node typically does Copyright <start year> to <present year>
for files that are worked on over multiple years, or do we typically just list the start year?
I'm not sure what the lawyers prefer, but the main license for node does the saner thing and just omits the year: https://github.com/nodejs/node/blob/53cc9785abcdd23aa578495ee6b97c3a0a83414c/LICENSE#L4
I created a new PR that removes years to match the main repo: https://github.com/nodejs/inclusivity/pull/75. Thanks again @scottgonzalez!
Required for all CONTRIBUTING.md files