Module 7 - Key IP questions when using open source and similar approaches

The fourth and final overall strategy for creating impact that we'll talk about is when you give other people access to your IP through open source licenses and similar approaches. The typical ways of doing this are through:

  • Commons, open source, etc.
  • Industrial/research networks (standards, ”knowledge platforms”, etc.)

This strategy to create impact is all about ”structured openness”. It’s about having control of your IP while at the same time making it widely accessible without having to negotiate agreements with each party that wants to use it.

This is different compared to the strategies around collaboration and commercialization that we talked about earlier where you make separate agreements with each ”recipient”, and it is also different compared to just spreading the information in the public domain where you do not, or cannot, claim control of the terms on which the information that you put in the public domain is used.

The typical example here is open source software, but also other types of copyrighted material like pictures, texts, etc. are often released under creative commons type licenses that allow anyone to use them freely.

Structured openness isn’t only about copyright, though, the same principle can be used for patents and other types of IPR. One example is technical standards like WiFi and mp4 where patents from different organisations that are needed to implement the technology are licensed to anyone on pre-defined terms. 

 

1. Open source and similar approaches

There are a couple of main IP related topics to keep a special eye on when you do open source or other forms of "structured openness":

  • Controlling AND sharing
  • Choose the appropriate license
  • Building on open source
  • Not everyone is comfortable with open source

Let's take a closer look at each one of them.

 

1.1 Controlling AND sharing

The "structured openness" approach to impact creation is both about controlling your IP and sharing it widely.

Here is KTH Innovation's patent engineer Thorunn Grenmark, who has long experience of working with IP management in the software industry, to explain some key things to keep in mind when you want to both control and share your research results with open source licensing.

 

 

1.2 Choose the appropriate license

You can create a license for your IPR with whatever terms you like (within what’s legally allowed) but there are already many different established open source licenses so it’s usually best to pick one of them. The licenses cover a wide spectrum of use cases so it’s usually possible to find one that fits.

It’s wise to make a well thought through decision about which license to choose and then stick to it to avoid unnecessary complexity where different parts of the IPR can have different licenses. You can change the license when you release new versions of the code/work but then it must be clear what the license covers and it should be coherent with previous versions’ licenses. In practice, it’s easiest to stick to the same license.

Here's a good site Links to an external site. to check out when you're choosing which open source license to use.

 

1.3 Building on open source

Open source software is all around us and when you develop something it is likely that you will use some elements that come under an open source license. This is important to keep track of, as Thorunn explains in this video.

 

Here are links to the trusted sites for download of open source software that Thorunn mentioned:

SourceForge Links to an external site.

GitHub Links to an external site.

 

1.4 Not everyone is comfortable with open source

When you do collaborative research together with other parties, you may be very used to releasing your work as open source, but maybe your partners are not as comfortable with that. This is a discussion to have already when you start talking to potential partners to avoid conflicts of interest later.

 

1.5 From theory to practice - Examples of IP management in practice at KTH - Open source software in research collaborations

We sat down to talk with Benoit Baudry, professor in software development at the division of software and computer systems at KTH. Benoit does research in close collaboration with the software industry on large open source software systems and releases the code he develops in his research as open source, so he has a lot of experience of this topic.

Here's a summary of the interview with Benoit where he highlights his key insights from working with open source software together with industrial partners.

 

Benoit Baudry

Prof. Benoit Baudry

 

First of all, do you publish all your research results as open source?

Yes, we put all our research in open source repositories so they are freely available to everyone. We also publish manuscripts in the preprint repository "arXive.org" when we submit them to publications. This is partly to make them openly available and partly to get a time stamp on them to show that we published it on a certain date. This is a precaution for the rare cases of foul play in the review process. 99% of the time there's no problem and the reviewers are fair and keep it confidential, but it has happened to us and other colleagues that you get a paper rejected and then 3 months later an almost identical publication appears with other authors...

 

So what's your view on the use of open source software in the software industry today?

Software (SW) development today is built on open source SW tools, so companies with any SW component in their products already use a lot of open source SW in their products and development tools. Database engines, development tools, etc. are all open source and many companies use the same tools and products in their development.

This is beneficial to all that complex and core underlying parts are developed and maintained as a common resource instead of each company having to develop all the software independently, and many SW companies actively contribute to open source SW projects to keep the quality high. This is more resource efficient than each party developing everything in-house. For the companies this is also a way to showcase what they do to attract talent.

 

How do the companies you collaborate with look at open source software?

The value proposition and the value for the pure SW companies is now not in the pure SW itself but the combination of the SW (open source + proprietary) and increasingly from the data that comes from the usage of the product/service. The SW has to be high quality, but you don't need to own it all. The data is more important to own.

What you have to understand, though, is that there's an important distinction between what's the core product (proprietary) and what's tools and non-core parts (fine to publish open source).

In research collaborations with industry partners this distinction is important to define. It's hard for a university to collaborate on the core parts that are supposed to end up as proprietary code, but it is possible for a university to collaborate on tools and non-core parts that can be published in open source repositories.

 

Is there a big difference in how comfortable different companies are with the results from the collaborative project ending up as open source code?

Pure SW companies usually understand the role of open source software very well and are good at defining what's core and non-core parts of their products, but more traditional industrial companies that come from primarily selling hardware products and now have an increasing software part in their value proposition often have a harder time to understand and define this. SW engineers in the companies get it, but legal departments and decision makers can take a long time to understand it... But, different companies have different maturity and understanding of this, hence collaborations vary in complexity to set up.

It is important to highlight, though, that when setting up a collaboration and when talking about what results are OK to put in open source repositories, it's important to first define how critical the SW is that will be developed to the company, since this determines how open they are to open source.

 

Do you see any clear benefits of the open source approach in industry collaborations?

Sure, open source can also be an enabler when collaborating with multiple companies. If you develop code in a research project with multiple industrial partners most parties will not accept that the source code is reposited with one of the other companies. Then putting it in an open source repository can be acceptable to all.

 

Module 7 - Key take-aways

Open sharing of information and IP is an important part of many researchers' impact strategy, and what we are highlighting here is that this can be a very effective way of getting broad adoption of your results and IP when done right. 

If you have questions or thoughts related to IP management in open source, you can first reach out to KTH Innovation and we'll guide you further. 

Finally, before we move on to the final conclusion of this IP management course we have prepared a few questions to make you reflect on your learnings from this module!