Who owns AI-written code? IP rights and risks when AI helps with coding

Transcript:

Gerard: Hi everyone, welcome to Tech Law Talks. I'm Gerard Donovan, and I'm joined today by my colleagues Sonny Grewal, Mike Forbes, and Tyler Thompson to talk about IP issues relating to AI coding. lot of us come to this area, this topic with a background in technology, uh, background in computer engineering, software engineering, coding. so these are are top of mind issues for us and our clients. First, let's do quick intros. Gerard Donovan, a partner in Reed Smith's Washington DC office. My practice focuses on IP litigation and counseling, especially relating to emerging technologies like artificial intelligence. Sonny, do you want to go next?

Sonny: My name is Sonny Grewal. I am an IP attorney also in Washington, D.C. My background is in computer science and I focus primarily on IP issues around software and development in software. I help clients with patent prosecution and copyright counseling. I'll turn it over to to Mike Forbes.

Michael: I'm Mike Forbes. I'm a counsel in Reed Smith's Houston office. I primarily litigate patents. My background also in computer engineering and software. I have done a lot of trade secret work in this space as well. And the prevalence of AI generated software in our cases just continues to increase every day. So this has become a top of mind area for I think for all of us.

Gerard: Exponentially, I'm sure. Tyler, you want to go next?

Tyler: Yeah, sure. So I'm Tyler Thompson. Along with Gerard, I'm one of the co-chairs of the firm's Global AI Practice based in Denver. And I'm a data privacy and security attorney besides AI.

Gerard: Great. So I want to go into this. a AI coding assistants are unquestionably a mainstream part of coding at this point. Companies that develop software use AI tools. Companies that didn't develop software in the past now use AI tools. individuals are vibe coding to create things. And so there there's a lot of questions about the AI consequences of generating code with or questions about the IP consequence of generating code using AI. Who owns it, what the risks are, what IP can protect it. And so today we want to dig into some of the interesting issues surrounding IP and AI coding. uh First, let's talk about copyright issues. We have the the Thaler decision, which essentially held that AI itself can't be an author for copyright protection. So you have to have a human author. And we have guidance from the copyright office that distinguishes between AI-generated works not being copyrightable and AI-assisted works being copyrightable. How do you make that distinction and what does that mean for AI coding?

Sonny: So I I think the central question really from the copyright office's point of view is whether there's any creative control exercised by the user over how the AI system is generating materials. I think in their view, you know, if if the AI technology receives only a prompt and then generates complex works, then the user's not exercising any kind of creative control or creative input over how the material is generated. I think the language they use is using AI as a stand-in for human creativity. I think if the user is exercising some control, that could be sort of in modifying or arranging the work or providing some kind of what they call expressive input to the generation process itself, then the copyright office considers there to be some human authorship. But what's interesting is you know they go through a couple of different examples, and one example they give is of like an image editing tool where users select a particular region of an image. And then the AI system generates content for that region as sort of being in a gray area because the users controlling selection, the users controlling placement of the creative elements, the creative elements themselves are being generated completely by the AI system.

Gerard: Yeah, one thing I thought was interesting about the copyright offices guidance is they they do seem to recognize that this is a fact specific area and the technology's changing quickly and the way people interact with AIs is changing quickly. And so I think they were providing as best the forward looking guidance as as they could, and this was now I think over a year ago, that they they provided that guidance. and so I mean, as you apply this to new AI technology and coding specifically, which is a little different focus than the the art creation they were looking at, I think you do still get to questions of where where there is sufficient creativity to give give the prompt author you copyright in in what's output. A a separate question, if a developer accepts a coding tools, you know, suggested code with no modification, if that's not enough for the the prompter to have copyright in the code, did does anyone have copyright in that code?

Michael: I think I think that one's a little bit clearer. I think the answer seems to be no, right? That the AI cannot be an author. So to the extent there is no human who is an author, then the answer is that there does not appear to be a protectable right there. Um I I'm unclear why that's the correct answer, but that seems to be the the answer.

