Episode 16: Best practices for using open source software

Lisa: You're listening to Canadian IP Voices, a podcast where we talk intellectual property with a range of professionals and stakeholders across Canada and abroad. Whether you are an entrepreneur, artist, inventor, or just curious, you will learn about some of the real problems and get real solutions for how trademarks, patents, copyrights, industrial designs, and trade secrets work in real life. I'm Lisa Desjardins and I'm your host.

The views and opinions expressed in this podcast are those of the individual podcasters and do not necessarily reflect the official policy or position of the Canadian Intellectual Property Office.

If you are considering open source software for your next coding project, then this episode is for you. Open source software can be a great tool to boost your coding production and even be used as a way to make money, but it comes with a set of criteria and a licence. And you need to be aware of both, as they determine what exactly can happen to whatever you do with the open source software. Because, even if the code is yours on the copyright, you may need to share it for free without any limitations.

In this episode, which is a little bit longer than usual, you'll hear from Jules Gaudin, lawyer and IP expert at ROBIC in Montreal. Jules will explain what exactly is meant by open source software and some of the key considerations, pitfalls and best practices for both users and providers of open source software. Jules, I'm excited to have this conversation with you. There's much to learn in this field. But before we start, would you mind talking a little bit about yourself and the kind of work you do in relation to open source?

Jules: Yes, absolutely. It's a pleasure being here and speaking about open source. It's an important topic that I feel is going to be more and more prevalent in software and in artificial intelligence in the coming years, especially in Canada. I'm a lawyer in intellectual property and technology at ROBIC. I assist my clients with anything regarding technology, so it's a vast topic. It can relate to either trademarks, copyrights, contracts, litigation. Usually, when there are some kinds of technological components, people tend to think about me and say, "Oh, maybe Jules has some technical knowledge that might be useful."

I also tend to work with anything relating to open source, whether it's creating open source policies (we'll discuss that a bit later) or whether it's reviewing the different open source materials that are currently being used in proprietary software and solutions and how it might affect your IP rights, all the different kinds of open source licences that are available to use that you could use with your business or your solution, or even sometimes it's just raising the topic when you are creating a new solution or trying to license it and maybe, I'd say, raise the flag about some issues that might be related to this topic with your commercialization and distribution of a software.

Lisa: You're talking about licensing and open source, and I think it's starting to become clear that we are talking about open source as a business tool and a product. Would you mind explaining what exactly is open source?

Jules: Yes. What is open source? I think it's a good question and a vast one because, rather than having a very static definition of what is open source, over the years, we pretty much can instead rely on different criteria that have been created and used by different organizations working in the field. The ones that I tend to use are the ones created by the Open Source Initiative, OSI, a non-profit that was created in 1998. Their goal was to promote the open source licences and open source software. If we look at the 10 criteria listed by OSI, maybe that gives us some, I'd say, clues as to what can be an open source licence.

First and foremost, and I think this is one of the biggest criteria with any kind of open source licence, there should be free redistribution. It means that there should be no restriction to sell, give away the software or the components that is licensed with said open source licence, whether it is distributed as a component of an aggregate software distribution that contains all the software from other third parties, and it should not force you to obtain any kind of royalty or fee for such sale or such distribution. So it should be really a free redistribution of the software. No restriction. The second one is the fact that software, the software that you are currently distributing with this licence, should also include the source code of software. So when you're providing the software with an open source licence, you can provide it as an executable, as an object code. But at some point, you should also provide the source code of said software.

Usually, from a practical standpoint, it's even recommended that you are providing it as a source code material because it's usually the best tool to make sure that you can modify the software, redistribute it, change it, integrate it with other solutions. But if you do not distribute it directly in source code, at some point, there should be a publicized way to obtain the source code. It should not be deliberately obfuscated. Most of the time, people tend to use the solution of including in their technical documentation a link or a form that you can fill out to obtain the source code for their open source software.

Third, there should be some criteria relating to derived works. The open source software that you are currently using, you should be allowed to modify it and derive works from it. You should be also able to distribute the modified software that you created under the same terms of the open source licence, or sometimes under the terms of a different licence. But most of the time, the main idea is that you should be able to modify and redistribute the open source software.

