Add contributor CLA and change to Apache 2.0 license

[jacobtomlinson]

Thanks to hacktoberfest there has been a nice increase in the number of contributors to opsdroid. Despite the size of the project still being reasonably small it might be a good time to start thinking about introducing a CLA and thinking about open source licensing going forward.

License

When I started this project in August 2016 I chose the GPLv3 for the license of all opsdroid projects. This decision was reasonably arbitrary as I was unsure what the future of the project would hold and it didn't feel like a big decision at the time. Time has gone by and looking at other open source projects there seems to be a push to get away from the copyleft nature of the GPL to a license which is more permissive and therefore allow wider usage.

Therefore I am going to change the license of opsdroid to Apache 2.0 from the 1st of November 2017 for reasons including:

• Many enterprises avoid using and contributing to GPLv3 code as it can cause legal headaches.
• Linking code with GPLv3 code can sometimes be interpreted as creating a derivative work which then must be released under the GPLv3. This could potentially be interpreted to cover all skills and many users will want to keep their skills private.
• Apache 2.0 doesn't allow others to use the opsdroid name.
• Many people and organisations misunderstand the GPL, and while there are usually no issues at all it is enough to make people avoid it to be safe.

These are pragmatic and human reasons, rather than legal ones, however I feel it is necessary to provide clarity in the future.

CLA

Many projects are requiring contributors to sign a CLA before submitting code because in open source development ownership of code is rather complicated.

Any code you write belongs to you even if it is mixed in with everyone else's, and it is up to you which (if any) license you wish to release it under. Contributing to an open source project through GitHub implies that you are happy for your code to be added to the project and for it to be distributed in the same manner as all the rest. However increasingly having an implied agreement is not enough and a formal agreement is required. Having developers sign the CLA protects the project, other developers and users from complicated ownership issues.

Signing the CLA simply allows the project and your fellow contributors an unlimited license to use your code within the project. The code still belongs to you, but you can't change your mind and remove your code if you decided to in the future.

What next?

At the end of the month I'll go through and update the license files with the Apache 2.0 license and do a minor release. I will also implement the CLA signing using CLA assistant. The CLA will likely be a variation of (if not identical to) that of Home Assistant, GitHub and others.

In the mean time if you have any comments, questions on concerns then this issue thread is the place to raise them.

[jacobtomlinson]

Pinging existing contributors for visibility.

@pjbollinger, @bege13mot, @tpowellmeto, @arhix, @gabeduke, @gtseres, @TechieBoy, @hougasian, @pohzipohzi, @FabioRosado, @go8ose, @orangenbaumblatt, @Blendify

[pjbollinger]

I think that the Apache 2.0 license makes sense based on the project being very product-like. However, I would worry that the CLA would deter people from contributing to the project but I understand the concern, especially with the different modules and wouldn't want a contributor to pull their code due to a dispute.

[jacobtomlinson]

Thanks for the feedback! What about the CLA do you think would put people off? Is there anything you can think of that would make it feel less of a blocker?

…

On Fri, 20 Oct 2017 at 18:35, Patrick Bollinger ***@***.***> wrote: I think that the Apache 2.0 license makes sense based on the project being very product-like. However, I would worry that the CLA would deter people from contributing to the project but I understand the concern, especially with the different modules and wouldn't want a contributor to pull their code due to a dispute. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#286 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABiUYlV1pcEfWsuht7pUiTWUeh_K_XYVks5suNnygaJpZM4QAyrn> .

[pjbollinger]

I see it as a barrier to entry for committing to the project since you have to join this other service. I'm surprised something can't be included in the pull request itself, like an automated message or something with text similar to the CLA, but without leaving the Github ecosystem.

I don't think it will be that bad or anything, this is just the first time I heard about this kind of thing and thought it would be good to explore thoughts about it.

[jacobtomlinson]

It's a fair comment. It is done through the PR, a bot sends a message, the user clicks a link, agrees to the CLA and then is returned to the PR. Its an increasingly common thing and if you contribute to any project like Docker or Kubernetes you have to do something like this.

…

On Sat, 21 Oct 2017 at 13:47, Patrick Bollinger ***@***.***> wrote: I see it as a barrier to entry for committing to the project since you have to join this other service. I'm surprised something can't be included in the pull request itself, like an automated message or something with text similar to the CLA, but without leaving the Github ecosystem. I don't think it will be that bad or anything, this is just the first time I heard about this kind of thing and thought it would be good to explore thoughts about it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#286 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABiUYoQm2e8kYEEl9DP9iJBN4WZYBSpdks5suefLgaJpZM4QAyrn> .

[go8ose]

I don't have a lot of experience with them, and what Jacob has written confuses me in a couple of places. Hence some thoughts and questions.

The code still belongs to you, but you can't change your mind and remove your code if you decided to in the future.

I don't understand how a developer could choose to re-license their contributions and remove their code. Once they have released it under once license, isn't that fixed? I can understand that they can release future versions of that code under a different license, but I don't understand how they could withdraw code that's already published, especially if it's under a GPL license.

It's my understanding that some CLA's include terms to assign your copyright to another entity, so that the ownership of the code is clearly understood, it's owned by that entity. The example CLAs Jacob linked to do not include that. Is it fair to assume that this won't be the case in the CLA that's used?

What I read on CLA assistant made it sound like the agreement process is very simple, which might address @pjbollinger concern. We'd probably want to note in docs/contributing.md that the CLA exists, and is enforced by CLA assistant, so there are no surprises when someone does send a PR.

From what I've seen so far, I'd be happy with the change.

[jacobtomlinson]

I understand your confusion. I'm still trying to get to grips with it. My understanding is that the license only applies to the original work, e.g my code in opsdroid. Contributions are not covered by the license and so generally it is assumed the contributor is happy with it being distributed and used in the same way, but they do have the right to withdraw it. The CLA grants the project explicit rights to release it under the same license forever.

…

On Sun, 22 Oct 2017 at 03:40, Geoff ***@***.***> wrote: I don't have a lot of experience with them, and what Jacob has written confuses me in a couple of places. Hence some thoughts and questions. The code still belongs to you, but you can't change your mind and remove your code if you decided to in the future. I don't understand how a developer could choose to re-license their contributions and remove their code. Once they have released it under once license, isn't that fixed? I can understand that they can release future versions of that code under a different license, but I don't understand how they could withdraw code that's already published, especially if it's under a GPL license. It's my understanding that some CLA's include terms to assign your copyright to another entity, so that the ownership of the code is clearly understood, it's owned by that entity. The example CLAs Jacob linked to do not include that. Is it fair to assume that this won't be the case in the CLA that's used? What I read on CLA assistant <https://cla-assistant.io/> made it sound like the agreement process is very simple, which might address @pjbollinger <https://github.com/pjbollinger> concern. We'd probably want to note in docs/contributing.md that the CLA exists, and is enforced by CLA assistant, so there are no surprises when someone does send a PR. From what I've seen so far, I'd be happy with the change. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#286 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABiUYiKeybbzh9LxfXIyb8Ao_O070Ht0ks5suqszgaJpZM4QAyrn> .

[Cadair]

(IANAL)

My understanding is that the license only applies to the original work, e.g my code in opsdroid.

I do not agree with this. I would argue that opening a PR is a implicit agreement that the code be covered by and distributed under the terms of the project licence, and only the project licence. (This is what a CLA would make explicit.)

If you want to re-licence the code in the repository you would need each copyright holder of the work to agree to their work being distributed under the terms of the new licence.

[jacobtomlinson]

I appreciate you opening with IANAL, I should've probably done the same. I agree that this is one interpretation, and I agree that you could be right. However you could also be wrong. I guess that's the point of making it all explicit, so that this kind of thing doesn't come up. I'm basing this on examples such as Docker, Kubernetes and Home Assistant. I would expect that the first two have had legal advice on this, although that doesn't necessarily make them right. I feel that now is the best time to do this while the number of contributors is small so that if anyone does disagree with changing to an Apache 2.0 license and wishes to revert their PRs it will only have a minimal impact. However I'm hoping that everyone will agree that this is the best move both for the contributors and the users.

…

On Sun, 22 Oct 2017 at 18:38, Stuart Mumford ***@***.***> wrote: (IANAL) My understanding is that the license only applies to the original work, e.g my code in opsdroid. I do not agree with this. I would argue that opening a PR is a implicit agreement that the code be covered by and distributed under the terms of the project licence, and only the project licence. (This is what a CLA would make explicit.) If you want to re-licence the code in the repository you would need each copyright holder of the work to agree to their work being distributed under the terms of the new licence. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#286 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABiUYnyQh2GmJkZrqNZqpXquu_DEgwLpks5su314gaJpZM4QAyrn> .

[Cadair]

This is a reasonable description of the issues from github. https://opensource.guide/legal/#what-if-i-want-to-change-the-license-of-my-project

[jacobtomlinson]

Yes this is reasonable. And this is the guidance I am following.

…

On Sun, 22 Oct 2017 at 20:35, Stuart Mumford ***@***.***> wrote: This is a reasonable description of the issues from github. https://opensource.guide/legal/#what-if-i-want-to-change-the-license-of-my-project — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#286 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABiUYuThYMymD5vv7HmGjYuM4lDDeP6Aks5su5kSgaJpZM4QAyrn> .

[opsdroid-bot]

http://i.imgur.com/lnvJm9a.gif

[Cadair]

I think you will need to get everyone with code in the repo to sign off on the re-licence, as the apache 2 licence is not compatible with the GPL (the GPL places more restrictions than apache 2). For instance, a contributor may only want their work distributed under a licence that includes a copyleft clause.

[jacobtomlinson]

Agreed. Which is why I raised this issue and pinged the people who
contributed to the project so far to let them know of my intended changes
and to gather agreement.

[Blendify]

Generally, I am fine with a CLA, however, I do know that many people will not submit code simply because they do not want to go through the hassle of signing a CLA. Regarding using Apache 2.0 I say go for it, it is a nice license for large-scale projects such as Opsdroid.

[go8ose]

So far only 2 people of the 13 that Jacob pinged (me and @Blendify) have explicitly said they are agreeable to the change. But no one has said they disagree with the change, the discussion has been mostly about clarifying things.

I'm sometimes a bit cynical, so I suspect we won't get a majority reacting with a thumbs up. The CLA that seems to be talked about is about explicit license choice, instead of implicit license choice, as well as re-licensing for pragmatic reasons. Doing so now for those reasons seems like a reasonable course to take, to mitigate the risk of such a change being much more complicated later on.

We haven't talked about whether there is a real risk that the GPL copyleft nature would cause problems for people who want to integrate opsdroid code into a larger thing, and hence reduce the number of submissions. IANAL, so my opinion doesn't count for much. But I don't think anyone would be compiling and linking opsdroid code into a larger thing, so I'm not sure that is a real issue for this project.

Does anyone want to discuss that, or is that a bit of a tangent (and discussed at length elsewhere)?

[Blendify]

I am not one to comment on that because I have not contributed anything highly meaningful and do not know the project that well. From personal experience though, I do not find a license will not stop most users from contributing to a project.

[FabioRosado]

I've been following this issue and did a bit of reading about both licenses, I can't seem to find a massive difference between the two licenses and if changing the apache license will potentially bring more people to the project I'd say I'm happy with the change 👍

[jacobtomlinson]

TL;DR - My primary goal here is to choose appropriate licenses for the opsdroid community going forward. So let's talk about it as a community.

I'm going to start this comment by saying this thread is really awesome! The level of discussion here is way beyond what I expected.

When I raised this issue I decided to phrase is at "I am going to..." rather than "Do you think we should...", mostly because I didn't expect much feedback. However you've all blown me away with the time and thought you've put into this. I must confess up until now I've thought of this as my project. A project which has two goals; creating a chatbot framework that I enjoy using, and to build an awesome open source community. However I think this thread has demonstrated that the community is already here and that it is now our project, which is super exciting for me!

When I started the project I knew I wanted it to be open source, however I didn't put a huge amount of thought into which open source license to choose. I just selected one which sounded appropriate from the GitHub dropdown when you create a new project. What I really want to achieve here is specifically choosing a license for the project rather than just steaming ahead with an arbitrary decision I made 14 months ago.

Reading more about what the GPL means for contributors and users has worried me a little that I’ve chosen something which is too restrictive.

The main issue with the GPL is the definition of “dependancy” is loosely defined. In my mind it means a library which you import and use in your project. Therefore opsdroid could only be imported in GPL projects. As @go8ose points out this is unlikely, however you could easily argue that opsdroid skills depend on opsdroid to run and they do import things from opsdroid. Therefore the GPL on opsdroid would enforce that all skills should be released under the GPL, which would definitely put off many users.