Gerard: No, I agree with you on that. I think that's how courts have interpreted the Copyright Act so far that it's just has a human requirement. And so, you know, that that's what the law says, and until the law changes, I mean the policy could change the law, but that that's a congressional thing, not not courts. But Mike, let me ask you a kind of a follow up. If if you can't get copyright in that, if you're just prompting and don't get copyright, if that let's let's assume the prompt's not sufficiently creative, can IP still protect it or or is there just no protection for the code that's created?

Michael: Yeah, it's a it's a tough question. And it, you know, obviously the answer is like everything else is it depends. But I I think the the places where I see value are almost more on the contract side primarily than rather rather than the IP side. And I of course that hurts to say as an IP lawyer, but licensing terms and how how do people get access to your software, right? If your software is something that's just out there on the web uh for people to use, well they're gonna be able to have an AI agent. Run your software and figure out how it works. but if it's something that you can, only provide on a business to business, you based on an actual written contract, well then you put in a an anti-reverse engineering clause like we've had for a decade and or or more. but in terms of other IP protection, I think trade secret is a ver is a real challenge. Like to the ability to document like what reasonable measures you took to keep something secret. When it came from an AI, I think at the minimum, you know, you've got to look at the terms and whether they can train on the outputs and things like that would to me, those if you know, if it if the AI can train on the outputs, well then I don't think you've taken reasonable measures, just out of the gate. So trade secret's a tough one, but I think it could be fact dependent.

Gerard: I think on trade secrets you're you're absolutely right. If you're using a public AI that it's able to train on on your inputs, train on the outputs, then I think trade secret protection is sunk. And the the only case I've seen addressing that exact issue had, the the input going into Chat GPT and so trade secrets are gone, that's not reasonable measures. But i if you are, you know, self-hosting in a secure environment, if you're using an enterprise license with no train, no retain type of terms. I think there's a pretty strong argument for trade secret protection if you're taking other reasonable measures. And that that alone's not sufficient. But I think using AI doesn't blow trade secret rights if if you're otherwise protecting. But as you first noted, it's also gonna depend on how you're distributing the software. whether the code stays as a trade secret is is gonna depend on a lot of factors. So we talked about how if if it's just coded by AI where the law currently looks, you probably don't have copyright protection. What practical steps can a developer or coder using AI tools take to maximize the chances of of having copyright protection in in what they create?

Sonny: So I think and in order to sort of explain this, that I think it's sort of necessary to explain the copyright office's position. they seem to sort of take it a somewhat arbitrary line. They they draw an arbitrary line between prompts and user created expressive elements. one thing that they bring up again and again in their guidance is that even an identical prompt to an identical system will produce a different output. And so they sort of see that as evident that the prompt has no creative control over that output. Um and so, they say there may come a time when prompts can be sufficiently sort of expressive to to reflect human authorship, but right now it doesn't seem to be the position that that that they have. And so I think in light of that, uh I think the practical guidance would be wherever possible, use input files rather than prompts. So put that same information that you were going to put into the prompt and put it into some kind of document that is sort of labeled and and indicate that that it's human authored. I think you can document creative expression wherever possible, input files, headers, specifications, and and mainly just also keep track of you know human created code versus AI generated code. Those those types of things.

Gerard: Yeah, the the the one other piece that I often recommend to clients is if you are modifying the code after it's created, if you're getting the output from the AI and then going and revising that's more human input that yeah, I think is pretty clearly copyrightable from the the guidance we currently have. Sunny, to one one follow-up on kind of how you explain the copyright office's guidance. I always think one interesting thing about when you're using AI for coding, if you especially if you're creating new code for a project that's already ongoing. You're gonna have some context and some you know functions you're gonna have to interact with. And so it's not kind of the same open sky as you would have if you're you prompting for creating art or literature. And so it's still a non-deterministic system, but you're confining the results based on prior creativity, prior creative decisions. In that context, do you think there's a stronger argument that you the prompts themselves or the output of the prompts could be copyrightable even without you input files or revisions afterward.

Sonny: Yeah, I mean I think to the extent that the overall scheme of what you're creating conforms to some kind of human created specification, the overall work is is more protectable. you're right that in in software, even if you're vibe coding, you're going to have some connective glue, so to speak, between the different sort of software modules in terms of you know it could be human created or it could be AI generated, but you're going to have to sort of design that and configure sort of the placement of the different code and how it interacts with other sort of software. And so I think there's sufficient creative expression in that, at least to provide coverage for the work as a whole, if not individual modules.

Gerard: I think when, you know, in house council are thinking about documenting what their their people are developing to show the copyright ability, you know, thinking about that from what what creative inputs are we giving to this, whether it's input files, whether it's the the prior coding that humans did, revisions. I think it's just don't don't think overly formulaically about it. Think about what what creativity is going into it, how you're doing that, because you this technology's moving quick. And I don't want to, just look at the the guidance instead really think about where where the creative inputs are. last question on this topic. If a startup came to you with a vibe-coded program and they assume they own all the rights to the software, how would you counsel them?

Sonny: So we we sort of touched on this, I think, a little bit, but I would say, you when software is vibe coded, we're usually talking about specific modules or classes or functions that might be generated and inserted into a larger library. and if that's the case, then the arrangement of the various different pieces, as well as sort of any connecting human generated code, make the work as a whole copyrightable. I think if the entirety of the software is vibe coded. There may still be protection possible depending on what types of inputs were provided to the generative AI system. but it's going to be less than the degree of protection that would be would be there if it was entirely human generated.

Michael: Yeah. And I would add I would add just kind of as I mentioned before, like I think at that point you have to look at what is the distribution model for this particular client, right? If it's a software as a service and ultimately only limited parts of the externals are going to be visible to the outside world, then I think they can proceed and ultimately copyright is probably not the most important vehicle for their protection. Uh if it is something, you know, if it's a web app, if it's a mobile application, uh then that's then that's a different story.

Gerard: Yeah, I think you guys both make very good points. One is, you know, you gotta investigate the the facts and figure out, what what is there, is there sufficient creativity, whether it's vibe coded or not, it's all spectrum. And second, copyright isn't always the most important thing. And that's it's a good right to have when it's there, but that's that's not everything. And so you wanna think holistically what their strategy is and how how IP can align with it, you know, if if it can. Let's switch gears and talk a little bit about licensing and specifically open source licensing and how it relates to to AI coding, because this is something that that comes up a good bit. first off, this can be a pretty complicated subject, so let's not get deep into the weeds of of AI licensing terms and things like that. But let's say a chunk of public code the developer wants to use is under a restrictive license, if they use AI instead to generate code to do the same thing, what are the implications of

Michael: Yeah. That's that's a great question. I think it's one that is actively being being figured out. But I I think the my first reaction is it depends on whether that particular code has been used to train the AI. And the sh short version of that is that you may never know the answer to that. So, you know, at least until you get into a very expensive discovery fight. my initial reaction to that prompt is that I think that sounds like, you you're using the code to generate a replacement for the code, that sounds like a derivative work under traditional copyright analysis. and you I I think most coding AIs will openly acknowledge, and some have openly acknowledged, that they they have used public code bases that are on the internet, including ones that are covered by licenses like the GPL and others. So I it it strikes me as very fraught at the minimum. I think in a situation where you specify the functionality, that's something entirely different, right? Is it instead of saying write me a replacement for this module, but to say, I, you know, here is my existing code, I need a library that will connect to said database, said obscure database, or whatever the answer may be that you're trying to use the code for, I think that's a different question because that the GPL or any other license can't protect the concept of connecting to the database. So it just really depends but I I think the concern is even if you don't tell it to use the GPL version, you don't know whether it did or not.

Gerard: Yeah, I think one of the the challenging issues here, at least to me, and it different factual cases could could vary, but is kind of the the merger and functional versus creative aspect of the code. And if if it's creating a new version that accomplishes the same thing, you is it or is it not copying the the creative works? And that that gets to be a really complicated factual issue. And if you're if it's creating it based on, you know, being trained on the prior library and using the information from that, then it's easy to see the argument that it kind of inherently is using the Creative Works. But at the same time, if for example there's zero to one percent overlap in the code out of it. If it appears different and it's doing it in not the same way, even if it allows you to interact with the the same, you other code or accomplishes the same goal, I see pretty good arguments also that that's that's not copying the creative expression, it's copying the functionality. So I think and this is all obviously a hypothetical here in a a given case it could be much more clearly on one side or the other. Mike, as a follow-up question, because you sort of gave some different ways it could be done, do you have any thoughts on how you could mitigate risk if using AI to generate code to not not infringe on any unknown code that the AI was trained on?

