Transcript: Keynote Address - “Google’s Philosophy of FOSS” by Max Sills

November 2, 2018
Jerome Greene Hall, Columbia Law School

Session Description:

Google’s open source compliance philosophy briefly. A talk on topics from Google’s open case book and a discussion on copyright infringement versus contractual breach, joint versus collective works in open source, and how the distinction informs policy.

Presented by The Software Freedom Law Center and Columbia University Law School with Max Sills of Google and moderated by Mishi Choudhary, Legal Director of the Software Freedom Law Center.

See event page for further information.

Transcript

MISHI CHOUDHARY: Good morning, a very warm welcome to all of you, old friends and some new. For those of you who have gotten used to Eben’s erudition and wit, I’m sorry you’re stuck with me now. Don’t worry, I advise you some patience. He’s in the room, as you see, and I promise you’ll get your fair share.

For those of you who don’t know me, my name is Mishi Choudhary. I am the professor of nothing. I’m the Legal Director of Software Freedom Law Center. Every year, we gather here to talk about free and open-source software and law stuff. But it’s not always just law stuff, because there’s a lot of FOSS. There’s a lot of community. There’s a lot of industry because that’s how we all work together.

We’re in the midst of a lot of things, and it’s the right time to be in the midst of everything. Eben and I planned this conference kind of late, in the early part of summer, because he’s writing his magnum opus during his sabbatical. You will soon see that book, and that’s what he’s busy with. We talked to our program committee, to whom we are, as usual, extremely grateful. I would love for you to see them all, because if the program is not interesting, you would know who to blame. Can you all wave? But this – don’t be threatened – this is just all friends out here! Thank you, thank you for all your work and all your support.

We’ve figured out with the help of our program committee what we want to use this day and this time for. We wanted to talk about the extraordinary influence that cars are having on the way software is made and used around the world. We wanted to talk about why there is consensus that AI and machine learning are free and open source software-based activities. We have some interesting ideas about how licenses are evolving these days: free, open, not open, not free, everything. So, we went and organized this, and look where we are: it’s a full day.

We have a broader consensus than we expected to have because we didn’t expect to be welcoming Microsoft in its all-in-on-open-source form this year. But here we are. We knew it would happen someday but didn’t know it would be this year. Thanks to OIN and Keith Bergelt, who brought Microsoft in. Then there is some small corporate news about IBM and Red Hat, so we have enormous changes in the industry to discuss.

Like every year, we have people who work around FOSS, and then some who may not work in the industry but apply those ideals to larger issues of politics and everyday life. You will hear from Julia Angwin later in the morning. We are going to put up this law stuff, put a bunch of reality around us, expand it to the larger world of politics of journalism–put context around everything. And we are going to present some ideas about what is happening right now, and what that means for our future. Given the extraordinarily well-informed audience I see before me, I am also sure this will be interacting, energizing, and a little bit confrontational, or fun for all of us.

To begin this extremely interesting day, we have the omnipresent Google. It is my great pleasure to introduce Max. Max Sills manages the legal team doing open source licensing at Alphabet, setting open source policy across the company, and managing business relationships and corporate structures for some of Alphabet’s most important open source projects. He and his team are writing a casebook on open source legal issues. Max is a technical committee member of the OIN and a legal committee member of the Cloud Native Computing Foundation and the Node.js Foundation. He advised on open source issues related to the Oracle v. Google litigation, was a deal lead for partnership that brought the Kotlin programming language to Android, and worked on machine learning for patents.google.com. Max earned a Doctor of Law from Vanderbilt University Law School, and his B.A. in Mathematics and Cognitive Science at Case Western Reserve University. Max is an attorney admitted to practice in the state of California and giving you CLE credit in New York.

I need some more coffee, and you need Max now, so welcome Max!

MAX SILLS: Hello, how are you? I’m Max, nice to see you all. I see a lot of friendly faces here. Today I’m going to be talking about research-based open source policy. And what does that mean? Well, when you’re in a position to design IP policies for an organization, you can do a couple things.

The first thing you can do is just make it up. I see a lot of people just make it up. So, I’m going to try to persuade you folks that there’s an alternative, which is you can use the same legal tools we’ve all been trained with, which is reading statutes, reading case law, and actually come from a common base of research to formulate these policies. And you’ll see that actually some very basic stuff that you didn’t even think involved legal analysis or IP policy – grubby technical details – actually really depend on case law. So, I’m Max. Thank you, Mishi, for the introduction.

