Blockchain Webinar Series | How do open source licenses affect your intellectual property rights?

Usman: Okay. So, I'm going to get started because we have quite a lot of ground to cover and usually it takes a few minutes for everyone else to trickle in but that's fine. I wanted to thank all of you for joining our webinar here today. On behalf of Gowling WLG let me welcome you to this really exciting session called 'How do Open Source Licences Affect your Intellectual Property Rights?' My name is Usman Sheikh. I'm the head of our Blockchain and Smart Contract Group at the firm. By way of a little bit of background, our group has really been immersed in Blockchain matters for probably about 4 to 5 years now. We have probably around 30 to 40 practitioners who practice in this space from all different sectors, whether it's IP lawyers like Roch Ripley or capital market experts like Viona, privacy lawyers, litigators and many others. We represent some of the co-founders of Ethereum. We represent banks, stock exchanges, crypto platforms, pioneers, start ups, many, many different parties in this space and our group has really taken it upon itself to do quite a lot of speaking around the world to help educate governments and regulators. So whether it's really addressing the Member States of the IMF, for Monetary Authority of Singapore or assisting our local regulators we've been very, very active in this space. If you would like to learn more about our Blockchain Group, or our Broader Tech Group, feel free to visit our website or feel free to reach out to any of the members here that you see on the screen today. Our contact is also in the invite. Before diving into today's topic I should note that this particular webinar that you're attending today is actually the fifth in a six part series of webinars on some of the hottest topics that we've seen in the Blockchain space. The first session was on crypto asset trading platforms. The second was on non-fungible tokens or what are called NFTs. The third session was on Stablecoins and CBDCs, or what are called Central Bank Digital Currencies. We just had one very recently on DeFi, or what's called Decentralized Finance. Today's session, as you know, is on Open Source and Intellectual Property Rights. We have another session coming up. It's on October 14. Last, but certainly not least, is a session on Blockchain Litigation where we're really going to be covering lot of the key civil, criminal regulatory cases that we've been seeing in the area. So to sign up for these webinars just click on the invite that you received. There's a little bar that you can click on to sign up. You can also send us an email to our webpage and you can also actually access all of these webinars online and if you have any difficulty feel free to reach out to us.

Okay, just a few other quick preliminary things before diving into the substance of today's session, I should note that this program is eligible for up to one hour of substantive CPD credits with the Law Society of Ontario, Law Society of British Columbia and in Quebec and you may also be eligible for one hour of CPD/CLE credits in other jurisdictions. Finally, being lawyers, here is a key disclaimer which is that this presentation is not intended as legal advice. For specific legal advice on issues that are going to be discussed today please contact legal counsel. With all of that background stuff out of the way let's get into the topic itself. To that end, let me begin by making a few introductions. I'm very much honoured to be joined here for today's session on Open Source and IP Rights by our panelists. Let me begin, perhaps, with my colleagues. We have Roch Ripley. He is a partner in our Vancouver office and the head of our Vancouver office's department on intellectual property. I actually work quite closely with Roch on many IP matters in the Blockchain and tax space. We also have Viona Duncan. She is a partner in our Waterloo office and, in fact, is co-Chair of our Global Tax Sector Group. Her practice is primarily transactional with an emphasis on helping Canadian, US and international clients with M&As and debt and equity financings. We also are very, very privileged today to have an external guest who we are thrilled to have with us. We welcome Lesley Boveri. Lesley, I'm pretty sure I pronounced that correct.

Lesley: Yes.

Usman: She is Senior IP counsel for SAP, on of the largest enterprise software companies in the world and the company's Paulo Alto office in California. She practices IP law, focused on internet copyright and open source issues and has worked extensively in matters involving international protection of IP in the computer software area, including working quite closely with development teams on open source licencing matters. Lesley, welcome. It's a privilege to have you.

Lesley: Thank you. It's good to be here.

Usman: So, let's jump into the heart of the matter. Roch, if I can perhaps start off with you, but others feel free to chime in. What is open source and, if you don't mind, while our discussion is quite general today, not specifically focused on Blockchain, can you also just tell us why do we see open source really coming up quite frequently with Blockchain space, in particular?