The fourth is usually an easy one. There should be the integrity of the author's source code. The licence may restrict the source code from being distributed in modified form only if the licence allows the distribution of patch files with the source code, just to make sure that it allows the modification of the source code at build time. It should also explicitly permit the distribution of software built from modified source code. And it may require derived work to have a different name and number just to make sure that you are not passing off as the creator of the initial open source software. Most of the times, those obligation requirements are not very difficult to agree.

The fifth and sixth criteria go hand in hand usually in my mind. It goes very well with the idea that open source should be open, free, available for all and the fact that there should be no discrimination against people or groups or against certain fields of endeavour. The main idea is that you are providing the software with a licence that allows everyone in every field for every use to use the software, the components. The main idea is that you're providing it and anyone can do whatever they want with it.

The seventh criteria is a distribution of the licence. The idea behind it is to make sure that open source licences are simple to use. The idea behind it is to say that the right attached to the software must apply to anyone to whom the program is redistributed without the need for them to execute an additional licence. The main idea is that they get the right because they get the software.

Eighth criteria: the licence should not be specific to a product. So you should not have the right to use the open source software because it is specifically part of a particular software distribution or hardware. The last two, which are also very easy to accept and go hand in hand with the idea that open source is open and free and accessible to everyone, is that the licence must not restrict other software. So you should not prevent someone to distribute the open source software with other third-party software, whether they are open source or not. And it must be technology-neutral .It should not prevent the use of the software to be used with specific technology or interface. It should be open and as free as possible. Pretty much the general idea and feel that we have when we read those 10 criteria, at least for me, is the idea that it should be open, easily accessible, easily modifiable, you should be able to do whatever you want with the software and redistribute it, whether in its original form or in its modified form. Those are the 10 criteria.

Lisa: It's not as straightforward as it sounds. But at the same time, we know that open source is still used in a commercial context. So can creators of open source actually make money off their software?

Jules: Yes, absolutely. Because the main idea behind open source is that it's not a free for all. It's not because it's available for free that no one can make money out of it. Nothing in an open source licence, at least with the criteria that we discussed before, would prevent you from selling an open source software. What will happen is that, sure, you can sell the executables, you can sell it in object code, but at the same time, you should always make sure that you provide the source code, and you should not restrict anyone buying the software from you from redistributing it and modifying it and redistributing it to any third party.

What happens is that you see sometimes people selling open source software, but what they are selling is more their service space to host the solution and providing it to you to download it, pretty much. The best way, and the one that we see the most, and I think that is the most profitable one, you can look at Oracle Red Hats that are very successful doing that, rather than selling the software itself, you sell services related to the solution that is otherwise available for free, and that can be support, that can be training. One of the ways that they also make money is that they create paid plugins or specific features for existing products.

For example, you can have a text editor that is available for free for everyone under an open source licence, but at the same time, you think, "Okay, but I need to integrate a very specific feature for automated transcription of text or video." So you go to Oracle, for example, and say, "You are offering this very cool text editor, but I want to add this very specific function just for me." You'll pay them. They'll develop a proprietary plugin that you can insert in your software, giving you access to these new features. That's how they make the money, by making sure that their solutions are very tailored to your need and to your specific requirements.

The third way that they also tend to make money is through offering open source solutions through software as a service (SaaS). Rather than providing the software itself, you are pretty much providing access to the function of the software through the internet. Here we fall into a very specific question and discussion regarding open source, where providing a software through SaaS services is not distribution per se, so you are not obligated to provide the code source of the said software. It's a very specific question, not resolved entirely. People have been fighting over it for the past few years. The main idea is that, rather than providing the software itself, you can sometimes provide the software itself and say, "Hey, by the way, anyone can create their own SaaS service with my software. It's available for free. You can modify it."

But if you are a very big company, you might not want to rely on, I'd say, a small provider or even using your own server to set up the SaaS platform for your services. You might be, "Oh, you are Red Hat. You are a big company. You know what you are doing. You have a good server. You have good services, good training, good support. Rather than setting ourselves as the SaaS service, we'll require your services," and what you're paying for, pretty much, is, once again, the server services: the creation of a specific space for your company maybe tailored to your needs, the support services and the warranties that they offer regarding access to the platform. That's pretty much what they are offering, their knowledge and expertise in the open source software that you can otherwise access freely.