We do a lot of stuff. Open source touches basically every single thing that Google does at this point. We also use it to do transactions with folks because open source is an incredible deal accelerator. It can be a lot faster, if you just want to get code in someone’s hands, to apply an open source license to it than to negotiate a full collaboration deal.

Here’s the problem statement of my talk: there’s this tendency to mythologize how open source works. This leads to really deep confusion, like deep confusion on the internet, where we all are, on forums, among clients, even among lawyers, about what is the correct law that applies to an open source license. How should we interpret it? How does this influence the policy we might make? And I think this leads to reading the tea leaves instead of acquiring informed knowledge.

And from my perspective, it makes doing business extremely difficult, unnecessarily difficult, because every day, you’re going to be doing a deal with a new partner. And they have their own kind of idiosyncratic understanding of how open source law works. This creates incredible friction.

Here’s the solution for not only just IP policy design, but just for all of us in the field. We should be able to agree on what the underlying law is. And even if we disagree on what the law is, maybe we can at least converge on how we approach the problems. Maybe we can converge on how we argue with each other. And that would be my hope.

Jim, even if you don’t agree with me, I would like to set the table so that we have a structured argument, and so we can figure out where we disagree. One of things we’re doing to try to help this is a public open source casebook. And I’m going to take you through a couple of the cases and show you with some hypotheticals how having a common base of understanding can really help.

Let’s start with what I think are the ingredients of a good IP policy. I hope I can convince you to not just make it up. You could just make it up, and maybe you won’t get found out. But over the long haul, this is going to lead to a lot of problems with your organization. And just making it up doesn’t scale.

The first thing I like to do when making an IP policy is these kind of core concepts from law and economics. I think these are fundamental inputs to any IP policy. The first is cost-benefit analysis. And I know people hear this word all the time, and sometimes that can be a symptom of just making things up, honestly. Here’s the cost: you just articulate something which doesn’t make any sense. And then, you create the benefit, and the benefit is amazing, and then it can be a way to avoid thinking, which we want to avoid. We actually want to think through this.

The second law and economics principle is this idea of the cheapest cost avoider. An organization like mine is this deep, complex web of people, and they each have their own utility functions that they’re trying to optimize, right? We’re all in competition with each other, even within an organization. You want to figure out for compliance and for IP policy, who’s the cheapest cost avoider, if there’s some kind of harm you want to avoid, who is best positioned within that organization to do it, and finally–and this is kind of related–principle agent problems, and monitoring costs.

For example, a couple months ago, we had to create an IP policy for folks who wanted to work on hackathons, right? You have sixty-thousand employees, and they’re very creative, and they don’t care about their employment agreements. They don’t care about the law. They just want to go be creative. And so, the problem is, “What do you do with that?” Because you want to make them happy, but you also don’t want to completely destroy your IP portfolio, right? You don’t want to be licensing patents to the wrong people or in too broad of a manner.

What you want to figure out in the principle agent issue is what’s the minimal amount of monitoring costs you can spend to kind of maximize the value. Alright, I have to talk through this. I think of it in a kind of engineering way in that IP policy should have these things as inputs. But, really, at the end of the day, they need to be grounded in law.

This is kind of how I see all of our policies: we start with the law, we try to come up with a common understanding of what the law is, then we have the principle-agent analysis, the cost-benefit analysis, and then finally the implemented policy. And it’s really important to us at Google to keep these things separate because the law is evolving, the costs and the benefits of doing any particular action are evolving. But the analysis should be separated from the policy, and this is what I was saying earlier: we need a common base of understanding.

Let me walk you through a couple of hypotheticals to show you how this kind of common base of understanding and open source case law can help us make better policies. I’m just going to say these are hypotheticals, but they’re informed hypotheticals. You have a bunch of brilliant engineers, and they just invented a new compression standard. Super cool, everyone’s extremely excited about it. It can make the internet better. To encourage adoption, your client says, “Hey, I don’t just want to do this by ourselves. Let’s work with others, because working with others is great, and we all support open source. Let’s collaborate on GitHub.” Alright, so, you’re on GitHub, and let’s say you’re not a very careful IP policy manager. So, you go, “Alright, I know this open source thing; I’ve got it down cold. I’ve got to pick a CLA, and then a project license, and then that’s open source–done, right?” And then the rest is the community thing, this nebulous community thing, so you pick Apache.

