May 7, 2018
The use of open source software (OSS) — where the source code is made available under an open source licence — has become ubiquitous across many industries, especially for companies operating in the tech sector. But the use of OSS comes with a set of risks that businesses, including emerging and high growth companies, must understand.
Because protecting source codes is a key concern for many emerging and high growth companies — including in the context of strategic acquisitions — complying with open source licences and having robust policies and procedures in place is crucial in guarding against unintended consequences, such as the loss of rights to use the OSS software and monetary damages. This presentation by Sam Ip, an associate in Osler’s Technology Group, details key considerations for emerging and high growth companies regarding OSS. Available in both webinar and PowerPoint format, the goal of this presentation is to help you navigate the following issues:
- definition of OSS and trends
- associated risks and consequences of non-compliance
- risks of using OSS in the context of a strategic acquisition
- types of open source licences including “permissive” and “copyleft” licences
- practical strategies to mitigate risks of using OSS
- creating and maintaining inventory of open source usage
- cautious use of copyleft licences in distributed software
- governance strategy and policy
- Osler’s Open Source Licence Identification Tool
Transcript
For more information, contact Sam Ip, associate in Osler’s Technology Group, at sip@osler.com or 416.862.5955.
This presentation is part of Osler’s Emerging and High Growth Companies 101 series, designed to help emerging ventures navigate through the various issues and legal requirements they will encounter throughout their growth cycle.
Video transcript
PRESENTER: So I'm glad to be here. Open Source is a topic that I've got a passionate interest in. When I was at Blackberry, I was there for five years. And part of my role there was, in corporate development, to acquire and evaluate start-ups.
And one of the common themes, as you can imagine, for tech company like BlackBerry is a lot of companies we buy use Open Source software. And so it was just a common theme. And so there was a lot of risks that we learned along the way. And so I wanted to share some of those with you guys today.
But before we get into the presentation, I just want to get a sense of the audience here. Who's actually never heard of Open Source software? OK, and who is a software developer, whether in this life or past life? Because we've got a couple. That's fantastic. And who works with Open Source software, whether as a tool or as-- OK, you're fantastic.
So with Open Source software, let's start with why it matters. Almost every company uses Open Source software today, especially tech companies. But the problem with Open Source software is that most companies actually don't know what Open Source software they use. And unfortunately, they just don't find out until an acquisition situation or some scenario where someone is doing diligence on the company.
And all of a sudden, they realize, hey, use of Open Source software while it's free. It doesn't come without its risks. And principally, for a lot of the clients that we work with in the emerging space, your source code-- that that's your treasure. That's your secret sauce. That's your code. You've got to protect that.
And some of these unintended consequences with use of Open Source software will, potentially, require you to disclose and give away the very thing you've been working on. That is principally, by far, the common risk that our clients face.
There's other risk, as well, that comes along with it. You could be required to give away patent rights, if you own patent. Or, you could lose the right to use your Open Source software. And in many cases, a lot of times, when our clients build software, it's not from scratch. And that Open Source piece is actually a critical piece of their entire solution working. And so when you have this critical piece, that you no longer have the rights to use, it could be expensive to remediate.
But I really think there's an opportunity for really savvy companies to really get ahead of some of these challenges. And so there's really three things that I'd really like to talk about. And I just encourage, if you have questions, let's keep a dynamic, interactive. Let's ask. And I've got questions for you guys as well. Really, four things-- go ahead, there's a question at the back, OK.
We'll talk a little bit of Open Source software-- some of the risks, but not just in the abstract. Let's frame it. Let's frame it from the example of your company that's going to get acquired. Let's talk about risks in a scenario setting. And then let's talk about some practical things that we can take away. And then we'll show you a tool that we've developed that can help mitigate some of these risks.
So Open Source software-- in one sentence, Open Source software is software with a source code-- the recipe, is made available under an open source license. License is just a fancy word for the right to use something.
So the way I think about Open Source software, it's like you got a restaurant, not only do you get the meal, you also get the recipe with it. And the recipe allows you to recreate it. You can modify it. You can adapt it. And that, in a nutshell, is Open Source software.
AUDIENCE: Is it about an [INAUDIBLE] definition to object libraries as well, not just source code?
PRESENTER: Yes, and so some people call it open licenses. And so, you take up the source. This might not always be code. Sometimes, these licenses apply to even bodies of text. It could apply to design documents. That's a very valid question. It could apply to object code as well, yeah.
But we'll touch on that in a little bit. But that's very good point. Examples-- Firefox, Mozilla.
So where do you get Open Source? You get Open-- is that a question. OK, yeah.
[INTERPOSING VOICES]
AUDIENCE: Wouldn't that also depend if you have the commercial open source license?
PRESENTER: So that's right. So I don't distinguish between a commercial and non-commercial at this point. Open Source is just any license, where source code is made available. [INAUDIBLE] Microsoft has, what you would refer to as commercial open source licenses. Microsoft authored it. And in it itself, it's Microsoft's way of giving away source code that has very similar-- it operates in very similar ways that we'll talk about. But that's a valid point.
Where do you get Open Source? The most common way is people Google. They go Google online on the internet, an they find Open Source. And it's often free. In the way that we look at Open Source, and it really helps us understand why Open Source is drafted the way it is. So understand why someone would make it free.
And so Open Source is really about a movement. That's really about the idea that software should be free, not in the sense that you and I think about free. It's not that it doesn't cost anything. But it's free in a sense that it's free from restrictions. That's the ethos of the Open Source movement.
It's the fact that without restrictions, I can study the source code, I can modify it. I can do what I want with it. That's what we mean by free. In order for Open Source to be free, in order to do those very things with it, often, it's the case that you need the source code.
You need to design. You need to be able to see how it works, so you can tweak it. And so that's in a nutshell. And that concept of free is going to permeate through why licenses are drafted the way it is, and why it causes some of the risks that it does.
And so that guy there is the Open Source hero. His name is Richard Stallman. He's not exactly a looker, but he authored a lot of these Open Source licenses that we use. And he's also the leader of the free software movement.
So I'll give you a sense of what these Open Source licenses look like. They really range the gamut. Many of the Open Source licenses are not written by lawyers, but really, by software developers.
And so there's some interesting ones-- there's the Beerware License, for example. You want to use software in the Beerware license if you see the guy at a bar as you buy him a beer. And then you have the right to use the software.
The other really wacky ones out there too, like the Death and Repudiation License. You want to use software license under this license, you have to be dead. So he's a general question-- how would you go about using this license? Just a general question. Any thoughts?
So you want to use the software-- the author says, you got to be dead to use it. Just take a guess. [INAUDIBLE], what's that?
AUDIENCE: [INAUDIBLE]
PRESENTER: It's pretty good. And so, basically, this license, says you can use it, but you could submit your use cases to your kids. And they can use it on your behalf. And so that's exactly it. And see, you've got all these wacky ones, and that's really far out of left field.
But, really the common cases are really two types of licenses, and they really play off this concept of free. Many software developers who believe that the best way to make software free from restrictions, on terms of cost, is actually just to draft the license, so it doesn't impose a whole lot of restrictions on you. And so we call these permissive licenses.
You can do whatever you want. You could sell it, even though you've obtained it for free. You can modify it. And oftentimes, these permissive licenses, they just require you to attribute the author. The author wrote it, so give them credit where credit is due. Everything else is fair game.
But not all software developers share this view. The other view of a lot of software developers in the Free Software movement is that the best way to keep software free is actually to include a vital element to it. And what that means is the software itself is free, but not only that. If you're going to use that free software in some way, and combine it with your own software, your own source code must also become free.
And so if there's anything to take away from this session from this portion, it's the understanding of the concept of viral copyleft licenses. Just two characteristics-- if you distribute, you give away the source code. You combine it with your own stuff, and you distribute your own stuff-- got to give away the source code. So we'll stop. Are there any other questions?
AUDIENCE: Where's that based on? I mean, the other that's not--
PRESENTER: Also a fantastic question. So some of these licenses are drafted without reference to copyright law. And that's actually the challenge in interpreting open source licenses. And so based on is not actually a copyright language. And so when we interpret it based on, it depends.
There's different schools of thought-- from the most conservative to the most liberal. The most conservative school of thought is you can't take any concepts from the copyleft code. So you could look at the code. You don't even have to take the code and put in your own. You don't even have to combine it with your own.
But even looking at it, and taking substantial portions, would trigger the based on. That's the most conservative approach. On this other side of the spectrum is you'll hear about these concepts if you Google online about depends on how you combine. Are you linking it dynamically or statically?
In other words, are you combining it at runtime when you're running the software, or you're doing a compile time when you're building it? That's the other school of thought. And depending on the use case, our view depends on the risk to the client. Sometimes, you really want to take a very conservative approach to remove all risk.
AUDIENCE: So I thought, you can don't link it. You're safe against GPL [INAUDIBLE]
PRESENTER: The problem is it doesn't cover cases where you're copying code. And so when we we're at Blackberry, I used to be a software developer. And a lot of the stacks, a lot of software developers copy at left training center. So a lot of TCP/IP stack. It sounds like you're a developer as well. It's really hard to make it compatible.
You can read a standard, and then you can try to implement a standard. But implementing a standard is completely different than all the nuances that are trapped in the standard. So a lot of software developers, when we're writing the stack at Blackberry-- the TCP/IP stack, they just took the open source one, and then they just put it there. So taking source code is clearly based on.
And then you step one step further, and you look at how it's designed. You can change all the variable names, all the functions. If it still looks like from someone who knows how to code, it's basically ripping their code with all the names changed. The design is still the same. There's still an argument, though. That's based on.
We've got a few more thoughts. But if we talk about how I typically advise clients depending on what it is that you're trying to achieve, that we can just mitigate the risk. But those are fantastic questions. Keep them coming.
The good news is when you deal with Open Source software, there are hundreds, hundreds of them. But really, when you break it down, the top 10-15 are either permissive that we talked about. You could basically do what you want. Just tell the world that if the author wrote it, he wrote it, but you can charge for it. You can do everything else you want. And those are in green.
The other copyleft viral licenses that have some source code disclosure requirement-- you got to give away your source code if you combine and use in a certain way. And those are red. And then the in-betweens are not highlighted. And so they range the spectrum.
But I think the most useful way to talk about the risks is not in the abstract, but really, in a life scenario. A lot of the attendees here either have companies or work with companies, that when they try to sell or invest, someone's going to look into how you use Open Source. So if we frame it that way, it's a bit more practical, and it might help.
So let's use, for example, you're a tech company. Almost every tech company that I work with, their solution is based on one of the three, if not all three. They are the distributed software, they've got a web platform, or they've got some mobile application.
I bought a guitar effects pedal this weekend. It had all three. There was a web app. There was a mobile app to control my guitar effects, distributed software that I installed in my PC. Let's just assume you use a few of these licenses. And so there's an opportunity now-- someone's approached you to acquire your company. What are they concerned with?
Typically, these four items, and these are the same four items that when I was at Blackberry, these are the four things we looked for. And it's consistently been the case. When I look at startup companies, the questions that a strategic acquirer would ask is are you in compliance with open source licenses. If not, you will lose your rights to use the vast majority of these licenses. So one step into your shoes would have to address that in some way. It could be expensive to remediate.
There is always the risk of monetary damages. I downplay that risk a little bit because the enforcement bodies tend to be volunteers. So there's still that risk there. There's also the reputational risk if you're engaging with the open source community.
Second question that always gets ask is, is the company I'm buying, are they required to give away the source code? If they are, gosh, that is a lot of the value of what I'm buying. If they have to give that away, will my competitors get access to it? And it dilutes the value of what they're buying.
Third question they ask, a lot of time strategic acquirers buy technology companies because they plan to integrate in some way. They find to build on top of it as part of the portfolio. And if they do that-- if I'm Blackberry, for example, and I buy a company, am I going to infect my own Blackberry source code, such that I have to give away my BlackBerry source code? All the questions that cross your mind.
And of course, last is, how are the practices of the target company were buying. Do they have a robust source practices?
And so I'm going to go through just three or four steps in what it looks like when we used to buy companies, and when we look at it from open source perspective. Acquirers will often just ask outright-- what open source licenses used? And they will focus on the copyleft licenses because as we discussed, permissive licenses let you do almost anything you want. It's the copyleft ones that tend to trigger concerns.
The general rule is that the vast majority of the undesirable effects of open source licenses are triggered on distribution. And so a strategic acquirer will look at distributed software first. If there's no distribution, generally, you don't have to give away source code, and all of the other undesirable effects, your way.
OK, so if you're using open source on the back end, you're using it as like OpenOffice, for example-- low risk. You're just using Firefox browser-- low risk. High risk is when you start taking open source software combining with your own, and now you're shipping it. That's active distribution. It will require you to also give away the source code to the recipient.
AUDIENCE: If your model is to [INAUDIBLE] the customer uses your software in the cloud, does that constitute distribution? Because it's not on the customer side.
PRESENTER: That's a fantastic question. The other thing that acquirer will do is look at your cloud solution.
AUDIENCE: OK.
PRESENTER: And so, in short, the general rule is you have to be careful about copyleft licenses in web pages, in JavaScript. And you need to be careful of a licenses, specifically, targeted at the cloud. So more directly to your question, if I had used GPL code in JavaScript, that act of a user accessing a web page downloads that web page on the computer first. That's a distribution. So you'd be careful about these cases.
But I hear that all the time we're a SaaS solution. And so it doesn't matter that we use GPL. Well, it depends on where you use it. The second scenario you need to be careful about is some licenses are drafted, specifically, to cover that.
And so, the guy with a beard that I showed like slides and slides ago, when he drafted some of these original licenses, he wanted to capture the viral effect. And what he noticed was that people were circumventing that by using a cloud solution, and saying, that I'm using cloud solution, and therefore, there's no distribution.
So he went ahead and worked on this new license called the Aferro GPL-- AGPL. And that license says, you know what, if you are making available your software over the internet, that counts as a distribution. You have to give away source code. So those are the two scenarios that we typically look for. It sounds like you've actually worked with open source and encountered all these questions.
So here's another corner case. We'll look at mobile software. Yes, it is distributed. But in addition to the distribution problem, some licenses are actually not compatible with application stores. And specifically, the classic example that we see again and again is licenses that are drafted for libraries. And library is really modules-- open source modules that you can kind of plug-in and out.
They're not actually compatible with application stores because a lot of these licenses require the flexibility of the person receiving the application to take apart the open source piece, modify it-- that's the freedom aspect, and put it back together.
The problem with app stores is a lot of them are signed binaries. You can't change it. And Apple does that, for example, to really protect the user, so that nobody can change a mobile app, and inject spyware or any kind of malicious code into applications that you download. That very same security mechanism makes it impossible for you to comply with some of these open source licenses.
OK, we'll go through this again when I summarize because I know some of this is certainly a little bit technical for the non-technical audience. But the last step is there's really not a technical point. It's that the acquirer will ask, am I acquiring a company that has a lot of patents? If I am, some of these licenses actually require you to give away patent rights.
Other licenses will say, you can't sue. Because if you sue, you're going to lose the rights to use this critical piece of software. So these are limits that are of interest to inquire. And then, of course, the security-- the Heartbleed problem. You may have seen or heard about in the news. That was an open source tool.
That open source component-- people knew about the flaw months and month ago. It's just that, people didn't know they had or were using open SSL. Most companies don't know what open source software are these. So they couldn't take steps to mitigate or address or implement some of the bugs, and of course, open source practices.
OK, so I'll summarize all this again because I know we went a little bit quickly. In terms of practical pointers, like practical takeaways, and how to really manage use of open source software, it really starts with just taking stock-- taking stock of what we use and have, and to just categorize them. Not all open source software use cases present the same risk. Back end software, like office tools-- low risk, Firefox-- low risk.
Then you have products that are not distributed to customers, like the gentleman mentioned, the cloud software. As long as it doesn't have those exceptions, generally, it's low risk. Yes?
AUDIENCE: I mean, do you see more issues in vertical software versus horizontal software companies, or not, in terms of people digging into the code, and think that's a problem? Or is it more applicable to one or not in your experience?
PRESENTER: To me, the risk exposure is actually how likely it is that someone knows you're using open source, rather than that dichotomy. How likely it is that, so if you have end user software and your participant open source community, that tends to be the dichotomy that creates the risk or not.
If you're creating enterprise software, it's unlikely that someone's going to figure something out. If you're using consumer software, it's more likely that your exposure is greater, but none of those terms.
AUDIENCE: I used to work with vertical software companies, and I think the impact is the same. But one thing we used to look at is whether the open source was integral to the software, or if it was based on something that was in a module.
AUDIENCE: The technology is not necessarily the differentiator. So that's [INAUDIBLE]
[INTERPOSING VOICES]
PRESENTER: Yeah, and plus is if it's not integral, it's easy to replace. It's easy to swap out. The con is, of course, if you're using a non-integral piece, there's the possibility of it infecting the piece that is integral. So that's the area you want to watch it for.
And so there's a lot of layers to open source analysis, and I think, what starts as just being very cautious about the copyleft licenses. I think there's a place for copyleft licenses. But if you're developing proprietary software, managed the use is really important.
And so I know we've talked about this principle a few times. If there's no distribution, it's unlikely you're going to be required to give away source code. It's also unlikely that you're going to trigger really any obligations at all. In fact, if you're using copyleft software on the back end, you could do what you want with it. You never have to do anything more.
But if there's a distribution, then you're going to want to ensure that if there is copyleft licenses, that it's sufficiently isolated from your own proprietary code. And that's the challenge. So is there a question? OK.
And again, the scenarios to look out for-- the cloud scenario is one that's often overlooked. It's the one where most people think there's no distribution, but there actually is. If any aspects of the code, it's often JavaScript. That's on the browser side. And if you use the Affero license, the AGPL access over the internet, that counts as distribution.
And then just watch it for the mobile apps. The AGPL isn't compatible with many of the app stores. Yeah.
AUDIENCE: You mentioned enforcement earlier, and so some of these even smaller ones, it is easy to buy. If you forget to do the [INAUDIBLE], then [INAUDIBLE]. So what's the enforcement on that? So you forgot to do the [INAUDIBLE], what happens then?
PRESENTER: So often, cases for enforcement, if [INAUDIBLE], most of the lawsuits are-- sometimes, it's from some of these enforcement bodies like the Free Software Foundation. They got a bunch of affiliate bodies. But some of these lawsuits are actually from your own clients.
And so some of the more popular ones are clients where there's a dispute. And the client says, I actually don't owe you any money because actually, what you've given me-- you've actually infected all of your stuff with GPL. You should have given to me the source code anyways. And so, I actually don't owe you anything.
And so some of the litigation, the states, the recent litigation has been around that concept. It's your own clients that are bringing it back to your attention. The risk of the individual author coming after you is actually low because there's a barrier to entry in terms of the funds that they would come after you.
And then there's also the question of-- by the time it got to you, which part did he actually author? And so those are all questions that they'll have to establish, and it's actually not that easy to do. And so for that reason, we say that is a risk. But I, typically, minimize that as a practical risk.
One thing I will say, open source policy-- very few companies, when I do diligence, open source, actually, have a policy. And having an open source policy will already put you in the minority. When someone asks, hey, do you share with me open source practices?
If you can already produce an inventory of what you use, and have some sort of policy to say, hey this is how I comply with licenses. This is how I evaluate open source components before I use them. This is how I participate with open source community. Just even having that puts you so far ahead of the companies that don't. Of course, have of it means complying with it. And then just having training, and regularly auditing your software.
So that really brings me to the end of the speaking portion anyways. But we've got a tool we want to show you. It's a tool. We've been working on that. We're excited to launch later-- I think, in a couple of months. So the project team is at the back that are working on the tool. And they can comment on timing.
But I'll show you an example the tool and what it's really designed to do. So the problem is that most companies just don't know what open source they use, and unless you know, that really is baseline the starting point. You can't even begin to address the risks.
The other problem is you go to pay for a very professional audit firm. It becomes very expensive. And so as a consequence, a lot of companies never do a scan. And so we've developed a tool that, it's not a replacement for professional scan with your source code, but what it does is it looks for the top 20 licenses.
And so this is how it looks like. Let's say, for example, you've got-- this is just a website. It's going to be available on the web. And let's just say, for example, you've got source code. You're just not sure what license is that you use there. And so you're not [INAUDIBLE] to any of the risks. And so you just choose a folder, and you click Scan.
What our tool does, it does a regular expression search. And so it spoke of binaries earlier. It will not scan binaries. It'll only search source code. And it's going to break down, for you, the various licenses that are found in your source code.
And so you'll see I scanned TreeFrog, which is basically like a framework for the Swift language. And so it shows right away, look you've got some of these copyleft licenses. The very ones where distribution would actually cause you an issue. Before, you might not have known that. But at least the tool tweaks your mind to that. And then you can take a look at what these files that are subject to that risk. And at least, now, start to take steps to do something about it.
So based on the pie chart form, all the various licenses that you're using. It's not perfect, but it's better than not doing anything at all.
AUDIENCE: Which language is this used for?
PRESENTER: So this is actually not language-based. This is regular expressions. It actually looks for a list. An FAQs that has a list of common source code extensions. So it'll do not .c, .cpp, .h, .js, all the common extensions. But it's not even actually-- if we've missed one-- one of the source code extensions, let us know. We'll add it. Yeah.
AUDIENCE: How do you [INAUDIBLE] Is that a critical piece of the [INAUDIBLE] or you just have identifying [INAUDIBLE]
PRESENTER: OK, so this tool will not tell you that. The way I identify is actually to go back on the analysis. I always ask when to do with open source analysis-- do you have an architectural diagram? Without that, it's really hard to tell, whether it's actually important or not, whether the right measure is actually just to swap it out or not, whether there's a distribution or not, whether there's a combination that causes a risk.
And so you can't tell from this. It's often an architectural diagram in a question with one of the members of the technical team. But that's how I determine.
AUDIENCE: We can [INAUDIBLE]
PRESENTER: Like in the sense that what would cause the major risk?
AUDIENCE: Yeah.
PRESENTER: OK. And so more specifically, I would actually start with this tool. So in your example, I would run this tool against your source code repository. I would actually love to see if any of the copyleft licenses come up. And if they do, I would actually just see if any of these pieces are exactly part of the critical.
If GPL and AGPL didn't show up at all, I actually wouldn't even be concerned. I actually wouldn't be very concerned with any risks at all. If they are concerned, then I would ask if it ties back to some of the critical pieces you're looking at. That would be the link. And then, depending on what it is addressing in the appropriate way. Yeah.
AUDIENCE: By [INAUDIBLE] to replace that open source code [INAUDIBLE].
PRESENTER: Yeah, so a lot of times, you can probably replace it with another equivalent that may have different, but perhaps comparable features. That's also open source. But under a license, that doesn't cause you as much concern. And the feeling that you could also re-architect your solution, so that there is no combination. That's the other way to do that.
And the other way would be, technically, you would really separate the two, and make the two components talk to each other through an interprocess communication or through sockets or some other way. So you have to find a replacement or you re-architect the solution so that there is not a combination, there's not a technical combination.
And so then it's the question of what that is exactly-- how crucial that part is, and how it's architected with all the components around it.
AUDIENCE: You're talking about the absolute [INAUDIBLE], plus you pointed out that in the signed image, then you can actually reuse the source code by the principle of the free software. So if you have that on on-prem selection, so it's clearly distributed, and you're only dividing binaries. But you have a lot of [INAUDIBLE] to that and creation of the binaries. I got the [INAUDIBLE] because you [INAUDIBLE] to be shared--
PRESENTER: So let's be specific. Are we talking about the LGPL?
AUDIENCE: Well, no. I'm talking generally. Because it is what being able to share-- the software. Is the software free? So you're [INAUDIBLE] binaries. I'm actually taking [INAUDIBLE].
PRESENTER: Yeah, so there's two scenarios there. It depends on which license because they're all different. In the case where it's the GPL, and the GPL is the first of the two, if you're giving binaries to someone-- is that the first scenario? You're giving binaries?
AUDIENCE: Yeah.
PRESENTER: So basically, you would also give them the complete open source.
AUDIENCE: So we would have to.
PRESENTER: You would have to. That's right. And you could do that in a few ways-- you can give it to them on the same [INAUDIBLE]. You can make it available for download where they got the binary. You could do any number of ways.
In the LGPL scenario, they're different license. That license requires you to be able to put things back together again. In that case, you could also do that because you could give away your proprietary stuff. And they could also give with LGPL. The problem with the app store is you can't do that through the app store mechanism because it's signed. And you have no way of really giving things to the end user through that means.
And so one of the defensive measures you could take is in the app store disclaimer, you can outright say, look, this is a limitation. But if you want to be able to exercise your rights to be able to put things together and back together again, here's a link to where I store everything. Go do it there.
And while it doesn't comply, technically, with the license, it'll, at least, gives you a defensive measure where look, this appear the license has been met. And so one of the damages really. And so that's another way you can address the LGPL. Yeah.
AUDIENCE: Are we going to [INAUDIBLE] service. So if they're not [INAUDIBLE] software, then [INAUDIBLE] You're not really buying the software. [INAUDIBLE] our team's time to service the software are standing by for all [INAUDIBLE]
PRESENTER: Yeah. So two comments on that-- the first is it's always a question of what you are actually doing versus what you are calling it. The other comment is you just have to be careful the way you drive some of these commercial licenses-- that layer on top of, especially, GPL. Because one of the requirements of some of these copyleft licenses is that you cannot impose any further restrictions. And the interpretation is actually very strict.
So once you start imposing things, and layering things on top of it, it could be interpreted as an additional restriction, and you'd lose the rights to use it. So you just have to be cautious the way we do that. But it's often substance over form. Yeah, [INAUDIBLE].
AUDIENCE: [INAUDIBLE] will link this to a code [INAUDIBLE]
PRESENTER: So that's a great question. Not in the first version. The first version, you had to-- so I was just at the TreeFrog GitHub. I had to actually download the repository. So I just download locally. But that'd be a fantastic feature set. And the product team is actually the back. And so, I think, Heather's managing that. But that that's a wonderful feature for sure.
AUDIENCE: [INAUDIBLE] by external contractors and [INAUDIBLE]. Are there any best practices or things that should [INAUDIBLE] before in this [INAUDIBLE].
PRESENTER: Yeah, so from a contracting perspective, I always actually ask them to disclose what open source they're using to obtain your permission before they use it. Because they could put you in a very difficult position, otherwise.
So one of the clauses that I include in contract agreements is when they include not just open source, but really any third party, of which open source is an example. Let us know, and then you should have approval rights, so you know exactly what you're signing up to. Yeah, and then you could, of course, use this tool to validate whether they've complied with that. But fantastic questions.
You could throw all the hard ones out. I think, almost every question that you might have thought that we probably would have encountered in some ways. So happy to speak here or happy to speak one on one.
So thank you for the [INAUDIBLE]. Thank you for the opportunity to speak of open source. It definitely is a passion of ours here. And if you have questions, let us know. And then I'm not sure, Heather, if you have any comments about the product, or anything you want to talk about in terms of, at least-- Heather is the product manager and the project manager for the open source tool.
HEATHER: Yeah. Thank you. We're currently refining the tool. So it's in data. And we're hoping to release it in early May.
PRESENTER: Great. So you look for it on our website. I'm sure we'll make a splash.
HEATHER: We will.
MODERATOR: [INAUDIBLE]. If there are any other questions, Sam mention, he's going to stick around. So if you want to chat with him, feel free, after this session. On your tables, there should be a feedback forms. If you can please do us a favor, take two minutes to fill that out. It'll help us with planning for our future sessions and get specific topics that are important to you, or that you think would be interesting from this group, feel free to share with us.
Our next session is on April 16. We're going to be talking about workplace harassment. So a very different topic. That's something that's relevant, especially, these days with things that we need to move in. So stay tuned for an invite for that one. And we'll also be sharing the slides from this sessions. So if you didn't catch all the content, you want to just take a look at those. We'll reach you guys on the guest list. Other than that, thanks again for attending. And stay tuned for the next session. Thanks, again.
PRESENTER: Thank you.