 So this is Don't Love It to Death, Best Practices for Downstream Use of Project Trademarks. My wife actually came up with that name when I was describing what I wanted to talk about at Open Source Summit. And I really, really liked it because I think it really kind of captures what we'll be talking about today. I commend you all for choosing to leave the puppies and come listen to a lawyer talk. I'm not sure I would have made that decision, but here we are. So introductions and housekeeping. My name is Daniel Scales. I'm Chief Brand Counsel at the Linux Foundation. I've been at the Linux Foundation for two years. Before that, I was at Chote Hall and Stewart, a Boston law firm, led their trademark and copyright practice. So I've been employed by the Linux Foundation for two years, but I've been working with them and their projects on trademark matters since 2010. I'm a U.S. attorney, so the legal concepts I'll be discussing are based on U.S. law, but they're pretty universal. So I don't think there's anything too U.S. centric about it. While I am a lawyer, I'm not your lawyer. And even if I am your lawyer, this is not legal advice. This presentation is for informational purposes only. And the views expressed are my own, they don't necessarily reflect the views of the Linux Foundation or any of the projects that we host. So as the LF's trademark lawyer, I get a ton of questions every week about how somebody can use the trademarks of one of the open source projects that we host. I also handle trademark enforcement, which that's the shorthand word that trademark lawyers use, but for our work, most of the time it's an educational exercise rather than an adversarial one, because when we talk through the issues and what's relevant, I think people understand it pretty quickly. All right, so why did I want to discuss downstream users and how they show their love for open source projects? Well, let's talk a bit about what a trademark is. So trademark signifies the unique source of a good or a service. It signifies the source, so it's important that any use of the trademark direct consumers back to the project. So the source for an open source project is the project and it's important to keep that clear. Sometimes even with the best of intentions, downstream users kind of lose sight of this and use project trademarks in a way that don't necessarily promote the project. And so there's a lot of confusion out there, but also confusion about not just how to use project trademarks, but why that is, and so I want to cover some of those things today. All right, I'm going to briefly talk, hesitate to do this, but putting up a statute. But I think it's important because I want to kind of get to the root of what we're talking about. So trademark law protects marks that are used to identify and distinguish his or her goods from those manufactured or sold by others and to indicate the source of the good. So that's directly from the US Trademark Statute. So what does that mean? It's not just the mark itself, it's mark when used with a specific good or a specific service and to communicate to consumers where that came from. So remember, while trademarks are a type of intellectual property right, they have a lot of value, they play an important consumer protection role. Where did this stuff come from? Who made it? Can I trust them? Do they make other good stuff? And this is all kind of generic trademark information. It's not specific to open source projects. But let's talk specifically about open source. Oh, sorry, yeah. So a single unique source, that's the other component here. So for a project, that's not always straightforward. And that's fine as long as the project has kind of decided like what it is. So, is it a sole maintainer project? So then the person is the source. Is it a legal entity? Is it hosted at a foundation? Is it a legal partnership? Whatever the trademark owner is, that's where the, where the trademark drives people. So for open source trademarks, they're the beacon for the project. It brings the relevant people together. It's the central rallying point. And remember, most popular open source licenses grant broad copyright rights to downstream users, but they don't grant trademark rights. So this is the Apache license. Apache actually has an express provision on trademarks. Not all open source licenses do, but they don't include a grant of trademark rights. Apache does expressly exclude the right to use the trademark. Sure. Yeah, so trademarks in most countries are generated through use of some thing, a word, a logo, a color, a smell that indicates the source of that good or service. But the key part there is that it's used and used in the sale of a good or the distribution of a good or the rendering of a service. So just by creating a logo or creating a name of a project, that doesn't create trademark rights. It's actually putting it out there and using it as a source identifier. So registration in the United States, which is kind of the odd duck here, you don't need to register trademarks to have enforceable trademark rights in the United States and some other common law countries. In other countries, you obtain the trademark rights first through registration and then you maintain those rights through use. So you can register a trademark before you've used it, but you can then be challenged after registration by somebody saying, wait a second, you're not entitled to registration, you haven't used this in connection with the goods you say that you're doing it. So I mean, registration even in the United States provides a lot of meaningful benefits. There's a cost there, obviously, and they're national in scope so it can get expensive very quickly. But yeah, so even where registration is how you get the initial rights, use is still relevant for maintaining those rights. Okay, open source trademarks. So they help users, contributors, sponsors, partners navigate the software landscape. So how can people find the project? Why do they want it to in the first place? So if I'm a user, I learned about this great software with the features that I need. So I seek it out based on its name, right? I do an internet search for it. And then I confirm that, yes, that is in fact what I'm looking for when I see the logos that I recognize and the other branding features. A contributor thinks they can help. It seeks out the original project to get involved. They wanna make sure they're working with the right folks. Sponsors see the value and they seek out those running the project and wanna support it. Partners wanna communicate to people things like compatibility or how everything works together in a stack. The brand of the project helps facilitate all of this. I wanna briefly touch on a few other trademark concepts that are gonna be relevant to this discussion and why they're important specifically for project trademarks. So all trademark owners, including open source projects, must control how their marks are used. It's not optional, it's not should, it's a good idea, it's not best practice. They must. The reason is if you allow somebody else to use your mark and you don't control the quality of the goods that are being used with your mark, how the mark is displayed, whether the mark is modified, remember the key function of a trademark, it's a source identifier. So if somebody else is using that same trademark to communicate something else, then it's not a trademark anymore. It's not identifying a source or it's identifying a different source. In any event, it can invalidate the trademark rights completely. Another concept that I think is important, particularly for this discussion, is that the trademark is the trademark. So combining two or more established trademarks could invalidate both trademarks. So this is definitely a case of more is not better. So adding features or additional words to another party's trademarks kind of dilutes the value. If you're adding your own trademarks to a project trademark, it's confusing for both sides and dilutes the value and could potentially invalidate both trademarks. Also see requests from people who want to use project trademarks where they want to modify it. It's like, oh, I see your logo, but we want to add this to it to show how we're using it. Again, the trademark is a beacon and it should be driving people back to the project. And so if there's too many variations on a single mark, all different beacons, then it's not functioning anymore and it loses the value that it's supposed to be serving. All right, so this is not a, never use a project trademark talk. And quite the contrary, there's a lot of situations where projects want their marks to be used by others. So project trademarks are often used descriptively to discuss the project software, its activities, other information about the project, the fact that you're sponsoring a project. And that's a different type of use than a trademark use and that's an important distinction. Descriptive use is just kind of natural language. You're not using it to as a brand. And that generally is fine as long as it's not misleading. Some projects expressly license out their trademarks to others to communicate specific use types or compatibility or something conforms to the project specification. And so there would be actual license terms in place that expressly grants the rights that the project intends for the licensee to have. And in those license agreements, I was thinking about this the other day. I've stared at this language a couple million times in my 20 odd years of practice. You'll see it in every trademark license that used by the licensee endures to the benefit of the trademark owner. And it's like, I wanted to take a step back and think about that for a minute. What does that mean? So it means any goodwill generated by these authorized uses endures to the benefit of the trademark owner. So what it really means is the authorized use of the mark is kind of directing the value back to the project. It's not for the licensee or other authorized user. It's not for their benefit that they're using the project trademark. It's for the project. And I think asking those questions, are you using the project trademark to support the project? Or are you using the project trademark to attract people to and promote your own product and service? Using the goodwill that's already been established by the project trademark to attract people to you. That's not really enuring to the benefit of the project. And so I'm gonna get into some specific examples in a bit, but I think you're getting it right that it's not a binary switch, right? The best result is that a downstream user is using the project trademark in a way that supports the project, but they're also building their own brand and communicating to people why it's relevant, like why would they care about it? And I'll get into some examples about that in a bit. So ask yourself why you wanna use the project trademark. If you use, if you built a product using, if you built a business using open source software, and wanna use the project trademarks, do it in a way that supports the project and its trademarks. And then the point we were just talking about, and it builds your own brand too. There's alignment here, and when you talk to people when issues come up and explain this to them, it hadn't occurred to them about how they can build their own brand and that they should be building their own brand. And they're often great conversations, but I'm just kind of amazed that if you're using a really well-known open source project and you want people to know that you're using it and that you're providing services related to it or you've built something on top of it, that's great, but so are lots of other people. What you should be doing is promoting your own business. And now you can certainly communicate that you're using the open source project and how you're using it, but the brand value you should be trying to be building is your own. So how do we do that? All right, so step one, some basics. I would say do at least this. So one, comply with applicable trademark law. I think that's straightforward enough, but yet I'm still gainfully employed because that seems to be a challenge. So what does it mean comply with the law? The basic concept is don't create confusion. So if you're using a project trademark, make it clear what is yours and what is the projects. That should be immediately recognizable and the legal standard is the relevant consumer. Somebody visiting your company's website should be able to understand and distinguish between the goods and services that you're offering and what came from the open source project. Other thing is comply with the project's published trademark usage guidelines. So most trademark, most open source projects publish trademark usage guidelines. Typically they provide a bit more detail on what the law allows and they do specific examples for that project and how the law applies there. But they often go beyond that and provide specific blanket permissions in certain cases. So if a project says, you know what, if people want to make t-shirts with their logo on and hand it out at a conference, that's great. Happy to see it, go ahead, knock yourself out. And they'll include things like that in their project usage guidelines. So I'd say that's the first place to look you know, consult with your trademark lawyer but you know, even before you do that, read the trademark guidelines from the project. There's gonna be, you know, useful information in there. Other information is, that's typically included is if you do use it, should you use the R with a circle which signifies a registered trademark or the TM symbol which signifies an unregistered trademark. There might be links to the official artwork. So again, typically, you know, you shouldn't be modifying another party's trademarks so if you can get the official artwork directly from them, that's a preferable. And there might be some, you know, I'm sure you've seen it, you know, can branding guidelines of how to actually display things. So how much white space around it and you know, is there a specific font that should be used, things like that. Now that said, sometimes you read them and you still don't know if what you want to do complies with the project's guidelines or not. So ask. The other thing that trademark usage guidelines almost universally have is contact information. There's gonna be an email address in there where you can reach out to the project and ask them, you know, what you want to do complies with the guidelines. I want to talk specifically about names and I think, you know, this might go to one of the questions that was asked, you know, earlier. So a lot of times where we get into issues, companies want to incorporate an open source project's trademark into their product name or into their company name. Sometimes it makes sense and there's ways of doing it that are, they're certainly described in the Linux Foundation trademark usage guidelines. I think you'll see it in a lot of other ones where there's a distinction between including it in the brand name and then including it in the name as a descriptive, you know, tool. So for example, you know, if you're doing something in the container space and you name your, you know, widget and you add on, you know, for Kubernetes and for the Docker version, you do for Docker. Well, that's kind of describing, it's not really part of the brand, that's more of a descriptive use and generally that's going to be okay because it's communicating to people like which version it is and is it the one that I want. But, you know, more often than not there's better ways to communicate the relationship between what you're doing and the open source project and it's just amazing to me the links that people will go to try to accomplish all marketing communication through the name. Use the entire marketing toolbox. I love a good tagline, taglines are great. So name your product wherever you want to name your product and then, you know, it's a solution for Kubernetes as a tagline. It's like, okay, you know, now I understand what it is or, you know, documentation. Make it clear, make it great. You know, everyone goes to the company's website so that they can read there about how it relates to the open source project. But jamming everything into the name, more often than not, it's not a great idea. All right, so step two, you're going to do the easy stuff. You're going to comply with the law. You're going to comply with the usage guidelines. You're going to talk to the project and make sure that, you know, if you want to do, you know, it works for them. But, you know, what I'd like to see is, you know, companies go beyond what's required and really tell themselves, like, no, I'm going to, you know, we built a business off of this project software. Like, I'm going to promote them. Like, I want this ecosystem to thrive. So, you know, use your branding to help do that. So, you know, one thing, trademark notices. You know, there's a customary way to post legal notices right in trademark notices, you know, particularly on a website. It's in that four point font at the bottom of the screen that you can't read and nobody bothers reading. But it doesn't have to be like that. So I would say, you know, still do that because I think people are conditioned to seeing it there. But, you know, so something like that, you know, copyright 2023 Daniel Cole already deserved. It's like, all right, you know, I'm using software from the scale somatic project. In fact, so I have to include scale somatic as a trademark of the Linux Foundation. Okay, like, yeah, that's what's required. But I mean, if you love the scale somatic project, you know, do something more like this. You know, Daniel Cole, that's my company, uses software from the scale somatic project and its products. Daniel Cole developers frequently contribute to scale somatic and actively participate in the community to learn more about the scale somatic project and how you can participate, see the project website. And it's a beacon guide people to the project. Scale somatic is hosted by the Linux Foundation, see linuxfoundation.org for more information. You know, so, you know, I think you can see the difference between notice one and notice two and the difference there in the relationship between the, you know, Daniel Cole and what we're doing and the scale somatic project. All right, what else can you do? You know, publicize your use of the software more to the community. There was a great example of this on day one of the summit where a company presented on how it uses EBPF. And I loved what they were doing because they were singing the praises of EBPF, but then they were communicating how they used it in their business. So it was very clear, you know, the separation of the two, EBPF is the project and its software. But then they were talking about their own brand and what they were doing with it. I thought it was fantastic. Consider sponsoring the project. You know, all projects, you know, need support. You know, whether it's, you know, dedicated engineering time or financial support. You know, find out how you can get involved as a sponsor. And then when you do, publicize that. The project will state that you're a sponsor, but, you know, say it with pride on your own marketing materials. Offer to do a case study that can be posted on your website and the project website where you can reference each other, where you describe how you're doing great things with that awesome open source project. Present at an event like this. So again, you know, we're seeing a lot of that, you know, this week where, you know, people are talking about the great things that they're doing with open source projects. And I think that's fantastic. And I would say, you know, again, we're all, it's a community, right? And it's all people, you know. So if you send an email to, you know, trademarksatlinuxfoundation.org, it goes to me. Like, I'm that, you know, the black hole where that email is going, it goes to me. And, you know, so I'm the one you'll be talking to. And the same thing with the project. Just engage with them. Like, hey, we love your project. Like, how can we promote it in a way that's going to make you happy? And they're going to have ideas. And every project is, you know, community ecosystems are a little different. So, you know, even if you think you have a great idea and they're going to love it, I'd still discuss it with them. You know, see if they feel the same way. All right. And one, the last thing I want to do is promote somebody else's talk. And actually, I don't know Libby and Colleen, but I was looking at the schedule and I was like, this is awesome. So they're going to be talking, I looked through their slide deck, which is already on the Summit's website. They're going to be talking about a lot of these same issues but from the marketing perspective. So they're at Amazon marketing professionals. So I'm going to be at the session. I encourage you to go to hear probably some better ideas than I had. But hopefully this gave you a legal grounding. Like, we're not just mean when we say, hey, stop using the project trademark this way. Like, there's good reasons for it and important reasons. And like I said, I don't feel like it's necessarily antagonistic. I think that it's downstream users and the projects can really be aligned and develop and promote each of their own brands. So I will open the floor to questions, comments, ideas, things you love that companies do with projects that you work on. Right. Yep, could be. So I would say that's a decision that the project has to make for itself. So I'll talk specifically about open source projects and what the brands are. So certainly then the name of the project in some cases very important modules or features within it are branded as well. Typically there's some sort of a design element. So whether it's a logo or just a stylized font in a particular color scheme. You mentioned colors. You don't see that quite as much, but it is an effective branding tool. And so sometimes, you know, like the Linux foundation, you know, we've got our two shades of blue and we kind of always have. You know, I would take the view that that is, you know, that's a distinctive part of our logo is the color scheme. You know, but sometimes projects will use different colors to communicate different things. So the yellow version of the logo is, you know, for this use scenario and the green version is for this scenario. But so it can be, you know, part of the branding, but you know, I say one, be intentional, but also keep it simple. You know, like I said earlier, you know, more is not necessarily better. It's better to have a really strong mark, one of them, and build everything around that. Now, you asked about mascots. And again, that's, I would say, you know, be intentional about what you want to do there. Because I think, you know, you can go a couple of different routes. You can have a mascot that is functioning as a trademark. And there, you probably do want to keep it consistent or, you know, maybe it has, you know, different hats or whatever, different color shoes and, you know, but you control that and decide what you want to do. Other companies, and I think probably the most prominent example, although it's quite dated now, was the Android guy for Google. They didn't claim trademark protection in that. So they licensed out the mascot artwork under a copyright license, which allowed people to make it. They wanted people to play with it and mess with it and be out there. And that was the strategic decision that they made. So that's an approach, like, right, wrong. No, it's just, you know, it's just what they decided to do. And it seems like it was pretty successful for them. Any other questions? All right. So like I said, I'm the Lennox Foundation Chief Brand Counsel. I'm the guy who gets those emails when you email trademarks at Lennoxfoundation.org. I'm a lawyer, so please don't be bashful about reaching out if you ever have any questions. Thanks. Yeah, so the, I mean, you might have two separate questions in there. I mean, they're always going to be, they should be really easy to find on any projects website. You know, again, typically at the bottom with those links that you ignore, again, the privacy policy, et cetera, there should be a link there to the trademark usage guidelines. They should be nested under like other legal policies. But then it's like, oh, well, you can you just like take somebody's policy you like and claim them as your own. Probably want to discuss that with your lawyer. Arguably, it's covered by copyright law. Some trademark usage guidelines expressly say that you can license it, you can use it under one of the CC licenses. Follow that. You know, it's, I think it's, it probably is protected by copyright, so it's worth talking to a lawyer about it. You know, it is, there's a lot of it that's functional, which wouldn't necessarily be protected by copyright. But it's probably enough creative expression in a trademark usage policy that has it protected. So before you just, you know, copy something verbatim. You know, again, yeah, exactly. I mean, that's probably, you know, the better point is, I mean, you might find once like this says exactly what we want to do, but, you know, at least over time, there's going to be situations where you're going to want to change things to match, you know, what your project is doing. Right. Yeah. I mean, you know, the, you know, don't use the trademark in a confusingly similar way. Well, every trademark usage guideline has that sentence in it. So, you know, copying something like that is, you know, a risky behavior. But you might say it your own way.