Wicked Good Development Episode 25: The struggle with open source licensing

In this episode, Kadi and guest co-host, Dariush Griffin, sit down with Filipp Kofman (Partner, Davis Wright Tremaine LLC) and Adam Such (Solutions Architecht, Sonatype) to discuss struggles with open source licensing.

There’s not always a clear-cut answer on the best way to handle open source licensing, especially when it comes to managing your dependencies. Topics of discussion include ideas from legal and development perspectives, the struggles they face, and best practices for working together to reach mutually beneficial goals.

Tune in for the full conversation and check out the resources from this episode below.

Listen to the episode

Wicked Good Development is available wherever you find your podcasts. Visit our page on Spotify's anchor.fm

Show notes

Hosts

Kadi Grigg - Host - (Twitter: @kadigrigg)
Dariush Griffin - Co-host

Panelists

Filipp Kofman, Partner (Technology Transactions), Davis Wright Tremaine LLP
Adam Such, Principal Solutions Architecht, Sonatype

Relevant links

Blog posts

Transcript

Kadi Grigg (00:11):
Hi, my name's Kadi Grigg, and welcome to another episode of Wicked Good Development, where we talk shop with OSS innovators, experts in the industry, and dig into what's really happening in the developer community.

Dariush Griffin (00:21):
Hi, my name is Dariush Griffin, and I'll be your co-host. I've been an open source developer for many years. In these last few years, I've been working as a product manager on legal products.

Kadi Grigg (00:29):
I can tell why you're interested in today's conversation. So, as Dariush alluded to, given his background, today's episode is all about the struggles between legal and development with open source licensing. Today we have a wicked good panel comprised of both legal and development professionals to talk about this struggle. So before we jump into the questions, Filipp, can you introduce yourself and tell us a little bit about what brings you to this conversation?

Filipp Kofman (00:53):
Sure. My name isas you said, Filipp Kofman. I'm an attorney. I'm with a firm called Davis Wright Tremaine in their technology group. And I work with tech companies and handle their intellectual property licensing and commercial transactions and advise them, a lot of them, on open source licensing compliance issues, things like that. So, very much in this space and do a lot of counseling with clients on topics like the ones we're going to be discussing today.

Kadi Grigg (01:25):
We're lucky to have you here today. Adam?

Adam Such (01:28):
Hi, I'm Adam Such, I'm a solutions architect at Sonatype. So, I've helped lots of customers through their legal journey, understanding their open source risk. In a past life, I was a developer and a product manager. So, I've also gone through the other side of this working way trying to select the component for the right licenses or make my team select the right licenses.

Kadi Grigg (01:49):
Well, let's dive in. So, before we get into the nuts and bolts of this and where some of the struggles are, can one of you give us a high-level overview of what licensing means in regards to open source components, artifacts, or libraries?

Filipp Kofman (02:05):
Yeah, sure. I can jump in on that one. So, the foundation of licensing is this idea that as a creator of something, in this case code, I would have exclusive rights to that thing. And I can give those rights out to others. So you have the creator of the code, the licensor, that is granting rights to other people---the licensees. And usually you do that pursuant to a license agreement, a set of terms and conditions that set out the rules of the road. "Hey, You can use my code, but here's how I would like you to behave." So, since code has been around, that's usually been subject to proprietary licenses, closed-loop licenses. "My Code is my code and nobody can see it." In the eighties, this concept came about of "well, code should be free, not necessarily free, as in you give it away for free, but free as in it should roam free."

Filipp Kofman (03:05):
Everybody should have access to it. Let's all collaborate and improve it. That concept came about through various foundations. And it was worked on in the nineties and brought from this sort of hippie ideology into something that was much more commercially accepted. And the whole ecosystem grew up around it. And it's an ecosystem that is focused on a lot of these very commonly used known licenses in various types of these open source licenses. There's lots of variations, and they've taken really a central role in code development throughout the software industry. So, that's kind of the overview of where we stand. And now what we have is---Kadi what you said about the struggle between legal and development---doesn't have to be a struggle, but sometimes it is because you have developers wanting to use the code that they need to use to make their programs work. And you have people like me in legal saying, "well, let's just pump the brakes a little bit." Let's make sure that those terms and conditions of the license are what something is. The company that you're working for that we can comply with and that don't put us in an awkward position in the future.

Kadi Grigg (04:24):
So, Adam, I'm curious to hear what your thoughts are since you previously managed a team where you were advocating to choose these right licenses. How much of a headache can that be for development sometimes? Because sometimes we do hear that, "hey, it's slowing down innovation, we have to do a workaround." But that's obviously not ideal, right? As Filipp just said, you're trying to keep yourself out of the courtroom basically. So, can you walk us through a little bit about what development's kind of mentality is on this?

Adam Such (04:52):
Well, I'll be honest, when I started as a developer, I didn't understand these things at all. I knew these licenses were there when I browsed open source. I could see them in GitHub and the other places the code live that I looked at. But I just kind of saw them there and generally ignored them. I became more aware when I was developing. Some of our customers were asking about what licenses we used. We found some slightly more unusual. Some of our developers were slightly more aware and brought to our attention. So, I slowly learned, and there was some features in platforms like GitHub that added a bit more detail and kind of broke those licenses out and made them a bit more obvious. And I kind of learned through that journey. And then when I became a product manager, I was looking at all the risk profile of our applications. And we started off with security. But I then looked at legal, and it was kind of an unknown thing for other product I was looking at.

Adam Such (05:49):
We had to delve into it, look at what we had, and what was a risk. And that was a manual process when I did it. But it was an interesting journey. And we found most of the licenses were similar licenses repeated again and again, but some were unusual or required a bit more thought. And that was kind of the journey we went on going through them all. And speaking to customers now, and I speak to lots of customers going through their similar journey, and they go through similar things, and we often help them with that. But they've got to go through and work out what's already there.

Filipp Kofman (06:24):
Yeah, and if I could just jump in, what you were saying, Adam, that is a process that a lot of companies go through. And it can be really difficult because maybe 90% of commonly used components and libraries are subject to the same 15 or so licenses. And everybody's familiar with them. And even though they're not---if you ever try to read one of these---they're not written very clearly, even for lawyers. Lawyers struggle with them. But there's kind of a general understanding of what they mean and what they say. But then there's that last 10%. And a lot of times these license are what we call non-standard licenses. And those can be just a license that is very rare that just not a lot of people use. Can be a license that the publisher of the code just wrote themselves.

Filipp Kofman (07:15):
They don't have to pick from the commonly used licenses. And those are the ones that really tend to trip people up, because you have to spend a lot of time and effort trying to parse through and understand, "well, what does this actually say and how do I comply with this? And can I even comply with this?" Some of these licenses are just difficult to comply with because they're maybe not crafted so carefully to allow companies to comply with them. So, I sympathize with that struggle, and I see it a lot.

Dariush Griffin (07:46):
So like, if we want to give an example, is that something like the JSON license, where it has an obligation of "shall be used for good and not evil?" What does that mean? It's very broad, vague.

Filipp Kofman (07:57):
Yeah, exactly. There's a whole category of licenses called ethical use licenses, and they vary in what they say. And those kind of licenses, a lot of them are good in thought and spirit. They say things that we can really all agree on like, "use my software for good, don't use my software for human rights abuses" or things like that. I mean, yes, please don't do that. But if you're looking at it from, let's say a company's perspective and trying to figure out, "well, I'm basing a lot of my company value---my core intellectual property is going to be somehow based on this component or utilize this component." Is it predictable how that clause could be interpreted if this is ever challenged? And you imagine a judge looking at that and trying to figure out are you at all times objectively good. Or maybe you have a customer that is an oil company. Some people could say that oil companies do not do objective good. Other people may disagree, but a lot of times companies do not want to be caught up in that kind of uncertainty. So yeah, that's a great example of something that trips companies up a lot.

Adam Such (09:19):
Some of the most deep conversations I've had with our customers have been around things like beerware and coffeeware licenses, which seem ridiculously simple when you read the license, and developers think they're funny. Yeah, it seems to cause a big headache for lawyers. The lack of clauses within those licenses, which often ends up in a interesting distinction between developers saying, "Well, that's very simple. It seems very easy. I just have to buy the developer a beer or a coffee or a whiskey if I meet them in a bar." But lawyers see it completely differently. And it's interesting how they see the lack of clauses in there.

Kadi Grigg (09:59):
So, it's become clear that there's so many different types of licenses that it can almost be overwhelming in being able to select them. So, what does that process look like for developers when they're trying to choose certain components? Is legal a part of that process? Do we typically see enterprise organizations having gated systems around how they choose? Just trying to get a better understanding of what that process looks like.

Filipp Kofman (10:27):
I can speak to that from what I've seen, and then I'd be really interested to hear Adam's perspective from a more developer perspective. So, from the legal side I often work with clients on setting up open source policies. And an open source policy is a policy, which doesn't make it terribly popular a lot of the time, but sets out the rules of the road for the organization for how they interact with open source software and open source licenses. So, a lot of times in the open source policy, you'll have lists, you'll have a column that'll say "these licenses are green lighted." There's whole categories of permissive licenses, MIT, BSD, others that are just universally known. And it's generally acknowledged that they're fine to use in their organization, subject to the organization, complying with some attribution requirements and things like that.

Filipp Kofman (11:22):
There may be some other licenses that have copyleft aspects to them---GPL, LGPL, and some others---where that would go, maybe in the yellow category, there would have to be a little bit more discussion. It could involve legal. It doesn't have to involve legal. Maybe there's some kind of an escalation process where somebody just is tracking those, making sure that they're used in the way that the company is comfortable. And then there may be other licenses that are in the red category. So, the non-standard licenses that we just discussed, ethical use licenses, some companies have them in the non-standard category. And Affero GPL is often in the red category because it has some aspects that are non-standard in terms of SaaS use that companies don't like.

New Speaker (12:15):
So, you have legal work closely with the development team to put these policies together. Where I've seen these policies be most successful is when the development stakeholders are part of this process from the beginning and there's a lot of buy-in. Where I've seen these policies fail is when you get a group, a room full of lawyers drafting a policy and then handing it down to the engineers---"here follow this." And then maybe it's followed for a little while, but then you start to diverge from it, and then you wake up two years from then and realize that it's a policy that's gathering dust somewhere and nobody's really implementing it. So what is the most successful path is a collaborative environment where you've set up appropriate paths of escalation and have clear expectations, both from the legal side and from the development side. Adam, has that been similar to your experience?

Adam Such (13:09):
Yeah, definitely. That's exactly what we try and help people do because that's the only way you can make it successful. Having just a list is one thing, but you need to be able to automate against it. That's how you get that developer buy-in. It's well and good having a list. But yeah, development need to know what licenses there are. It can often be two-minute look-up for the library you're selecting. But when it comes to transitive dependencies, those dependencies that come in underneath, it can often get very complicated, and you have less control. So having a big framework like Struts, something like that, can have many, many transitives underneath it. And if one of those licenses are banned, can you not use that whole framework? That gets quite complicated quickly. And yeah, you definitely need that feedback between the legal team and the development team to understand what's actually being used, how it's being used, whether you can make an exception for the licenses. So, that two-way feedback and that information to hand, not spending days researching it, is important and makes for less friction between the teams. Because that's the last thing you want is developers not wanting to do it or finding it's a pain, sticking to their old libraries never updating because their fear of picking the wrong licenses. Because that leaves you open to other risks, but equally not being restricted by those licenses. So, it's great to have that feedback and two-way communication.

Dariush Griffin (14:38):
Yeah. Let me ask. So, having a policy is great. How do those policies typically handle things like multi-licenses or incompatibility? Is that something that developers tend to want to tackle or is that more of a realm of legal, or do we just say if there's a multi-license just ignore it? How do we approach that bridge?

Filipp Kofman (14:59):
It's difficult, issues like multi-licenses. So, you have a software that's dual-licensed and can be tri-licensed. I've seen that too where you have to essentially pick one. It's hard for any policy to contemplate any possible alternative. You can set it out and say, "well, okay, in a multi-license scenario, you look at if it's completely just you choose," then you look at the lists and if one of those licenses is on the green list or the permitted list, then you go with that one. But incompatibility is really tough. It is tough for lawyers in this space who are there all the time to figure out which licenses are compatible with other licenses. But there are good rules of thumb.

Filipp Kofman (15:49):
And if you can have a process, automation here is always really good. Anytime you have people cross-checking things by hand, you're going to get mistakes and you're going to get a lot of exhaustion from your people. If you can program those in to have an automated way of doing these things programmatically in your organization and establish those rules that way it just makes compliance a lot easier, both from the legal side and from what I've seen from the development side.

Dariush Griffin (16:24):
Adam, I was also going to ask you since you kind of brought it up.How frustrating do you think it is for developers when they go out to GitHub and they see GitHub says it's Apache, and then they talk to legal or they use other scanning tools and the scanning tools are like, "well, it's actually not just Apache, but inside here there's this piece of code that is actually GPL" or a different license? What has your experience been with developers reacting to that? Or do they just not care? Do they ignore it? Do they just throw their hands up and say, "oh, this is terrible, terrible, terrible mess, and I don't wanna have to deal with it"?

Adam Such (16:58):
Yeah, it's very hard to understand. And as developers, we often delve in and look at the code and kind of understand technically where those things appear. Sometimes they're in separate files, sometimes been copied from other libraries, and that often brings in other legal challenges. And I'm sure we'll talk about copying code from other libraries and things like that later on. But yeah you can understand it technically, but understanding the legal implications is so hard. As Filipp said, even lawyers sometimes struggle with these things, so as developers it's almost impossible to understand. So, having that constant communication with legal for the special cases and having the language to talk about what you've found technically is important. I think that's often one of the hardest parts, is having the shared language between legal and development, because you know what you found, where you found it within the code. But being able to say where that licensee is, what it is, is often quite different language. Clauses are quite hard to understand, impossible to understand sometimes, and I'm glad to have someone legal behind me to make sense of them. But I also want to not be bogged down by having someone look over them every single time. Hopefully they can do it once and put it into the automation so I don't have to bother someone every single time I look at a license.

Dariush Griffin (18:21):
Well, I think we've kind of highlighted that choosing, understanding how a software component being licensed can be challenging. Whether you have a policy in place, there can still be other aspects of it that can make it a difficult decision. But are there any real consequences? Do we have any, are there any examples of companies that maybe didn't get this right and have suffered some consequences for it? What are the real dangers here? What does it matter if something is Apache or MIT or BSD, and I just don't notice it or don't care?

Filipp Kofman (18:50):
There are real consequences to this, and I see it on a fairly regular basis. So, there's some consequences that are very, very public and those tend to be actually somewhat rare. But there are instances of publishers suing licensees, usually big companies, for not complying with their code release requirements or their attribution requirements. I know Vizio got in trouble for this. Sony got in trouble for this. I think BMW got in trouble for this. That happens. It doesn't happen that much. And so that makes it seem like, "oh, nobody really cares." I see on my side that this is a huge issue. And where it becomes a huge issue is if you're a company in investment rounds and acquisition. In every investment round or acquisition scenario or transaction that I'm involved with, and I'm involved with in a lot of these, there's open source diligence if you're a software company as part of IP diligence where you will undergo an open source scan and all of these little things come out.

