-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Attribution or original author clause as part of contributor agreement #1275
Comments
👎 to a CLA, 👍 to more explicitly forbidding copy-paste without proper attribution. |
+1 to this. It is fine to share code, but copyright and license annotations should be preserved. I don't know the exact solution here because I am not familiar with what fraction of the code is copy/paste or trivial modifications of existing code. One solution Brian mentioned was: https://twitter.com/puffnfresh/status/762811494719291393 but I don't think that's such a great solution as:
It seems Brian wants to be added or acknowledged in some way, so the first thing we could do is try to make a quick pass for the obvious candidates of places where the ball was dropped in the past. |
For some, "contributors" may imply endorsement and / or intentional activity, so "Attribution" or some other section distinct from contributors and prefaced appropriately may be a more broadly appreciated way of providing attribution. |
So, this file is here (as pointed out in gitter): which contains the scalaz notice. That may not be enough. I still think if you contribute something you should state where it came from if not original work (whatever that means in this area that is so highly derivative of other work generally). |
Indeed, the wording makes it seem like this was a one time thing that stopped in 2014 (based on the copyright). Not that it is being "continuously derived" from Scalaz, including recent 2016 code, and including many contributors not mentioned in the copyright notice, such as Brian McKenna.
👍 In many projects, I often see these notices in the code itself, e.g. Having had my open source work copied and not attributed before, I can attest it's not a particularly good feeling... in my case it was rectified soon after it happened, and there are no hard feelings. Not everyone is so lucky. |
@jdegoes note that when you say "the wording makes it seem like this was a one time thing that stopped in 2014", that we MUST not change this wording. It is exactly what is required by the scalaz redistribution license, see here: https://github.com/scalaz/scalaz/blob/series/7.3.x/etc/LICENCE#L7-L8 If this copyright notice is to change, it should only change after scalaz changes their license. We cannot add Brian to this copyright notice without scalaz doing that first. This is, of course, not to say that we cannot make some additional attribution to people that have contributed. |
A CLA is a good thing but only if it agrees word for word with the License that is offered to the public. Don't do what Lightbend do and accept Apache code, but release under the weaker modified BSD. This isn't a CoC concern. It's a legal and licencing concern. Let's not mix it up. Attribution is a legal requirement if the original code has a copyright notice and a modified bsd style license (as do many other libre licenses). However, attribution is not a legal issue if the original code does not require it or if the original code or license does not include the full list of copyright owner. Cats includes some scalaz code, and its license reflects this. I'd like to point out that when you use bsd style license you should be aware of what rights you give up. I encouragee everybody to prefer Apache 2.0 over mit/bsd and better yet a copyleft license http://fommil.github.io/scalasphere16 |
There is legal framework, for which you might give a shit but I don't. Then there is moral and netiquette. For the later I think you should clearly attribute copy/pasted works, I think it's a shame it was not done properly before. |
The scalaz license is here https://github.com/scalaz/scalaz/tree/series/7.3.x/etc but there is no license for 8.x and until there is, I recommend not deriving any works from it. They could change to a license that is not compatible with cats. You cannot assume that the previous license applies. As to this ticket, I vote to close. Cats is obliging the terms of the scalaz license and this ticket has been raised by proxy. If there was concern from a copyright owner that their license is not being respected, only they can bring it up. In this case, the copyright owner has said they don't want to update the scalaz license, which means they forfeit their right to attribution in derivative works. |
Exactly. IMO a copyright license is not the rug to sweep all attributions under.
Note that a CLA provides other features important for some businesses, such as offering legal protection against submitting non-original work for which the submitter does not have sufficient rights; protection against use of patented materials or trademarks, etc. Some companies will not allow use of open source projects without a CLA. At minimum, a CLA should allow the organization or project to issue the contribution under the project's same license (as you say above). One can argue this is implied by the Github model of development, but that has never been tested in any court, and I've seen some projects act as if this were not true.
The COC dictates terms by which you are allowed to participate in the community. Not giving a fellow developer explicit credit for her work is something that could conceivably fit into a COC (of course, it doesn't have to, and the consensus here seems to be that people don't want it to).
This is not a legal issue, this is an issue of helping authors feel appreciated for their works by giving clear attribution. It's a professional tip of the hat in recognition of the hard work that others have done which makes projects like Cats possible.
This seems useful advice. I think such guidelines (as well as any attribution requirements, of which there are none right now) may fit well in the contributor's guide, since I fear your above comment will be lost on this ticket and few who make future contributions will see it.
I empathize with how Brian feels since I've been in a similar situation myself. I didn't mean to imply that Cats was breaking the law, I just wanted to propose a low cost way of tipping the hat to fellow developers. I'm not sure I understand why there is resistance against this idea, but in any case, I said what I wanted to and everyone heard me out, so thanks for your time. |
This is inspired by typelevel#1275. It doesn't include a CLA, and there is most likely more work that should be done with respect to attribution, but I'm hoping that this is a step in the right direction. I've added a link to the scalaz contributors page within AUTHORS.md. I'm not sure who all out of that should and would want to be directly listed in the authors page for Cats. I've explicitly added Brian McKenna to the authors page, as my understanding of [this tweet](https://twitter.com/puffnfresh/status/762901748772057088) is that he would like to be on there.
a CLA can't possibly protect against this, unless it requires the submitter to take the liability, which would be unlimited. All a CLA can realistically do is remind the contributor that they should only be submitting original content or flagging up derivatives work.
Agreed. I consider such minimal CLAs to be good CLAs. Although I may add a gentle reminder about non-original works to all my CLAs.
Well it is and it isn't. Licenses formalise this sort of thing. If somebody wants to use a different mechanism to get attribution then really it just means they used the wrong license or don't understand why licenses exist. The same goes for any cats AUTHOR... if you want attribution, be sure to update the LICENSE (or COPYING) file. There is absolutely no obligation on distributors of cats to include the AUTHORS file with source or binary distributions. In ENSIME, we explicitly link to the git log from the LICENSE but we'd like to automate adding this information into the source files, see sbt/sbt-header#35 |
Legalities aside, I think it is important as a matter of good form that original authors are credited where credit is due. To that end I think #1276 is a fair start. I hope moving forward Cats continues to credit original authors, be it from papers, Haskell, OCaml, Scala, any other language, and folks who've translated it from another language. In the interest of moving forward, I hope some folks (perhaps @aloiscochard ?) can do us the favor of looking at #1276 and adding comments and/or suggestions to help resolve this. |
Something which hasn't been mentioned here… (disclaimer: I'm not a lawyer, just a legal hobbyist who's been around the OSS community for while) US copyright law dictates that, in the event of a legal challenge on a copywritten work, at least 51% of all rightsholders must be notified and named. This figure is not based on "lines of code" or anything intuitively obvious like that, but actually based on the complete unweighted list of rightsholders. There are serious penalties if this constraint cannot be followed in the event of a challenge. For projects with a lot of contributers (where "lot" is defined as "more than 2"), this is a huge, massive problem. Like, insanely massive. Tracking everyone down and getting confirmation that they have been notified within the time window (which is not long) is hard enough, but then getting them to participate in the legal action (which they are compelled to do) is even harder. Mozilla ran into this several years ago, and it literally took them almost 2 years to get it all sorted out. They're obviously an outlier case, but still. Commercial companies and consultants (engaged in "work for hire", which has a rigid legal definition under copyright law) get around this problem entirely by attributing rights to the commercial entity who is also responsible for paying the creators. This is why the "works for hire" clause exists in the first place. I work for Verizon. Verizon doesn't need me to sign a CLA to ensure that legal challenges on their code can be handled by them and them alone, since they're literally giving me money for the code that I produce for them. Under this framework, I'm no longer a rightsholder (despite the fact that I created the work originally), and so I don't need to be involved in legal action. If money isn't changing hands though, which is to say in nearly all open source work, this clause does not apply. Even if there is a single legal entity which governs a project, if that entity is not paying contributors, then it doesn't qualify as "works for hire" and the contributors are still the rightsholders. Another way of thinking about this is the following intuition: under US law, copyright can be sold, but it cannot be donated. CLAs solve this problem. The most important clause in a CLA is the grant of license (clause 2 in the Apache CLA). Without this clause, a CLA is meaningless and we're back in the "everyone needs to be individually involved in every legal action". This is why Mozilla's solution to their massive legal contribution knot was to get everyone to sign a retroactive license grant, and then move to a CLA format for all future contributions. CLAs also legally indemnify the organization from contributions of invalid provenance. If you have a contributor has signed a CLA who copies someone else's code and claims it as their own work, the CLA is a legal failsafe in the event that said code is challenged by the original rightsholder. The entity in charge of the project is no longer liable, because the contributor was the one who perjured themselves and violated the agreement, while the entity acted in good faith. This is also vitally important for any non-trivial codebase. Note that CLAs don't have to be a massive pain, though this is where we enter slightly more legally uncharted waters. Gateway was involved in a US Supreme Court case back in the 90s which established the doctrine of a "shrink wrap agreement". This acts as the legal precedent for projects who literally just drop their CLA into a Here's the bottom line: if you share source code, you need to care about CLAs. Full stop. You can't just ignore this issue. Either you, or Typelevel, or some company using typelevel's work is going to get in trouble eventually, and the legal fallout will be staggering without this kind of framework in place. CLAs may suck, but they exist for a reason, and that reason is far broader than just "don't copy someone else's code". Cats uses the MIT license, which does not have a pre-baked CLA anywhere (that I'm aware of). Also, the MIT license has somewhat legally dubious protections in the event of patent claims and the like, but that's a larger discussion. If typelevel means to stick with the MIT license, then they need to get a CLA written up which applies to it. Another option would be to pivot to the Apache 2 license, which has a ready-made CLA, significant legal analysis, and appropriate patent protections. Again, this is a longer discussion that seems out of scope here. But at the end of the day, you cannot just ignore the CLA issue. Not if you want to share and collaborate on source code in the US and/or with US developers. (not ruling out similar EU or other problems; I'm just only familiar with US IP law) |
Well, maybe you cannot, but 99% of the open source projects I've ever contributed to do, and many of them have organizations with big legal departments as adopters, sponsors, and contributors. I'm also not a lawyer, and to be honest I don't care about this legal stuff half as much as I probably should, but potential contributors will bounce off a CLA that requires more participation than being directed to read a CONTRIBUTING file. |
You don't have to take my word for it. Look up anything related to the contributor process at Eclipse, Apache, Mozilla, or the other big organizations. Look up why it is the way it is. If I recall, Ian at the Eclipse Foundation actually has an essay about this somewhere. Ignore it the issue if you like. But I want you (well, really typelevel) to be absolutely clear on exactly the risk you're accepting by doing so. It's your decision, not mine.
So put the legal catch in the contributing file. If you read my reply, you'll notice that I mention that alternative and also how it is that it can be legally justified (also the potential perils of it). There's a reason CLAs exist. A very good reason. Ignoring that reason isn't "lean" or "low friction", it's simply risky. If you think the risk is low enough to justify ignoring it, then fine, as I said that's your decision. But the risk is objective reality, and there's no point in denying it. |
@djspiewak a lot of what you say makes sense in the context of US IP law. However things are very different elsewhere ... for instance, in Germany copyright assignment is impossible, even for work done for hire. All Typelevel projects are international, Cats included, and it's important not to get bogged down in parochial concerns. I'd happily defer to @fommil, but my understanding is that Apache 2.0, without an additional CLA, is pretty close to optimal for free software (but not copyleft) projects across multiple jurisdictions. |
@milessabin I agree fully. In as it is important to ensure that typelevel projects are keeping their ducks in a row with respect to US IP law, other countries are just as important. I certainly didn't mean to marginalize IP law elsewhere, I simply have no knowledge whatsoever on the subject outside of the US. Apache 2.0 is a very safe bet. I don't know anything more definitive about it than "yep, it's a safe bet", but there you go. I will say that an additional CLA is unnecessary with Apache 2.0, since you get the CLA for free as part of the license. Mentioning the CLA somewhere in the CONTRIBUTING document and adding license headers is probably sufficient, and doesn't impose any added friction on contributors. |
If I'm being deferred to :-P I'll say that Apache 2.0 with a CLA that basically is the Apache 2.0 is about as good as you can get if you want to go the permissive licensing route. ENSIME uses https://cla-assistant.io/ highly recommended. A typical ENSIME CLA looks like https://gist.github.com/fommil/211088434c6187218ffa |
Here's a random example of a "shrink wrap CLA": https://github.com/RichRelevance/scalaz-netty#license (also with apache 2.0). |
@djspiewak there are also PR templates in github now. A cheap alternative to a CLA checker would be a template that just says "I agree to contribute this code under the terms of X" |
Whoa! I think you might have missed some steps in the legal argument there. (Since you're making legal arguments). One question that has not been asked: If @puffnfresh is not represented in the scalaz license, do you have the rights to use his scalaz contributions at all? IANAL, so I have no idea. |
@mbrcknl no steps missed. That's the way it works. I really wish developers would care about these things and understand the licenses that they use. As copyright owner you are entitled to be recognised as the author, which could be verbal, or a letter, or even non-action to a declaration by the author but there is no obligation for distributions or derivative works (source or binary) to list your name anywhere. This is exactly why the BSD licences are used, to require it. If the copyright owner really wanted to push the limits of their legal power they could claim that they never agreed to the original license in the first place, in which case I refer you to Daniel's post regarding shrink wrapping (and also scalaz and their distributors/users would be in trouble). Like he says, there is a reason why the big organisations insist on copyright assignment or exclusive licensing agreements. I understand that you have an IP lawyer, why not ask her? Ask if you need to include the names of every committer to every oyen source project that you use when you produce your binaries. Good organisations will keep a database of all licenses that are used, smaller companies would be proactive in producing the list if required. This is also true for cats. If you are a cats contributor and you want public recognition for your contributions, you must add your name to the license. Derivative works and distributors are under no obligation to retain the AUTHORS file, line comments or the git history. This is important for many people, the license is there exactly for this reason. |
My question concerns whether @puffnfresh applied the license to his scalaz contributions. No-one other than @puffnfresh can do that, not scalaz, not you. At a glance, I see no explicit shrink-wrap CLA in the scalaz code, so I'm not sure how that's relevant. I'm glad you're confident that it is implied. Given this issue and the surrounding conversation, I probably would not be. I'm happy to forward you my IP lawyer's details, if you'd like her input. Last I checked, her rates were around AUD 500 per hour. |
@mbrcknl it sounds like an issue you need to take up with scalaz, Brian and your lawyer if it concerns you. Everybody here seems to be happy with the implied license from the github workflow. I'd certainly rather than both scalaz and cats used a CLA to make this explicit. Contributions to scalaz 8 are in a gray area as it doesn't have a license so we must assume it is proprietary. If cats is using any scalaz 8 code, we must remove it @ceedubs @adelbertc @stew I strongly encourage you to investigate and warn people of this with a I don't recall asking for your lawyer's details, perhaps you misunderstand: contacting her would be for your own peace of mind. |
I'd like to agree with the moral comment and point out unattributed code is plagiarism. |
Hi, I'd like to update my comment. I think my understanding of plagiarism is outdated, I was working on the defn of "the practice of taking someone else's work or ideas and passing them off as one's own." I should have said "I would like to see author attribution", I wasn't meaning to imply there was plagiarism. Also this and the original comment was on the general movement of code and not this specific commit. |
@jonoabroad it's definitely a good and moral thing to attribute code, even if the license doesn't demand it and especially if the author asks to be attributed. I recommend to anybody who feels strongly about attribution to add your name to the LICENSE, rather than relying on friendly parties doing The Right Thing. For anybody who feels really strongly about attribution, there are some libre licenses that are specifically for highlighting attribution, e.g. https://en.wikipedia.org/wiki/Common_Public_Attribution_License |
@fommil just so you know, some people can feel strongly about something without wanting to enforce it on others. For example maybe they tolerate it, even though it's not what they see as optimal. Thanks for sharing your advice anyway. |
See here for context.
Quick thoughts:
The text was updated successfully, but these errors were encountered: