Developers of proprietary software are often faced with the decision whether to develop software, or a part thereof, from scratch or whether to rely on existing, "free" open source code that achieves a certain function tried and tested by a large community of developers.  Aside from the relevant technical and commercial decisions involved, it is also important to consider the possible legal considerations, namely the obligations imposed by open source licences, which can be onerous and unexpected.  

The Open Source Initiative (OSI)[2] and Free Software Foundation (FSF)[3] have published substantially similar criteria for what constitutes "open source software".  These include:[4]

1. Free redistribution

2. Access to source 

3. Distribution under the same licence terms 

4. Access to derivative works under the same licence terms

Developers most often opt to open source their code using established and trusted open source licences, typically those endorsed by the OSI or FSF.  For this reason, certain open source licences have gained a lot of popularity – to the point where one might say they are market standards.  These include:[5]

1. 2-clause BSD License  

2. 3-clause BSD License  

3. Apache License 2.0

4. GNU General Public License version 2  

5. GNU General Public License version 3  

6. GNU Affero General Public License version 3

There is no reason why a person cannot create their own open source licence terms.  This however does not happen often as the principal benefit of open sourcing software is to kickstart a collaborative effort with a larger community of developers.  If each person crafts their own licence, it will deter developers from doing so, as they will have to study each licence to see if the particular open source software project is truly open source and whether the copyright owner has sought to either reserve certain rights or impose others on the community.

As mentioned, open source licences often have as their goal to make software freely available and for such software to remain freely available if adapted in any way.

As a result, many open source licences compel developers to make their adaptations publicly available under the same licence as a precondition to the use of the software.  

This is where developers of proprietary software need to take care.  The obligation to make available adaptations often does not only apply to the adaptations made to the open source code, but also the product or solution in which it has been embedded.

Often open source licences include "trigger conditions" for some of the obligations to become operative.   A common trigger is the "distribution" of the product or solution.      

The GNU General Public License version 2 licence for instance argues that if any product or solution would constitute an infringing work with the open source code included, such product or solution falls within the scope of the licence obligations, if the trigger conditions occur.

Depending on the wording of the particular licence, making the product or solution available between related group companies can qualify as "distribution", technically triggering the obligation to release the product or solution under the same open source licence.  

Writer was not able to find any South African case law directly on point, so what follows is an application of the usual remedies under South African law, as applied to the present scenario.

The licence to use the relevant open source code will be conditional on the acceptance of and compliance with its terms.  Therefore, failure to abide by the terms will likely make the use of the open source code unlawful and constitute copyright infringement.  The usual remedies will be available to the claimant, namely an interdict to stop the infringement, with or without a claim for damages.

Interestingly, the right to institute proceedings by default lies with the owner(s) of copyright.  In the context of open source software, ownership may be no simple matter to establish, as depending on the project, you may find multiple authors responsible for the code as it stands at a particular point in time, each having made their own contributions.

An interesting question to consider is whether the owner(s) of copyright can seek specific performance (i.e. strict compliance) with the terms of the open source licence insofar as it may compel the release of the proprietary code on the same terms?   

Generally speaking, under the South African law of contract a party to a contract can claim that the counterparty honours the agreement, with or without a claim for damages. 

It would follow that if the language of the relevant open source licence creates a binding obligation in favour of the copyright owner(s), such a claim may be available.  If the language of the open source licence is however framed in a way that non-compliance with the terms of the licence merely renders the licence invalid, the consequence would likely be copyright infringement, rather than a claim for specific performance in terms of a binding contract.

Under South African law, parties to a contract can agree to a term for the benefit of a third (or "stipulatio alteri" in our common law).  

The point was made at the top of this post that open source software licences have at their aim for such software to remain open source for the benefit of the larger development community.  

It is therefore interesting to consider whether any person (not only the copyright owner(s)) would be able to rely on the terms of an open source licence that requires the release of proprietary software as a stipulatio alteri.

An analysis of the stipulatio alteri falls outside the scope of this piece, but a cursory review of relevant case law reveals that there are two considerations that would be material, namely (1) our courts have generally sought to limit the scope of persons that can seek to accept the benefit of a stipulatio alteri and (2) our courts require clear language permitting reliance on such a term.

The wording of the relevant open source licence would accordingly be important in determining whether a third party could compel compliance with its terms.  Generally speaking, the writer's assessment is that such a claim would be difficult to prove, as one first has to pass the hurdle of specific performance (discussed above) and then the requirements of a stipulatio alteri.

On another but related note, there is a common misunderstanding that software that is in the public domain is also open source.  This is not the case.  The fact that a piece of software is in the public domain – i.e. publicly accessible – does not mean that it is open source.  

Typically, it requires very little for a person to become vested with copyright over a piece of code.  The code does not even have to be objectively new in the world.

With the advent of the Internet and online developer forums, it has become very easy to take some code from the internet to fix a problem.  This was famously referred to by Jeff Atwood as the "The Bathroom Wall of Code".[6]

While he was more on about the quality and reliability of such code, the same holds true for the rights possibly attaching to such code.  

Simply put, certain types of open source software are incompatible with proprietary software.

Every developer should have a software asset management ("SAM") programme where every piece of code in every project is clearly identified for purposes of rights management.

Where specific licence terms require compliance with obligations, steps must be taken to ensure compliance, which could include:

It follows that it also makes sense to investigate the possible legal risk arising from open source software when concluding any transaction that involves software, as the value of the product or solution could be adversely affected by infringing code or other onerous obligations.      

Swart Attorneys can help you develop and manage a SAM programme that manages your compliance with third-party licences in a structured and auditable manner, building up to fully compliant licence agreements.  We are also able to assist in legal due diligence investigations should you wish to investigate the possible legal risk arising from open source software.

[1]https://www.reddit.com/r/ProgrammerHumor/comments/6cer5t/what_are_clouds_made_of/ 

[2] https://opensource.org/ 

[3] https://www.fsf.org/ 

[4] See https://opensource.org/osd for more. 

[5] See https://opensource.org/licenses for more.

[6] https://blog.codinghorror.com/the-bathroom-wall-of-code/