Filipp Kofman (20:02):
And what happens is that the companies that are proactive, that have an open source policy, that show that they've been mitigating these issues, they have answers, they've solved them, they can provide their bill of materials that show all of their licenses, and why it's okay that there's GPL here and this other license there---they fly through really quickly. Where you start to get into trouble is where the company doesn't know what they have, and the company is shocked to learn that they have components that are under these licenses. And I've seen transactions get delayed. I've seen engineers having to spend days literally in rooms trying to fix these things. And it costs a lot of money, time, and effort. And it serves a signaling function.

Filipp Kofman (21:01):
Sometimes you have an acquisition where the acquirer really digs under the hood. They want to know everything, and they spend lots of time and diligence. Other times you have an investor and an acquirer who just wants to make sure you know what you're doing. And how do they do that? They can talk to you. But then they, they also look at objective evidence. So, do they practice good open source hygiene? Do they have an open source policy? What is their process for license compliance? Do they have a programmatic way of detecting these issues? Are they attributing? If they see that you are doing these things? That might be enough. They might say, "okay, check." They really know what they're doing as opposed to the opposite, where none of those things are present and now they start to get worried, and now they start to dig more. So, that's really the main cost that I see. Not to say that litigation isn't a possibility. It absolutely is. And you could if you're not complying with licenses, get hit with a copyright infringement lawsuit. That has happened as well.

Kadi Grigg (22:02):
Adam, what would be the impact on you? I know Filipp said he's seen things where engineers are literally stuck in rooms for days, but has that been your experience or what you might have heard in the community?

Adam Such (22:16):
Well, it's interesting you talk about the acquisition thing. I used to have a Linksys router, and I hacked around with it, and I thought it was cool that it had free firmware. But I'm sure Cisco didn't think it was so cool that they bought Linksys and then had to open source the whole of their firmware. And it meant I've got cool stuff like OpenWRT and things now running. But yeah, they had to open source all their---I think it was the Free Software Foundation made them open source the whole of their firmware. So, we see those real examples around. And that opens things up, but it's not so good commercially. As a developer, it's just hard to know where you draw the line. And we hear a lot of people talking about hard to understand when they need to apply licensing.

Adam Such (23:03):
Some people say to me, "I don't ship my software to people, so think I don't need to do anything with it." Because it's not in a physical product. But they're just exposing it on APIs and those type things. So, they think they don't need to do anything. Others know they need to do things on certain things. Most companies now have things like mobile apps. But I often find they also realize later on they need things like their frontend JavaScript ends up in certain areas. I'm sure Filipp can talk in a lot more detail about where those things actually sit. My knowledge is relatively limited, but I know that it can be very difficult to understand where your distinction lies between those things that sit inside and outside and when you need to apply certain licensing rules.

Filipp Kofman (23:53):
I think what you just said is a really good point, and I see this a lot. And that is: "I'm a SaaS company. I make all my products available as a service. I don't need to worry about licensing. I've done compliance with open source licenses." And there's a kernel of truth there, but like a lot of things where you simplify something down to one sentence statement, there's a lot of nuance that's lost. Some of the licenses like, for example, GPL and LGPL and some of the other weak copyleft licenses, the obligations to license your proprietary code that is either linked to the open source code or your modifications that is triggered upon distribution. And the general understanding is that "distribution" is actual distribution of the code, shipping the code.

Filipp Kofman (24:46):
If you're making it available as a service, you're not shipping the code, therefore you do not need to comply. How easy is that? The problem is that---well, there's two problems. Problem number one is that some licenses do not follow this logic. Affero GPL, which I mentioned before, is a great example. That license is designed specifically to close that SaaS loop. And the obligations are triggered not upon distribution, but making something available as a SaaS under a SaaS model. There are other licenses like that as well. Also, it's easy at one point in time to say, "my company will never ship this product on-prem." But we can't really know that. I've had so many clients who had that viewpoint at one point in their software lifecycle, and then a customer comes along, maybe it's a federal customer, maybe it's a large financial institution that says, "I will give you a lot of money to put this on-prem behind my firewall because as a matter of policy, I do not want this sitting in a public cloud infrastructure." And sales and leadership says, "yes please, sounds great."

