5 Tips for Deep Tech Startups to Take Advantage of Open Source Without Compromising a Patent or Trade Secret Strategy
Deep tech startups should carefully plan and manage the integration of open source components into their technology and R&D

5 Tips for Deep Tech Startups to Take Advantage of Open Source Without Compromising a Patent or Trade Secret Strategy

Believe it or not, open-source software and hardware can actually coexist with a formidable patent or trade secret strategy – but only if you are very careful, and if appropriate protective measures are taken. Since open source software / hardware has serious benefits for deep tech startups – reducing development costs and speeding up the development-testing cycle, just to name two – this article will cover five tips to enable your deep tech startup to take advantage of open source without compromising your patent or trade secret strategy.

The advantages of open source for deep tech startups

So, what are the main benefits of implementing a process of properly utilising open source components as part your R&D strategy?

  • For non-core software and hardware, you have the opportunity to save on development costs (after all, why reinvent the wheel?) and cut down on some R&D time. As you well know, the shorter your development cycle, the sooner you can focus on commercialisation.
  • By reducing development costs and the development cycle, your deep tech startup’s burn rate can potentially be lowered, meaning the founders and key employees can retain more equity.
  • By utilising open source, you may come up with improvements to that open source component that has commercial value…and that your company would otherwise not have discovered.

There’s so many darn open source standards…how do I know my patent or trade secret strategy won’t be compromised?

The many open source licensing frameworks can be confusing. Especially with regards to figuring out whether the integrity of your patent or trade secret strategy will be preserved if your company chooses to use a particular open source component that has a particular license.

We’ll cover some of the common licenses, but if you want the one line summary, it is this: only consider making use of an open source component for your R&D if the associated license is “permissive”.

I like this definition of a “permissive license” from https://blog.ipleaders.in/permissive-license-copyleft-possible-distinctions/ (bolding is my own): “A permissive license is an open-source license that guarantees the freedom to use, modify, and redistribute, while also permitting proprietary derivative works. In other words, when a user modifies a software, he or she is not obligated to make their altered software open-source, however, the user usually needs to give credit to the original project.”

The most popular permissive open source licenses you want to be on the look-out for, include:

  • The Apache License
  • The MIT License
  • The Berkeley Source Distribution License

It is nonetheless important that you carefully read the terms of any permissive license associated with an open source component to ensure that there is no fine print that could compromise your patent or trade secret strategy.

By contrast, a “copyleft” open source license comes with a whole host of restrictions, including derivative works having to also be open source. This is a big no-no. If you see any of the following copyleft licenses, steer clear!

  • GNU General Public License
  • Affero GPU
  • Lesser General Public License
  • Exclipse Public License
  • Mozilla Public License

What about open source hardware?

Now, as you probably know, open source software is far more prevalent than open source hardware. This is because it is just so much easier to develop and release new versions, and therefore it is easier to build a thriving community. With hardware, on the other hand, the development / improvement and release cycle is so much longer. This certainly creates a level of friction in terms of creating a thriving community. The more limited community around open source hardware also means there are less “eyes” to verify components – say to catch faulty components or potential security risks. However, it is increasingly probable that you will come across open source hardware components that could be very useful.

In terms of a useful definition, open source hardware is electronic hardware design that is "freely available under one of the legally binding recognised open source licenses". The open source hardware includes schematics, diagrams and design rules that can be used, studied and modified without restriction and can be copied and redistributed in modified or unmodified form either without restriction, or with minimal restrictions. For all things open sourced hardware, I recommend checking out this link and going from there: https://www.oshwa.org/faq/#what-license-to-use.

In any case, when considering using an open source hardware component, only consider a component licensed under a permissive license. Some hardware specific permissive licenses include:

  • The FreeBSD License
  • The MIT License
  • The Creative Commons Attribution License
  • The Solarpad Hardware License

?The copyleft licenses you want to steer clear from are:

  • The GNU General Public License
  • The Creative Commons Attribution ShareAlike License
  • The CERN Open Hardware License
  • TAPR Open Hardware License

?Okay, with this background out of the way, let’s get to the five tips!

Tip 1: Don’t use open source components that would compromise having – and potentially being able to enforce – bargaining chip patents