Roch: Sure, I'd be happy to. We can advance right to this slide. So again, Usman mentioned being lawyers, let's start with a definition. The most common definition of what open source software is, is one that's promulgated by the open source initiative. Without delving too deeply into legal language, open source software is basically software that you, or more particularly your employees or contractors, can download off the internet and use in your business subject to the terms and conditions, the open source licence, that's published with the software and that governs how you're allowed to use it. So in the open source context, these terms and conditions usually include the requirement that the open source code be freely redistributed. Not necessarily freely in the sense that you can't charge anything for the redistribution but in the sense that you can't legally tie someone's hands with respect to the redistribution, making available of source code and a requirement to permit modification or the creation of what are typically referred to as derivative works. With all that being said there are, I'll say, countless open source licences. So you always have to be careful to read the terms of a particular licence you may be agreeing to. In terms of Blockchain in particular, I mean Blockchain, of course the nature of Blockchain is that it is a distributed ledger. It's not centralized so when you're mining Bitcoin, when you're adding new blocks to a more general Blockchain, all that computational activity is being done by different people, independently. One of the things about open source licences is that these requirements I just talked to, for example the requirement to make your source code available, a lot of time, not always but a lot of times, those requirements kick in when you distribute or redistribute the software. So in Blockchain when you're taking software and you have to, by definition, distribute it to a whole bunch of different people who are running their own nodes, that act of distribution will trigger a lot of the requirements that you find in the open source licences.

Usman: Well that's really interesting. You talked about downloading this software so why would a company use open source? You mentioned licences. What type of licences are out there?

Roch: So the reason to use open source, there are a few. The one that's most common is that you don't need to reinvent the wheel. If someone has created a great product, they've made it available online, and you can download it with what hopefully are reasonable terms and you can use it commercially in your business, why not do it and focus on the part of your business that it's going to generate value. Your proprietary code that is going to generate a lot of revenue for you. That's the inbound answer. Inbound being you take open source software from the internet and you download it to your own computer or business. In the context of Blockchain, in particular, where there is a very strong open source community and there's a very strong emphasis on security, I think it's also important to talk about outbound licencing. So the software you create, in house, and that you want to share with the open source community, it can be important for credibility. For security it can be important because you want other people to be able to analyze your code and to make sure that it in fact, mathematically, is as secure as you say it is which can help increase adoption. The slide says right here that it can also help drive competition in the market which can be very good. Your business model as well may not necessarily be to keep the source code proprietary and to make money by selling the code. It may be you want to keep as many people as possible using your code and then you have a services model where you offer services to support that code. So by making your code publicly available, and licencing it outbound, you can increase revenue that way. Just may be a different type of revenue than a software company might be traditionally used to.

Usman: So maybe we'll just pause there before going into what type of licences. Lesley, maybe you want to speak to some trends that you've seen around this topic as well.

Lesley: Sure. There's the slide. This is actually a slide that one of my colleagues at SAP put together for some of our internal training. This data doesn't have a date on it but I think it's from 2019 because I just looked yesterday and there are now over 128 million repositories on GitHub. So the adoption of open source is accelerating. It's becoming common place. It's not longer an esoteric area. It's actually very rare that you would encounter any software products today that don't include at least some open source components. The open source is typically directed towards features that are more commoditized. Like Roch was mentioning earlier, this might be open source, the basic features of a software program might be open sourced and then you might keep some of the more advance, or complicated features, proprietary and build on top of that open source to give yourself a competitive advantage. There are open source projects directed to lots of cutting edge technologies today. Not just Blockchain. Cloud, AI and other projects. But since this is a Blockchain published webinar it's worth mentioning that Hyperledger is an open source project now governed by the Linux Foundation, which is a free open source platform that offers a lot of tools and frameworks for developers to create inter-price focused Blockchain solutions. I did a search for the keyword 'Blockchain' on GitHub and it came up with about 100 thousand repository results. Most of these are forks from either Hyperledger or Ethereum or other popular Blockchain platforms but there is a lot of activity there. Open source has changed. For example, back in I don't remember what year, I think it was like 2001, Steve Ballmer who was CEO of Microsoft said that Linux is a cancer and that no intellectual property can be protected with open source. Then Microsoft open sourced their .net platform in 2014. Then they bought GitHub in 2018. So things have completely turned around and the main reason for that is that no one company can effectively compete with the open source ecosystem. That's basically it for that.

Usman: Why is that? Why do you say that no one company can compete with open source?

Lesley: Because the advances that are happening in open source are, like the Linux operating system is updated about 9 times an hour, on average. There's not a company with enough resources to be able to keep up with that pace. Because there are people all over the world with different interests advancing the different open source projects. There's the paces not sustainable within a company.

Usman: Interesting. So maybe, Roch, if I can go back to you. Can you maybe speak to the type of licences that exist in relation to open source? Maybe you can ... through the slides.