Maybe one last way to use truly open source software and make money out of it—it's not accessible to everyone, but it's becoming more and more useful—is GitHub sponsorship. GitHub is a platform that allows you to distribute your open source software. One way that they realize they can help support this project is by providing an opportunity for companies or even individuals to sponsor said projects. They get to use the trademarks and logos and names, saying that they are a sponsor of specific products, and they provide money for it. All of the money that they pay for, say, sponsorship, is actually given to the people maintaining the project.

Some people and some developers, whether they are a team, whether they are solo, are actually making good money using the sponsorship because they provide very useful solutions for the entire open source community or, I'd say, this is the entire internet sometimes. Those, I'd say, are the most big commercial, without the need to look at the licence, ways to make money. Because open source in itself can also be a tool that you can use to create proprietary solutions. Not all licences will require you to provide the open source of your proprietary solution. Those are called permissive licences. Pretty much, you can, most of the time, use the elements that are licensed this way to integrate them into your own proprietary solution that you can, after that, sell without the need to provide the source code.

Then open source become a very useful tool to create high value-added development because you don't need to, for example, create from scratch and from zero, an entire library. You can base some of your solution on existing software libraries that are well proven and that have been maintained for a while. It reduces the time necessary and the cost to half and can cut production because you can move faster to finish product for a fraction of the cost.

One other way that we also touched upon is a dual licensing model, which is an option that tends to appear more and more, where you offer two versions of the same software, one free version under an open source licence, usually with a copyleft mechanism, meaning that anyone can use your software, redistribute it, they can modify it. But if they modified it and distribute it, they need to provide the open source under the same open source licence that you've used. Meaning that you could still see what they've been doing with your code and maybe take some inspiration as to what they created.

Usually, what happen is that it allows, I'd say, small clients or single users to try your software, maybe sometimes train on it and become familiar with it, so that, if they want to switch, they know that it's an option. At the same time, you provide a paid version of the software and this time under proprietary licence. That would allow a bigger client to obtain a specific licence that allows them to use the software or even integrate it within their own solution without any kind of risk for their own source code because they wouldn't need to provide it to anyone.

That's the dual model that we tend to see appearing more and more. Usually, it's sometimes used as a way to attract potential customers, where you offer this free open source trial, "Sure, let's try my software, see how it works." Maybe try to see how it would integrate with your solution. When you're ready to, I'd say, go forward, you can pay for a specific licence and obtain the closed versions, the full version, where you can do whatever you want with it without any kind of risks for your IP.

Like I mentioned, there is also the open code model that we discussed a bit before, where you license most, I'd say, the core of your software under an open source licence, meaning that anyone can use a core of your licence and do whatever they want with it. At the same time, you offer a very specific fraction of your code under a proprietary licence, for example, module extensions, that users need to pay for. Sometimes, it can create even a market of module extensions applications. We see that, for example, with certain SaaS platforms where most of the code is open source and people can create module extensions that they can then license under a proprietary licence to sell it to users, and it  creates, sometimes, very thriving markets for developers that can make good bank by providing a very short and small code to integrate with an open source solution. One good point to note with open source is that sometimes it can become, what I call, an indirect economic tool. We see big companies, like big actors in the tech fields, starting open source projects by themselves or participating in open source project because they either see it as a way to create an ecosystem around the solution to ensure that they remain the leader in the industry. It's something that people are using more and more as a tool to show that they are a leader in the industry, they should stay the leader and make sure that everyone knows what they are doing and are trained with their solution.

It's also to create a bond of trust with your users because when you create an open source product, you have access to different people who can provide you with new, innovative functions or features that you might not even have considered that could be integrated in another solution. You also have an immediate feedback because, as long as you push something forward, you'll have people reviewing it, asking question, maybe even offering some insights or some advice. It creates a direct bond of trust with your users, with your clients, where they can directly give you feedback even if they are not paying you for it.

