Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File copyright policy #216

Closed
rvagg opened this issue Dec 30, 2014 · 11 comments
Closed

File copyright policy #216

rvagg opened this issue Dec 30, 2014 · 11 comments
Milestone

Comments

@rvagg
Copy link
Member

rvagg commented Dec 30, 2014

I've seen @bnoordhuis suggest contributors either assign the copyright to "io.js contributors", or their company and he's also putting his own name in new files too, like in #215. I'd like this clarified by TC and would personally prefer all new contributions have their copyright assigned to "io.js contributors" as contributors get to share ownership of io.js and assigning copyright elsewhere defeats this somewhat.

I don't believe there has been a discussion on this yet has there?

@vkurchatkin
Copy link
Contributor

+1, really confusing

@bnoordhuis
Copy link
Member

I've seen @bnoordhuis suggest contributors either assign the copyright to "io.js contributors", or their company

Or their own name. :-)

I initially suggested "io.js contributors" but it has since been pointed out to me by an expert on Dutch and German copyright law that in many civil law countries, copyright inalienably belongs to the original author unless it's a work for hire, in which case the copyright belongs to the entity that commissioned it (like your client or your employer.)

The license is a legal document where the copyright holder grants rights to users beyond the rights granted by copyright law. It's important that the right name appears at the top because "io.js contributors" is not the holder of the copyright and is not even a legal entity as such. My lawyer friend joked you might as well put in "(c) 2014 Santa Claus".

(Aside: the above is why in some countries, it's not possible as a citizen to put something in the public domain; you retain the copyright, whether you want it or not.)

Wrapping up, I don't think this is something for the TC to decide on. We should consult legal counsel, the more so because the rules are no doubt different in common law countries.

@rvagg
Copy link
Member Author

rvagg commented Jan 2, 2015

as per TC meeting 2014-12-30 #229 this is on me to get legal advice on and come back to TC with a suggestion. I'm leaving the tc-agenda label on this in anticipation of having something for the next meeting.

@mikeal
Copy link
Contributor

mikeal commented Jan 3, 2015

A few things.

  1. Per file copyright notices are not strictly necessary and are, in my opinion, a maintenance nightmare.
  2. Under the old CLA contributors retained their ownership and granted Joyent a license which essentially had all the rights of an owner. AFAIK, Joyent hasn't asserted that it owns the work-for-hire assets (the code written by people employed by Joyent) so we should be able to remove these notices. There are certain assets I'm sure they own outright, like the copyright on the all the node logo artwork, but those aren't in the repo so we're probably fine.

I've had a few questions in private messages about the need for a third party, like a foundation, to retain a license the way Joyent used to under the CLA. The only reason we would want this is if we thought that we needed to enforce the terms of the license because in order to file suit you need to "represent" at least 51% of the property. This is important for GPL projects but I don't see why it would be a concern for an MIT project since the license allows you to do pretty much anything you want.

If for some reason we do decide that we need to enforce the license, or will want to some day, there are better ways to do it than an "up front" CLA like we used to have. For one thing, the foundation could get key contributors to sign CLAs and contributing companies to do the same and easily cover 51%+ of the code base without forcing people sending doc edits to sign a CLA. The other protections offered by a CLA are covered by the DCO which is already in our CONTRIBUTING doc and signed implicitly, the same way you implicitly agree to license your work under the MIT license by contributing to a project with a public copyright notice.

I'm +1 on removing license and copyright blocks from the tops of files, this is a super old and paranoid practice that is always inaccurate, the only way to find the actual owner of the copyright in a file is to go through the git history and we shouldn't have misleading text that claims otherwise.

@ghostbar
Copy link
Contributor

ghostbar commented Jan 4, 2015

Actually in a body of work you can put the license anywhere you want because you are shipping it as a whole, not in pieces.

The copyright must be assigned to actual people, not a non-legally-binding entity. I remember on the debian pkg-perl team we had this issue. We were saying "© Debian pkg-perl" and the lawyers came and said "You actually need to put an actual existing person there, be it a company or an individual, it doesn't care if it's an alias of that person but it needs to refer to someone actually".

Even just printing a file with the output of git summary (from git-extras) should be enough if they all agreed to the MIT license.

EDIT: With the last paragraph I meant something like: «© of the projects contributors, listed on CONTRIBUTORS.md», and there the list of all contributors which actually hold copyright because even just a comma.

@mikeal
Copy link
Contributor

mikeal commented Jan 4, 2015

You implicitly agree to license your work under the LICENSE when you contribute it to a project with a public copyright notice. The principal is called "inbound=outbound" and has been written about most extensively by Richard Fontana.

@ghostbar
Copy link
Contributor

ghostbar commented Jan 4, 2015

I understand that. I think maybe that phrasing sounded better for my head since it came from spanish :). "if they all agreed" maybe should have been phrased "since anyway they all agreed".

@rvagg
Copy link
Member Author

rvagg commented Jan 11, 2015

Both OSX and Windows installers show the LICENSE file prominently, which begins like so:

Node's license follows:
====
Copyright Joyent, Inc. and other Node contributors. All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

Can someone propose a way forward with this please? Up-front it says "node" and "joyent", I'm not sure either we nor they want our releases to be so tightly associated with them and joyent/node. Can we insert our own block of some kind at the top? Do we need to get more legal advice for this?

@bnoordhuis
Copy link
Member

IANAL but I don't see a reason why we can't put our own license first. There is still proper attribution for the bits that are (c) Joyent, they're just a little further down now.

@rvagg
Copy link
Member Author

rvagg commented Jan 12, 2015

I've left this on tc-agenda because we don't seem to have reached an actionable point with this yet. I'd particularly like sign-off on the proposal to change LICENSE file is in #294, or some alternative because this shows up in the OSX and Windows installers.

Also @isaacs has a pending task of removing all the license & copyright blocks from the top of each file.

@rvagg rvagg added this to the v1.0.0 milestone Jan 12, 2015
@rvagg rvagg mentioned this issue Jan 12, 2015
14 tasks
@isaacs
Copy link
Contributor

isaacs commented Jan 12, 2015

Patch to remove excessive boilerplate: #311

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants