What's more complicated? Writing code, or understanding what someone else has written?
Contributions License Agreement
What is a Contributor License Agreement? And how does it apply to you?
After writing a lot of code in my career, I've found one thing to be universally true: understanding someone else's code is a lot harder than reading my own.
One of the goals of Open Source software is to encourage others to use it. One of the signs that it has "caught on" is when someone else starts to offer bug fixes or updates to your project.
Then comes the hard part. And no, it's not hitting the "merge" button in GitHub. And no, it's not reading that code, and knowing if it will work. As programmers, we often miss implications of accepting third-party code in to our own projects (other than the obvious part, called "will it work").
So, let's take a look at the non-code implications.
Implications of accepting third-party code
In my previous blog post, I mentioned many different legal aspects that go with Free and Open Source (FOSS) software. The important takeaway is that all of the legal rights to FOSS start with the Copyright. Everything about who owns the code, and who gets to make the rules, starts with the person who wrote it.
The astute readers will immediately see the implication: if you didn't write it, you don't have the copyright.
I suspect this point is missed by many authors. They assume that any code "contributed" to them would become the property of the person/group who whom the code was given. That make some sense, because the person who contributed the code obviously knows about the license and can see that the project is Open Source.
But, looking a little closer, and inconsistencies start to appear. First, GitHub (like most tracking systems) is very good at showing who wrote which piece of code. Which means that the author of a piece is easy to track. Especially if that author decides to claim copyright later.
That's the first problem. But if that person works for a company, it can be more complex.
Employee or Person?
In many instances, the person who is contributing the code also is an employee of a company (organization, something.) And that can make the code ownership even more complex.
For example, anything written by an SAP employee is (as local laws permit) the property of SAP. Especially if that person is working on SAP time, and working on SAP equipment. So, if an SAP employee writes a piece of code, they can't just give it away - because it doesn't belong to them in the first place.
Each company, of course, may have policies that apply to the employees. And those policies don't always match each other.
Even worse? If an employee accidentally contributes something
important. Like a trade secret, or something that makes the company work better. In that case, the company might want to fight and take it back.
It's a big legal mess, right?
Understanding the CLA
How do you, as a FOSS project owner, work out these legal issues? The best way is through a Contributor License Agreement (or CLA).
The CLA is simple. Just like your license, it's an agreement between the person contributing the code and the group hosting the code. The agreement says, basically, that the person contributing is giving up all legal (and "moral", but in the law sense) ownership of the code they are contributing. In other words, they may have a copyright, but agree to let you use it forever and ever, without limit. When they say "forever and ever", they mean "we won't change our mind later". It's perpetual.
The CLA also states that any code contributed, to the best knowledge of the contributor, is free of any other ownership restrictions. That covers the "company or person" question we raised earlier. Another company might own it, but you as the receiver wouldn't be liable, because the contributor told you it was OK.
And finally, the CLA can cover how the code is going to be used. If you want to offer some protections to the contributor, this can be here too.
Here is the SAP standard CLA, if you want to take a look.
Automate the process: CLA-Assistant
This brings me to one of our great projects from SAP:
CLA-Assistant.
This tool, free for use by anyone (not just for SAP) is how we automate our CLA system for FOSS projects. It both establishes the license, and then becomes a part of the PULL request cycle for any new contributor. Before the contribution can be put in, the CLA assistant makes sure that the user has agreed to it's terms.
TL;DR?
A fully-automatic way of taking care of CLA's.
The
CLA-Assistant website has a full explanation of the process, and even a video that shows what happens when a person contributes code to your project. And, it's FOSS. And completely free to use.
Add this to your arsenal
OK, so Contributor License Agreements are worthwhile. From a legal sense, it's an important gap to understand - because it could prevent trouble with another person (or worse, big company) sometime in the future. Covering all the legal details is just thinking ahead.
It's also easy to fix. Pick a good CLA from the many offered by different organizations, and then apply it to our free tool. Voila. Problem solved.
There are more tools for this arsenal of "covering all the legal details" and we will get to another next week.
Thanks for visiting Open Source Monday. More soon!
