 Well, thank you everyone. My name is Jeff Kaufman. I'm an open source attorney for Red Hat. And we're going to talk this evening about Oracle v. Google and the fair use case, which I'm sure most of you have heard of. We're going to take a little bit deeper dive into that case and explain some of the more interesting aspects and the holdings of the case. I want to first start out by talking a little bit about my background and you'll understand why. Back when I was 16 years old, I wanted to be a pilot. And one of the things you do when you're aspiring to be a commercial pilot is you take instruction to be a flight instructor. So at 19 years old, I became a flight instructor. And one of the courses that the Federal Aviation Administration requires you to take, if you're not already a teacher like my wife, is to take something called fundamentals of instruction. They want to teach you how to be a teacher. And what I've learned and remember from that course is concepts such as primacy and bias. And primacy, what you essentially learn first, sticks with you. And that can actually form biases in your thinking and behavior. So for example, when you're learning to fly an airplane, you want to learn how to avoid stalling the airplane. Stalling the airplane causes, in many cases, the nose to drop rather rapidly. You get some shaking. You get sirens or horns going off in the cockpit. Something you generally want to avoid. And the instinctive reaction that you're taught is when you get into that condition, is to immediately push down on the yoke to recover. Well, it turns out that many, many years later, the FAA had determined that certain types of stalls may require a different form of recovery. And there's been a number of accidents as a result of this. And it's very difficult for pilots like me who have been trained in the old way to recognize and behave in a different way because of primacy and the bias that were formed as a result of my early training. And the reason I bring this up is something similar happened to me in the legal profession. I went to Marquette Law School and became an attorney shortly after that. And one of the courses that I took was on copyright law. And in copyright law, we learned a concept called fair use. And I remember very clearly my professor telling us that you never want to try to argue fair use in a commercial context. You're generally going to lose that the debt gets stacked against you significantly. And I don't remember a lot of my lectures from law school, but I do remember that lesson. And that stuck with me for a very, very long time, which is why when this case came up, where Google was arguing that their use was a fair use, which I will describe some of the elements of their argument, I was very biased. I said, there's no way they're going to win this because look at the commercial aspects and success of the Android platform. It'd be difficult to argue, I would think, a fair use argument. And of course, I was wrong. And I really wanted to understand why I was wrong and why I formed that bias. And I spent a significant amount of time going through this case. And that's what I want to present you today as some of my findings and kind of walk you through the journey that I took with this case and the results. I do have to say just for completeness, I am an attorney, but I'm not your attorney. So if you have specific legal questions about unique issues to yourself or your organization, I do advise you to seek out counsel. What I'm providing here today is just some general perspective. And in terms of questions, we can keep it somewhat interactive, but there's a limited amount of time. So we may have to take some of those questions after the talk and it may have to stay here as late as anyone wants to answer those questions. So let's get started. By the way, I appreciate everyone being here so late. So let's start out with the Java background. I've given this talk to lawyers and technologists. And I think some of the items here are probably repetitive or well-known to the technology community, but let me just make sure we level set on this because there's some terms that I use in subsequent slides that if I don't level set here, they may be confusing at least the way I use them or the way the court use them. So Java was created in the mid-90s by Sun Reco Systems, which was eventually acquired by Oracle. And this enabled software developers to write programs to run on any Java virtual machine, virtual machine being like a sandbox where you can run that program and the virtual machine being a program that runs on a specific piece of hardware and an operating system. So the idea here is that regardless of the underlying computer hardware, you can write your program once and deploy it anywhere. Great solution, right? So they came up with two different types. Actually, there's multiple versions of Java, many of you probably know. But one of them is called Java Standard Edition Platform, Java SE. And that's a technology targeted more towards computer systems, servers, desktop laptops. And then there's the Java Micro Edition, which is a technology targeted towards embedded systems, at least it was back in the day. And it seems like they're targeting that more towards the internet of things in that market. So Java SE, Java ME. Now, APIs are used in a wide variety of ways. I think it's a bit, an overloaded term, so to speak. I've had to be very careful in my practice when I'm speaking with clients about what they actually mean by an API. It means multiple things to multiple people. I think what we're gonna have to do in this presentation is talk about it in the way that the court discussed it because that led to the various holdings and communications that they had in their documents. So, an API here stands for Application Programming Interface. And the way the court describes this, it allows Java programs to use pre-written programs to build certain functions in their own Java apps rather than having to write them themselves. So the example I often use, at least with non-technological audiences, if you wanted to compute the square root, you're not gonna go to your old math book and figure out how to do that and the algorithm for that, you're gonna just call them math.sqrt or whatever the equivalent is in Java to do that. So, but as defined in this case, the copy dispute in this case involved 37 packages of computer source code. And they refer to these groups of computer programs individually and collectively as the API. So whatever your idea of what an API is, this is how the court defined it in this case. So I like graphics, I'm kind of a visual person, so I drew this up. And this describes what we call the structure, the sequence in the organization, or in your US law called SSL, is how we abbreviate that, for the organization of this API that it was of interest in this case. And it starts out on the left side as in the blue column is packages. So you have Java AWT, Java.lang, Java.io. And if you look inside those packages, like Java.lang, you'll see a number of classes, like class byte, class long, class math, class number, so on and so forth. If you look inside one of those classes, like class math, you'll see ABS, Max, Min, ULP. And every time I get this presentation, I cannot remember what ULP stands for. Maybe someone in the audience does know that U is in the last place. Thank you. I'm getting this presentation like 10 times and I didn't know what it was. It tells you what the precision of a floating point value is. Awesome, thank you. So I did not use that one as an example, but we're gonna look at the method, the max method as an example here. But you can see as ABS would be absolute value, Max is to compute the max of two values and so on and so forth. So what's interesting here is each of these packages is a class and then these classes divide it up into methods and what is critically important in this case is the way that this is structured and organized. This organization of packages, methods, classes and methods is actually copyrightable expression, or it can be copyrightable expression. We're gonna talk about that in a little bit and that was really the essence of this case. So each Java method is broken into two components. We have declaring code, the method declarations and we have the implementing code. So the method declaration identifies the pre-written function, it identifies the method body, the input names and other functionality. And then we have the way that you implement that function. So this is an example of what I pulled from OpenJDK and what I also pulled from Android. So we have a method declaration of a sort. We have public static, long max, long a, long b. And being a technical audience, I'm not gonna explain all those elements. Does anyone want me to take a deeper dive into that? Long a, okay. And it returns a value, right? It says if a is greater than or equal to b, then return a, otherwise you return b. And then Android, we have a very similar declaration at the top, static, long max, long a, long b. You'll notice the implementation is slightly different. There's just greater than, not greater than or equal. So the top non-molded line is more the method declaration that defines the name, the inputs and the outputs. The bolded section is the implementing code, as we all know. Now, these are slightly different. The implementing code is slightly different, but they do have the same result, correct? Thank you. They do have the same result, correct? No. No? For long, yes. Yes. I'm asking the wrong audience for this. But I think the issues of a and b are equal for longs. The first one's going to return a, the second one's going to return b, right? But a and b are equal, so literally it wouldn't matter. Okay. So the point I'm trying to make is someone in the Android team created a version of this method, the implementing code, but they did it in a slightly different way. And I don't know, perhaps if you did it the second way for Android, it runs more efficient on a mobile device. Maybe it uses less battery power. Maybe it runs on clear, but the point is you can have different pieces of implementing code and they can be written separately while having the same method declarations. And why am I elaborating on this point? Because the copyright infringement case here was not safe for one item. It was not about the implementing code. It was about the method declarations, okay? So here was Oracle's complaint. They had some patent complaints and they also had copyright infringement complaints. I'm not gonna talk about the patent side of this except for the reason about why it went to a certain court, okay? The key of this case, at least I think the most interesting part to all of us is the copyright side of this. So the copyright claim consisted of an infringement of 6,000 method declarations, 6,000 of those declarations we talked about of the example I show here. And the structure, the sequence, and the organization of all of those declarations. The fact that they copied those method declarations all 6,000 of them, they in essence copied the structure, the sequence, and the organization. And as I talked about before, both the method declarations themselves as literal elements may be copyrightable, protectable expression. The structure and the sequence in the organization that learners call non-literal elements are also protectable under copyright law. So a couple of things in this case that we're not in dispute. The Java language is not copyrightable itself. Google admitted copying almost 12,000 lines of declaring code from those API packages from Java SE. They admitted copying all those method declarations in essence. And that the declaring code reflected that structure, the sequence, and the organization that is not in dispute. And, Key, Google wrote all of their implementing code, except for one function, which I'm not going to talk about. It was just a small part of the case. So all that implementing code, when they wrote it for Android, not copied from Java, from monogoricals of Java. OK, so here's what happened in terms of Key events. 2007, Google announces Android. 2010, Oracle acquires Sun. 2012, we have the first jury trial. The jury found that there was copyright infringement of the 37 API packages. So the jury said, they copied it. And the trial courts subsequently decided, though, that what they copied was not copyrightable expression. So I just said all those method declarations and the structure, the sequence, and the organization could be copyrightable expression. But the judge, the court said, in this case, they're not copyrightable expression. So I don't care what the jury says, even though you infringed it, that's not copyrightable to begin with. So there could be no copyright infringement. Make sense? And the jury was also asked to look at, just in case this thing went on appeal because they knew it would, whether, if they did copy it and it was copyrightable expression, would Google's use be a fair use? And they didn't decide that at the lower court. So at the end of 2012, we're in a situation where Google was found to infringe, but they infringed something that wasn't copyrightable. So they're off the hook, right? So then there is an appeal. This goes to the Court of Appeals of the Federal Circuit. This is a really strange court in that they normally only hear patent cases. They don't normally hear copyright cases. The reason they heard this case is because there was an element of patent infringement here. So it went to this case that normally doesn't hear this type of thing. They reversed the decision of the first trial, and they found that the API code was copyrightable. Uh-oh. So now Google was already found to infringe, and now they infringe something that was right. They can infringe because it was copyrightable. OK, so now what does Google have to argue? They have to argue now that their use was of fair use under the law. We're going to talk about what fair use is in a minute. Is everyone with me so far? Very confusing court history here about what happened and a lot of nuanced issues. But this is, I think, a good summary of that to where we're at. And there's a question in the back. Yes? This is Mike's. I'm sorry? This is Michael's in these courts. The juries? Are they just lay people? They were lay people. And in fact, both juries were different. When we go to the jury trial in fair use, it was a different jury than the first case. Yes, these were your neighbors. Yeah, generally probably non-technical people. Which, when I read the jury instructions, I try to synthesize a lot of the court documents and the jury instructions. And it was a very involved set of instructions that was presented to the jury. And I actually felt for them that this would be a very, very difficult thing to process. I think it would be increasingly difficult. They didn't have a technical background. And they did a very, very difficult job. I'm confused. You said the second trial found a patent case. But then they were arguing about fair use. Are those separate laws? Yeah, completely separate thing. What I was trying to say, I'm sorry I didn't make that clear, is because there was a patent element as part of the initial complaint that when this case was appealed, it went to the special court. If there was no patent element, it would have went to a different court in the Ninth Circuit. But because there was patent aspects in the original complaint from Oracle, it ended up being appealed to the special court that normally hears patent cases and other interesting cases in the United States, but normally not by itself copyright issues. So the second court wasn't considering the patentability of it at all? Well, there was some patent issues in the case. But that's kind of beyond the scope of what I wanted to discuss. But it's because of the patent issue that it went to that court, which normally a copyright case in itself would not normally go to the CAOC. So in 2016, the second jury trial was remanded back down. There was the jury, which was a different jury, found that Google's use of the copyrighted API code was a fair use. Now, Oracle has appealed again, so the story is not over. Let's talk about where we're at. I think there's a common misconception about this case. When the community heard that Google was successful on a fair use argument, I think there was an idea that APIs are not copyrightable. What happened here is Google's successful argument in that 2016 second jury trial that Google's use of the API was a fair use doesn't change the earlier appellate CAFC decision. That decision still stands. And that Oracle's API code is copyrightable expression. Oracle's API code, in this specific case, their code is copyrightable expression. It's just that Google was successful to argue that their use of that copyrightable expression was a fair use under the law. And the reason I talked before about the CAFC to kind of address this other question is that they normally don't hear copyright cases. And I think because of this decision at the CAFC level about whether this code is copyrightable or not, they're finding that it was, I think it has limited residential value in the court systems. It would be influential or persuasive in certain cases. But it may not be all that significant just due to the nature of the way appeals are handled in the United States. But this court's opinion may not be all that significant, but it certainly will be persuasive. And it depends on what circuit that case similar to this may arise and how it will be appealed. So what I'd like to do now is put all of you in the jury box. And I'm going to present to you in part what the jury heard in this case about fair use. So you're in 2016, you're in the Fair Use Jury trial, the second trial, whether I should say the third trial, right after the appeal. And again, what I had done before is I tried to synthesize a number of court documents to try to come up with what may have been argued at this case. I was not at the trial. I do know some people that were there. What I could try to do, the best I could, is try to glean and understand a little bit from all those documents for what was presented and focus on the key arguments. Because we only have 20 more minutes. But fair use, how do you argue fair use if you're Google? Fair use, there are four statutory factors for fair use. And there's one non-statutory factor. I'm going to talk about all of these. The first one is purpose and character abuse. Actually, before I go there, I do have to say, in the jury instructions, they were presented all of the law around fair use. And what all of these elements statutory and non-statutory elements mean, how you should interpret them, and in the context of this case, how they should be interpreted. But it's complicated. And you're going to find out, as we discussed this, that some factors influence other factors. And there's kind of this pull and push and urging different directions, depending on what one factor finds. It may put more weight on another factor. And it's a holistic experience, I guess. You just have to look at the whole thing and come up with an idea at the end, is does this sound like fair use or not after you evaluate all of these factors? All right, so the first one is, under purpose and character abuse, is the fact that bad faith doesn't support fair use. So, there were many people at Google that understood at least the declaring code and their structure, their organization, of those APIs, was free to use and re-implement. Both, you know, basically as a matter of developer practice. And the availability of independent implementations of the API enhanced the popularity of the Java language, which Sun was promoting as free for all to use. And there were people at Google that testified that in Google's view, the practice of duplicating declarations existed and that the real competition was on implementations, right? I talked about before, maybe that way they implemented that max function that was more efficient in a mobile device. Now, Sun was arguing that, in Oracle now, that Google needed to get to market very quickly. And early on in this case, right, there was discussions between Google and Sun about licensing Java. And frankly, those negotiations broke down. So there was these arguments that, well, you know, maybe Google worked in bad faith. So that's the arguments that went on bad faith. The second point about purpose and character abuse is around commercial purpose. So this is what I talked about earlier with my earlier bias. Commercial purpose weighs against fair use. That is clear. But even a wholly commercial use, okay, may still constitute a fair use, contrary to maybe what I thought out of law school. So I don't think there was much of an argument in this case that the use was commercial, although there may be some disagreement about the extent. But Google's use, Google was arguing that their use was not entirely commercial. Google's decision to make Android available open source and free for all had non-commercial purposes. You know, general interest in sharing software and promoting innovation. The last aspect of purpose and character abuse is transformation. And transformation supports fair use. I'm gonna talk about that in the next slide. The more transformative a work is, other factors such as commercialization recede and important. So if you're more transformative, you have a better argument for a fair use argument. Being successful on a fair use argument. So Google argued that its work was part of a new mobile platform versus desktops and laptops. And Google combined it with brand new methods, classes, packages written by Google for the mobile space. And they argued that this constituted a fresh context, giving new expression and meaning to the duplicated code that was transformative. And Google, or Oracle argued that Google used the exact lines of declaring code, at least those portions, and their structure and sequence and organization with no new meaning or expression. So that's the way the two arguments went. So the key here is that the more transformative something is, other factors such as commercialization will recede and important. And really what is transformative, right? The work's transformative if it adds something new with further purpose or different character. Altering the first of new expression, meaning or message. You can get transformation when you change your work or you even use the work in a different context. So here taking Java SE and now moving that to the mobile space could be an example of transformation. Okay, so let's go into the second factor for fair use. Fair use favors functional works versus creative works. Okay, this is the nature of the copyrighted work. Of course, my notes here. I'll argue here is that the process of designing APIs are highly creative and thus at the core of copyright protection, which doesn't favor fair use. And there was some testimony from various designers of many of the Java APIs saying that API design is an art, it's done in science. And then Google's experts were emphasizing the functional wall of these declaring lines of code. They were trying to minimize the creative aspect. The next factor is the amount copied. Now it turns out, does anyone know what percentage of lines of code, for example, that was copied from Java SE that was put into Android? Do you have a guess? In terms of percentage, what was that? One. One, yeah. Less than one. It was about one, copy one percentage. It's important when you look at this about what you copied from, not what you copied to. So you're not looking at the percentage of what went in, of Android, what was copied. It's what you copied from. So the amount copied, you have to evaluate the amount and substantiality of the portion used in relationship to the copyrighted work was a whole relation to Java SE. And wholesale copying doesn't preclude fair use per se, but certainly goes against it. So you see all these factors kind of point against each other. And the extent of permissible copying varies with the purpose and the character of use. If you only copied enough to be transformative, then this factor doesn't weight against the accused. So if they only copied enough to make it usable for mobile, then this factor doesn't have a lot of weight. And then the last factor was the effect on the market. So Google argued, and this is probably obvious, but if you materially impact the marketability or the value of the copyrighted work, that cuts against an argument for fair use. So what Google was arguing is that Android didn't cause any harm to the market for Java SE, which was targeted for desktops and laptops, not mobile. And Java NE, right, the micro addition to the extent it targeted mobile device was declining in revenue as predicted by Sun before Android was even released. So there were arguments that Android had no further negative impact on Java NE. And that APIs are open sourced under OpenJBK, which is one of the code snippets I showed previously, under the GPL v2 and class path exception. Anyone could have copied those APIs without any fee, of course, subject to the GPL copy of terms. So how could Google's activity really harm Oracle's market in light of all three of those arguments? And then there's other factors, and this is non-statutory, so it's not written into the code or legal code, but the jury was instructed to consider any additional circumstances, pro-con, that in their judgment, bear on the ultimate purpose of the Copyright Act, including protection of authors and the right of fair use. Namely to promote the progress of science and the useful arts. And this is why we have long copyright law, is to promote the progress of science and the useful arts. So the question is, did Android do that? Did it promote the progress of science and the useful art? And this is kind of a squishy little, non-statutory factor, but it is part of the law in the United States. And it was one of the factors that the jury was asked to use and synthesize with all the other factors to come up with a decision on whether Google's use was of fair use. So this is, after all of that, this was the single piece of paper that was presented from the jury after the jury instructions. And it said, has Google shown by a preponderance of the evidence that it's use of Android in the declaring lines of code and their structure, their sequence, or organization, from Java to SE, constitute a fair use under the Copyright Act. That's what they were asked to analyze and they either had to check yes or they had to check no. That was the only question after all of this, right? So what would you decide? Who would have found in favor of Google? And by the way, there's no right or wrong answer. You could have been in the jury and had a different conclusion, right? So this is for Google, right? Seems more than half. I should ask the other way, how about Oracle? This is a biased audience. Now he says so, I figured that. How about Oracle? So say them both. So we know how this ended up, right? It was in favor of Google. So the current disposition here is that the Court of Appeals of the Federal Circuit that decision still stands that API method declarations and their organization, their structure, their organization of the type in this case, right? Our copyrightable expression. The lower court decision on fair use, right? Does not reverse that higher court decision, right? Holding that this API could be copy, is copyrightable. But I think the impact of that ruling is still questionable for the reasons I talked about. And then Oracle has filed an appeal. So that is the case in a nutshell. And I hope my goal here was to explain the technical side and the legal side and maybe get rid of some misconceptions that were in this case. And I hope all of you found this useful. I'm happy to take some questions here on the stage or we can do this after the event. I really wanna thank you for your time and for coming out this evening. Thank you. So you mentioned that you thought the Federal Circuit decision would not be significant. You didn't explain why, but you did say it was sort of persuasive. So to the degree it is persuasive, what would be the avenue to undo the persuasiveness or in other words, how could the Federal Circuit decision be overturned? Yeah, that's a great question. So this case, if it was normally, if it didn't involve patents, it would have gone to one of the appellate courts in the Ninth Circuit. And then to the extent there were other decisions and other circuits, there could be a split in those decisions and that gets resolved ultimately at the Supreme Court. So I think to the extent there's other decisions and other courts outside the CAFC and we start to get a split, I imagine that could ultimately get resolved in the Supreme Court in terms of being persuasive. So this goes to what court would actually be bound by this decision? So the CAFC was bound, was required, even though they're not in the Ninth Circuit, they were required to use Ninth Circuit law. And it actually is a bit un-clerk to me if this went to the Ninth Circuit again, a similar case to the Ninth Circuit, whether they would be bound by that decision, I don't think so, but I think it would be highly persuasive because that court was supposed to be applying Ninth Circuit law. Now if it went to another circuit, it would be less persuasive, because it was Ninth Circuit law, not this other circuit's law. So it's kind of an interesting issue, but that's why I think it may just have some limited impact because I think at best it's only highly persuasive in the Ninth Circuit and less persuasive in other circuits. I suppose that with a similar case when in front of the CAFC again, they may be bound to that decision, that court only. One of the reasons why this particular court decision has been interesting is that it seems to weigh in directly on the copyright ability and fair use of interfaces as opposed to code. And one of the things that appears to be related, and I'm curious if it actually is related, it seems to be related to one of the probably the most famous open question in free software licensing, which is that if you write a program that links with the GPL library, is the program required to be covered by the GPL, seems related to this question of is the interface part of the copyright? Is this at all related? And I'm curious to clear that up because I know that people, some people think it is and people think it isn't. It's a great question. Frankly, I think that discussion has been going on for well before I got into open source. I don't think I could clear it up right here on the stage as a result of this case. I think the issue about what the GPL actually covers relates to some of the texts in the GPL about what is a program. If you look at that, you could certainly do some derivative works analysis and some of those legal tools. But if you look at the spirit of the GPL, what is an entire program? What do they mean for that entire program to be subject to GPL terms? So we can have a discussion after this. I'm not gonna be able to clear up that. And certainly today, I'm sure the role of a, perhaps more clarity on that, but that's beyond, I think, our talk right today. But happy to talk to you after the talk. So right at the start, you defined that a language could not be copyrighted. The API, is that not the definition of what the language is? I think when they're, it's a good question. When they're talking about the language is not copyrightable. It's some of the syntax that's used, how you maybe multiply numbers together, just overall how Java is constructed, not the, of the language elements itself, but not necessarily the API. But it is a little bit squishy, right? About what that means. But I think when the court was talking about that, they were talking about just the low-level syntax of the language itself. But not the API, right? Because that clearly was carved out as something that could be copyrightable expression in terms of the method declarations themselves and the way all those method declarations were organized and that taxonomy that I showed on that picture. So there were no frustrating things about, for all this of this case, the most frustrating for me was to hear a project I named and an exception I helped write and talked about by a federal court. That was very odd. Made on a class path, except me. But the thing that bothered me most was this problem with what an API is. I think most developers have that to quote another US court thing. They know an API when they see it. But when you start to analyze what's copyrightable, what copyrightable components end up in an API, I can only find three things that could be gotten right. There's the implementation, which I think it was shown pretty clearly in the case was not in French. I actually don't even know the max function of the French. I think it was an accident that he had to write it exactly the same way. That's a question, not obviously. But the documentation for the API, which clearly wasn't in French. And then all this left is the function signatures. And I don't think the appeal score, when I write the decision, really explained what copyrightable material they felt composed the API. So do you have any opinions about what is the copyrightable material that is the API in your view? And how does that relate to the decision? Yeah, great question. I think there were a lot of unfortunate issues in this case. So really, I'll talk about what the court discussed. And then we take a little deeper dive into that either now or afterward. So the piece that was a little more clear and crisp to me in that decision, the pull-up decision anyway, was the fact that you had non-literal element structure sequence organization of that API that was viewed as copyrightable expression and they viewed it as copyrightable in this case. And that I think is something that may have been unexpected for people that don't study copyright law by trade. So again, I don't- Could you pop back to your slide with the definition of non-literal in this context? I'm having trouble remembering it. So I think this is probably the... Okay, so that's the non-literal side of it. So the fact that they copied like 6,000 of these function prototypes, method declarations, right? The fact that they copied all of those naturally led to them copying that organization. Cause you know, it's like Java dot laying dot math dot max, right? And you start laying all these out and you start getting this taxonomy. And it was the way that organization occurred that caused us to have non-literal copyright protection, right? Attached to this taxonomy. But then there's also the method declarations themselves. So that would be the public static, long max, long A, long B, okay? They sadly, I think, this is my one opinion, that they did attach copyright protection, perhaps to these method declarations themselves. These really short phrases, right? And as a copyright attorney for many, many years, frankly, I've never given a lot of weight that there's, you know, if there's copyright protection on just those names, those function names, I mean, it's gotta be really, it's paper thin, right? But yet the appellate court here seem to discuss the possibility that these things could be copyrightable themselves. And they had some logic behind it. I think it was a little bit confusing and I don't think it had a lot of, I think it just added a lot of confusion to the case. I think the second part of the SSO was a little bit more at least clear in my mind about what the colorful arguments were that are about copyright protection. So that's kind of the two areas where copyright protection attached in the case. We have time for maybe one more question. Okay, I've got more of a piece of advocacy than a question, I'm sorry, it just makes me so mad. Because from my perspective, the CAFC is used to seeing patent cases. So they looked at a mixed copyright patent case and saw just patents. Just think about it, APIs are an interface to something. It's like a gizmo, like a replacement fuel pump for your car. So the interface is the part that fits to the other components in your car. I mean, everybody loves these car nowadays, actually everybody hates them, but I'm gonna use one anyway. But you know, how are you supposed to, the whole point of a patent is to say, okay, I've got the machine of this design that does this thing and nobody else can do it. In exchange, you know, I'm publishing my design in 17 years, give or take, board, fun, pharmaceutical. Then everybody will be free to use this. But with copyright, the argument is, okay, well if you can come up with something that is just as good as Mickey Mouse, just as entertaining, say, Colin Mugs Bunny, then you know, that's your independent thing and there's no relationship between the two. You know, in software, let me point out if nobody's ever noticed this, probably many of you have, the BSEs didn't like the fact that Rewind was under full GPL and they went and on at least two, possibly three occasions, people have re-implemented the Rewind API. So, you know, the question we should ask ourselves was this a legitimate thing to do or not? Because according to the CAFC, that was not legit because Rewind's API, which has a lot more of a claim to creativity, I would submit than math.sqrt, how many ways are you gonna write that for integers? It might have been fair use for the BSEs to do it, though. Okay, fair point, but I mean, I don't think the case shouldn't have had to reach that. Like I said, that's more of an abyssin thing. But what I'd invite you to say is like, what's the weakness in what I'm saying? How would you argue against it? It's just a couple of brief points about that. You know, although the CAFC does primarily hear more patent cases than copyright cases, I'm not sure if I read the opinion that they really conflated those two to any great extent. I think they didn't try to apply, at least from my understanding of copyright law principles in there. I didn't see them conflating those two to any, I don't remember seeing that. The other thing that I would just caution everyone on is that this case was very fact specific with what Google did with Java. And other examples that you may have, like the one you brought up, I'm not directly familiar with that, just be cautious about applying those, the facts in that case to the facts in this case. There may be remarkable differences that you have to take into account for yourself. So, thank Jeff again for his very interesting talk, and he'll be glad to thank you for that.