But then your engineers come to you and say, “Well, that’s not enough; we have follow up questions. First of all, what should the attribution line be at the top of source files? Should we put an AUTHORS file in there, because we’re working with a lot of organizations, and they say that they want credit? And then, finally, can we let our collaborators merge pull requests? Can everyone just edit it together? Should we be the sole editors?” And then, here’s what you say: you say, “I don’t care. Leave me alone. I’m a fancy lawyer. I don’t care about this GitHub thing. I just told you I picked a license; I’m done.”

You made a mistake–whoops! You just made IP policy, but you didn’t think through it. There are a couple of problems with that approach. The first is you didn’t articulate your grounds for analysis, and this happens, I think, all too commonly in open source. The policy you just made is not scalable. Telling people, “Don’t worry; just go do whatever you want,” is not scalable, because the more projects you do, people are going to continue to ask the same questions. You could have at least tried to articulate the cost-benefit analysis–maybe you could have written that down somewhere, or the principle-agent analysis. What are the monitoring costs that you’d incur to try to get the optimal policy? And where did you want to spend that money? And then, probably the worst thing is you didn’t think about the case law.

Let’s think about some of the case law behind that little hypothetical. There’s more in the book, and I encourage everyone to go read it and to send me a pull request and contribute to it. But I’m going to just go through a couple. The first thing is basic copyright law. I want to distinguish the types of authorship under copyright law from the types of work. There’s really two types of authorship, fundamentally. Multiple people can own something, or one person or entity can own it–and the same types of work. A collective work is a collection of independent copyrightable contributions versus a single work. And I just want to start with that because people tend to confuse and oppose joint versus collective, which doesn’t make full sense because one’s a type of authorship, and the other’s a type of work.

Let’s look at this case. Is anyone familiar with this case? Has anyone seen this? This is Aalmuhammed. It’s a super-interesting case, and I encourage you to go read it. Spike Lee directed the movie, Malcolm X, and he hired this expert, Aalmuhammed. Aalmuhammed did a lot for this movie. He suggested script revisions. He worked with the actors and coached them on their acting styles, which you could argue created expressive elements that were captured on film. He translated Arabic into English. He even wrote substantial portions of the script, including scene directions, like the directions that people should pray, praying towards Mecca, and other things. The movie was moderately successful.

And Aalmuhammed sued, and he asked for two things. The first is he said, “I want to be an author. I want the credit, and I want the money that goes along with being the author of a joint work.” And the second thing he sued on was quantum meruit. Now I’m not going to talk about quantum meruit, but I hope you get really freaked out by that, because I don’t think we talk enough about quantum meruit, the concept that someone could contribute something of value to an open source project and then be owed something for the benefit that they conferred to you. Now, I’m not going to go into that too deeply, but I want you to be freaked out about it.

Let’s talk about Aalmuhammed. The Court really got caught up on this statutory definition of joint work, specifically the word “authors.” And then, this is the kind of thing that keeps me up: authorship is not the same thing as making a valuable and copyrightable contribution. That is a little bit surprising. It suggests that someone could make a valuable, independently copyrightable contribution to your code base, and they might not be the author.

Now, if a definitive contract is signed between parties that states who the author is, that’s usually going to be dispositive. But that’s not how open source works. Even in our CLA’s, we don’t really talk about authorship status of our works. Something again, an asterisk–go look at your own CLA’s, because this could be an issue that you have not examined.

The Court says three things–here are the behaviors of an author. First, an author exercises editorial control over the final work. Coauthors make objective manifestations towards each other that you can go look up in the record that they have an intent to be coauthors, and you distinguish who made the fundamental contributions to the work. Under that–and I’m going to save time for questions, and hopefully we can have a little bit of a debate and talk to each other.

But that really changes the policy now, that you form, right? Because just a few minutes ago you were just making it up. You didn’t think about the case law that might inform this, but now you think, well, geez, all of these could be elements that a court would look to see whether you’re a joint author with your contributor or not. I mean, that AUTHORS file could be that objective manifestation that you intended other people to be authors of the work. And that’s bad, because if another person was a joint author of your work, that would mean that they would have the independent ability to relicense it and sue others over it. That might not be what you want.

The second thing I want to talk about–I’m just giving you a little flavor of what it’s like to design a policy based on case research, resolving ambiguity in open source licenses. This is for Dave; this is specifically for you, Dave. So, your client has spent years doing R&D, and they came up with a brilliant way to detect a type of cancer. Now your client has a bunch of patents on detection and bioinformatics, and let’s say, for the moment, that these are valid patents; these are good patents.