Roch: Sure, yeah. So as the slide says, at a high level there are really two kinds of licences. You have permissive licences and you have restrictive, also known as copyleft licences. So if we could advance to the next slide. The permissive licences are, as you think they would be, they allow you or they permit you to freely amend, adapt, combine, basically do what you want with the open source code, even integrate it with your proprietary code and create a commercial product. A lot of times the requirements are pretty straightforward. They usually only require that any distribution of the originally open source software be on the same open source terms that it was received in. So what you'll see a lot of times, for example, if you have a permissive licence you go onto your phone, you go into the about field and you see the open source disclaimer which has all the various kinds of licences that are there. You'll see that one of the requirements is that it says we're using this piece of open source software. Here's the very short permissive licence that says we're basically allowed to do whatever we want with it subject to, of course, making it known that we're using the software and including this attribution notice in the product. You've got a lot of freedom. You've got to provide notice. You've got to provide attribution but they are designed to be compatible with a proprietary licence. That's in contrast to the other kind of licence I mentioned, the restrictive or copyleft licences. Those tend to be the general public licence, the GPL, which is a very popular kind of open source licence which we'll talk about more, or variants of it. There the biggest restriction is that if you, using the GPL again as an example, if you created derivative work on the GPL. So for example if you take the piece of open source code that you have that is GPL licenced, and you modify that and you want to keep your modifications proprietary but at the same time you want to be able to distribute copies of your software to your customers, you're not going to be able to do that. The GPL says if you modify that piece of open source software and you distribute that software to your customers you've got to make your own modifications public. You have to be able to let your customers download that source code. Which of course is a problem if your business model is predicated on keeping that source code secret. I'll mention here as well that the GPL, all of these licences, the GPL as well, they're quite old so they were created at a time when software commercialization business models were different. It used to be that everybody distributed their software. But of course that's not necessarily the case anymore. You have a lot of web services now. Software is a service. It's a huge business model. The GPL actually doesn't cover situations where you're not distributing the software. So if you've got open source that you're using entirely in internally, and you're making the functionality available to people outside your organization like your customers, the GPL won't require you to distribute that software but a separate class of licences, the most prominent of which is called the AGPL, will. You've got licences which are restrictive which require you to make available source code that is derived from, or combined with, code that is licenced under the GPL and that requirement can kick in when you distribute the software in a conventional, I'll call it, business model under the GPL. But it can also kick in under a new class of licences like the AGPL if you're just making that functionality available online.

Usman: Okay. I think we have another slide.

Roch: Yeah, if we could go to the next slide there is an example list of licences here. We can go through them fairly quickly.

Usman: There some technical difficulties so just while we're waiting for that slide to come up, Lesley, did you have anything to add to the licences at all?

Lesley: Yes. I just wanted to mention one thing. So like Roch mentioned, sometimes it's impossible to comply with the GPL because you don't want to disclose your own proprietary source code. Permissive licences are very easy to comply with. Basically most of them just require you to redistribute the licence and provide notice, reproduce the copyright statements. But you do still have to comply with them and where a lot of companies get in trouble is they say, "Oh it's a permissive licence. I can use it for whatever I want. Great. I'm using it. That's it." If you don't provide those notices, which is easy to do, but if you don't provide those notices you're not in compliance with the licence and that has tripped some people up because if you're not in compliance with the licence, you could actually be held to not have a contract at all and then you bring up the specter of copyright infringement. Or, even if it doesn't go into a legal dispute, the reputational damage is hard to quantify because people don't want to be seen as bad actors in the open source community. That kind of reputation will follow a person or a company around. If you disregard, or disrespect as some people call it, intellectual property rights.

Usman: Okay. While we're just waiting for this slide to come back on, Roch, if I can maybe push forward on the question. So what are some of the risks when using open source software? And perhaps, if you can also just speak to the best practices, and then I'll turn to Lesley and others, and Viona as well, on that point.

Roch: Sure. I think the biggest risk is with the restrictive licences. Where, if you have a code that is proprietary and you are wanting to keep it secret, and you inadvertently get it licenced under a restrictive licence like a GPL. So you modify GPL licenced code and without wanting your proprietary code to be governed by the GPL, and that arises for example in litigation or in due diligence or something like that, so it's the inadvertent requirement to make your source code publicly available. One thing I'll note here is that we've talked about the permissive licences, we've talked about two kinds of restrictive licences, the GPL and the AGPL, I'll add a third GPL variant which is also very common, it's called the LGPL. The lesser GPL and that is used, in particular, for libraries. So the position of the people who have authored the GPL is that if you have a software library, which is basically a software module that is used to implement a certain type of functionality and you want to distribute that, under the GPL the position of the Free Software Foundation, which are the people who wrote the licence, is that regardless of how you integrate that library's functionality with your main body of code, that's called linking. You can link either before you distribute, which is called static linking, or you can link after you distribute, which is called dynamic linking. Their position is regardless of how you link, if you do that linking, you're entire code base that links with the GPL code is governed by the GPL. Which I think they found is a disincentive to using the GPL in a lot of situations. So the LGPL is a licence that actually permits you to licence the library just under GPL terms. So if you modify the library then you've got to make your modifications to the library publicly available, but you can link to that LGPL licenced library without having to make your entire code base publicly available. I do want to mention that third kind of licence because it is a restrictive licence, as we show on the slide, but it is a restrictive licence that I think is fairly widely used because it can be used in a way that makes commercial sense for a lot of clients.