As you are likely developing a complex technology, it is probably that you are infringing on third-party patents. Hence, having "bargaining chip" patents is a powerful strategy to secure freedom-to-operate.

A “bargaining chip” patent strategy is useful to keep on the table – even if it doesn’t presently form a part of your patent strategy. A “bargaining chip” patent strategy means your company owns patents that have claims covering technologies used, or likely to be used, by close competitors. Hence, if a close competitor threatens a patent infringement suit against your company, your “bargaining chip” patents can be used to enter into a cross-licensing agreement and (hopefully) minimise the risk of having to defend a patent infringement suit in court and all the disadvantages that flow from that. Basically, a “bargaining chip” patent strategy helps your company secure freedom-to-operate, which is important for your present and future investors, customers, and strategic partners.

In terms of open source components, you want to figure out whether a particular open source component you are considering using is materially used, or is likely to be materially used, by your close competitors. If so, you will want to consider leaving the option open to secure “bargaining chip” patents on this open source component in the future. If you actually use the open source component, you will be restricted (by the terms of the open source licensing agreement) in the future in terms of enforcing patents covering that open source component. Remember, although you have no intention of going to court yourself, a potential acquirer of your company will most certainly want the option of enforcing your company’s patents without encumbrance.

Tip 2: Don’t use open source components that would compromise patents or trade secrets that could be of immense value to strategic acquirers and key strategic partners

You should think ahead and determine the types of patents or trade secrets that align with the current and / or future priorities of strategic acquirers. Part of assessing the appropriateness of a particular open source component should be to make sure that using the open source component will not negatively impact your company’s acquisition prospects, or ability to enter into critical partnerships.

Tip 3: Educate employees on the importance of open source license compliance and implement thorough risk assessments

Because making use of open source components carries high risks in terms of compromising your company’s current and future patent and trade secret strategies, employee education and documented procedures on managing open source procurement and open source components is essential. Your employees should be taught to read and understand open source licenses and distinguish between permissive licenses and copyleft licenses.

As such, your employees should have a solid understanding of IP strategy in general and understand your company’s patent and trade secret strategies.

Tip 4: Implement thorough risk assessment policies prior to obtaining an open source component

Before any open source component is utilised, a thorough system of verification and risk assessment should be in place to ensure that making use of a particular open source component will not compromise your company’s current and future patent and trade secret strategies. For example, when procuring an open source component, what criteria needs to be met to ensure that the open source component does not pose a security risk to enable hackers to expose trade secret information?

More specifically, proper open source procurement and risk management processes will seek to minimise the following risks:

  • The risk of software code (in software and hardware open source components!) containing a security vulnerability that exposes your company to trade secret compromises. Malicious hackers are aware of the prevalence of open source and are free to try and find exploitable vulnerabilities in the source code, itself.
  • The risk of an open source component comprising a misappropriated trade secret from another company.
  • And yes – the risk of an open source component being exposed to patent lawsuits from third parties that could force the termination of the open source component, altogether!

Tip 5: Have regular management meetings to ensure your open source strategy is aligned with the overall IP strategy and does not compromise patenting and trade secret activities

Following on from Tips 3 and 4, your company’s IP team should have regular meetings (at least monthly, even if it’s just for 20 minutes), to ensure that open source policies and processes are being followed and to make sure that any open source components being utilised or under consideration do not – and are unlikely to – compromise your company’s current or future patent and trade secret strategies. You can never revisit the risks of using a particular open source component enough. The future of your company – raising investment, securing strategic partners, and an eventual strategic acquirer – depends on not making mistakes and errors when it comes to using open source components.


Obviously, there are no simple solutions to minimising these risks! It is up to you and your company to be aware of these risks and to put together (and regularly review) an appropriate risk management plan.

?

Conclusion

Hopefully this article has given you some guidance as to how to approach – or refine – an open source strategy so you can benefit from the advantages of utilising open source without compromising your core IP strategies, as well as identified for you the key minefields you needs to be aware of.

Disclaimer: this article is not legal or financial advice.


要查看或添加评论,请登录

Ben Mandeville-Clarke的更多文章

社区洞察

其他会员也浏览了