Michael: Yeah, I think that's I mean, that's a difficult, scenario to to address without knowing the specific tool that we're talking about. But I mean, fundamentally, you there is information and and as you mentioned, we're you know, generally we're not talking about like the consumer grade, we're not talking about getting code from Chat GPT. We're talking about, you real enterprise solutions for AI coding assistance. And I think there is public information about how they're trained and what their process is. So I honestly I think that's a first step is to make sure that you're using tools that that you're comfortable with the risk level. And I I looked I've looked recently at the you terms of use of a number of them and the way they treat, ranges from indemnification to yeah, you're on your own. And it's that's an important distinction that, you know, the coder isn't going think about, right? I don't think that most software coders are concerned about that, but obviously the enterprise needs to be. not sure that fully answered your question, but I think the other the other aspect of that is, you know, you you mentioned specifically like code analysis engines that will say, well this is only one percent similar. I worry about those. I think they're a great litigation tool and they're a great tool for making sure. Uh but at the same time, like and to a certain extent the metric becomes the measure, right? Like, okay, well, Mr. AI, generate me some code that only comes up with a five percent or less comparison when you you know, like that's that's not helpful. Uh and obviously you could, you know, maybe find that out in discovery, but it it makes those measurements less relevant to me.

Gerard: Yeah, I I think I mean I to your comment, I think indemnity can be one of the the most powerful, you mechanisms for mitigating that risk. a lot of those indemnity terms can also have requirements on the the prompting or the way you're using the the software or the

Michael: Absolutely.

Gerard:
the AI. And so you do want to make sure you're not prompting in a way that's likely to, you create infringing code. and you can go further. I think you can affirmatively beyond what you need to do for the indemnification, but if your you prompts or your interactions with the AI are explaining that you do not want to use anything from you infringing libraries, you don't want to copy anything, we don't know how these systems are working under the hood, so you don't don't know with certainty, you what the consequence of that is. But I think those steps show uh they they help to create a record of doing everything you reasonably can not to, you copy anything, uh, not only inadvertently, but affirmatively trying to avoid it. And same with code analysis tools. I I I don't think those give you, a certainty that you don't have risk there because you can have a copy without it being a a literal copy that still has the creative expression copy that would show up as as clear because it's sufficiently different. but I think those types of checks further show good faith, show diligence in in trying not to copy. And when these cases start getting to court, which they they surely will. I think having that type of record just shows that, yes, I'm using AI, but look, we're doing everything we can to to not copy with it. And I think that's gonna probably go a long way uh to making it, if not a closer call to to put the the coders on the the safe side of the the infringement risk.

Michael: There's a follow-up on that, Gerard. d do you think at a certain point you can craft it carefully enough that any inadvertent use becomes you know fair use? Or

Gerard: I mean that that goes uh I'm gonna put aside the whole like is training on data fair use? Is that transformative? Because if if that is, that'll flow through and I think we're in safe fair use territory. But that's very uncertain area right now. So uh assuming it would not be fair use, you know, for it to be trained on the code for context of this question, I don't think it's a particularly compelling argument that it's fair use just because you put in, you comments and tried or, you specified your prompt to try to avoid this. I I think that that gives you a strong argument against willful infringement, which could be the increased damages. and I I think it, you know, it paints a better picture generally. But I think, the the question of whether that output is transformative, whether it's used in a different way. I'm not sure the changing the prompting materially changes that. I think I think you still have fair use arguments and probably pretty decent ones. but I don't think they really shift by that that prompting. That's a great question. I hadn't really thought deeply about it though.

