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

Contributor License Agreement #125

Closed
hymerman opened this issue Dec 9, 2015 · 4 comments
Closed

Contributor License Agreement #125

hymerman opened this issue Dec 9, 2015 · 4 comments

Comments

@hymerman
Copy link
Member

hymerman commented Dec 9, 2015

This is just a discussion that may lead to adding a CLA to the project. I'm splitting it out from #123 to make it easier to keep track of.

Here's what has been said so far:

@hymerman

I think we also need a Contributor License Agreement - having been on the other side of the fence I know the legal protection is more than superficial! Either CLAHub (https://www.clahub.com/) or CLA assistant (https://cla-assistant.io/) look like good options to get this done easily.

Next I'd love to get Continuous Integration set up - I've actually already got a pull request open for this :) (#89). I see you've got a really nice AppVeyor setup in your fork, @rwindegger - let's get that merged in if it's easy to separate from the other things merged into your fork, and we'll use my Travis setup. I updated to premake5, and I see you've updated the way lots of dependencies work with submodules, which is also cool.

One more thing, I've just bought recastnavigation.com just in case we want to do something with it - perhaps to host documentation, or just for project-specific email. So nobody freak out if you notice it's not available :)

@dougbinks

I had a discussion with @memononen about the CLAs @hymerman recommended: https://twitter.com/dougbinks/status/674544666264539136, and he asked me to post my points here.

Basically most CLAs are complex enough to require a lawyer to understand the implications, in particular whether there is any potential liability exposure for the contributor. These issues tend to be more complex than they appear. For example guaranteeing that something is your original creation means you could be exposed to liability if someone later claims your code is a copy of theirs; litigation defence in some regions is extremely expensive.

In my view Apache 2.0 covers the main issue many companies have - a guarantee that a contributor won't sue for patent infringement for use of their contribution. This seems reasonable and fair, and doesn't expose the contributor to needing to guarantee that they own the patent rights nor infringe others. Going Apache 2.0 would need all prior contributors to agree, or a dual license. But then adding a CLA won't protect the current code either without getting all prior contributors to sign.

Note that I'm not a lawyer, but that's the real problem here - putting a legal barrier in place really requires people to have or be one.

@hymerman
Copy link
Member Author

hymerman commented Dec 9, 2015

Hi @dougbinks, thanks for getting involved :)

The reason I suggested adding a CLA is that I know companies that avoid using open-source libraries like this because they fear getting sued by contributors, or even other companies that legally own contributors' work. Say for example someone contributed a feature to Recast whilst under the employ of company A - company B could then get sued by company A if they make use of Recast.

I'm a developer, not a lawyer, so I would prefer a world where this wasn't an issue. But this is the world we live in so I'm suggesting it to hopefully make it easier for more people to use Recast safely :)

That said... you're right, this would put a burden on contributors, and clearly would put off at least some of them, yourself included. Maybe it's better to leave things the way they are, and leave the legal burden with users? Without contributors, the project is nothing, after all. Any more opinions on this?


Two other minor things to mention:

@hymerman
Copy link
Member Author

@JanielS, @grahamboree What are your thoughts on this? There has only been one opinion expressed besides my own so far, if either of you are doubtful or against it then we should just drop it now and close this issue.

@jakobbotsch
Copy link
Member

If companies do not want to use R&D out of fear of getting sued by contributors that's a big problem. However, I think it is also a problem to impose a CLA when we have so few contributors to begin with. So I would say we should leave it as it is now without a CLA, and not impose additional barriers on new contributors.

If we really are excluding companies this way we can always reevaluate. If someone is considering R&D but have problems with this I hope they will reach out! With that said I'm also not sure how CLA's work retroactively if we do change our minds later.

@hymerman
Copy link
Member Author

We'd need to chase down all previous contributors and either get them to sign a CLA, or remove their contributions somehow, whether we implement this now or later. So, it'll always be a PITA for us!

Your answer is good enough for me; I'll close this and leave it alone for now. If it becomes an issue in future we can revisit.

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

No branches or pull requests

3 participants