Companies must train in 3Os licensing best practices, aligning with traditional IP management. This establishes a common foundation, particularly for innovative firms. Proficiency in compliant 3Os use, including inbound/outbound licensing, software reuse, license compatibility, and value-building strategies, is vital for effective training.

Supporting Organisations

Defining legal IP strategy and policies

The goal is to support the definition of an IP management strategy for the 3Os involving different functions/departments in organisations.

  • Support the definition of a strategy for reuse, contribution and valorisation of the open IP aligned with the business implementation by identifying the value created and identifying the KPIs relevant to measure it.
  • Design an open-source policy.
  • Encourage and support management in defining a collaborative development strategy on identified open projects and the definition of teams and budget dedicated to the contributions.
  • Submit suggestions and ideas on adaptation to the business model based on the evolution of the relevant projects in 3Os
    Support in the strategic evaluation and identification of relevant projects and creation of processes to evaluate and make decisions based on the valorisation strategy, licence and risk analysis.

BEST PRACTICES FOR OPEN LICENSING


How can you identify protectable assets in companies?

Identifying the protectable assets in a company can be a daunting task. Organising internal IP workshops could help overcome this difficulty. Ideally, these workshops should be attended by an IP professional, such as an IP counsel or a patent attorney

REQUIRED RESOURCES

Either or – IP counsel, IP professional, patent attorney.

MATERIAL REQUIRED

White boards, post-its, etc.

POTENTIAL QUESTIONS THAT CAN BE ADDRESSED

  • The following is a list of questions to discuss during an IP workshop which will help a
    company develop a better IP strategy:

    Identification and assessment of existence of any contractual overrides in the absence of IP protection. For example, when a database is not protected either by copyright or the sui generis database right, the owner is free to determine the contractual conditions of the use of such database; patent cross-licensing etc.
  • Assessment of downstream open source licence conditions in light of the framework’s business components
    • Permissive conditions – they are usually fine, regardless of the business model.
    • Reciprocal conditions – exercise caution when combining with other subject matter.
    • Compare licence conditions applicable to different subject matter – are there overlaps or incompatibility between the licence grants?
    • Identify any dual or multi licensing conditions.
  • Assessment of horizontal compatibility of the input subject matter
    • Are the licences applicable to all components in the input compatible with each other?
    • If not compatible, is it possible to mitigate the incompatibility, eg, remove a non-essential component. If not possible, what would be the consequences for the business model? Assessment of vertical compatibility of the input licence grants and the output licence for the project
    • Do we give more rights at the output than we have in the input?
      • If yes, then choose a different output licence
      • If not, check if the chosen output licence meets the business needs of the company
    • Are there residual risks of incompatibility?
      • If yes, describe how they are managed.
  • Is there a licence compliance management system in place?
    • If not, is it necessary for the company to implement one in light of its short- to mid-term objectives?
    • If yes, is it based on any recognised international standard, eg, OpenChain, or industry good practice?
  • Is there any risk assessment system in place? For example, a software bill of materials (SBOM) which facilitates the implementation of legal, export and security compliance measures.
  • Assessment of export control regime and compliance. The export of dual use items (software/technology, eg, sent by email or by remote access of a server)) from the EU is subject to the EU Export Control regime. In addition, releases/disclosures of software source code to a foreign national in the EU or outside, and releases/disclosures of encryption source code and technology in a foreign country to a foreign national are also governed by EU export control laws. 
Multi-jurisdictional businesses should be cautious of any export of such technology/software.
    • Assessment of whether the software/technology can be classified as “information security” items, i.e., controlled cryptography products.
    • Assessment of whether the software/technology is for user’s personal use.
    • Assessment of whether the software/ technology transfer is for “basic scientific research”.
    • Assessment of whether the software/ technology was released is in the “public domain”.
    • Assessment of whether the software/ technology is used “for minimum necessary information for patent applications”.