Sonny: I mean, I think it just sort of depends on the type of prompting because there's sort of a wide range of ways that you could prompt the system. You could prompt the system, for example, to say, don't use this specific, make sure that this specific OSS library is not used at all in the creation of the output or something like that, which is slightly different than saying like make sure you don't use any open source. and I think like Gerard pointed out, this is helpful in terms of sort of showing your intent in combination with using tools like, open source software scanners like like Black Duck or something like that, they can they can pick up portions of code. So, you could you could prompt carefully and then also have a step of scanning everything just to make sure that there's no nothing that shows up, at least on on those kinds of checks, showing any kind of overlap.

Gerard: Let me ask you talking about, you traditional scanning tools. e AI has improved abilities to scan things in kind of non pattern oriented ways and to come up with, you recognition. Is it reasonable to use AI tools to to check whether or not AI generated code creates legal risk?

Sonny: I think in this specific context that we're talking about, I think it's reasonable irrespective of context, but I think in this particular context it's helpful because we're talking about creative expression. And so if you're covering the same functionality with a different creative expression, that's not that's not an issue unless that functionality is patented or something else. um But more generally, I'd say you know, different AI tools are trained for different purposes. I don't think there's any reason to think that an AI tool that's trained to sort of identify certain types of risk would be less effective when applied to AI generated content.

Gerard: Yeah, I think that's right. To me, I think the key is using diligence and using the right tools. I I think you can't abdicate responsibility no matter what you're using. and so you can't, you say, hey, I used AI to check it, so I'm clear. Sort of like you have to check the sites for your brief and and everything else. But at the same time, it's not not wrong to use AI for a tool for it. It can be a powerful helper, it just needs to be part of a a system that's reasonable. To move things along, why don't we switch to to patents for a few minutes? and let me ask, when AI is used as a coding tool, can there still be patentable inventions created in relation to the the coding and the the system development?

Sonny: Yeah, so the patent office released some guidance on this in in in 2025 and and basically w what their position is is that if the sort of entirety of a particular algorithm or a method is created by AI, then that's not protectable. if you were to, let's say, input a problem and then ask the generative AI system to create a solution, then that solution is not protectable because you did not conceive of the solution. but if the sort of overall process, let's say, was conceived by a human inventor and you're using generative AI for, various bits and pieces of it, or to sort of uh help put together, the the practical sort of implementation, that sort of falls into the reduction to practice category and there still is an inventor there. And that would more likely that's more likely to be

Gerard: Sort of related to that, or I guess as diligence that would go with that, if human inventions are created that are are using AI as a tool in the process, how should that inventive process be documented to support patentability or that to have the evidence if this it gets challenged in court and there's a question of, was was the human involvement sufficient or was the AI the real inventor? 'Cause I would think if that, can't be proven or could be a theory for invalidation, you this all will become an evidentiary battle.

Sonny: Yeah, I mean that's an interesting theory for invalidation, to sort of argue that there's no inventorship. I think, you having invention disclosure forms, obviously, labeling sort of documents and specifications that are human generated, you know, in a lot of ways it's somewhat similar to what you're going to be doing for copyright protection. It's just the purpose is different. you're not trying to evidence human creativity, you're trying to sort of evidence human conception of a particular concept.

Michael: Yeah, to a certain extent, a it's legally distinct concept of creativity or ex creative expression versus inventorship or conception. But fundamentally you're documenting the same thing, right? That this is a human's idea implemented via an AI as opposed to an AI's idea, to the extent they can have ideas. But I think that's the think the documentation kind of is the same, at a to a large extent. And I think the I think really it as you kind of pointed out that the d this is a fight that we've already had, right? Patent litigator by trade, like inventorship is a well settled, like set of laws. And I don't think it really changes the dispute much when you're saying, no, it should have been Bob instead of, it should have been Claude the AI. Or it doesn't really change the fight. You still have to have documentation of who did what and where. And so if you have good practices in place for that already, you should be in fairly good shape, I would think.

