All developers will be familiar with Open Source Software (OSS) and how convenient it is, but they may not be as familiar with the legal requirements associated with the varying associated licences out there.
OSS licences fall into effectively two groups; permissive and ‘copyleft’. Permissive licences are those which allow developers to build the OSS into their own code without any commercial restrictions – for example MIT, BSD and Apache licences (as well as the aptly named WTFPL licence). Copyleft licences, on the other hand, are generally much more restrictive and often require developers using this kind of OSS to ensure their derivative work is also made open source. Examples of these are GPL and AGPL licence terms.
This obligation to make new code open source can deny developers access to a key form of protection in the form of confidential information and trade secrets. Trade secrets and the law on confidential information can be utilised by developers alongside the usual form of protection such as the copyright in software or patentability of the hardware.
A trade secret is something that is secret, has commercial value, and has been subject to reasonable steps to maintain its secrecy. This generally includes things such as source code, processes, algorithms and patterns as well as valuable technical information which is kept confidential. Confidential information can include information relating to current and future technology, commercial and marketing strategies, finances, personnel and contractual relationships with third parties, such as customers and licensees.
As outlined in the introduction to this series of articles, there are varying intellectual property rights which cover the work done by developers and businesses working within the VR/AR space. Previous articles in this series cover the benefits of trademarks and patents in this area but rights such as copyright are also very relevant; copyright being an automatic right which arises in relation to original expression is set out in the Copyright, Designs and Patent Act 1988 (“CDPA”). Copyright seeks to protect the tangible form of expression of ideas and not the ideas themselves (ideas may be protected under confidentiality and/or trade secrets). Works protected under UK copyright law are original literary, dramatic, musical or artistic works (section 1(1)(a), CDPA); the foregoing recorded in some way (section 3(2), CDPA); and, sound recordings, films or broadcasts (section 1(1)(b), CDPA). Specifically for software, copyright protection can be found referenced in the Software Directive (2009/24/EC) as implemented in the UK by the Copyright (Computer Programs) Regulations 1992 (SI 1992/3233). Copyright lasts for a set period, generally being the life of the author plus 70 years form the end of the calendar year of their death. Being unaware of OSS licence terms can undermine copyright too.
Below is a table that summarises where these respective rights would fall into place:
The important point to note here for developers and/or businesses is that when using OSS (which will often be the case) they should ensure they are fully aware of the licence terms associated with the OSS they are using. The fall-out from not doing this is that the licence terms of the OSS could potentially preclude them from categorising the source code, for example, of the derivative work as a trade secret or maybe even maintaining the copyright and/or patent protection itself, if relevant.
What if a business is contracting a third party to create something for them in this area, though? The solution here would be to ensure that the contractual relationship with the third party explicitly states that the third party contractor will not use any OSS which is bound by licence terms that will prevent the business from ultimately commercialising, and maintaining protection over, the third party’s output. As alluded to above, developers will more often than not be using OSS within any coding that they develop. It would always be best practice to ensure therefore that whether using internal or third-party developers, you are made aware of whatever OSS has been utilised within the project. The licence terms are often complex so seeking legal advice may be a good idea. There are many third-party security services that even offer to find and fix vulnerabilities in open source components; so should a business find that they have some software which is patentable and have some uncertainty as to the OSS used within it, it could be beneficial to have such a third party security service run through the software to discover any vulnerabilities before filing any applications.
Along with considering the interplay between OSS licence terms and intellectual property rights, it is although worth thinking strategically about which intellectual property rights should be pursued (or not), for example, whether innovations should be patented or protected as a trade secret. The manner in which an innovation should be protected should undoubtedly be decided prior to any details being published or even sample being circulated as failure to do so can severely limit or undermine the scope for protection the innovation in any case. A business could decide that it doesn’t need (or want) to protect its innovation by means of patents as it will be able to commercialise it quicker and better than the competition. This could be right but in many cases, it takes significant time for new technology to take off, and the benefit of some protection from competitors at the outset is very worthwhile commercially.
In conclusion, where a seemingly small oversight may have taken place (e.g. using a copyleft OSS within your developed software) it can ultimately have much larger consequences in the long term, in that it could potentially invalidate the protection the business seeks. The possible negative effect of OSS licences on downstream intellectual property rights should, therefore, be constantly kept in mind and not addressed only at the point where something arises which the business realises could be of commercial value.