Usman: Okay. So we have the list of licences up so I think our slides are now back up and running. So, maybe if we move to the next slide to slide them up, and this was really the risk that we're talking about. Roch, I don't know if you wanted to speak to any other part of that before moving onto the best practices.

Roch: Sure. I think Lesley's mentioned a couple of these. I have as well. The biggest one in my view is that second one, allowing competitors to gain access to proprietary source code, which I just talked about. As Lesley mentioned, another big one, is reputational damage and business continuity issues. She's also mentioned contract and copyright infringement, because even if it's very easy to comply with a licence, easy doesn't mean you don't have to comply. It means you still have to comply and if you don't, even if it's a permissive licence, you could end up in a place where you're liable for breach of contract or copyright infringement. Which again, as Viona will talk about, can be problematic, particularly during an M&A context. All of this of course goes to the customer, goes to the client. It can all be prejudicial to new customer relationships because you never want to go to a customer and say, "The product that we have given you is not what we thought it was." That's a bad story.

Usman: Okay. We're going to come to M&A in a second but, Lesley, I don't know if you had anything to add further on those ones.

Lesley: Just one point. A lot of this stuff, like Roch mentioned, it's easy to comply with some of the licence. You want to do your analysis before you release the software. But what trips up a lot of companies is that your initial analysis says, "I'm just going to use this piece of LGPL code, internally. We're not going to put this in the product. It's fine." So they start using it. Then they find a use for it in a product, and since it's already been approved and you used it in the company, the developer think it's fine to use. So the use case is extremely important to whether or not a piece of code under a particular licence is a good idea or not. One thing for companies to keep in mind when you're implementing an open source policy in your procedures is that just because a piece of code is okay for one scenario does not mean that it's okay for every scenario. The analysis needs to be done a very use case specific basis.

Usman: Okay. So, Roch, you had mentioned M&As so let's discuss M&A transactions. I'm going to pick on Viona a little bit here as our transactional lawyer. How do open source issues affect or play into an M&A transaction?

Viona: Thanks, Usman. M&A transactions have a lot of different components and pieces to them and one of things I find, when issues pop up, one of the things that happens is that there's significant delay. With open source, open source issues are fairly complicated and more often than not they may pop up on a disclosure schedule. You may be made aware of them during the due diligence phase, and so during the diligence phase, there's all these requests for information that go to the target company. Often with open source, and this is maybe not large companies like Lesley's SAP because they know what they're doing and have a lot of experience in that, but a lot of companies that haven't gone through the M&A process they get these requests and now is when they have to go talk to the CTO or a developer to figure out do we use open source? How do we use it? When do we use it? So the information that comes back to a buyer, in many cases, is information that they see and it's incomplete or it's not listing specific versions, as Roch showed on the previous screen. Different versions of the same type of open source have different implications. So often when that information is not forthcoming it causes a delay, and I can say I've seen a number of transactions over my years of practice where something has come up in the diligence process, it's led the buyer to say, "We're not comfortable. We don't know, or they don't know exactly what they're using it or how they're using it, so even though our target date was X we now need to slow down and figure this out." Because as Roch indicated, it could have significant implications. Whether it's allowing competitors to gain access to proprietary code or otherwise so significant delay in signing or closing are one of the big issues that we face. As well I found that when issues like this pop up the buyer tends to slow down, not just on these issues, but sort of slow down and look more closely under the sheets on a number of other issues because if they found one they're concerned that there may be others. That leads to significant delay among the parties. It also changes, in many cases, the deal economics or how you balance liability on a transaction. I can think of a few deals where we had issues with open source that came up and so now, instead of focusing sort of on the transaction and moving that along, we sort of pens down on the transaction. Had to work through what is the cost to fix the issue? Is the issue fixable at all? How long is that going to take? Then what does that mean for how they price the deal as a buyer? They're also trying to look at is there past non-compliance? Are there compliance issues, or lack of compliance, that's occurred due to how they're using the open source? All of those issues, liability and changing deal economics, those are big deals. Those are big items and then, as well, when you put all those together buyer's saying, "What else don't I know?" and depending on how significant, or how the open source has been used in a company's product or technology, in some cases it could kill the deal. Either because the buyer doesn't want to take the time to review it, do a deep dive, try to estimate cost and remediation and as such the uncertainty is enough for the buyer to say, "You know what? We're just going to move on. We don't want to take the risk." It depends on the risk profile of the buyer, and how badly they want the transaction, but we've also seen that happen when we look at open source and how a target has used it.