Gerard: Yeah, I I will say from having litigated inventorship disputes where there's questions about which people are inventors even without AI in there, it it can be recognized as a muddy area because who is an inventor versus someone who is involved but not not sufficient to be an inventor can often be disputed. And I think here I Mike, I think you're right that the the analysis really parallels well and it's not much different, except keeping good records, being able to show what happened and and assessing on the front end too, to make sure you are you know determining there was sufficient human inventorship so you're not, you filing an like you shouldn't file a patent application if if you're not gonna have the better side of the theory. So investigate this early on, document, what the inventorship was, and then I think you should be in good shape. Let ask kind of a a related question. If if AI proposes a breakthrough that is not a human invention, so you, you know, prompt an AI system giving it some some requirements or a goal, but it really invents something. Is there anything you can do after that to, you to protect protect what was created?

Sonny: And so one thing you could do is sort of figure out what's the what's the best version of that and and sort of work on creating that or the most practical, the most commercially viable version, and and and that would be protectable, an improvement on on what the AI systems created. Um and then there's also, you know, what we all talked about previously with respect to sort of trying to find a way to keep it trade secret, as well as sort of all the the the contractual sort of methods that that Mike was talking about.

Gerard: That would be a a human improvement on what it's doing to optimize for, w whatever variable to to make it better than what the AI came up with so you can protect that maybe slightly narrower but but a human invention that, built on top of it, kind of the on the shoulders of giants type of thing.

Sonny: Yeah, and and you could also sort of try to figure out what are all the different ways that you could improve it, and have some kind of overlapping net of coverage. So even though you don't you don't own the the original sort of invention as as developed by the AI, you you own almost all the viable improvements of

Michael: I was I was gonna ask a follow up on that and if that's the situation and you're coming up with improvements, do you have an obligation to disclose the AI output as prior art?

Sonny: So I think you'd have to you'd have to go through the different categories and think about, you know, is it publicly available, is it on sale? I think context matters a little bit here uh and it may vary depending on the factual circumstances. I don't think it's an

Gerard: Yeah.

Sonny: Automatic yes or no, in my opinion.

Gerard: Yeah, I would I would think in a lot of circumstances it wouldn't be sufficiently public to be prior art. however, you may still I mean if it if it does closely tie to the inventorship analysis, you could still have an ethical obligation to disclose it, just so the examiner can consider in, you know, the rest of the examination whether or not, know, there there is a a human invention here. I think if if you are sufficiently improving on that, that might actually create a stronger record for you of having the patent office, consider that, confirm there is an invention here with the human inventor. So I think it could also be favorable to to the applicant to to create that record. One thing we've all worked with clients on is is how they document inventions, invention disclosure forms and and things like that. Uh is that something that should be changing now that AI is involved with, virtually everything our clients do?

Sonny: So I'm a little mixed on this. I I'm not sure whether it's a good exercise in an invention disclosure to say AI developed this part or AI developed that part. I do think it's from an internal sort of standpoint, record keeping, it's useful. I would say that to the extent you did use sort of generative AI to come up with particular concepts or solutions at a high level. That can be disclosed and it should be, so that you focus on the right things for the patent application. but to the extent you just use AI tools, I don't think I think that's all sort of part of the workflow these days of just software development.

Gerard: Yeah, I mean to to me it seems similar to asking, who are the inventors, but that's sort of a a threshold question that in the diligence preparing application you gotta talk to them about what they did, who was involved to make sure, legally the right people are identified. And I think it's similar part of the the preparation of an application should be checking, Hey, was AI involved? How did you work with AI and so that you understand? Because you know, we need to figure out, hey, if this is was an AI invention, not human invention, then we need to not file a patent application or need to identify what the human invention was to to make sure we're focusing. Let me ask just a closing question for, either of you or both of you, but what do you see as the biggest or here is the biggest misconception from clients or in-house teams about AI assisted coding?

Sonny: I think a lot of them are viewing AI tools the same way that they might view other sort of coding assistance tools like debuggers or whatnot. almost as like a shortcut for for implement for implementation, to to make you more productive. I don't think a lot of teams realize the impact of using generative AI tools, that the impact that it has on, IP rights if you're using it for code creation. so that's just something that companies need to be aware of and they need to treat it differently than other tools, I think.