Clients want to move fast. They want to play. They want to collaborate, so they say, “we have some reference source code, but it might read on our patents; we’d to put in on GitHub.” They want to release the reference source code under the MIT license. What do you do? Client comes to you and says, “Is this okay; is MIT okay? Will it affect our patent portfolio negatively? Are we going to get sued?” And you go, “I don’t know. I don’t think the MIT license grants patent rights, but go ahead.”

When it says, “deal in the software without restriction and sell,” it’s being colloquial. And here’s why I’m having this thought: because the MIT license doesn’t include the word “patent,” the person who originally wrote the MIT license says it wasn’t their intent to license patents, and it just feels ambiguous. If we held that the MIT license granted patents, we’d give up a lot of R&D investment, and so it can’t be what it means.

Now, I’m not going to make a statement today about whether the MIT license grants patents, but I do want to get on the same page about the rationale we use to have that discussion, and what are appropriate arguments. I don’t think these are necessarily appropriate arguments. You just made IP policy without research again! This time, though, you did a little bit better, because you thought about the cost-benefit analysis. You said, alright, your client sunk a lot of money into R&D, so that’s good–you don’t want to hurt your client. You did a little bit of principle agent analysis; you thought of the other players in their field, their probability that they would come bring suit against you. But, again, there is no common base of statute in case law. If you were to go and try to do a collaboration with another biotech company, you’d have weeks and weeks of argument, probably with their lawyers, on whether the MIT license granted a patent, and it’d be very painful.

Let’s refresh ourselves on the basics of how to resolve ambiguity in open source contracts. And again, I don’t want to tell you one thing or the other about the MIT license and patents. But I do want to get on the same page about how we should have the discussion, because I think there’s a very clear analysis to do.

The first thing is the ambiguous term material to the contract. If the ambiguous term was not material, we wouldn’t care. Let’s say it’s material, because the right to use and sell something seems pretty material. Does the U.C.C., or the restatement of contracts, or something else apply? We know that when it comes to open source licenses, mostly it’s contract law, patent law, copyright law. Contract law is state-based–and I don’t want to get into it too deeply–but Versata is very interesting on this line, in terms of when preemption might occur.

And then we can look at the statutes, right? We want to start with the statutes. We don’t want to start with a blog. We don’t want to start with something our friend told us because that’s not valid legal reasoning. We want to start with the actual law, and the statute says, so 35 U.S.C. S. 261 says, “Patents shall have the attributes of personal property.” So, you go, “Okay, well, I’m not sure the MIT license grants a patent or not. I know that patents have the attributes of personal property. I’m not sure whether we need to say the word ‘patent’ or not for the grant to be effective, but I’m developing a base upon which I can reason. Alright, so the terms of material are still ambiguous to me. What do we do here?” And you’re going to have to do something because your client’s waiting.

Well, the first thing you could do is try to think about contra proferentem: do we read the license against the drafter? And that commonly happens. If you just stop thinking right now, you might think that the licensor is the drafter; therefore, open source licenses should be read against the people who are issuing them. That’s not true. There is no drafter for open source licenses, because they express community consensus. They’re not negotiated instruments, right? They’re just form licenses. If you go look at some of the case law around the contra proferentem doctrine, it’s all about putting parties who were in unequal bargaining positions–it’s trying to be fair to the party that was at a disadvantage.

I’m not really sure that’s the case, although we could argue that because you could say that a big corporation, bunch of fancy lawyers, understands the hidden, arcane implications of open source licenses better than the licensees. There’s a counterargument there.

Alright, this is how you should be thinking. Just go read the restatement. There is a sequence of authorities, and they must be consulted in this order. First, you look at the express terms of the agreement. Then, you look at the parties’ course of performance, and so there’s this cool concept of course of performance versus waiver. Then, you look at the parties’ course of dealings. And then finally, the least important thing, the thing courts care about the very least, is trade usage.

We’re going to go over a couple cases, and then I’ll wrap it so we can take some questions. But just to start thinking, where do we consider what open source foundations or other scholars say about a license? I think it can be very helpful, because it can help structure our reasoning. It can help give us ideas, and everyone loves reading creative scholarship, but I don’t see blog post on here, right? Maybe blog post is trade usage, but we’ll talk about it. Also, where should we consider what the drafters of the license said? That, I would argue, is nowhere because we consider the express terms of the agreement. But there’s really no room, when you’re resolving contractual ambiguity, to consider or care about what the license drafter thought.