Usman: So, what then are some of the ways in M&A transactions to address issues relating to open source you might recommend?

Viona: There's a number of different ways that you can address open source issues. When I note representations and warranties, that's less a fix or an issue, but it's about understanding. If I know in diligence that there is a concern, potentially a risk, I'm going to take a closer look as a buyer and make sure I provide more detailed representations and warranties and ask for more detailed scheduling of open source; how it's used, what versions, how it's incorporated, very detailed information that I'm going to be looking to call out in order to understand specifically my risk. Then, once you see all that information, you then have to assess what all that information's telling you and then, in a number of cases, it results in remediation covenants. If you're signing the transaction now, in some cases those covenants are pre-closing and conditions prior to closing. You may extend the period between signing a transaction and closing a transaction and as a buyer you say, "If we can't remediate all of these items we're not required to close at that later date that's been determined." I have seen a transaction where that remediation process took double the time, which Lesley will speak to this a little bit later, but took way more time than anyone ever anticipated, in terms of actually fixing it. The people doing the transaction often underestimate the actual time it takes for the business itself to fix some of these issues or try to address what the issues the open source has caused. So we do put in conditions about specific items that need to be fixed, when they need to fixed, how they need to be fixed and a time period. As well we've addressed it with specific indemnity. Meaning that the sellers will have to make buyer whole to the extent there's claims, etcetera, related to a breach of open source or there a competitor's been provided access to proprietary code and that risk, we have an indemnity for that. That being said, I will say that an indemnity is only as good as, you can put it in writing and you can put it in agreement, but you have to know that that's a solid indemnity and you have the ability to collect on it. So you also have to sort of examine the deal structure, who the sellers are, and so there's a lot of time spent reworking and adding in the specific indemnity so that you know that you can collect. Usually, and in many cases, had indemnities backed up by an escrow. An escrow is money that's not paid on closing. So if you had a deal where you were going to pay X%25 of the purchase price up front, and one year out you were going to pay another percentage, or after 60 days, 90 days, that you would pay another amount, or there's an adjustment process, this escrow would be held for a certain period of time, and usually a longer period of time, to make sure that remediations possible. To make sure that there's no loss of valuable IP rights. That a competitor isn't out there using proprietary source code and so that adds risk for the sellers and it gives the buyer some protection. But the time the buyer has had to take to decide if that's an appropriate fix usually requires them to have gone in and done a pretty deep audit of the code, etcetera, and the licences that are being used.

Usman: Okay. I'd appreciate perhaps all panelists comment on this but Viona we'll start with you. From a deal perspective what are some best practices that they should have on the front end to address some of those issues that you've identified relating to open source?

Viona: The best process is to, and Roch's outlined a little bit of it already, but if you're going to use open source you need to have a policy. Whether it's part of your IP policy or whether it's a specific open source policy, where you understand as an organization, do you need specific approvals for use of open source? Who has the ability to approve that? Is it your CTO or is it the CEO or is it the board? Who gets to decide how open source is being used when it's being used? It's also a process, and a specific process that's laid out for your IP team about recordal of licence versions. Making sure you know when it's used; that's it's been approved; that you know the version you're using and I'm going to tell you, as a buyer when you're dealing with a transaction, that might be something when you ask for that in diligence. It says a lot about an organization and the process and legal process they have in place and the governance if, when you ask do you use open source? That's great, but can you show me your IP policy or your open source policy and the company doesn't have one. Sometimes that's telling for a buyer in terms of what additional work and investigation should they be doing to get some comfort level. I can think about a transaction I did a couple of years ago where we did have an open source issue. Open source was used. Top management didn't know what open source was used, who was using it. There was no process or protocol in terms of how it was done and it was pretty significant in terms of trying to determine that and go back and try to sort through it and then also try to dig up old open source licences and trying to figure out which versions were used. It was timely and it ended up being costly. The other thing is periodic scans, audits and these are things that whether or not you're gearing up for M&A, it's easier done if it's just done as part of your regular process. Then when and if you do an M&A transaction you've already got all this ready and in place. I would also suggest that ensure that your contract contain provisions to provide appropriate protection. So if you're licencing from other parties, different inbound, understand what is they're using and have appropriate protection to protect you in the event that they've included open source and now you're using that as well. Then I would say to the extent there are red flags, problems, I always say to people address them now. Don't wait for an M&A transaction. But also, if they come out as you're preparing for an M&A transaction, address them and you also have to be transparent about it because these things can go to the heart of a transaction, and if you don't sort of address them up front or understand what you have, as I said earlier they tend to kill deals.