Maybe the last one, which can also be a risk, as we will see, is that you mutualize risk management. Sometimes when you provide code, it's hard to make sure that it's safe, that there are no liabilities, that there are no issues, whether it's a bug, whether it's even a security breach. So sometimes having even a third party look at your code and making sure that it's safe is a good way to use open source because you'll have thousands of people reviewing your code doing weird things with it, and maybe they'll notice things that you could not have even imagined. It's also a great tool for that to make sure that your review process of your code is mutualized and less expensive, I'd say.

Lisa: Thanks for going through these different options. When we talk about open source, there's still an ownership component. In terms of IP rights, what is open source?

Jules: The software that you've created, you usually will have some copyright on the source codes that you've created. Therefore, if you put, for example, your software on GitHub and don't provide the licence with it, well, you provided the world with your source code. They can see it, they can review it, and that is pretty much all they can do. They cannot use it because you haven't provided them with the licence, with the rights to use your copyright.

That's where open source came in. It was a way to make sure that you were providing the necessary rights to potential users to do what they needed to do with your software, whether it's using it, distributing it, installing it. At some point, it was even integrated in some old licences. It was a way to making sure that you were providing users with the necessary rights to your copyrights. At some point, it even went further than that. That's why sometimes you even see some discussion regarding patent in open source licences where it's specifically mentioned that, if you are using the open source components in the solutions that you want to patent, you can do it and these are the specific terms that will apply to your patents and maybe you'll need to offer some licence to the copyright owners, to other users of the open source solution.

Mainly the main idea behind open source, in any case, is that, at the beginning of it all, there is someone creating source code on which they have copyrights, then they decide to license it and, if they decide to use an open source licence, then all we've discussed before came into the light. The important thing is making sure that you use it properly. That's where, sometimes, people don't do their due diligence. They just see open source and they think, "Oh, it's free, I can use it." Sure you can use it, but there might be some mechanism behind it that would prevent you from having the best commercialization or could force you to even put you in a situation where you are breaching some of your contracts with certain clients, certain service providers.

So yes, open source, great tool. It can be a very, very, very useful tool to boost your code production. Just make sure to use it properly. That's pretty much what I'm always saying. Most of the time, you can find lists of specific open source licences that are recognized and established, but it's also always possible to find homebrew licences, where you see people create their own open source licence, and I'll put open source in quotes, where they'll take some of the criteria and leave others out of the table.

That's why it's always important to refer to the 10 criteria themselves, and the licence, just to make sure to know what we accept and what we agree with, rather than just reading a definition of what is open source and say, "Oh, it's an open source licence, so this is what should be included inside of it," without the need of reading it. That's always my caveat, to make sure to read the licence itself.

An important difference to make is between free software and open source software, which is not the same thing. Free software has a philosophical and political purpose, where you choose a specific open source licence because you want to encourage the diffusion of knowledge. You want to make sure that everyone will be able to access the source code and everyone who modifies the source code is obligated to make sure that this modified source code and the one that you've put into this new version will be available to everyone else. That's usually the idea behind the free software foundation and the new GPL licences, but at the opposite of the spectrum, there is the open source, which is qualified more as the method of developing and distributing software where you decide to offer the source code with an open source licence for various reasons—because you want to create a community around the software, because you want to show the world how good you are at coding—but it's not always with the idea to, I want to say, create and propagate knowledge. Maybe sometimes, you just want to show off and let people do whatever they want with your software.

There is always this slight distinction between free software, which is political, philosophical, and open source, which is more a means to an end. That's why usually we tend to say that free software is always open source, but open source is not always free software.

Lisa: You can be using open source. We hear about where the ownership of the open source becomes like a confusion. People have used open source, they've built a lot of assets upon it, and then they can be subject to almost like an open source infection, where using open source can become a problem. You can be using an open source that has been somewhat orphaned in a support sense. I was wondering if you could talk about some of the pitfalls and some of the things that you should watch for if you're thinking about using open source.

Jules: Yes, there are two kinds of, I'd say, pitfalls. The biggest one, and the one I think people think of the most, is regarding IP and proprietary IP. Because, as you mentioned, in specific, in certain open source licences, there are what we call the copyleft mechanism. Sometimes we speak about contamination. It's the same term, and it covers the same idea. The idea behind this mechanism is you can use an element, you can distribute it, you can modify it, you can distribute the modified version, as long as any derivative work that you make using this element is made available under the same open source licence.

