Solid Legal Ground for Open Source

| | by

It is tempting to imagine that when it comes open sourcing your organisation’s projects, you will find developers flocking to help out and donate their free time in spades. But this doesn’t happen. No community will spontaneously emerge to maintain your code for you.

The long-term benefits only come about as a result of up-front investments of time and effort made by your organisation. These center around the two most important things needed to bootstrap an open source project: resolution of legal matters and community building. In this post we’ll focus on providing a solid legal ground for your open source projects.

Audit Every Line

You need to perform a full audit of your code before you release it to the public. You must make sure that you have the legal right to distribute everything, so you need to know the provenance of each line of code. For every piece of code that isn’t yours, you’ll need to figure out what the license is, and whether that license is compatible with the license you choose. Permissive licenses are usually okay, but copyleft licenses could present a problem.

Anything with no clear license must be researched or removed. There are automated tools which help to identify the license of each piece of code, and to flag problems. You may also want to remove anything that requires a patent license, or that integrates with a backend system which you do not intend to open source.

It is also crucial that the results of this audit are available to your end-users, so they must be documented unambiguously in the source.

Even after the licenses have been sorted out, you’ll want to scrub your code to remove anything that is embarrassing, proprietary, confidential, and so on. This might include customer details, staff details, passphrases, secret keys, salts, and profanities and disparaging comments.

Secure Your Source

There’s also a good chance that there are security vulnerabilities in your code. When you open source your code, you increase the attack surface. Security should be an important concern, because any issues in this area can damage an organisation’s reputation. This is true whether or not you publish your code. For this reason, it’s a good idea to use an automated security testing tool on your code before you make it public. It is also a good idea to establish a security response procedure, and publish this along with the project, to make sure that any vulnerabilities are handled appropriately.

Conclusion

There are many long-term benefits to open sourcing your organisation’s projects, but here we concentrated on one of the two major short-term investment costs that are required to enable this payout. In our next post in this series, we’ll look at the other short-term cost: growing an open source community around your project. Successful appreciation of these costs will be required to maximize the payout from your investment.

Have you encountered short-term costs when open sourcing an internal project? Do you have any tips to share, or questions about the sorts of problems that can arise? Tell us your stories in the comments below!

This is the second blog in a recent series by Noah Slater. Read the first post from this series: The Benefits of Open Source Investment.

Tags: , , , , , ,

One Response to “Solid Legal Ground for Open Source”

  1. “It is also a good idea to establish a security response procedure, and publish this along with the project, to make sure that any vulnerabilities are handled appropriately.”

    I feel like many companies don’t think about security until the very end. But at that point vulnerabilities can be so buried you can’t find them. But if you make security part of the whole development process security issues can be addressed and eliminated as they happen.

    July 16, 2014 at 7:38 pm Reply

Leave a Reply