I want to talk to you about this case, Nanakuli. And this is for the course of performance. Nanakuli was a Hawaiian company that made a deal with Shell to get some asphalt at a fixed price. And Shell raised the prices on them, and Nanakuli almost went bankrupt. So, they sued. They sued Shell and said, “You have to continue to give us asphalt at the exact same price, or you’re going to drive us out of business.” And Nanakuli said it’s what would be commercially reasonable. The problem is that nowhere in the actual agreement was there anything about price protection.

What do you do here? Well, you go back the U.C.C, and you go back to the principles of contract drafting, right? “We are persuaded by a careful reading of the U.C.C., the underlying principle is to promote flexibility in commercial practices.” Course of performance shouldn’t be broadly interpreted, but narrowly, given the context of the parties. Just think about that for a second.

This is a really weird outcome and principle if you apply it to open source licenses, because what is a course of performance with respect to an open source license? I have no idea. Google, personally, we have a few thousand projects. We’re the licensors to a bunch of licensees. There are thousands of parallel courses of performance that a court could look to here. The thing is, you really want to look at how the parties interpret it. And what was the narrow commercial context at the time of the license grant?

The Court actually favored Nanakuli here and said, “Okay, the prices can be fixed.” But, the Court said there’s also this concept of waiver that might apply, and you’re not really sure which one would apply. Waiver is going to apply when people really can’t tell what the meaning of the agreement is, and the commercial context surrounding the agreement doesn’t make sense.

Let’s just talk a second–this could be extremely relevant. I’m not going to give you the answer, but I want you to think about it. If you give someone some bioinformatic software, under the MIT license, and you don’t sue them over patents, are you waiving your patent rights? How about if it’s the course of performance between you and other people to explicitly never seek patent relief? Can you seek it later? How about if you have an active licensing program? Are you now explicitly disclaiming patent rights? Should that be read in?

And then, finally, the final case I want to talk about is on trade usage, which again is the least important, but it seems to be the first thing people point to resolve ambiguity in open source licenses. So, there’s this case, Wolf v. Superior Court. It’s about “Who Framed Roger Rabbit?” You guys have all seen “Who Framed Roger Rabbit?”–great movie. It’s actually based on a book. The author sold his rights to Disney. He sold an option, and he said, “Alright, if you make a movie, I want five percent of gross receipts.” So, Disney made the movie, the very famous movie, and they gave him five percent of box office tickets. And so, he sued, because he said, “Gross receipts doesn’t mean box office tickets. How about all this non-monetary value that you got out of all these other licensing deals?”

Because Disney did a couple deals with McDonald’s where they would put characters in Happy Meals and then get some promotional consideration from McDonald’s. So, Disney definitely derived an extreme amount of value, but it wasn’t gross receipts. And so, here’s what happened. It was remanded to the trial court because there was no evidence of the objective manifestations of the parties’ intent. The Court really tried hard both to examine the express texts of the agreement and to go back, look at, in a narrow context, the course of dealing between the parties. It’s only then that a court will even consider looking at trade usage.

I’ve been a little bit cheeky about Stack Overflow, blogs. But one thing to consider is maybe these things don’t mean anything with respect to trade usage, but maybe it’s our consistent citation of external authorities that actually makes them trade usage. There’s a bit of a chicken-and-egg problem. The more you cite to a blog, using that as your grounds of agreement, the more you might be making that trade usage.

Just some final notes. I just wanted to give you a flavor of what we would consider to be research-driven policy design. Public interpretations of licenses constrain behavior in the open source community, and given that there’s really not a lot of litigation, and it’s kind of a happy-go-lucky, although extremely corporate now, space. This is important. The blog posts, the open source foundations, what they say matters, maybe not for legal reasons, as I’ve illustrated here, but because it constrains people’s behavior. It sets expectations for how to be a good person, how to behave ethically and respectfully in the community.

It’s important to separate community perception and belief from what the law is when you make a policy. Both are important, but we should be keeping them separate in our heads, and I think all too often they’re getting mixed up. Okay, that’s it. Here is some contact information if you want to go read through the book or email me. Are there any questions? I’ll get to you next.

