Open source – start using it

Do you love the idea of open source software, and want to make your employer take it more seriously? Not just running Linux and OpenOffice, but to make good use of it in your software development efforts?

At King, we have gone from using a lot of open source software in development to doing so safely, to contributing to existing projects, and finally to publishing new works under an open source licence. I want to share some of the details of that journey in the hope that it helps you get there in one piece as well.

Why use open source software at all?

There are lots of good reasons; the best one is that you get access to code that has been seen and used by lots of people, and therefore is much more likely to work well than closed-source software that has been seen by just a small number of people inside the company that made it.

Another good reason for using open source software is that you get the ability to change what the software does, whether that involves fixing a bug, adding a feature, or changing something in how it behaves.

Even if the group that made the software goes out of business or loses interest in it, you can still use and evolve it, along with anyone else who also uses it.

Finally, open source is ‘free,’ at least in the sense that you don’t need to pay anyone to use it. Bear in mind, however, that it does cost time to learn how to use and modify it.

Note that the definition I use for open source software is “Software distributed under a license approved by the Open Source Initiative (OSI) and where the source code is made available under such a licence.”

Are there any downsides to using open source software?

Sometimes, open source software is a bit basic, or poorly documented, or is written for a purpose that isn’t exactly the one you have. Even in this case, open source software gives you the ability to change it and make it better, if the need is strong enough.

It can also be difficult to get professional levels of support for open source software, though some open source software is ‘dual-licenced’ and you can choose to buy the version that comes with support if your use case requires that.

The biggest hurdle to cross is probably that of the open source licence itself: There are so many licences that permit different things that it can be hard to know where to start. More on that in a moment!

How we started using open source software at King

At King, we started with a common set of tools, such as the Jetty web server, zlib compression, and Apache Ant for our builds, and quickly grew from there.

If you are a developer, using some open source code is very easy – find some software that does what you want, download the source code, and start using it in your own project. Whether it’s from GitHub, Google Code, Apache or somewhere else, there are a million useful projects available.

Dealing with licences

But what about licences? There are lots of open source licences, and maybe someone told you that using them makes using open source software dangerous!

It is a bit complicated and it is worth educating yourself – fortunately, there are lots of sites that are really helpful in getting to grips with the basics, such as these two: – Lots of good information about open source licences – Provides an easy to read interpretation of most licences

The main thing to think about is what you need to use the software for, and whether you and your company want to contribute any changes you make back to the community and project. In most companies that are large enough to have a legal department, the answer is that they do not want to be forced to contribute changes back, and there must be no risk to the company!

If that is your starting point, you can classify open source software in a table based on what the licence is on the one hand, and what you use it for on the other. This is a simplified version of the one we use at King:

OK to use? Shipped Internal On server
Permissive OK OK OK
Attribution OK OK OK
Copyleft        Not OK OK Depends
Other Not OK Depends Not OK

In this, I have classified all licences into four groups:

  • Permissive. Licences such as BSD and MIT that allow you to do more or less whatever you want, including commercial use and redistribution.
  • Attribution: Licences such as Apache and libpng that are permissive, but require that you give credit when used.
  • Copyleft: Licences like GPL and CDDL that have a viral element to them. There are lots of variations, but the essence is that your code may become subject to the same Copyleft licence if you use this software in specific ways.
  • Other: Licences that don’t fit in another category and may be seen as open source but are not, such as Public Domain.

The other axis in the table represents the way you use the software. If you ship it to your users, you will almost certainly be subject to the terms of the licence, and you may want to permit only Permissive and Attribution licences for such use.

If, however, it’s software that you use just on your internal systems, perhaps for testing, the terms are often different, and you can use a wider variety of software for this purpose. In this case, just make sure it does not accidentally get shipped or otherwise trigger the ‘copyleft’ provisions of the licence.

Finally, ‘On Server’ is a category that is a grey area in many licences. Is the software ‘shipped’ if it runs on your server, helping deliver value to your users? I think the answer is yes, but this is subject to interpretation. Some licences such as the MPL mention this case explicitly, and I hope more will do so to eliminate some of the uncertainty.

Time to get legal

If you have one, get your IP lawyer involved and explain what you need, what the complications are, and how you intend to manage those via a matrix like the one above.

To make this happen at King, I spent a lot of time with our Legal team and ended up introducing a formal ‘third-party software policy’ that explained exactly why we were allowing or not allowing certain licences. We also added a clear process for using the policy, and added a requirement that teams thoroughly document the open source software that they use in order to make sure we continue to be safe.

This process allows King’s teams to be self-sufficient most of the time, and make good decisions about what open source software is safe for them to use. Occasionally, there is a need for software that is licenced under a new licence, and we now have a simple process for reviewing and agreeing how to apply those.

With this, your lawyers will probably continue to worry about two things:

  • What about software patents?
  • How do we enforce the policy?

Dealing with software patents

The subject of software patents is a divisive one, but the fact is that the patents exist and we need to deal with that fact. I sometimes wish they didn’t, but that’s a different discussion!

One way we dealt with the issue of patents was by joining the Open Invention Network, an organisation that shares everyone’s patents in a pool, allowing free use of those patents on anything related to Linux, GNU, Android, etc.

Enforcing the policy

How do you know that your teams understand and use the policy the right way? After all, the company’s own source code could be at risk if they don’t!

Our solution was to start in a lightweight fashion: We asked all our teams to document their use of open source software, creating a list of what they use, under what licence, and how they use it. This helped communicate the policy and get teams to think more actively about the topic.

Next, we sought the help of an external company that specialises in scanning source code to identify third-party code. If you do this, make sure they can identify a very wide range of software and versions so you get good coverage. Whether you try to identify ‘snippets’ rather than whole files depends on how much time you are willing to spend on wading through heaps of false positives.

When we got the output from the third-party scan in hand, we compared the result to each team’s self-assessment and used that to drive a discussion about the discrepancies. Fortunately, we found no cases where teams had used software with a Prohibited style licence agreement, so we were in good shape! Smiley Face.

We do those scans occasionally as well, to make sure we stay up to date, and are in the process of implementing a tool that allows our developers to do the scanning themselves and integrate the scan in our build and source code management process automatically – I’ll let you know how that goes in a follow-up article about tools.

How about attribution?

Some licences require attribution when you use the software. The ways in which different licences require this differs wildly, from “you must include this notice in your documentation” to “you must give credit and not pretend you wrote the software.”

We create games that typically don’t have any documentation and where a lot of the code runs on a server that our players never see, so how do we honour the spirit of such licences?

We decided to treat all licences that require notification or attribution in a similar way: by putting a page on our web site that lists all of such projects along with their licence. We really want to give a shout out to the software we benefit from using, so this feels like the least we can do – thank you!

In the next article, I’ll talk about how we took the next logical step: Contributing changes back to existing open source projects that we use. Take a look here.

Join the Kingdom -

Share this article!


About TechBlog

The TechBlog Editor looks after all aspects of, from handcrafting the CSS with his tiny little hands to encouraging other Kingsters to create content for the blog. His primary role at King is as the star of Diamond DIgger Saga, where he burrows away for you happily looking for diamonds. Outside of work he relaxes by collecting rare obsidian, attracted to its vitreous lustre and conchoidal fracture.