Gerard: It's funny that two responses I could offer from clients are either that they assume they have all of the rights to the code that's created, like they would have when their teams develop it, or or the exact opposite, that they they know that IP is different when AI is used, and so they assume they have no rights. And it's almost always somewhere, you know, in that big gray middle, depending on what they're doing and how they're using it. And so helping them to to figure that out. Usually they do have significant rights between copyright, trade secret, potentially patentable inventions. And so helping them to unwind a little bit of that, you without getting too complex into the coding details, I think helps them navigate and put systems in place to to make sure they are protecting the IP.

Tyler: Hey, do we have a final minute I can put I'd love to put these two guys and even yourself on the spot with kind of an off-the-cuff question if we have time.

Gerard: Let's try to challenge us. Let's go for it.

Tyler: Sure. So, pretend I don't know anything about IP law, which will be easy for me to pretend. And I'm in-house counsel, right? And I have to go into, dev team with a lot of tech debt who's overworked. They've got in-house AI tools, maybe they're even using shadow AI behind the scenes. What would you guys recommend? How do I really quickly and easily kind of show them the risk? Because all the risks that we've been talking about today around AI and get them to kind of take a lot of this risk seriously and you know, what would you recommend? How do I scare them, I guess, is what I'm trying to say.

Gerard: I'll jump in first, not to step on anyone else, but I mean some of it is I think making them appreciate the risk they have, not only of not I mean today mostly we focused on protecting our IP and the things we're creating, you know, what can we still get copyright protection for things, but especially if you're using shadow AI, if you're using non-enterprise things, there's a big risk that you're infringing other people's IP. And that you're not having IP protection for the things you're creating. You you probably don't have indemnity then. If you if there are indemnity terms, you might not be complying with the requirements for the indemnity. Uh and so helping helping them understand the different risk profile between using enterprise stuff that we've checked out, has safety, using it as trained versus going and and using things that are. Waiving our trade secret rights, potentially creating infringement risk, potentially creating security risk. You know, you have a lot of other issues as well. and so letting them know like, look, this is that that's probably not acceptable to most of our clients. different different clients are different, but no, most wouldn't allow that just because of the the risk it creates. And then on top of that, explaining no that they're spending all of this time and energy creating things. I mean, one thing I love working with developers is they're passionate about what they're doing. They're figuring out ways to fix new problems and they're innovative and helping them explain that, look, they they can protect these things if they're taking these right steps, but a lot of times they kind of stumble out of the gate by using systems, using tools that that might be very effective, but they don't understand the consequences of using them. So I think some education can really go a long way.

Sonny: Yeah, I would echo what what Gerard said and I think people tend to respond more quickly to potential risk than potential reward, especially you know if you're trying to scare them. And so I think starting out with that, starting out with the risks of for example having open source software in your in your code and it it's sort of a good way to segue into um generative AI and and sort of the IP issues around.

Michael: Yeah. And also, you you're in our business, telling horror stories about open source audits, you know, like is pretty easy easy to do without without violating confidences. You can you could tell pretty pretty horrific stories. And the the time to do that is not, four months before the IPO, right? The time to do that is right the heck now. And getting the developers to understand, like, if you screw this up, those stock options you have, like th those those aren't eventually those aren't gonna be liquid. Right, we're not doing an IPO if you've gone off and and done all the things that you're not supposed to do. that that would be honestly my approach with the developers directly.

Gerard: All right, well thank you to the audience for listening. it's been great talking with you, Mike and Sonny and Tyler. and we'll talk later. Thank you.

Michael: Thanks for having us.

Sonny: Thanks. Take care.

Outro: Tech Law Talks is a Reed Smith production. Our producers are Shannon Ryan, Amanda Saunders, and Mason Kautz. For more information about Reed Smith's Emerging Technologies Practice, please email [email protected]. You can find our podcast on all streaming platforms, reedsmith.com and our social media accounts at Reed Smith LLP.

Disclaimer: This podcast is provided for educational purposes. It does not constitute legal advice and is not intended to establish an attorney-client relationship, nor is it intended to suggest or establish standards of care applicable to particular lawyers in any given situation. Prior results do not guarantee a similar outcome. Any views, opinions, or comments made by any external guest speaker are not to be attributed to Reed Smith LLP or its individual lawyers. 

All rights reserved.

Transcript is auto-generated.