AUDIENCE MEMBER: First of all, thank you for the talk, great talk. I appreciate the idea of worrying more about case law and, you know, statutes, and measurable, factual things when we’re trying to set policy. But I look at what I know about copyright law, and there are a large number of cases putting forth this idea of a merger doctrine, and this idea that, you know, functional elements of software aren’t really copyrightable, and only the expressive elements are. And then, a few years ago, there was a case–I’m not sure if you’re familiar with it–Oracle v. Google, where the federal circuit kind of threw the merger doctrine out the window. And I think, specifically given the federal circuit’s history of… I don’t know if they still have a fifty-fifty overturn rate, but they’re a little bit arbitrary in some of their decisions, and they throw out existing case law, apparently. So, how do you deal with the fact that it’s not always as predictable as we would like for it to be?

MAX SILLS: What a wonderful question; what’s your name?

AUDIENCE MEMBER: Daniel.

MAX SILLS: Hey Daniel, nice to meet you. That’s a great question. Talk to Jim. He’s right here. He can explain that. The merger doctrine is a beautiful, frustrating thing, and with Oracle v. Google, in my opinion, it becomes even more complex. It really depends on what you think a creative or expressive element is versus a functional element, right? And it is true that it would be a lie to say that the law is clear. Right, the law is not clear, especially with respect to the merger doctrine and functionality versus expressive content. I would say a couple things. First, if you look at a code-base of considerable size, there’s going to be expressive elements in there. And I’m saying that. I mean, I hate everything about the recasting of the merger doctrine, and even I’ll say, “No, no, no, there’s going to be a ton of expressive content that’s going to be protected by copyright.” I’m not saying that there’s only one law, right? Because there’s not, and I’m not saying we can’t have disagreements. I’m simply saying let’s get on the same page, first, about what the cases are. Can we do that? And then about what are the standard interpretations that we advance.

Right, and think about if, from a policy perspective, when you did the cost benefit analysis, because you’re going to be working at a big company, and you’re going to have to make these IP policies. Well, if at least you started with the case law, and you could iterate two or three or four possible interpretations and their probabilities, that would help you a lot, right? Because you can model something after it. So, I guess my point is even when there’s ambiguity, we can still come to certainty about what that ambiguity is enough to design policy.

AUDIENCE MEMBER: Hey Max, thank you. I appreciate the invitation to engage on those points. So, I was interested… And I actually like, you know, the points that you made about, extrinsic evidence. But I was also interested, if you’re looking for, sort of like, principles around community discussions, community expectations that have been set, if you go back through, you know, the discussions over the past couple decades, you know, a lot of that conversation has taken place on mail lists, you know, such as License Discuss, License Review.

The reason why I like the points that you made around following precedent, if you will, is that I don’t think that it’s helpful for anyone to make a categorical statement around, “Open source categorically precludes one set of IP rights or the other.” I think that people who have looked at open source carefully have all concluded that certainly, as to copyright rights, that is the basis on which many, many obligations and rights have been predicated. Less universally on patents rights, but I do like the notion that in each instance there are use cases that inform how a hypothetical fact-finder might sort of arrive at a conclusion one way or another, based on the behavior of the parties, based on expectations set in that particular type of context.

But as to the larger picture, the reason why I have spoken to this issue in a couple different places is because I’m looking for a way for open source and other collaborative approaches to work well together, okay? And those others approaches are things outside of software collaboration in the open source sense. It’s also standards collaboration, and the place this rubs together specifically is in the area of FRAND.

And we’re not even getting into the topic, you know, that can also be interesting around things like implied patent licenses, estoppel, exhaustion, and those are going to be very rich areas for discussion as well. I know that you don’t necessarily want to open those pieces up, but those are… To me, those are oftentimes jurisdiction-specific, fact-specific, and sometimes the law is still moving in those areas. But coming back to the points that you wanted to make, looking at these extrinsic factors as to the expectations that have been set, those do seem like relevant points, but to stay from sort of categorical statements in this area is perhaps helpful to all the informed parties. Thanks.

MAX SILLS: Yeah, thanks, Dave. I think you bring up a lot of good points. The first, when you say “avoiding categorical statements,” I’m kind of opening up a Pandora’s box here because open source has worked for a lot of years, it’s created tons of value for all of us, and it’s worked even though we haven’t thought too deeply about it. Or, I mean, we’ve thought deeply about, but courts have not thought that deeply about it.