Usman: Okay.

Viona: I was going to say I know Lesley probably has some stories or thoughts to add on this.

Lesley: Yes. I agree with everything you just said, Viona, and just a couple of additional things. The due diligence question, which is always asked, what open source do you use? If the company being acquired, because I'm always on the buyer side, if the company being acquired comes back with the answer, "Oh, we don't use any open source." that is a huge red flag. Which means you're going to be investigated very deeply because it kind of indicates that you don't know what's happening in your development. The importance of scanning. We use Black Duck internally. I think a lot of big companies do. Maybe even some small companies today. But Black Duck and there are others out there, I think actually there are some open source products that scan for open source components, that will tell you what you have, and being prepared and having a good answer to the question of what open source are you using, will do a lot to advance a deal. The other thing is, it's not just in the context to M&A. We get this question from customers. Customers are starting to become more interested in what open source we are using for a variety of reasons. They don't want to have their own code that they run on top of our code be infected. So it's kind of in the supply chain. You want to check the code that you're using on the end out basis and if you're supplying a product that others build on top of they're going to check you out. It also is a back to the community. There are a lot of open source enthusiasts out there who really want to see compliance with licences, and think that the notices are very important, and they will do investigations on their own to find out whether or not someone is using their code and not providing the appropriate attributions.

Usman: Okay. Roch, anything from you or should we push on?

Roch: Yeah, maybe a couple of points I think just to echo and sort of delve or add to what Lesley and Viona have said, which I agree with completely. I think an open source policy is important. I think it's important that it be practical and realistic because you might have a policy that says just don't use open source, and then maybe in a deal you say we don't use any open source, but I'll bet you have open source. One of the coders who was against a deadline and knew the solution was out there and thought everything was fine, just unilaterally made the decision to download that software and incorporate it in your product, because they didn't think that the policy was realistic and practical. I think it's a situation where you want a workable and practical policy so that you can manage that risk and reap the benefits and maintain your credibility in a transaction. I really do think in this field credibility is really, really important. Like Lesley just mentioned, there is a very fervent open source community, and a lot of times there is disagreement between what the open source community thinks the open source licences say and what, I would respectfully submit as a lawyer, the open source licences actually say. There's not a ton of litigation with published decisions in the area where you can point to black letter law and say I'm right or you're right, or I'm wrong or your wrong, because a lot of these cases, when they do arise, they settle. So you don't get that guidance. If you don't have the guidance and you have maybe a disagreement between what someone in the community says, and what you're saying in a deal, credibility is key. I think you really do want to stay on top of things and, of course, maintain your credibility for every transaction. For a ton of reasons but this is one of the reasons. For best practices, the only other thing I'll add is I think it's a best practice to keep the open source software you use in its directory or repository and just wink to it. If you have a permissive licence, and you're complying with a licence providing attribution, legally you wouldn't have to link to it. You could copy and paste the code and put it in your code base. I just don't think it's a best practice because if something goes wrong, if you make a mistake, you're going to be in a better position if you've got a completely modularized piece of software where the open source software is not literally copying and pasting your code. You've linked to it. You can maybe replace it with a different piece of modular code. You might have an argument that by virtue of the linking that you haven't arrived at a place where you're governed by the open source licence. You've just got a better back up position.

Usman: Okay.

Viona: An easier remediation for sure.

Roch: Yup.

Lesley: Yeah. For sure, yeah.

Usman: So we now know what open source is. We have discussed how it affects transactions. I wanted to focus on how to manage open source once the deal is done and Lesley, in particular, I'd appreciate your thoughts on this. From your perspective what should a company do to mitigate the risk associated with using open source code and how can it put itself in a better position for due diligence?