Filipp Kofman (26:02):
And then they kind of go down this road, get there before engineering says, "wait a minute, our whole company production lifecycle has been based on the assumption that we're never going to ship, now we've got to unwind and figure out all of these things." So, those kinds of assumptions are very dangerous and can get you in a lot of trouble down the line. For my clients, I generally say, "look, if you're a SaaS company, plan on being a SaaS company, but don't discount the fact that one day the strategy may shift, and have a plan in place for how are you going to react to that and what are you going to change to make that happen."

Dariush Griffin (26:42):
There's one topic I want to get to before we close down here, and I think it's been in the news quite a bit. And that's Copilot. For those of you unaware, Copilot is an AI-powered pair programming tool that will essentially offer suggestions that have been generated from open source that's been run through machine learning, essentially. I'd be interested to hear what your thoughts are around that, if it's a good idea, or what kind of legal questions or little conundrums it might raise.

Filipp Kofman (27:08):
Yeah, Copilot is really interesting, and I'd love to hear Adam's perspective from a developer perspective. From a legal perspective, from my perspective, it raises two questions. Is it legal, and is it right? And those are two separate things. From a legal perspective, Copilot is, like you said, it's basically an auto-complete for code. It's in a category called generative AI where it is trained. Github uses OpenAI's technology. Took the dataset of the code in public GitHub repositories, a lot of that is open source code, using a machine-learning algorithm trained a model that helps developers auto-complete their code. And for a lot of developers now, people are saying, "look, this is replacing StackOverflow."

Filipp Kofman (28:07):
I'm going to this to figure out what I want to do. In terms of legality, the open source, the code that the model is trained on is copyrighted code. But the model is not actually copying and pasting code. It is generative AI. It is creating new code based on learnings from the other code. It may be that by happenstance some of that code is identical to some of the code that it trained on. But it should not be copying any snippets of the code it trained on. This is a fast-moving area of the law, and then there are no settled answers here. But the general understanding right now is that training a model on copyrighted content falls under what's called a fair use exception in US copyright law.

Filipp Kofman (29:02):
You can do it---so long as you're not actually copying the snippets of the code itself, you can train a model on this. So, that is the legality of it. Not 100% yet. There's a lot of litigation in this area. There's governments both US and outside of the US looking at this question. But that's kind of where we're trending right now---that this is legal. The other question is: Is it right? And the "right" aspect is, well, is it right that it's training on this code and the developers are not getting any benefit of it? They've contributed the code under an open source license. Maybe it's like a GPL license where the understanding is that if somebody uses my code and modifies it and makes derivatives of it in this general sense that should also be under a GPL. But now that's not what's happening here. So, I know there's a lot of consternation in the development community over that. I'm curious to hear Adam's perspective as a member of that community about how that's being interpreted and what the sentiment is.

Adam Such (30:07):
Yeah, it's really interesting. The whole snippet thing's been going on a long time. It kind of comes and goes, the arguments about snippet matching. I work across quite a few industrieswork with customers across those industries. And I found that the embedded world, for various reasons, have been quite aware of snippet match for quite a long time. I think it's partly because they obviously ship product and trigger some of those licenses, physical product with embedded software. So, they're much more aware of those licenses because they often trigger more easily. But it's also because they work in C and C++, and I think those kind of communities have long looked at snippets because there's no central community around how these open source projects come in. So, they tend to actually just copy code, copy bits of code often rather than pulling whole libraries themselves.