That's the copyleft mechanism, the idea that you can use my code, you can create something with it, but what you create needs to be made available under the same open source licence that I've been using. Pretty simple, as it is. Makes sense most of the time.

Where the issues lie is as to how exactly it will compute and link to any kind of proprietary code that you will create, especially if you integrate it with an existing solution. So, for example, I'll take my text editor idea as before. I created very good text editors. It's all proprietary software. I've been creating the entirety of the code. Everything is good. Out of the blue, I see this very cool new function that allows me to predict the next word that you are going to be typing. It's made available under an open source licence with a copyleft mechanism. I'll take this line of code, integrate it into my software and start distributing it.

What happens here is that I've potentially created a derivative work of the open source component, of the open source code, by integrating it into my proprietary solution. What I should do after that is make sure that all the code of my text editor, even the code that I've created before integrating the open source element, should be made available to anyone who has access to this new version.

That's where usually the copyleft mechanism is worrisome, in that, suddenly, you are forced to make sure that all of the codes that you've created yourself and on which you have the copyright, and you remain and you still have the copyright, but you are locked in a position where you must make sure that the code source of yours, this new version, this new derivative work, is made available under this new open source licence, which can be a problem if you were selling it before because suddenly someone is able to access this new version, the source code of it, and they're allowed to modify it and redistribute it without you being able to claim any kind of fee, any of royalty.

That's where usually the big danger lies. It's with these copyleft licences. When you try to advise people as to what kind of licence they can use, a permissive licence should be okay most of the time. With copyleft licence—it should be okay, just be careful as what you do with it—copyleft licence, red flag, be very careful there. There might be some big issue down the line. I'd say that's the main IP risk with open source. There are also other pitfalls like you mentioned. First, the less important one but one that I'd like  to underline still, is the fact that some specific licences restrict the commercial use of their components.

Sometimes you're like, "Oh, there is no copyleft mechanism. It's all good. I can move forward with it." Or it's a very weird open source licence, maybe a homebrew one, and they prevented the commercial use of the components, and then you're locked. As always, make sure to refer to what is actually said in the licence itself. As you mentioned, there also is the issue of support, of what kind of elements and codes that you're using. Has it been updated? Has it been maintained? Is it something that has been on the internet since 2012? No one has been making sure that it's still up to date and safe to use? Always make sure that you're not using something that's been abandoned for too long.

Same goes with using what we call in cybersecurity weak elements because, as always, it's like in a chain. You are as weak as your weakest elements. So if you integrate some things that suddenly could be the target of potential cyber attacks, maybe integrating open source is not the solution. Maybe you should find an alternative, whether it's creating something, maybe it's another open source component. As we mentioned before, usually when there is a cybersecurity issue with an open source component, it will be publicized, and it will be highly publicized even.

There has been, when we registered the podcast, some news about some library that had been a potential target to specific attacks. When I say highly publicized, I say general media has touched upon it and said, "Oh, this is an issue and this is why some of the websites that you've been using are down." Everyone was freaking out, so rather than correcting it or while waiting for a solution, it was easier to take down the website as a solution rather than to be a potential risk to cybersecurity attack.

Other specific pitfalls that start to appear especially with SaaS solutions is re-licensing. Re-licensing is very specific to open source software, and the idea is that you've been providing software, and there's the MIT licence, or a very permissive licence, which should not be of any concern to you. You're like, "Okay, I can use it. It does not present any kind of risk." You've been using it for the past three years, and suddenly, the new version, version 4.10, for example, is being re-licensed.

What it means is that instead of being made available under the MIT licence, they say, "Oh, now it's going to be available under the GPL licence." Oh, suddenly, it's a copyleft licence. Oh, there is a concern. But if you're just updating the software, making sure that it's always up to date because you don't want to be subject to any kind of cybersecurity risk, you could update the software and then, suddenly, contaminate your code where you're like, "Oh, there is an issue. We've been providing the software with some open source elements that are being licensed under a new licence and one that we don't want to use."