Lesley: We've talked about a lot of this already so I'll go through it rather quickly because I know that we want to leave a little bit of time for questions at the end. A policy is important. The policy should include enough detail to allow employees who are following the policy to know what they can and cannot do. It should have management buy-in so that it can be enforced if needed. It should be clear that so others in the context of a transaction can understand what the company is doing with open source. In addition to employees, it should be understood and followed by third party software suppliers, the inbound thing that Roch mentioned a few minutes ago. Service providers, contractors, others who will be touching the code. It should have training, in a perfect world. Training is a good practice because it allows the employees to understand the risk associated with using open source and their obligations. It allows employees to identify the key issues in open source licences. Another important component of the policy is that it should identify the personnel responsible for managing open source within the company. At SAP this is done by what we call the Open Source Program Office which is something that is starting to get more traction. A lot of companies are starting to have an entire Open Source Program Office rather than just one person who's responsible for it. But in a smaller company it might make sense for the Chief Technical Officer or some other designated individual to have responsibility for open source. At SAP, the OSPO office is about, I think, 10 people and they're responsible for everything that touches open source that's internal. How we use it, how we contribute it to other projects, how we talk about in the public in our community relationships. So one of the big things in our policy is how we contribute to open source projects, which brings up a topic I wanted to talk about a little bit, which is why would anyone contribute to open source projects? You're just giving away your IP, right? Can you go to the next slide? There are actually a number of reasons why a company might want to participate in these projects and contribute code. It's really a donation of code because you're giving it to them for free. I think we've mentioned many of these before. It is really code for encouraging wide adoption of technology. If you get a platform out there and you want to get platform adoption, or create a de facto standard for a large user base, this is probably the reasoning behind a lot of the Blockchain projects. At SAP we do it a lot because we want to collaborate with our customers and partners. There's a lot of software that interacts with our software and in order to create those integrations we make some of our code available under open source projects so that customers and partners can develop these integrations and integrate ... software with other software. Obviously it can build goodwill and reputation within the open source community. One thing that hasn't been mentioned yet, but is actually a pretty big reason to participate, is that the, I want to say kids, it's not kids, young developers coming out of universities are very active in the open source community. If you want to attract and retain this talent, being active in the open source community can really help you, attract and retain this talent. For your existing employees it can facilitate improving development skills for those who participate in open source communities. Being able to show that you are an active participate in open source communities can go a long way. If you can go to the next slide?

I just want to say a few words about what SAP is doing. Just kind of promote our open source activities and also say a few words about how this can be applicable anywhere. One part of our strategy is to support the technology that we rely upon. These are all projects that we use internally. Either in our products or for internal development processes. One thing we do, and I would encourage anyone to do, is to contribute any bug fixes up the stream. This is a best practice, not only because it's good community behaviour, but if you don't do this you could be considered a free rider which would be a bad reputation, but if do fix the bugs in the project it actually helps yourself because you will have access to that contribution, that bug fix, in the future. If you don't contribute it back to the community, next time you download an updated version, you'll just have to fix that bug again. Once you fix it upstream you don't have to deal with that bug again and everyone benefits. As I mentioned earlier, Linux Foundation governs Hyperledger. Hyperledger is an umbrella project that includes several sub-projects such as Hyperledger Fabric and others. The other reason to contribute to these projects is that we want to influence the direction. If we think that certain functionality needs to be developed by the community, by being an active participant and actually contributing code, we can better influence the direction the projects are taking. If you contribute the time you can dictate the future of a project in many cases. If you can move to the next slide?

Usman: Just on that last bit, Lesley, it appeared to me, because our logo was there, I thought you were using our code or something from our firm.

Lesley: <laughter>

Usman: <laughter>

Lesley: Don't know how that logo got on there.

Usman: Go ahead.

Lesley: SAP also created our own projects. Not only do we contribute to the Linux Foundation and other projects but we have created our own. Some of these are issue employments or to get adoption of SAP products like the OpenU15 project is used to integrate with SAP products. Some of them are more just general security research. We've created some projects that are just directed towards cyber security issues in general. Not really directed to a SAP product. Then if you move to the next slide, just a few final words about what do we think about? We don't just allow employees to go out and start contributing whatever they want because you would soon have your proprietary code out in the open source community. We actually have an approval process so that development teams, or even individual employees, when they want to make contributions they go through the process. In general, if it's a bug fix and an upstream project, that's approved. That's just kind of standard practice but in other cases we look at some different factors that are shown here. First we sometimes have to consider whether or not we have the sufficient IP ownership to actually donate the code. We have to make sure it was written by SAP employees or if it was written by a contractor that we have the rights to licence it out in this way. In those cases we might have to check the agreement with the contractor to ensure that they have given us sufficient IP rights to do this kind of licence. As Roch mentioned earlier, we want to make sure that there is no unintentional disclosure of confidential information. This frequently comes up in terms of proprietary APIs. If we want to keep an API proprietary we take special care not to release code that might disclose what the API is. If it's an open API that's really not an issue. There are a couple of other issues which are really beyond the scope of today's talk but all the open source licences will grant a patent licence. Some of them make it explicit. So we have to consider the impact on the patent portfolio which could be a whole hour in and of itself. There could be export control obligations that the code contains encryption. We want to make sure that we're putting the code, if we put it on a third party's website, that it is a repository that doesn't violate any of our internal development standards. That is basically it for contributing. In terms of other best practices, we do do a lot of training and the training can be directed towards developer, a deep dive into our processes and then we also have some more higher level training which is just for product people, our support people, just so they are aware of SAP's involvement in the community and what open source is at a higher level. So I think training is an important component if you have the resources for it. Then otherwise it's back to the policy and the procedures on how to manage open source.

