the call today. I'm happy to get to speak with you and appreciate your time. Looking forward to sharing some of our practices and thoughts on open source licensing. So I think for the talk today we're going to start with looking from the licensing side, talking about what open source means in that context. So starting with a broad look at it, starting with a kind of broad and informal definition, then narrowing down from that to looking at some of the specific definitions that are out there from some organizations around what open source or other similar terms mean. From there we'll then talk about some of the underlying legal mechanisms such as copyrights and patents that drive the way that open source licenses work in practice. Then take a closer look at some of the different types of open source licenses and ways of categorizing to think about them. We'll look at the moving then from the substance of the licenses. We'll look at some ways that when using them you can more easily manage open source license information in your projects and in your code. And then finally we'll talk briefly at the end about the ways that license concepts work in contributing to open source projects. And throughout this at the end of the slides we'll be making the slides available after the call. There's a number of resources at the end that'll be of use to you. And if we have time after the Q&A I'll go through and touch on some of those resources. So let's see what that will go forward. So feel free to contact me after this as well if you have questions or if you want to follow up on anything. I should note here I kind of the obligatory statement. I am a lawyer. I'm not your lawyer. So I'm not able to give you legal advice. So what we'll be talking about today are general think of them as general community understandings of these concepts. If you're looking for legal advice you'll want to look at the if you want to understand how a particular license works in your particular case you'll want to talk to your own legal counsel about that. So here we go. So when we're talking about licensing what does open source mean? And you know when we talk about open source broadly away from the legal and the licensing context it can mean a lot of things. But what I want to do is try to narrow down on a specific meaning of this that you've probably seen elsewhere if you've looked at open source in the licensing context before. So you know informally we might think of open source as being some people may think of it as being just software that you can download for free something like shareware or freeware or people might might incorrectly think of it as being source code that you can download for free. If the source code is available does that mean that it's open source if you can just get access to the source code or if the source code is available and you can contribute back to it. If there's a project if there's a community that people can take the code change it contribute it back to does that make it open source. And what I want to focus on for this call is that for purposes of talking about open source what we really want to focus on it being software is open source if the source code is available under an open source license. That might sound circular but you know it leads to the question okay what is an open source license. And as I said we'll get to we'll look at some of the formal definitions a bit further down the call but we'll start with a broad kind of informal look at what an open source license means. And so I want to I want to do this broadly to help you kind of get a sense for what for what an open source license means. And so informally what these are what I would say are kind of some of the key traits of something being an open source license. The first is it's a set of legal terms so a license is a legal document that's granting rights and so it can be a short as one sentence it can be multiple pages long but it's a set of legal terms and those terms grant broad rights to use modify and distribute software. They grant those rights for both source code and for binary or object code form of the software. And that's something that you know the the context in which some of these licenses were made in some cases assumed that there was a distinction between source form and binary form in some programming languages and some ecosystems there that might not necessarily apply as a difference but for these purposes we'll assume there is that distinction between source code and binary code or the binary being the compiled source code. These licenses or open source licenses are typically written for use with any type of software so not typically not focused on a particular type of technology and they're typically standardized to an extent there's a specific set of terms that make up the license and there's generally speaking there's there's a you'll run into hundreds of different licenses out there if you're looking in kind of all the corner cases but there's a small set of the most commonly used licenses and these are typically standardized so this is unlike proprietary software where proprietary software often you'll have a different end user license agreement for every product or for every service that you're getting for open source licenses there's a small set of the most commonly used licenses that generally speaking will stay the same from case to case so and the key part of all of this is that they typically impose responsibilities or conditions on redistributing the software on using the software they do not typically impose restrictions on using it so they'll say essentially if you redistribute then you must do the following and for certain permitted things that are of those conditions but they won't typically say you may not redistribute the software or you may not use the software if it said something like that although certainly it would not be an open source license um so let's look in at a specific example so we'll go with the MIT license which is one that if you've looked at licenses before you've almost certainly run into um and this is and it's also you know hopefully it's one of the shortest open source licenses that's in common use so it's one that even you know that you can look at and get a pretty easy grasp around what it's what it's saying so the MIT license it's three paragraphs they're very short it's less than probably probably about half a page if you were to print it out um but what I've done here is to emphasize to bold and highlight a few of the the key phrases of it so looking at the first paragraph says permission is hereby granted so this is a granting of rights it's a granting of legal rights to deal in the software without restriction so granting permission to deal in software without restriction there's then examples of what that means including without limitation a series of other things but kind of those are sub those are uh given as examples of subsets of dealing in the software without restriction so that's the license grant and then at the end here sorry for the highlighting at the end here subject to the following conditions so what are the conditions the conditions are the above copyright notice so the copyright notice at the top and this permission notice this license shall be included in all copies or substantial portions of the software so the rights that are granted are this broad set of rights to deal in the software without restriction the condition the responsibility is to include and reproduce these notices and that's it this does not put forward a restriction on software it's a restriction on what you can do it says you can do you can deal in the software without restriction and then at the bottom of the license there's a uh the issue lawyers uh paragraph of all caps legalese uh i'm not going to go through that in this in this example but um that's where you find disclaimers of warranty and liability and that sort of thing so those make up part of the license i won't talk about them here but this in this unit told is the mit license and so this is um something that even not as a lawyer you know you'll want to talk to your your legal counsel for discussing how what this means in your context but just to get a sense of what it does this is something you can understand pretty easily just by looking at it steve there is a question about um are there any license uh checkers uh tools available um is this something you're going to cover later do you want to feel that it is yes that's a great question and that is something that we'll definitely turn to later we'll talk about it in kind of big picture and then at the end of the slides and the resources i've got links to a number of open source tools that are out there that can can help that do exactly this that help you find licenses in your in your source code or in dependencies that you're using so that you can so that you know what's there so that you can address it appropriately yep we'll definitely turn to that later are there any other questions at this point just that one okay great so thing going on um so that so up till now i've been talking with a pretty informal definition of what open source licenses mean um there are two the the open source initiative and the free software foundation have both put out um kind of well established definitions of what they mean by open source in the first case and free software in the second case so in the case of open source initiative osi um they they are the stewards of the open source definition which is a ten point essentially a ten point checklist of a license has to meet these ten these ten requirements in order for it to be considered an open source license so the informal definition that i talked about earlier it it didn't get into all you know i didn't get into all the details of what this includes um but the they have both their list of the ten points that they use to define what is an open what they'll approve is an open source license and then at the link that i've included here they include annotations which explain in some more detail each of those ten points for the open source initiative there's a license review mailing list so they have an open process for how they how they take submissions for new licenses to be considered and evaluated by the community and then whether or not they're approved by osi to make that determination whether a license meets those requirements and that they'll approve it as an open source license so in the case of the free software foundation they have the what they define as the four essential freedoms for something to be considered free software um and so there's those are essentially it's their four points of what they say how they look at licenses and so just in a nutshell it's that they require that uh that the software can be run by run for any purpose that it can be studied and changed uh that it can be redistributed and that you can redistribute the changes that you've made to it so again i'm summarizing that's just in a nutshell but that's what the fsf uses to define something as free software and the way that they look at licenses so these are two different i wouldn't say that these are opposites by any means i think these are two different lenses through which different folks evaluate licenses and think about them um and in most cases and certainly for any of the regular cases that you're going to typically encounter in practice virtually all open source licenses and virtually all there's going to be overlap between the most common licenses that they will be considered open source and free software if they're one or the other so um okay so then with all that is the background let's get into a little bit of the legal underpinnings of all of this so we've talked about licenses we talked about the fact that licenses grant rights so what's the basis for someone being able to grant these rights um and what it is is there's a couple of different different uh legal concepts that are established in national laws and these are these are gonna they differ from country to country there's some harmonization of them across there's a lot of harmonization of them across countries because of treaties that have been established but um i'm going to be talking primarily from the u.s perspective just because that's that's what i know um but we'll look at copyrights and patents primarily and then we'll turn to a couple of other things so copyrights are the key one the key legal concept that drives the primary way that open source licenses work and so copyright is something that's a legal right to control um original creative work that you've created um and here creative work is uh this can this originally when copyright was created this would have been centuries ago so it was more in the context of written of uh you know books published materials in that sense art that was created those those sorts of things um it's understood that copyright extends to software software in the u.s has seen as being a literary work it's included in that category because it's a because it can be written out the same way that a book or a written work can um and so these these legal rights in the u.s the owner of a copyright has the exclusive right to do a number of things and those exclusive rights include that that copyright owner has the is the only person by default under the copyright laws who has the right to copy the work to reproduce it to prepare derivative works based on it so to modify it or you know we could we could spend an entire separate session on what exactly derivative preparing derivative works means but for these purposes think of it as modifying or incorporating the work into other things um distributing copies of the work or publicly performing publicly displaying it so by default in the u.s and this is a key part of it too when you create a written when you create a work when you create software that is creative that kind of meets the minimal the the minimal threshold of being creative and you fix it in a tangible medium when you do that you or depending on the context you or your employer owns automatically owns a copyright in that work so you don't have to register it there is registration you can someone can register their work with the copyright office that's kind of a separate concept but just by fixing it in a tangible medium the the creator of it now owns the copyrighted and that's that's really the fact that that automatically happens is really the reason why it's important to care about open source licenses because in the u.s the law is going to say that once you've created something you now are the the the owner of the exclusive right to do these different things so if you take code that you've written and just put it up put it up on github put it up somewhere for people to access and don't grant them a license don't say anything about the license to it the everybody else doesn't know whether they actually have any rights to use it to to use it to copy it to change it to do anything so by putting an open source license on open source work that you create it lets the community know yes i am officially saying you can do these things i'm giving you permission to do these things um so i see there there's a couple of questions in the q&a let me let me look at those quickly um so see there's there's a question about um so we talked okay we talked about the uh we'll come back to the uh the frameworks for checking licenses um the there's a okay then there's a question about um comments that if you don't have the i think the question here is if you don't have a year on a copyright notice if you don't have a copyright notice with the c in a circle or if you don't kind of go through these particular formalities does that mean that it's not a copyright and so that that's um yes if a to have a copyright in in a work that you've created you do not need to go through those formalities of create of putting a notice on it in any particular form so it used to be the case in the us several decades ago it used to be the case that in order to have a copyright you would need to go through certain you'd need to include certain formalities you might need to include the word copyright or include a c in a circle or include a notice in a particular format that's been changed so current so under current law to own a copyright in something you don't need to go through any of those formalities you um just by creating it and fixing it in an intangible medium you now own the copyright in it um the there are we've we've put we've put out at the lf we've put out some recommendations to projects because we get these questions all the time about um what it should i be updating the year on my copyright should i be doing a certain other thing a year on my copyright notice should i be doing it in this particular format we've put out some uh some what we recommend as best practices for how open source projects can handle this um in the resources at the end at the end of the slide deck there's i've got a link to a blog post where we've put out these practices so i'll i'll i'll go to that afterwards um and we can we can look at that in a little more detail so um but here for so copyright because of that automatic creation and automatically applying to in most cases creative creative level of software that's uh that's fixed and made available um it's because that copyright and there's exclusive rights automatically apply that's why there's it's important to put a like put an open source license on work that you're publishing for with the intent of other people being able to use it and copy it and exercise the rights under open source concepts uh and i'll look at one more question so there's a question also for an open source project with multiple creators whose copyright and country apply fantastic question um also going to be something that is is a complex um fairly complex case by case basis but most projects most projects that i'm aware of will look at it as each contributor owns the cop owns a copyright in their contributions to it so the original the original work would have um the original work would have the copyright the copyright would be owned by the original creator other people who contribute patches to it or changes to it or additions own a copyright in their contributions to it so i see there's there's a question can you unmute to ask a question sure let's we'll go ahead and take one more question then then i'll move on and we can come back to other questions afterwards but yeah if you want to go ahead and unmute um i'm not you may be you may still be on mute i'm not hearing a question if there is one uh hi steve oh welcome yes uh my name is gilshano strucker uh i'm from uh surinamo uh it's a small country in uh south america hi everyone uh so in my country we do not have uh we do not have a law for royalties and for things for things like copyrights but if i do want to put a copyright on something i created how can i still do that yeah it's it's a it's a great question and i this is this is the sort of thing where i have to be very upfront that i'd be i'm you know i'm a us-based lawyer both since i'm you know since i can't provide you with legal advice but also because i to be honest don't know about the legal the legal system in your in your country i really wouldn't be able to tell you what is you know what's permitted what the process would be and whether there are you know certain formalities you need to go through um so yeah i i apologize that that's really something that i just don't i don't i don't have either the expertise or really the uh the ability to be advice what do you think that maybe if i say uh create my stuff and um i don't know let let it be copyrighted in in in another country or in the the region of my of of of where my country is like like um i'm from south america and maybe our region is uh south america you have north america maybe there's some kind of region i can still copyright my stuff yeah i think i think you'd really you'd really need to look at your own local your own local laws and either talk you know find find an attorney there to talk to or take a look at the the laws that would apply for your country yourself i really just unfortunately i don't i don't have the ability to know to be able to tell you um you know whether it's something that you could you could you know in your case shift to a different country somehow or how that would work one thing you could do one thing you could do would be to you know if there are other open source projects that have come out that you're aware of that have come out of your your country you know you could look at what their practices have been just to get a sense for how other people may have approached this okay steve thank you thank you all right so then going on um so we've talked about copyright as an overview let's turn to we'll talk briefly about patents as well so um so where copyright applied to legal rights to control a specific creative work so a specific program that you've written for patents it applies to control an invention so essentially to control the uh a concept that somebody has taken and built and embodied and in the u.s um again there's a set of exclusive rights that the owner of a patent has and the owner of a patent has the ability they're they're the exclusive ones who can make the invention who can use it who can sell it or offer it for sale or who can import it into the u.s um and again this is a summary there's many many more complications here we could get into but um there's a couple differences between excuse me between patents and copyrights one of the key ones is that patents do not automatically exist just the fact that you you know like what we talked about for copyrights the way that a a copyright would be um would automatically exist from fixing it in from fixing it in tangible work for an invention you don't automatically have a patent just by inventing something what you have to do is you go to the patent the in the u.s it's the patent and trademark office you apply and you have to demonstrate to the the patent and trademark office that your invention is useful that it's a novel it's something new and that it's non-obvious that it wouldn't have been obvious to anybody based on what already existed and there's a lot more we could you know again kind of entirely separate talk on how those concepts apply in practice but the key thing here is that um patents do not exist just by the fact of somebody creating something you have the a patent order would have to go and actually apply for it and take these steps to get a patent so um because because of the way that uh that the patent laws of or and the way that they're interpreted in the u.s have evolved over time patent considerations are something that open source that users of software of any sort open source or not any sort of uh developer of software may may be considering what patents uh whether patents apply and for for today's purpose is what i'm going to talk about primarily is around how the supplies to open source licenses so in when you look at an open source license we talked about the fact that it'll um that it will uh that's focused around copyright around granting copyright rights in addition to that most licenses will in some way talk about rights that may overlap with patent rights so um in some cases such as the apache two license they it talks very explicitly about copyrights and patents it says the the apache 2.0 license has a a section that talks specifically here are the rights that are being granted essentially under copyrights and then another section of here are the rights that are being granted under patents other licenses might not be as clear about this they might not explicitly use the word patent when they're talking about what they're granting so there's some there's you know differences of opinion differences of views around how certain licenses might apply to copyrights versus patents but um i'm going to go ahead a couple slides i'll come back in a second but for instance when you're looking at the mit license if you remember when we go back we go back to look at that we had that section in there that said to deal in the software without restriction and then listed out examples so including without limitation listed out examples of some of these rights and when you look at these examples you'll see you know here the way that the mit license is set up it's not as explicit about which rights are patent versus copyright versus whatever some of the words that are in here are more copyright focused so copy or distribute or the sort of the sort of words you'll find in in the us that you'll find in copyright law other words like using or selling sound more like patent terms and then there's other in others in here that don't that don't really show up in those in the laws at all so something like merge is more of a term that you'll find in you know in practice and software development but it's not something that the copyright or trademark laws use that term to talk about so the way that you look at the mit license and think about how it applies to copyrights or patents may be different from the way that you would look at a license like Apache where they're very explicit about those two those two different concepts Steve there are a few questions do you want to feel them now or later um let me see so there's a question about where's the line between an invention and an idea for being recognizable being a patent um that another excellent question that is something that uh that we could again spend a whole lot of time talking about and I think for for purposes of this call I'm probably not going to get into detail about that because that's a really that's really focused more on how someone at what point someone would be able to go and apply for a patent in it's going to vary by country in the US typically some aspect of it is going to be able is going to be uh being able to demonstrate both those things that I mentioned before so it being a novel invention something that's useful something that's not obvious um separately there's typically going to be some aspect of being able to show that you've reduced it to practice that you've actually built it that it's not something that's just kind of an abstract concept or an abstract idea um there's other other pieces like that it's a you know like unfortunately like many things I'm going to I'm going to be saying it's it's a complicated thing um but yeah that's it's there's a lot of pieces that go into it so it's not something that the the main takeaway I'd say is it's definitely not something that's going to be as automatic as creating uh as having owning a copyright in the work that you've created um I see the scheme so sorry um so we have um one question that came through the chat and then one attendee that would like to unmute and ask a question which one would you like to take first uh let me just there's a couple in the chat let me just take a couple um a couple things here quickly in the chat and then we'll go we'll go to unmute um so there's one I see here from earlier I think about what does tangible medium mean so this was in the copyright context um so this is the this is the wording that's used in the wall it's going to again it's going to be different in different contexts because um you remember if you remember the copyright laws are written not just for software but for you know kind of essentially any sort of creative works so when we're talking about written works like books it would be it would be the book itself um or or essentially writing it down writing something on paper fixing it on paper that paper is the potential medium so it typically you can think of it as something that exists that can be perceived and that that is not just you know sitting in your head um in the case of software I would say generally you know I think you'd see it as when you're you know I don't want to get too far into details here but when you if you're saving something to hard drive if you're making it available online um you know from something like github site things like that I think those are typically going to be seen I would expect as it being fixed in the tangible medium of existing on hard drive so there is a question Steve about making changes to the Linux distro I can read that out to you if I make changes to a Linux distro will I be bounded by the licensing issues for redistribution or can I redistribute my version of the Linux distro to multiple users so so what I'd say there so the the the Linux kernel is under the gpl2 license and so in looking at what you're permitted to do there the starting point would be to look at look at the gpl um and specifically the gpl version two there's multiple different versions of the gpl and for for the Linux kernel it's gpl2 um so when you look at the gpl the free software foundation is the stewards of that license they've written a number of things about that license and what it means and so they have a lot of guides that help that can help people understand not just the kind of the the not just looking at the legal wording of it but also how how you can use it in practice and what rights it gives you and so if you mentioned if you remember earlier I talked about the the different four essential freedoms that the FSF talks about so the freedom to run the program to study and change it to be able to just redistribute it and your changes the FSF you know as the authors of the gpl they've made it clear that they that they view the gpl as embodying those freedoms and so I think certainly certainly you can look at it and say yes it permits you to do those things what you would need to look at and what you need to look at in the context of your specific case and working with your legal counsel usually would be um what are the obligations that go along with that so I'll come back to that later in the talk when we talk about some of the different types of open source licenses but really that's that's the key thing is that the license you know speaking broadly the license licenses that are open source licenses or free software licenses don't say you may not x they say you may x you may do whatever but in for certain things there are these obligations or responsibilities that go along with it and so we'll turn we'll turn to those a little bit more later on um I see there's one more question in the chat let me um let me look at this and then I think there was one more to come off mute so we'll look at these two and then I'll go on and then we may come back to the Q&A further at the end um so there's a question in the chat about if I could address the patentual problem as it relates to trolls being able to take us take advantage of open source projects that are not Apache 2 so I see that's that's the question in the chat so what I what I'd say there what I think that's referring to is um so as I said before some licenses Apache 2 being one of them there's many more but Apache 2 is one of the licenses that talks about that has specific language around saying first here is a copyright grant under my as the contributor under my copyrights I'm granting you these these rights that second there's a there's a section that talks about patent licenses so it says as a contributor to this project under my patents if I had any patents I might not but if I did I'd be granting me licenses under those patents within the scope of what it describes and so um in a lot of cases people who are concerned about patents might prefer using software that's under a license like Apache 2 and there are many others there's many there's um some of the the weak and strong copy left licenses that we'll talk about later such as gpl3 some of the others um have sections that make this distinction that talk explicitly about copyrights and patents and so people who are using maybe some people who are concerned about patents might feel more comfortable using software that's under those licenses because it explicitly says that the contributor of code to that project is granting licenses under any patents that they may have regarding their contribution so that may help may help remove some concerns that people might have about if I'm using software under under one of these licenses I know you know explicitly they've said I'm getting a patent license for other cases where other licenses that might not be as explicit the question would be to what extent are patents owned by the by the contributor being licensed under that license and I'll say I think it's an open-ended question I think that there's you'll find disagreements about it for any particular license um kind of across the community so I'm not going to I'm not going to kind of get into specifically which licenses say this or that and what and what they mean but that's kind of the framing of it is that um with regards to contributions to a project looking at the license what's the scope of the license and does it encompass copyrights as well as patent rights and patent licenses so I think there was one more there you'd mentioned there was one question someone who wanted to come off mute if you want to go ahead and ask that yes I believe the attendees name was Mert and I'm sure I'm not you may not be pronouncing that correctly yeah hi Mark welcome I see I see the comment in the chat if you want to come off mute and go ahead last question thanks for the presentation first and happy new year I'm living in Turkey but uh volunteering to uh some foundations uh like Frisbee Foundation, FreeBSD Foundation uh in some sense not directly so I want to volunteer the Linus Foundation too I work with a project uh called Layer 5 uh I volunteer maybe it's uh more native in your range so my question is uh when we have meetings with FreeBSD Foundation we have a we have an application called scan code scan code tool gifts do you know that I yes I do I do know scan code and that is one of when we get to the uh to the end of the presentation in the or towards the end when I'm talking about managing license information I will talk about scan code and and some of the other things out there my question is in short I am in I'm into I'm keen to learn artificial intelligence for legal issues for both security issues like physical security or cybersecurity and licensing uh in short in other words uh I want to make a software and a framework or make existing better uh the and then Linus Foundation may use it or not but it is not about me uh we need a better solution rather than uh the existing one I don't want to make a speech or hate speech of course but I'm I do research for that I want to tell you about that great so thank you so that's that's that's really interesting that's great to hear so I think what what I'm what is your opinion in other words my question what is your opinion what should we do for licensing software sure yeah so so a couple of things so I'll get into some of the some more of the details further along towards the end of this talk and and in the resources at the end of the slides I've got some other some other comments on that but so I will get into talking about some of the details of what we're doing and some some Linux Foundation and other projects that that are looking at this specifically with what you're talking about for using for instance artificial intelligence to help supplement the ability to search for code search code and look for licenses part of that I I I know I believe within so phosology is one one project for that can be used to scan for open source licenses and I believe there's some work they've been doing in the past year or so to you know they have a number of different strategies different agents that can be used to search code for license information I believe there's one that is looking at using some artificial intelligence concepts for that so that could be a place if you're if you're interested in participating and getting involved that could be a place to look at um and I'll come back to some other parts of it as we get towards the the later part of the talk I just want to make sure that we um I'm kind of setting the context for the uh describing the considerations for open source licenses then I think we'll turn to some of the the more practicalities of how you manage that information afterwards so thanks okay then talk to you later great thank you okay um so we're going to keep I think we're going to keep going um so we've talked about copyrights and patents um I'm going to just briefly touch on a couple other a couple other legal concepts um so and we're we're not going to spend much time on either of these and you'll see why but so for uh in addition to copyrights and patents another additional kind of legal framework for rights are trademarks and so trademarks are the legal rights to control a mark so it's a mark being a brand a name or a logo that the purpose of it being to designate the origin of goods or services so to say where these these goods the software these services come from to do that you know people or organizations associate their name or their logo their brand with those goods and in the US there and in most countries there's going to be some rights that are given to owners of a mark to be able to protect that mark and to be able to use it in connection with the goods the services they're offering so in the US you can kind of similar to some of the others you can apply to register a trademark with the patent trademark office in the US something that is different from a lot of other countries you can also get some unregistered trademark rights just from using the trademark so just by going out there and using your mark you can accrue some some they're sometimes called common law rights in the trademark um one thing about trademarks is that they're not typically seen as being explicitly included in most open source license grants beyond certain circumstances and this kind of makes sense if you think about it so even though you're having the right to use you know to use software to copy it to redistribute it to do all these things that doesn't if you open source software even though you're allowed to do these things that doesn't necessarily extend to you can then declare yourself to be the project itself to be the source of the project there's kind of that distinction between the project using a trademark to say this is who we as the community are um and people participating in that community but preventing but not having organizations or individuals kind of being able to declare themselves to to use that trademark to declare themselves um kind of the owners of that trademark for other purposes so it's a complicated topic we won't get into it in kind of more detail here but just want to raise that is sometimes questions come up about how do trademark power trademarks addressed in open source licenses and again there's a range some licenses we'll talk about them explicitly others won't but it's something you'll want to if you're if you have questions about this in a particular case you want to look at the particular license and see whether and how it talks about trademarks and then finally there's one kind of if you uh if you go to a lawyer who is not uh kind of not open source focused and ask them what the you know sometimes they'll use the heading of intellectual property to come to cover a bunch of these different concepts um you know with kind of without getting into debates about what that term means if you ask someone who isn't associated with open source they'll often include something like trade secrets or confidential information in the bucket of things that are loosely thought of as intellectual property and here you know trade secrets in again in the U.S. or primarily thought of as legal rights to control information that the owner takes some measures to keep secret and where that information has value from not being generally known and the reason we're not really getting into this here is because it's basically the opposite of open source open source you're taking you're taking you know someone who's contributing to open source is willingly making everything available making it public and making it available for people to use under the under the open source license and so you know trade secrets are really kind of the opposite of that trade secrets are keeping everything back for just to use for yourself so we won't get into that in further detail here just raising this to mention if you're looking at an open source project and you're looking at the notices in it and you see something where a contributor or if you are contributing if you see a something that says in open source code that purports to have it be confidential or something similar to that that may be a signal that somebody has done somebody has probably either mistaken some notices or contributed something they shouldn't have for in in the project so typically if everything is what it should be you shouldn't be seeing confidentiality notices in in a project and so we talked about the looked at the MIT license in light of these concepts already so we'll go on from there so I see there's a quickly there's a question in the chat about what do you need to do to defend a trademark if we have time at the end I'll come back to that that is something that is I think it is kind of outside the scope of what I want to focus on on here so I do want to keep going for now but we may come back to that afterwards if we have time so thanks um okay so then moving onwards so we've spent quite a bit of time we've talked about kind of building up the framework for how what open source licenses are what are the legal mechanisms in in law that they're built on top of so now let's look at what some of the broad categories of different types of open source licenses are and I'm going to present this again just both informally and from one perspective so this is another thing where if you ask if you ask five people or ask five lawyers you'll get 10 different opinions on how to how to think about this so um what I'm going to present is just one way of for someone who's new to open source licensing one way to think about them and look at at categorizing them so here what I would say is think about it on a spectrum of obligations or responsibilities so again we talked about at the beginning open source licenses will let you do essentially anything um with certain responsibilities attached to some of those actions so we'll look at licenses that are on the lesser side of fewer obligations and then licenses they're on the we'll say greater side of more obligations and this is what so kind of this framework is one way that you can approach thinking about these licenses so on this spectrum one kind of broad bucket of licenses are those that are typically called permissive you'll sometimes hear these called attribution licenses something like that I think permissive is probably a better term um for permissive licenses what this really means the main responsibility here is that if you are if you are getting software from someone under a permissive license then your main responsibility around that you know each license will have different wording but the main irresponsibility is that when you redistribute the software to somebody else you should also be providing its license and its copyright notices along with it so like it's a mit license is a perfect example of this that's where we looked at the scope of licenses in that first paragraph with the responsibilities in the second paragraph boiling down to you have to retain the the license and the copyright notices so these are called permissive licenses on the other end of the spectrum for those that have greater obligations attached with them would be those that you might see described as copy left or strong copy left and here on again on this spectrum here the the main responsibility for these again complicated you want to look at them in detail but the main responsibility boils down to if you're taking copy left software that you got from somebody else if you're taking it and redistributing it you should also be providing the same freedoms and their same rights to downstream recipients so the way this is seen is from projects that are using strong copy left licenses the intent is you as the recipient of software from them you're getting the benefits of all of these broad freedoms and rights that they are granting to you so in exchange when you're then redistributing that software of someone else you should also be providing to your downstream recipients the same sets of freedoms and rights that you receive so here this is where a strong copy left licenses would typically say you know when you are taking and creating a derivative work or a work based on or there's different terms used here but a work that's based on the strong copy left work that you got then you should also be providing or making available to your downstream recipients the source code to your own software or your own modifications to it along and you should be providing that source code under the same strong copy left licenses so that enables downstream recipients of it to continue to exercise the same rights that you would receive so to be able to take it to change it to modify or improve it that sort of thing and then in between these again on the spectrum in between these are category licenses that are sometimes called weak copy left licenses so these are those that are similar to the strong copy left there's that same concept of you preserve the rights for downstream recipients from you the differences here are typically that there are differences in boundaries for how far that copy left extends and again this I know I'll keep saying it depends varies license by license but sometimes this will say this may be something like the file the specific files that you received from upstream those the copy left left obligations apply to so you have to continue to make make available changes that you made to those to those specific files but you could perhaps use these alongside other source code that or other software that is under a different license that is not under the same weak copy left license so differences in the boundaries but somewhat similar concepts here and these the weak copy left and strong copy left licenses you'll sometimes see them called reciprocal licenses again with the reciprocal being that concept of you received these these permissions from upstream you preserve these these licenses and these freedoms and grants to downstream so in these categories there's a bucket uh there's kind of buckets of different common examples and these these are I would say the most common licenses in these categories that you'll typically run to in normal you know in in normal practice you'll find others that are outside these categories certainly but these are these are probably the most common so in the permissive category we talked about MIT we talked some about Apache as well there's also BST two clause BST kind of the whole whole family BST licenses a lot of them have a lot if you if you look at all the variants that are out there a lot of them have nuances or differences but for the most common ones they would fall into this category for weak copy left LGPL is one of the most common there's also Mozilla Eclipse are pretty common in the javas ecosystem you'll find a lot of use of the CDDL the common development distribution license and then in among the strong copy left examples the GPL and then the Ferro GPL are going to be the most common um was a question in the chat can you define copy left and yeah copy left is um what I was saying before about this reciprocal concept of licenses it's this idea of preserving and when the rights that you receive from the upstream source of the software being obliged to preserve and make of it provide those same rights to downstream users of the software um for the I see there's a I'm going to answer one more question there's another question here about the the source forge platform um about changing program code structure and selling to others I don't I I'm not familiar with the specifics there so I don't think that's something I'm going to be able to in on here I'm sorry so great all right um thank you and then going on and sorry just to be clear on that I'm not familiar with the specifics there I I so I don't want to kind of weigh in with uh with details without no without knowing more about it so um I see there's another question about how to join the Linux foundation um so the Linux foundation so members of the Linux foundation are typically organizations and companies so um there is there is an individual sponsorship mechanism that's that you can find out more about on our website um but that's when it comes to actually membership in the Linux foundation um for for the organizations that are members separate from that any of our open source projects are open to the community to participate in on the technical side so there are um they're fully open anyone can come and as long as they're they're complying with the the um you know the policies the the the IP mechanisms the other things that we'll talk about a little bit more later in in this this talk um anyone is welcome to participate in our in our projects on the technical side and so that's something that there are there are mentorships there are other um you know other ways kind of on ramps for people to get more involved and if we have time we may talk about some of those right at the end um but yeah there's there are many different profiles and many different skills that skill sets that can be um that can be used and in contributing to projects so a lot of open roles and a lot of ways for people to participate um couple quick other other comments uh what about zero bsd um so i'd say zero bsd falls in that same permissive categories typically how that would be seen um for mit what has to go into the license dot txt file in source code root um that is so again here i i'm not going to get too much into the details of what specifically you have to put in which file for complying with which license and partly just because it varies so much in different use cases but what we will do as we get on is we get to managing license information um there it is something that there are best practices that we recommend and i'll be i'll be talking about some of those so i'm going to go on i'm going to keep going for now just want to make sure we get through everything in this um so briefly there are there are things other than software i've been talking entirely about software here but when it comes to open collaboration there's a lot of different types of content that is contributed and that can be worked on collaboratively in projects there's documentation there's other creative written and artistic content there's open data um there's even a growing open hardware space for hard for hardware designs um i'm not going to spend more time on these but just want to note for each of these there's um some parts of this may be covered by open source licenses um particularly around documentation some open source licenses will talk about documentation but there are subsets of licenses separate from open source software but other open licenses that do focus on each of these different areas so notably the the creative commons licenses for creative written and artistic content that's really what they're focused on and so when you're when you're looking at what license to apply to what type of content there are different categories of them out there so just noting that for you to be aware of the last thing i'll say on this concept of types of licenses is around what kind of a growing use of a term called source available licenses so this is where going back to the beginning of what we talked about not you know just the fact that source code is available or even that it's worked on collaboratively in an open in a project doesn't necessarily mean that the license that it's available under is a free software license or is an open source license so those definitions the free software license open source licenses really meant to tie into the different the those terms are meant to tie into the specific definitions that osi and fsf have put out there so i think the term that i've heard used and i think is is useful in this context is source available to be the super set of all of those so free software and open source licenses are source available because the source code is available but for other even for other licenses where they don't necessarily meet all the requirements of that calling them source available can be a useful way to think about them and still still understand them while understanding that they don't necessarily give all the same scope of rights that a free software or an open source license would okay so we're gonna so with that let's move on um we'll turn to talking about managing license information so this is everything up till now has been kind of the substance of what our licenses what do they do what do they you know from a legal and kind of substantive perspective what do they look like so now we're getting to the details of okay that's great but what does that mean for me in practice when i'm working with open source code and answering this question this is where it'll come into some of the questions that were raised about scanning tools things like that um to be able to manage license information you have to think about what licenses are relevant to a project so the easiest one here is going to be just the project's own primary license so look at its license dot txt file or look at what it says in the project metadata or wherever it says what its license is that's kind of the primary license for that project but different licenses might apply to different aspects of the full use of the project in context and that's because the your technology software is so complex and typically is built on top of so many different dependencies and sub dependencies there's a lot of different you know each of those might have a different license that applies to them um those licenses might interact with one another in unexpected ways so getting your arms around what exactly you you before you answer the substantive question of what are our obligations you need to know okay what's the starting point for which licenses i'm even looking at and for anything more than the smallest project this can very quickly become a large number of licenses so um the um sorry the typical high-level process for what what an organization would go through when they're thinking about this would look something like this every you know every organization every company is going to have their own different specific steps that they go through but very broadly it's going to look something like this it's going to be first figuring out just what software are we even talking about so which project which dependencies which third party other components are involved in the building and use and distribution of of our software the second part is is then saying okay that's great we know which software we're talking about now what are what licenses are are those pieces of software made available third is then okay we know what the software is what the licenses are how are we using it so as an organization are we just using it internally are we redistributing it are we using it in in various other contexts like a hosted or a SaaS sort of context getting getting a handle around all of those from that you can then start saying okay now that we know all that how do the licenses apply to our context of use are there incompatibilities there are there you know for instance are there multiple different copy left licenses that are interacting with one another in a way that is problematic in a way that would say that would say you have to make like make software for instance you have to make software available under both of these copy left licenses at at the same time in a way that you wouldn't actually be able to comply with so that would be an incompatibility of those licenses and we need we need to look at what the impact of that would be the fifth part is then the fifth and sixth parts are then really okay once we know all of that once we've addressed all of this what is it that we have to communicate and provide outward downstream to two recipients of our software for us to continue to be compliant with our responsibilities under the licenses so what information do we need to provide if there is source code we need to provide under a copy left license or if we are or whether whether or not it's required if we're providing source code how do we make sure that we do that as part of our building release process so for the for the the next several slides I'm going to be focusing really on those two on steps two and five so how do we identify the licenses how do we communicate that information outward so on identifying the licenses the challenges here are um first off the scale it's that if we're you know if we're talking a very small project that just has one or two dependencies it might be something you could do manually if you're getting beyond that and in some you know in some programming ecosystems even the smallest project is going to pull in potentially hundreds of other dependencies the scale of doing this manually quickly gets out of hand so the uh the difficulty of it as well comes into play so it's something that um if all you were talking about was kind of perfectly well formatted well structured data it might be something that could be easily parsed but the challenge is that you still find um you find license notices expressed in a wide variety of different formats including in many cases in what basically boils down to natural language so you're looking at doing natural language parsing or using other techniques to figure out what licenses apply if you're doing it in some sort of automated way and then last part is it's just not fun you know for most people this is not why they got into uh to programming it's not not why they got into open source to uh to be going around and trying to parse a whole bunch of different licenses and so um you know all of these are things that become roadblocks to having this be something having kind of license identification and compliance be something that is automatic and handled regularly and so um so I've touched on a lot of this already um but there are there are various one of the key things I would say is that for larger projects and here I mean both I'm talking about both open source projects as well as um you know organizations that are developing internal software or even if they're developing proprietary software that uses open source tools or uses open source components kind of any any of this if you're building something that's more than just a small project if it's something that's a larger project or product or service it's going to be something that managing all these different pieces of data is going to be something that's hard to do at scale without some sort of automation or tools there's a variety and fortunately there's a variety of tools out there that can help with this and there's ongoing efforts to develop new ones to address new technology areas so um at the end at the end of these slides there's I'm going to have in the resources there's some more specific open source tools that I'll talk about so I'll come back to this a bit later um but the the key thing I would say here is that what's really important is to pick one of them understand what it does and what it doesn't do because certainly you know like anything none of these tools are perfect each one of them is using some different mechanisms some different strategy to try to approach a certain piece of this problem and so it's important to pick you know pick one tool start with a tool if you're not using any right now start with one understand the scope of what it does and incorporate it into your development process and then as you work with that understand what it's not doing look at whether there are additional whether there are gaps that should be additionally addressed figure out ways to address that so kind of like any other sort of software development I would say look at this as something that is more area for continual improvement rather than you know needing to find the one perfect solution that's going to solve everything from you know from day one if this is something that you're not doing already so see there's one question in chat I'll address quickly it was a question about the the prior slide where we talked about providing source code does this just apply to your own work or also on dependencies that you use again this is one of those where it is going to largely depend on your specific context in your specific use case so what are the dependencies you're talking about are they something that you're just you're distributing or that the user is obtaining themselves is the work that you're where you're making use of those dependencies is your work using them in a way such that your work becomes you know I'm using air quotes here but your work becomes a derivative work or becomes a work based on that dependency or something else those all go you know if the if the answer to those questions is yes then in the case of a copy sorry just realized I'm answering a couple different questions here if the work if the answer to those questions is yes then you're likely going to need to be providing your own source code for your own modifications under a copy left license but setting that aside if you are redistributing even just the unmodified dependencies under an open source license in many cases yes you are going to have some sort of copy left obligations that apply just with respect even just with respect to those dependencies themselves and so that's why it's important to look at what are they how do we obtain them how do we track the source code from up from upstream so that we can meet our own obligations with regards to source code beyond just you know beyond just pointing upstream and saying that it's their responsibility to do that if we're redistributing those dependencies themselves we'll need to look at how we how we are responsible as well stay do you mind if I add one or two comments here so based on my previous experience I'm speaking as a developer and architect type role to see when you are designing a product and you plan to incorporate open source pieces right so then the first thing it it is beneficial to start with identifying conflicts and looking at overall peace and say which components open source components and am I planning to incorporate in my product and then look at all of those and identify ahead of time what conflicts you might run into so to save time later on it's usually counterproductive to develop a bunch of things and start pulling open source components and then right before you are getting ready to release you figure out no I can't do this so yeah great great points really really great points show and yeah that's a totally agree that particularly when it comes to this question of addressing incompatibilities that's something that the earlier in the development process that you're looking at this the easier it's going to be to be able to spot an incompatibility and address it before you've taken a hard dependency on it before it's going to involve going back and rewriting code to rip something out and find an alternative to it so yep great great points so okay so then going on so this is the up to this point I've talked about process for how you manage information so then getting into some of the technical details of you know what would you actually how do you actually do this turning to communicating the license information so we've got we've gathered the details about what software we're using we've gathered this license information how do we then provide that to downstream users in a way that's going to be effective and useful for them because part of this is you know it's kind of if you if you've heard the phrase like read it better than you found it if you've gone through this process of figuring out taking all these steps to figure out upstream what are all the different licenses involved if you can for your own project or for your own product or whatever it is if you can make that information available in an easy to consume way for your downstream users it's going to save them the time and effort of having to reproduce all of that when they are figuring out how to use your stuff so spdx is a project that has been at the lf for about I think about 10 years now maybe more that is focused on developing an an open standard for this is what's called software bill of materials information so and think of it as an ingredients list or as a bill of materials list of the different components the licenses the copyright notices and kind of as it's expanding it's it's coming to encompass other areas of information of interest about the software itself so potentially security vulnerabilities in the software as they're identified other information about the build process things like that are all part of the direction that spdx has been heading in its next version that's under development so um as and should set here part of this is that spdx itself one one part of spdx is focused on developing a the specification for an spdx document so the document the spdx document is that bill of materials so it's something that could be you know it's basically a another file with the metadata about the software that you're you're distributing and that that spdx document would contain the license information the copyright notices the security information any of these other things so one component of that one part of an spdx document this this is something that has seen uh i think quite a bit of use outside just spdx documents has been the spdx license list so this is a curated list of licenses that um the the spdx legal team which is an open team again open for anyone to come and participate in um this is a a curated list of i believe kind of approaching 500 licenses and exceptions now that have been found in practice found out in the wild licenses and license statements that are license texts that for each one it's it is when it's added to the list it's associated with a particular unique identifier and the benefit of this becomes now we can just refer to the license just by using that unique identifier and part of this is that the definitions on the license list include templating so they include the idea the understanding that licenses when they're used in practice they don't they aren't necessarily literally bite for bite every character that you thought that you know they don't match bite for bite even if they're talking about the same license so a bsd three clause license is a good example um they are there are parts in the license text itself where you'll sometimes find it modified to list the specific copyright holder in the middle of the text rather than just having standard text and so part of what the the license the spdx license list does is it gives you the ability to in your own processes when you're looking at what licenses are we talking about you can refer to bsd three clause just that identifier and know that it means this corresponding license text including that template so the benefit of this one benefit is that then these license identifiers have gotten uptake and use in a lot of other areas so there's some um believe some package managers and ecosystems that will that may even mandate use of spdx license identifiers for designating what license applies to their software um but separate from that what this also does is um it gives you the ability in your source code to be able to use these identifiers for the same way so something that we recommend to really all of our projects and that I think we've seen a lot of projects outside the Linux foundation use as well is to add short form spdx short form identifiers to um you know ideally it's to every file in an open source project or every file where it's reasonably possible you know for for certain like image like graphical image files things like that you might not be able to embed it but for source code or documentation or those sorts of files adding a an identifier as a comment in this specific format gives a lot of advantages so having as a comment just at the top of the file something that says this spdx license identifier in this format colon and then the license id what that means is a couple things first off it means that um you know this whether you whether you add this in addition or use this just by itself it's something that makes in addition to uh you know sometimes you see standard license headers that are 10 or more lines of comments saying in natural language what the license is for a file the spdx license identifiers in this format make it so that it's machine readable so it's now you can parse it just by looking for this specific phrase and it means that you can now search for it you can now grep for it um across a code base and collect all of the licenses that have been have been designated using this format so it adds a lot of advantages for making it easier for downstream users to parse and gather license information about your software if you make it if when you're providing source code you include these license identifiers in each file of a project so and then the reuse software um i've included that here that's a project from the free software foundation europe it builds on top of this short form identifier concept so it it includes that but it it builds on top of that to also include recommendations about um about which folders it kind of how to express the other pieces of license information in your project so it has recommendations around creating a licenses folder at the root level of your directory how to like what specific files to put in that what format to put them in again all of it aiming towards how do we make this information as easy to consume as possible so that there's so that it minimizes the time that folks have to spend running tools or doing searches or spending manual effort figuring out these answers how can we make it as automated as possible so that people can so that it's easier for people to do the right thing when they're compliant so um let me pause there and just look if there's a if there's a couple a couple questions um so i say there's a question about is there effort to make licensing easily easier in legal terms um so i would say so a couple things from the technical side i would say technically speaking this is a big part of it what what i'm talking about here um because it's making it easier to go through the technical process of finding a license identifying it that sort of thing um from the in terms of the license texts themselves there have been um there have been a variety of you know new licenses are always being written there's generally you know because because a lot of licenses have been you know have years or even decades of understanding kind of community understandings built up around them there's a general preference for typically for using existing licenses rather than going out and creating new ones because creating a new one is going to basically cause everybody who's using it to have to sit down you know in many cases talk to their lawyers to understand what exactly it means um so often the the preference is not to change existing licenses or not to create new ones if the goal is to minimize the effort that's going into um going into this all that being said sometimes new new versions of existing licenses or brand new licenses do come out sometimes they see uptake from different communities and in many cases those new versions or new licenses part of the reason why they might get published is to address what are seen as real what's perceived as issues or complications or lack of clarity in previous licenses so it is something that over you know over time across communities there is there is some change in this but it's kind of that balance between fixing everything to make it how what people might see as perfect versus um recognizing that there's a lot of value that's built up in what communities have been doing for decades and in the fact that even if new licenses come out all of this existing software is still under the existing license Steve there seem to be a there is a question in the chat and then also in the um Q&A that might be related can a license type change once the project has been created can it become less onerous and there is another one that is uh after creating a repo how do I choose a license you might have already answered that but those two look like a managing license part so you might want to if you want to tackle them together sure yeah both great questions so for the how to choose a license um there's a couple you know varieties of different ways I think if it's something that you're you know you're brand new to open source licensing and you're looking for guidance there's a lot of guidance you can find out there just by searching by going to you know particularly that I mentioned OSI and the Free Software Foundation websites both of those have quite a bit of information um there's other um you know and and each of them each of those organizations has different perspectives on what they recommend so you can get a sense of what they would what they would advise um I believe there's also a couple of other tools that are out there one of them I'd have I'd have to look and see I think the I think it's called choose a license the address might be choose a license.com I would need to look and and make sure but I believe it it gives you kind of a a click through series of questions that you can answer kind of yes no questions to answer to help you focus in on one of one of the handful of most common licenses that get used so that can be a good starting point for just guidance towards again big picture categories what are the most common licenses that get used at the Linux Foundation for our projects we have projects that run the gamut of all the different you know essentially all the different most common licenses that are out there so we mentioned before the Linux kernel itself is under gpl2 we have other projects that are under gpl2 versus gpl3 we have many that are in the the um the weak copy left category we have many that are in the permissive license category so we have you know we have project we work with projects that are under essentially any opens any any license that is approved by the open source initiative um separate you know there are some organizations that require their projects to be under certain specific licenses and in that case if you were working with or contributing to a project with one of those organizations you would look at what their policies are for the licenses that they use so and then as far as changing the license type once it's been created um I I'm going to hold on that for just a second I do want to move on there's one more section that I want to get to and it ties in somewhat to that question so I'm going to go ahead and move on and if we if we do have time I'll touch on that as part of this last bit so so the last the last part for the slides that I had was around contributing to projects and so everything we've talked about up till now has really been about when you are using when you're using software that you're getting open source software that you're getting from an upstream project what do you have to do to comply with it um we talked somewhat in the in the managing license info we talked somewhat about spdx and putting spdx and notices in your own files but from the the the legal side and from the licensing side let's we'll briefly talk about when you are contributing to yourself to an open source project and the main thing that I would say here is that depending on the project and depending on its policies outbound license might not be the same as its inbound license so outbound is from the perspective of the project what do they make their code available what license do they provide their code on so typically when you're thinking about what is a project's license usually you're thinking what is its outbound license but there's you know you can also think about what is its inbound license for the the people who wrote the code the individuals the organizations whoever owns the copyright in the code when they're contributing it to the project what is the license that they are providing to the project because almost always they're retaining ownership of the copyright in their own contributions the things that they made so they themselves are giving a license to the project or maybe to everybody else they're providing a license and you can think of that as the inbound license so for a lot of projects for and often for smaller projects um the they may not talk about this at all they may you know a project on that's on github or somebody you know that's hosting another place might just say here's our license our license is gpl or license is mit that's it they might not say anything beyond that but for larger projects where there's more of a focus on thinking about open source licenses and license compliance they'll often use a more formal contribution mechanism and the most common ones you'll see will be one or one of these so they may use the developer's certificate of origin it's called the dco or they may use a contributor license agreement called a cla and so for each of these so first for the dco so the the developer's certificate of origin is one text there's kind of one dco text and it's used across many different projects so you can see the text at at developer certificate dot org um it's very short it's about you know there's basically four sections to it um and this is something that that grew out of the linux kernel community so in the mid-2000s in response to the the skull lawsuits at the time and um what that what what developed out of the the technical folks in the linux kernel community was um this process and so it's a process where if you look at the developer the dco text there's a few different sections that are basically boiled they you know you should look at the specifics but they boil down to an assertion that the contributor so the person contributing code say an assertion that they have the right to contribute the code that they're offering under the license that's specified in the file so at the time that they're making the contribution to the project at the time that they make the contribution they include this assertion that yes i have the right to contribute this to the project and the the mechanism by which they make that assertion is via a sign-off in the the commit message so and it looks like the example that i've got here so signed off by colon and then the person's name and email address and the reason for doing this is really that it it builds on partly it builds on top of that that community of trust and the the importance of trust that was core to the the linux kernel community developing the way that it did um but the idea that the person who's showing up and is contributing code that in order to contribute it and before it'll be brought in they need to make the assertion that yes i've done the work i should do to be able to say i have the right to contribute this and to contribute it under the license that's specified in the file so yeah steve um we are getting very close about probably uh six seven six minutes left so okay great thank you so i i will go ahead and speed through the last part of this then um so that's the dco process it's it's often seen as being fairly lightweight because it's just this one this one statement that's added to a commit message when the contribution is made so then the other the other common mechanism would be a contributor license agreement so a cl a this is a an actual legal agreement so it's actually a you know an agreement that is signed by individuals or by employers by organizations before someone can contribute to a project so this would be a cl a is typically signed one time for each person or each organization um before they contribute there's a the there's a lot of different cl a texts out there so unlike the dco each cl a can say something different and that means that it is important to read the cl a text and to discuss it with your lawyer to understand what its impact is before you contribute before you sign it before you contribute to it and because it is an agreement if you're contributing on behalf of your employer you may need to work with your your legal counsel or your your supervisor to figure out who within your company has the authority the legal authority to be able to sign a c so um so quickly going to the questions the the reason I wanted to mention this was because around the the question about can a license type change once the project has been created so some so for projects that use a cl a for in some cases depending again depends entirely on the text of the cl a but in some cases the cl a the inbound license is very broad and the inbound license might be broad enough that it gives the the project the ability to change to on its own the project community to decide to change its outbound license from one thing to another um they typically that's not something that a project would want to do lightly because changing its license is essentially changing the terms on which everybody everybody downstream is making use of the of the code but if a project uses a cl a and the cl a provides a license an inbound license that's broad enough and every contributor has or every copywriter or has signed that cl a then in that case they might be able to change it if those things aren't the case then the other way that a project might be able to change its license would again would be if they go and get consents from all of the copyright holders of the of the project code and whether or not and how those consents are tracked and whether or not that's even going to be feasible really depends on the project and its current stage of development so a project that only has a couple of contributors that might be something where it's easy for them to change the license because they can easily get approvals from everyone something where there's hundreds or thousands of contributors and a lot of them are out of contact that might be an an extremely you know owners tasks go through and gather all of those all of those consents or to remove parts of the software from people who can't be contacted so um so projects do change their licenses sometime it is a typically a very can be a very uh heavyweight task to go through to be able to do it um all right so then with that that goes I know we've been answering questions all along but we're getting uh we only have a couple minutes left I will very briefly say um I'm not going to spend time on these here but for resources at the end of the slide so the slides will be available for download um they we do include links to a number of there's they do want to say there's a free training course on the Linux Foundation training website where we uh that's specifically about open source licensing basics goes into everything I've talked about here in more detail we have a number of blog posts and papers that we published that include more recommendations about specific topics um there's several projects that the the Linux Foundation sponsors and supports that tackle different aspects of license compliance ranging from open chain for processes spdx we already talked about to do group talk is a forum for collaboration and best practices and processes also and then at automating compliance tooling is supports the actual development of open source tools to do compliance work so scanner tools that sort of thing and I've listed a few of those here phosology open source review toolkit and turn are all within act scan code was also mentioned earlier on this call that's not part of act but it's another tool that you'll find out there all of these attack different aspects of the process of addressing open source of finding open source licenses in your code managing the process of compliance um so we've got just a just a couple minutes left for um doing well shua um and negan do we have time to answer just another question or two or do are we at wrap up um if you wanted to answer one one or two more questions that would be that would be good yeah just wrapping up in the next three or five minutes here okay sure um so there's a question let's see i see in the q and a there's a question about the comment about different inbound versus outbound licenses so the question being could we could we have gpl incoming and bsd3 clause outgoing so with that as a specific example that's typically not going to be possible because gpl if the inbound licenses gpl um then the the project you know they're receiving contributions from the copyright owners under gpl for the project to comply with those license with those contributions they would need to be be making their their you know the project code available also under gpl so typically you wouldn't be able to take receive something under a copy left license and distribute it under a permissive license i think typically in a lot of cases you'll hear projects refer to inbound equals outbound and in many cases that's what the dco is is generally seen as doing is seen as establishing that sort of inbound equals outbound structure even though the dco itself is not a license it's that assertion that i am yeah i have the right to make the make the soft make my contribution available under the license in the file is seen as kind of preserving that inbound equals outbound equivalent the main thing where you'll where you might see a different inbound license from an outbound one the main time you'll see that being difference is where the inbound license is a cla so where the inbound license isn't an open source license but you know isn't a standard open source license but it's a cla that is signed and that has specific license terms in it so there the inbound license would be the cla and the outbound license would be the project's open source license so now all that said just real quick on that too us also about going from less going from more to less permissive um so that is so if you flipped it around if you receive if the project were to receive something under bsd3 clause typically they can they would then be able to distribute that that software under something like gpl the main thing is they would still need to you know so if they take a bsd3 work incorporated into something else that is gpl and then distribute the the combination typically that would be seen as the combination is under gpl and it's okay to distribute that the project would still need to preserve the bsd3 license notices though with respect to that particular that particular contribution but those to the bsd3 and gpl would not be incompatible if they're distributed under the gpl together okay and i see where i see we're at time so um i guess any uh sure megan any last uh wrap up yes thank you so much steve and thank you to everybody who participated lots of really great questions um in interaction and just to reiterate um as steve mentioned um he is uh going to make the slides available to us and then this recording will also be on youtube later today um and both of those will be shared on the lex foundation webinars web page um so you'll have those resources resources available to you um and we hope you'll join us for a future mentorship session and um that is all have a have a wonderful rest of your day thank you everyone really appreciate the questions and thanks for joining today