A problem I’m worried about is if we start creating or exfiltrating the ambiguities in licenses, exfiltrating exhaustion, implied licensing, that could be for lawyers to do. But are we destroying the value of something that has kind of worked in a self-sufficient manner without us for a long, long time? And, I mean, you see this specifically with the Linux kernels maintainers, right? Famously hate lawyers, very disrespectful, but very smart people, and what they continue to do time over time is any time someone tries to introduce an ambiguity, for example, into how the GPL might be interpreted, they kind of just wipe the slate clean and say, “No, we’re going to make it very clear that this is how we want out community to operate.”

I guess what I’m hoping for, just to your first point there, is can we start discussing open source licensing on a common basis of fact and research, while at the same time preserving the core thing, which is that communities just want to share software? And we don’t want to be doing anything to get in their way, right? To your other point, in terms of “You don’t want to make categorical statements,” yeah, it’s tough. It’s tough because the client just needs to do something, and you just want to be able to give them clear advice, and the thing that they want to do is share code with each other, right?

And so, to be a good advisor, dean of the day, you’re probably going to have to come to some kind of answer that will facilitate that. I guess I’d say, “Can we have two brains about it?” In one side of our brain, can we problematize it? Can we do the research? Can we argue with each other based on the law? And then, in the other, and then, completely in a contradictory manner, can we still talk clearly to our clients and say, “Go have fun; go collaborate, because this is driving so much value.” I don’t know. That’s my hope. I think I got a little more time. Are there any more?

MISHI CHOUDHARY: It’s winding up.

MAX SILLS: Okay.

MISHI CHOUDHARY: We’ll take one more question.

MAX SILLS: Please.

AUDIENCE MEMBER: I wanted to ask you a little more about your copyright ownership piece of what you’re talking about. And specifically, you’ve been focusing really on United States law, but we know that if a work is created abroad, you know, in the United States, even, we will look to foreign laws. Does that make this even more complicated from your point of view? And then the second part of that is Aalmuhammed, which is the case you relied on, and the more recent cases in that line all involve places where we don’t have a contract. The whole point of that case was, “We don’t know what to do. We’ve got to figure out how to get the rights to the studio, because otherwise everything falls apart; Casa Sixteen’s the same; Garcia’s the same.”

MAX SILLS: Yes.

AUDIENCE MEMBER: So, is the solution here the licenses just need to be explicit, and then we don’t have to worry so much about what the background law is doing, so that makes more of a let’s-get-out-of-our-own-way situation?

MAX SILLS: Wow, great points. What’s your name?

AUDIENCE MEMBER: Joshua Simmons.

MAX SILLS: Thanks, Joshua. Alright, let me take that last point first. First, don’t write new open source licenses; please stop. That is going to… I mean had some slides on, like, numerus clausus and the beauty of open source being that there’s actually a limited menu of options that most people converge on. But I’ll leave that to later panelists, because I know we’re going to be talking about the commons clause and other things a little bit later. I would say don’t touch licenses.

Instead, you’re absolutely right: if we had explicit contracts stating what we wanted the copyright ownership to be up front, that would solve it. What I’m saying is go back and read your CLA’s, because your contributor license agreements are probably insufficient. You probably have an articulated policy objective that is not getting met. And then, also, let’s re-examine developers’ certificates’ origin under this framework. I know developers. Developers tend to prefer things that are fast, easy, don’t have a lot of legalese, so there’s a lot of pushback.

But, if you actually look at the case law, I think, yeah, the thing that solves this. The copyright problem is an express understanding between the parties. Let’s go back and look at our contributor license agreements. As to the foreign law issue, it’s so incredibly complex. I mean there’s moral rights, in Europe, database rights, privacy rights that are strange and different from our own. But you’re absolutely right. I’m giving this presentation just as a start under U.S. law. It would be so great if we could agree on what the cases are in the U.S. Let’s start there. That’s what I’d say, but definitely want to focus on global cases.

MISHI CHOUDHARY: Eben always taught me that licenses are the constitutions for the projects. You talk to also the clients and the lawyers for the projects. For me, it’s always just go to the next room and ask Eben all these questions. But those services are available. What I learn, mostly, is to talk into the projects and what they intended when they chose a license always helps to put the context around the law stuff. But, thank you much.

MAX SILLS: Sure.

MISHI CHOUDHARY: This has been very good and very interesting, and I’m sure that there would be follow-up questions, and we’ll have a coffee break. We’ll discuss that, and thank you, Max, for making this.

MAX SILLS: Thanks very much.