Ignoring the risks and challenges posed by a lack of understanding of the practical implications of using OSS can lead to difficulties in future, says Anoop Joshi
OSS: Interacting with Open Source Software (OSS) is a mainstay of modern software development and is encountered by software developers and users on a daily basis. To make the most of the advantages, we have to embrace working with OSS by understanding its role in software and product development.
All code is subject to automatic copyright protection. The first owner of copyright in any code is its author (or your employer if you are writing the code in the course of your employment). As the copyright owner you alone have the right to modify, adapt and copy your code. Without a suitable licence anyone using, modifying or sharing your code will be infringing the author’s copyright.
What is OSS?
OSS is software which is distributed under a licence that allows the code to be made freely available, distributed and modified. There are a variety of different types of OSS licence, each of which includes different requirements. They can broadly be split into two types:
- Permissive licences such as the MIT licence and Apache 2.0 licence. Permissive licences generally allow a third party to use, modify and share code without imposing any further licensing restrictions;
- Restrictive licences aka “Copyleft” licences such the GPLv2 and GPLv3 licences. Restrictive type OSS licences allow use, modification and sharing of code but are also subject to the additional requirement that any future works are released on the same or compatible licence terms as the original code. These licences are often considered ‘restrictive’ in the context of commercial software development.
Ignoring the risks and challenges posed by a lack of understanding of the practical implications of using OSS can lead to difficulties in future. Looking to sell your start-up? Have you considered the risks a potential buyer might have to take on if it is not clear how you are using OSS? What implications might that have on the company’s valuation or on the release of a new product?
Practical tips
If you are using OSS on a daily basis, what does this mean for you and your business? What are the practical points and what should you be thinking about to manage the risks?
What software dependencies do you have in the software stack?
It is important to carry out an internal audit to understand what type of software will end up in your final product. Do you have a list of OSS that will end up in the final product and the types of licences these are governed by, i.e. permissive or restrictive licences?
Once you have a view of all of the OSS software associated with your product it is worth considering preparing a compliance checklist for internal governance. What OSS licensed software is your organisation happy to allow? This check may then form part of the code review stage or could even be automated as part of a build process to check if the licensing of a particular piece of software is acceptable.
Sharing your code
Is your code stored in an online repository like GitHub? If you want people to use, modify and share the code you have uploaded, have you included the appropriate licence? GitHub gives you the tools to easily select a standardised OSS licence.Whether you want to grant permissive or restrictive access, the best first step is to use a standard OSS licence. These standard licences make clear to other developers what they can and cannot do with the software. If you try to add in your own licence, you may hamper future development or discourage use and development of the product at an early stage
Who is the audience?
If you want others to use, modify or share your software, consider the right licence to be used for that purpose. If you want others to use the product, build on it and be able to freely distribute and modify it, consider a permissive licence, such as the MIT licence. Alternatively, if you want to attract commercial users you may wish to opt for the Apache 2.0 licence, which is commercially- friendly and includes a patent licence (where necessary) from contributors of the code
Ongoing monitoring
It is important to remember if you are changing your code base and dependencies or lots of developers are adding to the master code base then governing the use of OSS will continue to be a moving target.Once internal procedures are in place to identify what OSS risk profile is acceptable for your business then the situation should be constantly monitored and considered a part of good governance. Procedures should be worked on and agreed between engineering and legal teams.
Conclusion
OSS is ingrained in the modern software development environment. There are fantastic tools and resources available for individuals and organisations to embrace and make OSS work with their own internal process. Users of OSS need to be aware of the importance of different types of OSS licence and understand that some can be more restrictive than others to best manage risk.
We can help you to understand your OSS licences, identify and address any risk before you come up against the pain points associated with the lack of a clear and cohesive internal approach to using OSS.
Anoop Joshi is a senior solicitor at Brodies LLP and a software developer
This column is supplied under the terms of the DB Direct service
Leave a Reply