Usman: Okay. That's terrific. I've asked everyone if they have questions that they liked to ask and if the panel was still free to use the Q&A function, I saw that we had one pop up, but that's been answered. So feel free to use that function. I'll just see if there's any right now. Maybe just while we're waiting for any final questions, Roch, do you have any comments on that? Or any other thoughts on where the future is head with open source and IP rights or other best practices that you wanted to share?

Roch: I will echo what Lesley said in terms of recruitment and talent. I mean particularly in this labour market. I hear time and time again from clients about the, of course the importance, but also how difficult it is to recruit top tier talent right now and how competitive it is. Being able to give back via open source, and maybe even more generally along the same line, publishing results of research which is an open source in code but a different kind of open source, really. That kind of policy and procedure where you can give back and help your employees and coders increase their credibility, that can be a really important piece for talent acquisition and retention.

Usman: Okay. Go head, Viona.

Viona: I would say the same. The collaboration is and sort of that feeling of innovation and collaboration is sort of key right now, to Roch's point for recruitment and to keep people motivated. The other piece I would say is what goes along with that and I would really echo Lesley's point about the training. Policies are fantastic and setting processes are fantastic but it's about training and consistent training as well, in terms of how do you do this and what do we expect? I think as an organization a lot of organizations implement policy without the training to go along with them. Or there's the view that there's a data base somewhere that all the policies are listed but no one actually ever reads or reviews them. I think that training and process, sort of on a continual basis, I think that's critical and it will help prevent errors in many cases, to Roch's point about hey, I'm rushed on a project. I have to download something and there's a policy, maybe, but I haven't looked at it. I think a lot of the unknown and errors in open source come just from a lack of understanding about the implications and the risk profile and the rest of the organization are trying to prevent against.

Usman: Okay. Two questions have popped up which one is a simple one and then one I'll turn to the panelists. The first question that has come up a few times is, will this package of materials be made available afterwards? Yes, it will. We will be sending it out. So thanks for that question. The second question is from one of the attendees, or the audience members, who says how common is it that a OSS licences also restrict users from protecting their OSS solution with other forms of IP rights which would still enable them to comply within an open source code? I'm not sure who would like to handle that. Roch, maybe I could turn it over to you?

Roch: Sure. So there are three IP rights that can apply to software. Copyright, which prevents copying, generally. You can also keep it confidential. So that's if you want to keep your software a trade secret and then as Lesley mentioned earlier, you can also patent software, sometimes. If you're going to open source your software, trade secret is irrelevant. You're not going to keep it secret. The only other right would be the patent right and I think as Lesley mentioned, other implicitly or explicitly, when you're open sourcing your software you're giving people a licence to use that software, including if it's covered by a patent. It's not so much, I think, that an OSS licence would prevent you from patenting certain functionality, necessarily, but it could very well prevent, I think it would prevent you, from enforcing that patent against someone who has licenced the software from you under an OSS licence. Lesley, I don't know if you want to add anything?

Lesley: Yes. If you think about it, it wouldn't really make sense if a company could make there code available under an open source licence and then sue, later, over patent infringement for using that code. I think it's pretty subtle that there is an implied licence. What is not subtle is the scope of their licence. While you may have a patent on a particular set of functionality, there may be multiple ways to implement that functionality. The scope of the patent licence provided by the open source licence has never been litigated, as far as I know, and you just have to think about it in terms of what is fair. If a company makes some code open source I don't think they could later sue for patent infringement for someone using that code. They could sue someone for patent infringement if someone developed code on their own that implemented the patented, the claimed functionality, but I don't know if that has actually happened yet or not. Roch, do you see many litigation in this area?

Roch: For this particular issue, no. The other reason you might want a patent is if there's a breach of your licence and you want to enforce. Then you could do it. I think the short answer is, which Lesley put more elegantly than me, you can protect your software in various IP rights but if someone's validly licenced under the OSS licence don't count on enforcing any of those other rights.

Lesley: Yeah. So see you still have a patent. That patent is still valid. It just may not be a enforceable as much as you would like it to be.

Usman: Okay. Well, excellent question. Thanks Roch and Lesley for those answers. We're not at the hour. We're just a few minutes over so why don't we end things there. I want to thank all of you in the audience for joining. It was a fascinating discussion. I want to thank our speakers, Roch, Viona, thank you so much. Special thank you to Lesley for joining us on our panel here today. I want to remind everyone that we're having our final session in this webinar series on October 14 on Blockchain Litigation. We hope to see you there and have a terrific rest of your day. Thanks a lot.

Lesley: Thank you.

Roch: Thank you.

Viona: Thank you.