It's a specific concern. Usually, when they re-license, it's highly advertised. They make posts about it. They need to explain why they re-licensed and people will usually let you know beforehand. Still, it should be an issue because there is always someone somewhere who will just click on the "Update" button without reading any warning or any documentation, and that could be a concern if you don't catch it early enough, I'd say.

If you're using also very different kinds of open source elements and you fuse them together, it can also be an issue because not all open source licences are compatible. A very specific, very complicated discussion, but still a concern, a pitfall to have in mind.

Same goes with the creation of forks. Sometime the creators of a specific open source project will not be friends anymore at some point down the line and you'll have two versions of the same software, or fork, where you'll have version A and version B, which are both based on the same, I'd say, general metrics, but they will offer different features, different positive and negative points. Maybe making sure that you use the correct version is also an issue. Sometimes it's difficult because both present like good options. This is a very specific pitfall, but one that happens more and more, especially if the project is growing bigger and bigger because usually it means integrating more and more people into the development of the core solution.

Like we mentioned, the general idea behind open source is to think about it beforehand, be proactive to prevent serious problems and make sure that you are up to date as to what you're using, how you're using it to prevent the discovery of an issue when there is an audit or due diligence because, otherwise, you can have very difficult consequences—whether it's a transaction being cancelled, lawsuits by your client, customers that leave you, a drop in asset value or even bad press because you have been not meeting the terms of an open source licence. It's a good tool, just be careful with it.

Lisa: If you talk to someone who's thinking about using open source, what would be the key considerations that you would share with companies that are trying to decide whether or not to use open source?

Jules: There are usually four practical things that you can do to minimize the risk or at least make sure that you are up to date as to open source components in your solution. The first one, and usually the biggest one, is to create and establish an open source policy. And it should always be tailored to the reality of your company. It means you need to review what you are currently doing internally with open source. Are developers using it? Is it something that's been prevalent? Are your employees familiar with what it is, what it implies? Or are they just avoiding it because they know that it could be a problem?

If there is any open source component, make sure to audit what is being used. Is it integrated in your proprietary solution? Are they just tools that you are using for internal use? Maybe make aware the different stakeholders within your company that you are creating a policy, and this policy should be easy to read. It should not be something very legal. It should be more practical as to, "We want you to use open source licence, open source components because it's good, it reduces development time, it reduces development costs, but we want to make sure that it does not create a risk. Here are the caveats, the way that you can go forward with it."

One of the ways that you can do it to make sure that it's very easy and very easy to read and easy to use is to create a list of pre-approved licences and say, "Okay, if you use, for example, an MIT licence component, you can go forward. No need to ask permission. If you find this under this licence, be careful. We might need some more information. If you find this under this licence, don't use it. It's a risk for me." The policy is usually the biggest of the work, but once it's done, you usually have a clear picture as to what is being done and what can be done in the future.

After that, there are three kinds of tools that you can use to make sure that you stay up to date. First is to have an approval process in place. Same, approval should be simple, quick, efficient. It can be integrating into the policy, but the main idea is that your policy will probably not cover every kind of possible situation that you might see regarding the open source. Having an approval process in place is to make sure that, okay, if someone has a question, if someone needs an approval, if someone needs to check with the higher-ups, they know how to do it and they know who to ask, pretty much.

The idea is also to create an internal jurisprudence on open source so that if someone says, "Okay, this specific licence with Mozilla. A Mozilla licence, for example, is not mentioned in our policy, but we've been accepting it in the past. Maybe it's okay. I'll just check. It's going to be simple. Just an email to someone with, ‘Hey, can I use this here? Yes? And by the way, we've been accepting it in this other solution that we've been developing.' ‘Okay, sure, you can go forward and we'll take note of it.'"

Having an approval process is to make sure that you are still up to date and remain up to date. And you don't need to have a policy that is, I'd say, 50 pages. That is too long and too complicated to read. The last two are more practical. You should create and maintain an open source registry where you list all of the open source elements and software that you are using, the versions that you are using, where it can be downloaded, whether it's the GitHub registry or if it's a website, and the licence that applies to the specific version that you are using. The goal is to make sure that if, at some point, someone has a question, whether it's during an audit, whether it's during due diligence, and because we want to check and make sure that that everything is clear, that you don't have to go through this entire process of auditing what is being done and making sure that everyone is up to date as to, "Okay, we've been using a lot of open source. Here are the different licences," and that you have an overall picture as to what is being used and maybe sometimes even encourage a developer to use such elements. Because if they see that everyone is using it and they are not, maybe some of them will be like, "Maybe I'm missing out on something."

