Photo by Markus Spiske / Unsplash

Leveraging Open Source Software

Intellectual Property Feb 9, 2024

When it comes to using open source software (OSS), companies may run into opposing views on the pros and cons of using OSS as part of their business:

  • Looking upstream of the commercial chain, use of OSS obviously looks like a cost-effective model, as companies don't need to pay for expensive license fees;
  • Looking downstream, however, things get a bit more complicated, as companies are not always aware whether using OSS could affect the IP they want to secure for themselves and, implicitly, companies are unsure whether they may even generate revenue by using OSS.

Understanding OSS

OSS is software that is freely available for anyone to use, modify, and distribute. It is developed by a community of contributors who collaborate and share their code and ideas.

In open source software, the code is publicly accessible.

You may have already heard of popular and widely used open source software projects such Linux, LibreOffice, WordPress, or Apache.

OSS licensing model

Legally speaking, OSS is actually just another type of license agreement. What stands out here is that:

  • the license is royalty-free; and
  • the licensors force you to redistribute the software you received from them in the same way, meaning as open-sourced.

Most entrepreneurs might focus on the first part. But, if you rely on valid and exclusive intellectual property rights to monetize or grow your business, the second part should be just as important. It has serious legal implications on how you can monetize any of your additional work built on top of OSS.

Adding value to OSS

Whenever you use OSS in creating software or providing software services, it comes with strings attached: you cannot receive OSS for free, then simply incorporate it into a larger work with your own work on top of that and call that your intellectual property.

Not all OSS is the same, though. Some providers require you to re-distribute only their OSS for free, others force you to re-distribute your own work that you added on top of that OSS (and for free as well).

So, when you plan on using OSS, you should really pay attention to using copyleft licenses:

  • these are the OSS licenses that force you to redistribute your own work that you added on top of the software received as open source;
  • this means and that you will most likely not be able to copyright or patent your part of the work that you incorporated into the software received because you are bound to make your own code freely accessible actually.

Other free OSS licenses (permissive licenses):

  • usually require that you release only that part that you received as open source;
  • this means that if you would want to grant your own license to your customers, you might still be able to protect your own part of the work, while still giving them free access to the OSS (the one that you received yourself).    

Start-ups raising investments should really watch out for copyleft licenses as well. There are customary clauses inserted by investors in the investment documents addressing these types of licenses, as investors want to avoid as much as possible investing in tech companies that are using copyleft licenses.

Benefits for companies using OSS

From an IP standpoint, the OSS model might affect what and how you might be able to sell software solutions to your clients, so most companies will be wary of using it.

However, if your company is a downstream client, some of these perks might seem appealing:

  • Cost: no license fees;
  • Quality: compared to proprietary software, OSS is argued to be more secure and stable, thanks to a constantly testing community;
  • Flexibility: accessible code allows customization to suit your specific needs;
  • No vendor lock-in: the beauty of it is that you avoid being vendor locked-in, as chances are that there are others working with the same OSS who might offer better services/cheaper ones to tailor a solution for you. They all have access to the OSS code, so you don't need to rely on providers with proprietary software.

But what if your company is upstream, looking to sell software solutions?

Upstream companies and dual business models

Monetizing OSS depends on whether a company relies on third-party OSS or develops its own.  

If you want to use OSS from third party providers and add your own work to it:

  • a potential business model is if you get customers who want to buy your services that revolve on adaptations or various integrations that could run on the OSS (software services company will have higher chances to monetize this dual business model, rather then product companies, however);
  • to do so, stay away from copyleft license & filter which permissive licenses are available out there. This way you will not be contractually forced to give out your own code to everyone;
  • you should also align your team of developers so that they know which free OSS is ok and not ok to use. Explain how they might affect your product / services. Implement some good practices regarding the code added to OSS (e.g. code labelling, maybe).

If you want to develop your own OSS, a common business model would be for you to keep the OSS for free and just sell premium licenses and charge a price for special adaptations or integrations only.

B2B is where you would be normally looking for in both scenarios. But, a hint from us, you should also try and have a look at public procurements where public authorities need to buy software solutions, because there is a growing trend (as well as EU recommendations) that the award criteria must prioritize software providers that rely on OSS. This is mainly because public institutions do not want to be vendor locked-in, plus some data would suggest that it is actually cheaper for them in the long run to buy solutions relying on OSS.

                                                                *

Read more about:

                   *

Using OSS and have questions about it? Reach out to us at office [at] venturesnlaw [dot] com to give you a helping hand.

Tags