Adam Such (31:02):
So, that kind of world has been long battling with: What constitutes a snippet? Is it aligned? Is it five lines? Do I have to take it from a certain place? And they've kind of been thinking about that a long time. There's tools that focus on that community, but then in the web world that I work with a lot that's using npm, Java, I feel like that awareness is completely removed, and there's a complete break between those different communities. And that's for good reason, because they often haven't been copying snippets of code. Why would you copy part of a library where you could just pull in the whole thing from npm or Maven? You're just going to pull in the whole library and use it. You're not going to go and break it apart and understand the code. Just pull in the whole thing and just use part of it. So, it's an interesting thing that we kind of started this whole conversation up again around a completely new product that's brought up old arguments really.

Kadi Grigg (31:55):
So, we have about five minutes left, and I'd be curious to get your thoughts. We've talked a lot about how licensing works, the different types of licensing, impact of choosing poorly, and even this new wave that Adam said is coming and going in regards to snippets. But what I would like to get from each of you is your final thoughts on what wicked good development under the lens of legal compliance looks like to you guys, and what your best advice is for those who are either just starting out or maybe in the thick of it right now. Filipp?

Filipp Kofman (32:29):
Yeah, I would say don't ignore the licenses. If you're an independent developer or part of a small team, you don't have legal help, that doesn't mean that you should just say, "you know what, I'm just going to ignore this completely until I grow enough to hire a lawyer to help me with this." There's a lot of this that you can do yourself. And there are a lot of really good guides out there that can help you interpret these licenses and help you start implementing these good open source hygiene processes that will carry you forward. So, on that side, I think that is a good strategy to take. If you're part of a bigger organization and there are legal stakeholders around that are interested in this topic, work with them. Legal does not have to be your enemy. It can be your friend. And sometimes legal does introduce difficulties, but usually it's for the good of the organization and to save you time in the future. So, try your best to help them and have them help you.

Kadi Grigg (33:43):
Adam?

Adam Such (33:44):
Yeah, this is a great point Filipp makes. It's got to involve legal, but also development---the two-way communication's important. Having those policies by fear---lawyers often approach it like most of the things they do. And it's understandable, like a bit of a tickbox exercise, and a one-off kind of tickbox, and it's done. But I feel that people who make the best use and get the best results create a two-way communication, shared language, and set the expectations of developers, but also enable developers to make the right decisions. It's often presumed that developers don't want to get involved in legal. And they often back off and say, "I don't want to touch legal in the first instance." But I find once they start to understand a little bit about the legal, where the distinction between what they can use and can't use, they become interested in what those legal terms are. Most developers, by their nature, like open source in principle and aren't against open source. Most developers contribute in some way to open source. So, they're kind of invested in it anyway. So, understanding when they can use it at work is important and normally going to be quite an easy process.

Kadi Grigg (34:56):
Final thoughts from you, Dariush?

Dariush Griffin (34:58):
Oh man, you're giving me the final word?I'll take it.I agree with everything that's already been said. It definitely looks daunting. However, there's a lot of tools that can help you,and definitely don't ignore it. If you're working on an open source project yourself, pay attention to how you've licensed your open source project, pay attention to how your dependencies have been licensed. It'll help you down the line if that open source project is ever to gain wide adoption. That's your goal. Please pay attention to your licensing. If you're working in an organization,just know that you probably have departments or tools that can help you make make sense of this, but definitely don't ignore it.

Kadi Grigg (35:38):
Couldn't have wrapped any better myself. Thank you guys so much for joining today. I really enjoyed the conversation.

Filipp Kofman (35:44):
Thank you very much. This was great.

Kadi Grigg (35:48):
Thanks for joining us for another episode of Wicked Good Development, brought to you by Sonatype. Our show was produced by me, Kadi Grigg. If you value our open source and cybersecurity content, please share it with your friends and give us a review on Apple Podcasts or Spotify. Check out our transcripts on Sonatype's blog and reach out to us directly with any questions at wickedgooddev@sonatype.com. See you next time.