It's important to have the necessary information because it can also allow you to make sure that, for example, there is no re-licensing. If you knew that, okay, the previous version was under this licence, you double-check and you see, "Oh, the update is actually being re-licensed, maybe we'll stay under the older version or create our own version, who knows."

The final one is very practical. Make sure to update any kind of open source components or software because, when we speak about open source compared to proprietary software, the responsibility to update lies on the user. Very rarely for software, there is not going to be an automated update process. You need to make sure that you're using the latest version. It could be an issue because, otherwise, it could create potential cybersecurity risks or even put your customer at risk if they're using an out-of-date component in the solution you're providing to them. It's also important to make sure that if you hear about a vulnerability, to check immediately if you can be the target of it.

That's why having a complete and maintained registry is important because maybe you will hear about this new library that is very, very dangerous and check and be like, "Oh, we are not using it so no need to worry about that."

Having an updated registry is also the opportunity to make sure that you update your open source components accordingly. If you mark the date in your registry of when you updated something, you can make sure to check in one month and be like, "Okay, we've updated everything each month. Someone has checked." It might also be a good practice to make sure that it's safe to use what you are currently using.

Lisa: Very active and even proactive management of your open source.

Jules: You need to be proactive. It's not as easy as a tool as proprietary software, where you can just install it and forget about it. But as we said, it's also free, so there should be some balance, I'd say.

Lisa: Where can you learn more about open source?

Jules: Good question. Most of the time when people ask me that, I'll say, "There is lots of online resources." Whether they're offered by different organizations promoting the use of open source. We spoke about the open source institution. There is the Free Software Foundation. Whether it's articles, books, conferences, presentations, just general articles. There is lots of stuff available online, whether it's also very general on specific licences. It can be technical, so don't be afraid to ask questions. Most people in the open source community are very friendly and very willing to teach people.

If you are a developer, do not hesitate to contribute. As always, the community is always willing to teach. Most of my dev friends will tell you that it's also a good tool to train yourself or to learn a new skill. As always, be aware of what you find regarding some analysis of specific licences. Most of the stuff that is written about open source is not written by lawyers. Most of the time they are written by either the person who created a specific open source licence or the company or the organization using it for their solution. Sometimes you'll find some FAQs that will tell you, "This is how we interpret the licence."

As always, refer to the licence itself. Sure, keep in mind the FAQs because they will give you insight as to what they tried to do with this licence. Keep in mind that, most of the time, it's not written by a lawyer, so maybe have someone with legal expertise double-check to make sure that it's all right or that it's not an issue. I mentioned the FAQs. They're also a very, very good tool to understand the practicality of open source. Most of the organizations or companies using open source will have some policy or FAQs to explain why they are using it, what is the intended goal. Is it to provide knowledge? Is it to look out for potential recruits? Will we be annoying if you don't mention us in our credits? What needs to be done from a practical standpoint? Because sometimes the licences themselves are not as easy to read, as it is. Finally, if you want maybe to learn more, but it's only in French, sadly, we've given a presentation in 2020 on open source and good practices and it's available online on the ROBIC website.

Lisa: Thank you, Jules, for sharing so much valuable information, both to users of open source, potential users of open source and to creators of open source. It has been a real pleasure. Thanks for sharing your knowledge.

Jules: My pleasure. Happy to share. It's in the open source spirit.

Lisa: Thank you.

Announcer: You've listened to Canadian IP Voices, where we talk intellectual property. In this episode, Jules Gaudin, at the law firm ROBIC, explained what open source software is along with a range of important things to consider if you plan to use it. If you're curious to learn more about the different types of open source licences that are commonly used, visit ChooseALicense.com. Maybe you're thinking about launching your own open source project or want to contribute in the open source community. You will find guides and information at OpenSource.Guide.