I also really want this project to be contributed to by as many people as possible, and if the copyleft clause is going to deter enterprise contributors/users then I see that as a bad thing. The other side of that is if an enterprise employee contributes to the project then that organisation may feel they can exert control over the project from a patent point of view. My hope here is that the Apache 2.0 license will lower the barrier for entry of enterprise contributors and also protect the project from patent issues.

I also thought a CLA would be good to protect the project itself as it could explicitly state the opsdroid community has full control over the code. But I see that it could be off-putting to contributors to have to take the effort to understand what they are agreeing to and then going to a third-party website to agree. This works against my goal to lower the barrier for contributors and so I am having second thoughts.

Finally in terms of reaching a consensus of copyright holders to change the license. I agree that it may not be realistic to contact and get agreement from everyone, but as the community grows that goal will become ever more difficult. Therefore I think if we are going to change the license then now is the time to do it. Everyone who has contributed has been contacted in this thread and there has not been any disagreement with the change. I’m tempted to follow the Python mantra of “Ask forgiveness, not permission” with the remaining people and go ahead and do the change, then if anyone objects down the line their code can be removed. As the contributions so far have been reasonably small (although highly appreciated) doing this now means that any code removal would result in minor bugs being introduced and some features may disappear, but the core would remain intact. We may have to endure for a while with a slightly broken project but these can be fixed/added again by someone else who accepts the license.

[pjbollinger]

@jacobtomlinson Thanks for sharing your thoughts, I can imagine it would be hard to transition thinking from your project to a community project.

I want to say that I agree with the proposed changes. Earlier I was just trying to get a better understanding and see if the CLA should be required.

An additional thought: I just submitted a PR on a Github project that required the CLA. It wasn't too difficult to complete but I feel it could be overlooked by contributors unless you draw attention to it. Doing something like @go8ose said, including it in CONTRIBUTING.md, would mitigate the chances of contributors not being aware of it.

[jacobtomlinson]

@pjbollinger It is hard but don't get me wrong, it's really exciting and exactly what I had hoped for.

Yes I agree with that! I'm aware that there is a small contributing section in the README.md and also a contributing page in the docs, but no actual CONTRIBUTING.md file in the root of the project. A nice change would be to merge these two pages into a CONTRIBUTING.md page and symlink to it from the docs in the same way the README.md is.

Also having the cla-assistant bot commenting in every PR should help.

[Cadair]

I am ok with the move from GPL to A2, although a move to L-GPL would solve the "import problem". Having the core being A2 means that as long as the plugin system remains as (or more) flexible as it is at the moment, code which wants to import GPL code can live in a plugin.

As for the CLA, I am not sure I really see the need, but I also don't see any issue with it.

[tpowellmeto]

I am OK with the move Jacob. Good Luck with the project and well done to everyone who has contributed so far. Go team Opsdroid 🤖

[jacobtomlinson]

After the discussion above and also getting some advice from other open source maintainers I have decided to go ahead with the switch of open source licenses from GPLv3 to Apache 2.0 as it has been agreed this would be a good move for the project, the community and the users.

However it is best for me to get explicit approval from all contributors. Therefore if I haven't had agreement from you by the switch over date I'm afraid I will have to remove your contributions from the project. This is the last thing I want to do, particularly if it is just a case of not being able to contact you.

So, if your name is on the "Not yet approved" list then please comment on this issue with your approval or click the 👍 voting button at the top.

Approved:

• @jacobtomlinson
• @FabioRosado
• @go8ose
• @tpowellmeto
• @Cadair
• @pjbollinger
• @Blendify
• @arhix
• @freedomofkeima
• @gtseres
• @pohzipohzi
• @suprithIUB
• @gabeduke
• @accessdenied12

Unresponsive:

• @TechieBoy
• @bege13mot

Not applicable (contributed to unlicensed repos):

• @hougasian
• @orangenbaumblatt

Edit: Updating lists as people approve.

[jacobtomlinson]

We are now at the end of October and I've gone ahead and changed the license throughout the rest of the projects, where applicable.

Everyone who has submitted code to an opsdroid project has approved the change of license, which is fantastic. Thank you to everyone for taking the time to understand what we are trying to achieve with this change and giving your approval.

The commits from the two unresponsive contributors only affect the documentation. I'm going to leave these changes in place but am happy to revert them at the users request if they wish. This will not affect any releases which are published in the mean time as documentation is not included in a release.