As I talked about in the first post in this series, using Open Source software in development is great – and gives you access to the source code, of course. That means that you can fix bugs you find and add features you need, without having to ask anyone for permission to do so.
Sharing improvements back to the original project is really important; the contributions from the community of users for a particular piece of software are part of what makes open source software so powerful and reliable in comparison to closed-source counterparts.
If you contribute your changes back to the project, it also makes it easier for you to upgrade to later versions – all you need to do is grab the latest one, and know it already has your changes in it.
At King, we reached the point where many developers really wanted to contribute changes back to the projects they use. We hope that the path we took to do that can help you to achieve the same thing in your company. Get your company to agree, and make it simple.
Whatever you produce at work is probably owned by your employer (check your employment contract if you’re not sure), and pushing your changes to an open source project makes that work accessible to anyone in the world to use. Before you do that, it’s important that your employer also agrees this is a good idea.
At King, we came up with a process of getting agreement that is simple enough that people actually use it. It’s easy to go overboard here, but an overly elaborate process will most likely just stifle your developers’ enthusiasm for contributing.
If your company has software patents, and you contribute code that is covered by one of your patents to an open source project, your contribution will probably give anyone a licence to use that patent.
That’s generally a good thing, but make sure your employer is in agreement!
Also, you can normally only patent software that has not yet been released, so whatever you contribute should not be something you might want to patent later.
You have to own it to share it
If you don’t have the rights to your contribution, you can’t contribute it, so keep in mind that most code also depends on other code in the form of libraries or frameworks, or may include snippets from some other project.
Separating code you have written from third-party code makes it easier to remember this distinction – putting all third-party code and libraries in a separate directory tree is a necessary starting point.
Contributor Licence Agreements
Some projects require that developers sign a Contributor Licence Agreement or CLA before contributing any code, and this actually makes a lot of sense as it makes it clear under which terms your contribution is being made.
There is lots of good info about CLAs at http://oss-watch.ac.uk/resources/cla.
What about copyright?
The copyright of your contribution normally stays with the original copyright holder, so any contributions a King employee makes will remain © Copyright King – contributing it to an open source project simply allows others to use your code under that project’s licence.
The details of this are governed by the CLA for the project, if there is one, so read it carefully to make sure you understand what it says. If there is no CLA at all, the legal situation is a grey area.
We ask our developers to get approval for every project to which they want to contribute, but we try keep the process light. We ask developers for the name of project, the kinds of contribution they will make, the licence of the project, the CLA it uses (if any), and the risks of contributing to this particular project.
With those details in hand, we can easily make a call to approve and document the contribution.
Document the approval
At King, we take pride in the fact that we contribute to open source projects, and want that fact to be well known inside the company. Keeping a list of all the projects we are currently contributing to helps promote that message – and as a side effect acts as a register of internal experts for the projects to which we contribute as well.
In the next article of this series on open source projects, I will describe how we have taken the final step in becoming an Open Source player: publishing entire system or tools developed at King under an open source licence.