Transcript: SESSION II: Peace and Its Dividends - “License Restrictions and Commons Clause”

November 2, 2018
Jerome Greene Hall, Columbia Law School

Session Description:

Additional restrictions modifying existing FOSS licenses are becoming noticeably popular. Is this license proliferation under a new guise? Does it help or hurt business models around FOSS?

Presented by The Software Freedom Law Center and Columbia University Law School with Jim Wright of Oracle, Heather Meeker of O’Melveny & Myers LLP, Karen Copenhaver of the Linux Foundation, Richard Fontana of the Red Hat, and Sarah Ward of MongoDB and moderated by Eben Moglen, Professor of Law at Columbia Law School and Founder of the Software Freedom Law Center, and Mishi Choudhary, Legal Director of the Software Freedom Law Center.

See event page for further information.

Transcript

MISHI CHOUDHARY: Additional restrictions modifying existing free and open source software licenses are becoming noticeably popular. We recently saw change of the license for the Redis modules. We also saw the change from MongoDB in issuing of the Server Side Public License. We wanted to bring all these amazing people here who are very knowledgeable about the issue because (a) they have been involved in this and (b) they have been practicing for a very long time around the open source community. Is this license proliferation under a new guise? Does it help business models or developers? And was the problem that there is too much freedom, and that’s what we’re trying to solve? So here are my great panelists. And I forgot their profiles. Again, I urge you to read their profiles. They are too long. They’re all very, very accomplished.

I will start from my very right: Karen Copenhaver. Karen serves as outside counsel to the Linux Foundation. She was named the 2018, 2016, 2014, 2012 Boston lawyer of the year.

And then there is Richard Fontana. He’s senior commercial counsel at Red Hat, an ex-colleague from the Software Freedom Law Center.

And we have Heather Meeker. Heather is a partner at O’Melveny & Myers and leads the technology transaction practice. She’s also a portfolio partner at OSS Capital, a venture fund specializing in open source software companies.

And, if you don’t know who’s on my left, Eben Moglen, obviously, and we also have Sarah Ward. Sarah is the general counsel at MongoDB. She’s currently Director Legal at MongoDB, where she oversees the corporate and product legal teams. From 2014 to 2017, Sarah was senior corporate counselor at Criteo, an advertising technology company specializing in securities and M&A. And last but not least, Jim Wright, who is Oracle’s chief architect for open source policy, strategy, compliance, and alliances. And you can read further about these people and their involvement and their work.

How we are going to run this panel is Eben is going to set some context about what is it that we are discussing in addition to the last stuff, and then each of the panelists, starting from Heather, will have an opening statement. And thereafter, we will have you ask some easy questions.

EBEN MOGLEN: So, there’s not much that needs to be said, I think, in advance of what the panelists will say for themselves. The licenses that we have been using for decades now either implicitly rely upon or explicitly declare certain sets of freedoms which are crucial to people downstream from the licensors using the licenses. In the case of GPL and its family of copyleft licenses, we identified four freedoms: the freedom to run the program for any purpose, the freedom to modify the program for private or for public use, the opportunity to make and share copies of code modified or unmodified with any party of one’s own choosing. These freedoms, which are users’ freedoms, freedoms of those who come into possession of copies of the code, have been regarded by the parties who made and worked on free software or open source projects as crucial to their own relationship to the code they make. We have in effect created not merely a consensus about how to make software, we have created a consensus about how workers relate to users.

But we are now experiencing pressure in the investment communities and around the businesses that produce software to modify those terms in ways which will more appropriately, in the view of the licensor companies, balance the market in which they are participating. This is undoubtedly going to continue to occur. Whether it is a threat to consensus or an evolution of consensus depends, I think, largely on the mind of the observer. But we need to have a conversation about it, beginning from where we stand now. Are our basic four freedoms no longer suitable for a market which has changed too far? Or are people unnecessarily worried about their own commercial possibilities in the face of the long-term operations of the licenses? I think we have here a good diversity of view about that, and I’m looking forward to hearing about it.

HEATHER MEEKER: Thanks very much. Thanks for inviting me here today. It is a great pleasure to participate. So, in case any of you are not aware, I was involved in the drafting of Commons Clause, which came out recently. I’ve also been involved in the drafting of a few other, what I would call, alternative licenses. And that’s probably the viewpoint I’m being asked to represent, so I’ll do that.

I have to say that I’ll try to be precise about what is my view. I’m certainly not talking on behalf of any of my clients here today. So, I’ll just talk about a couple of things very quickly. One, the pressure that you’re seeing, which Eben had mentioned previously today about the open source model being sort of challenged, has to do I think in large part with what has happened in the software industry. We have an open source model that’s worked really well for a long time, it’s still working really well, it’s still robust, it’s not going anywhere, etc. But in particular, as we’ve moved to Cloud-based implementation model. The triggers for conditions under the open source licenses, they aren’t getting triggered anymore. So we’re seeing a lot of pressure on the copyleft model, because people who are using software, but not distributing it, generally don’t have any obligation or requirement to do anything to share with the community. Companies that are developing software particularly in a kind of sector where it’s very useful in the Cloud, they are feeling a lot of economic pressure to step outside this model. That’s one thing I’ll say about how we got to some of these suggestions for solutions.

The other thing I’ll say is this: I’m a lawyer in private practice. I have been doing this for almost 25 years. I’m a software licensing lawyer. Okay, so I don’t want to, you know, tell you Santa Claus doesn’t exist or anything, but the fact is that what I’ve been doing for most of my career and what most software licensing lawyers do is write proprietary licenses. So we have this whole field of proprietary licenses. They’re all ad hoc. Many of them are very difficult to understand. They are a huge due diligence issue. Okay, I will say one thing. This is my view: you hear a lot of lawyers complaining about doing diligence on open source. That’s easy. Okay, doing diligence on proprietary licenses is hard, because everyone is different, and you have to look, you have to noodle about what it means, and you can’t find any community discussion of it whatsoever. When companies decide the open source model doesn’t work, for me, say for my primary product, because I think I’m going to get my lunch eaten and I won’t have enough money to go on with my company. And, you can disagree with that assumption, but that’s the crossroads where they get to. They have a choice, and they’re either going to go down the proprietary route, or they’re are going to do something that I would call an alternative open-ish model. It’s not open source, because it doesn’t meet the user freedoms, etc. And usually that comes in the form of some kind of license restriction.

Speaking for myself, I would say that open source is great. It’s here to stay. It’s not going away, but for developers who feel they need something different, what we really need is better proprietary licenses. We need them standardized. We need them understandable, and what we can get as an extra sort of peace benefit, if we think we can make this a big tent, is that we can get people to release code under licenses that make the source code available. Because if you go down the full-on proprietary route, then the source code won’t be available. I would like to preserve some of the freedoms. If we can’t preserve all of them, I’m a practical sort, I guess, and so I am personally very interested in working on a project to standardize proprietary licensing, and I only call it proprietary because it doesn’t meet the four freedoms. It actually will have a lot in common with open source licenses. So what I would say is, I hope we can make this a big tent and not a small tent. I think that, you know, vilifying people who try alternative models is the same “us versus them” paradigm–that caused a lot of pain for a lot of years. And I would encourage people to be open minded about different kinds of licensing models.

JIM WRIGHT: Well, I guess, you know, to begin with, obviously Oracle is accustomed to publishing a substantial portion of our portfolio under a dual-license model. And you know, I have watched these developments–I don’t want to say bemused indifference–but it’s been interesting for me to observe the attacks on these license models. I guess I sort of sit in the same seat, you know, coming previously from private practice as Heather, in that, you know, I view these licenses as–I think the consensus is that they do not conform to what the majority of us think of as open source, which carries with it certain implications, you know, regarding content, representations that you might make regarding the content of what you’re delivering. But, that said, I guess to the extent that the social environment of open source development has at times been hostile to anything which is less than completely open source.

HEATHER MEEKER: At times.

JIM WRIGHT: [Laughing] Exactly. This comes as no surprise, right? And I actually think that it may be somewhat of a moment of reckoning for the fact that companies need, you know, companies that release open source software need to make money, and sometimes they can’t, they need to come up with models that make money, which may not always revolve around–which may require them to alter their licensing on an outbound basis.

That said, I guess I’ll retort. Not all of us have found that the copyleft model doesn’t work, right? And for many of us, you know, when I see these, I have seen these changes as a user. And part of my, I guess I’ll say, consternation as an observer has been around the promulgation of these licenses prior to any sort of community discussion or consensus, such that things like the implications of a license for a use across multiple affiliates in a large and complex organization. Are you providing a service? Even at an internal use, where you have networks of intercompany agreements? If you stand up a simple compute service, and then you’re making available container images or VMs that contain a piece of software, are you now subject to a two reciprocal license obligations. For pieces of a service, which was never sort of directly connected with the code in question.

I’m definitely not in the camp with Max that license proliferation should prevent us from advancing the license ecosystem. Obviously, I drafted a license a few years ago, and I don’t think that we necessarily need to stand still in this regard, but I do think that careful consideration by the lot of assembled lawyers, many of whom are in this room, would probably benefit people who are trying to make these innovations.

EBEN MOGLEN: Sarah?

SARAH WARD: I am coming from MongoDB, so for those of you who don’t know Mongo, we are a database platform and our core product is open source, and we recently made the decision to switch our license from a GPL to a new license that we introduced called the Server Side Public License. And our rationale for doing this, our reason for doing this, was really along the lines of what Heather is talking about, which is that as our software has become more popular, and in particular our database as a service offering, has become more popular, we have seen a lot of companies, particularly international Cloud providers, who are willing to test the boundaries of that license and offer MongoDB as a service without contributing any code back.

As a company that owns our IP, we kind of felt like we had three choices. One was to go closed source, one was to move to a source-available license, and the third was to try and find an open source alternative that would address the issue that we see and that other companies in our position see but still allow the broader community to benefit from the investment and the innovation that we’re making in our open source database platform. So we chose option 3, somewhat controversially, and introduced a license called the Server Side Public License, which is based on GPL but has an additional provision, which essentially says if you offer the licensed program as a service, you have to open source the components of that service.

At the same time that we introduced the license, we submitted it to the OSI approval process, which is ongoing. I know that there is some criticism of that choice in terms of the timing, but for us as a public company with commercial interests, that was sort of the thing that was the right thing for us. And I think the last thing I would say is we understood that introducing a new open source license would be controversial, but we felt like it was a necessary step for us, and it was really the only way that we could stay in the open source community in a way that made sense for our business. But we do view this first version that we put out as a starting point for this conversation for us as a company and are open to iterating on that model based on kind of the feedback that we’re getting through the process.

RICHARD FONTANA: Hi, so I also mention, in addition to being a lawyer at RedHat, I’m currently on the board of the Open Source Initiative. And my term is sort of up in a few months, and it’s sort of a thankless job in some ways [Audience laughing]. One of things I do there is I kind of sort of de facto manage the license-approval process to the extent that I can. So, David Levine mentioned OSI and FSF in one of his slides and the role that they play in kind of being the institutional guarantors of meaning for what we understand to be open source and free software. For the OSI, this is very important. We’re very concerned about the dilution of the meaning of open source. In a different sense, this is very important for a company like RedHat for which open source is so important to its identity and its business. So now, I am, I think, unlike some of my colleagues on the OSI, I’ve actually never been so concerned about license proliferation. I think that we should not be afraid of experimentation.

I was, you know, in a certain sense glad to see Jim’s license get kind of debated and approved. And I think it’s actually added something to the suite of licenses available to developers. Yeah, I mean it kind of took some conversations with Scott Peterson many years later for me to see what was sort of uniquely beneficial about UPL as a license. But that license was kind of iterated on through many months of drafting, and it’s a very short license. It’s a very simple license, unlike current MongoDB license.

Experimentation is good, but it depends on the way in which it’s done. I’m concerned about some of the way that some of this has been rolled out. The Commons Clause, there’s a certain amount of what I think of as deception and kind of misleading communication surrounding the Commons Clause. The very name Commons Clause seems to be suggestive of Creative Commons. Admittedly Creative Commons has an anti-commercial variety of licensing, but in the software realm, in the free software realm, commercialization, commercial freedom, has always been a core value. Anti-commercial licenses are not new. The first version of the Linux kernel was under such a license. They were such licenses that existed back in the 80s. They didn’t really succeed in the software realm.

But these, the Commons Clause is taking a kind of standard model of licensing that is supposed to guarantee commercial freedom and then tacking on an anti-commercial restriction in a way that I am concerned may mislead developers and individual users who may not have the sophistication to understand that that fundamental value is being kind of stripped out and in a sense it’s converted from being a Commons license to an enclosure of a Commons.

The concern I have about sort of deceptiveness and the kind of misleading quality of around this. Redis Labs has a page, a website, on promoting some of the modules for Redis. I don’t know if they fixed this, but for quite some time after the Commons Clause was introduced, they were describing modules that were using the Commons Clause as being under OSI-approved licenses. This is a good example of the kind of problem that I’m seeing. Now, I kind of agree with Jim that to the extent that I think that Jim was making this point, that experimentation should be done in like a very multilateral way by a lot of stakeholders. I’m troubled by what MongoDB has done in, not in proposing this license and in kind of testing the boundaries of what we should consider a copyleft license in this sort of Cloud era, but rather taking a project that so many companies and users depend on and changing the master branch to this new license before it’s been approved and vetted by the community. I don’t think that was necessary. I don’t understand why that was the only choice from a business standpoint, but this has been very disruptive to users of MongoDB.

I’m hopeful that we get to explore this issue of what is the appropriate boundary for copyleft within the open source definition, and to understand also what the free software movement considers to be the appropriate boundary for copyleft from a free software definition standpoint. But this should be done in a very public way, with input from developers and companies, commercial, and individual users before commercially significant software is placed under these new licensing models.

HEATHER MEEKER: Can I just say then I disagree that what Redis did is misleading. If you want to look at Redis’s site and see whether you think it’s misleading, please go ahead and look at the site. You know, the fact that two things have the same initials doesn’t necessarily mean that they’re misleading [Laughing] or even similar initials. So, I mean, I think if you look at the messaging, one of the first things it says is this is not open source. Maybe there were–I never saw what you saw, to be fair.

RICHARD FONTANA: It’s an oversight, so I don’t know, it may have been corrected.

JIM WRIGHT: Let me just add one thing. Karen needs her turn here. But just speaking as a consumer of these products, as well as a producer of a lot of the stuff, having to disentangle stuff that comports with the four freedoms from stuff that effectively no longer comports, such that if I have a development team that is consuming Redis I now have to tell those folks, hey, you need to make very sure that you don’t touch any of this stuff. And for every release now and forever more, I literally had to say this to people. Like for every release now and forevermore, I need you to look at every single module and make sure that they did not add this clause to any of it. And for all we know, they may add it–they have taken this closed source in part. We don’t know whether it will be taking closed source in whole. To the extent that we have made representations to any of our customers about the content of any of this stuff, or otherwise are making commercial use of any of it, it has now become somewhat radioactive.

And my concern there is that this was changed from open source to proprietary. And I think those things, you know, do need need to be cleanly severed, irrespective of whether there was any sort of misrepresentation on the site or whatever, which I’m not saying that I ever read anything like that because I didn’t. But alterations of license in a way that takes something from a piece of code that comports with the open source definition and the four freedoms to something which no longer does that–that affects users dramatically. And you know, as a consumer, the steps that I’ve had to take, that I’ve had to tell my development teams to take around the consumptionist code are fairly drastic.

KAREN COPENHAVER: Let me pick up on it. Ok, I think I’m on, because I want to go back and talk about community. I want to talk about license proliferation. I want to talk about a bunch of other things. Number one, we would not be here without the work of some unbelievable developers, starting with Richard Stallman who wrote the toolset, and going through the current developers who built an infrastructure on which everything we’re talking about in terms of business models is entirely dependent. And that infrastructure was built by developers who had certain assumptions, and the value that they brought is why we’re all here. And why Nicolas is here.

It’s astounding to think about what has been achieved in a couple of decades. There were a few threats along the way that that were problematic to the commercial embrace of all of this. And I know that I can look around this room and see so many people who spent so much time talking to each lawyer at each corporation that was brought into this conversation to get them to the point where they thought it was a commercially reasonable act to use these things. That was a huge process. We also, we did go through this period of license proliferation where we lost to the value of these community assets. And I love Scott Peterson’s discussion about shared resources, and the license proliferation issue was one where we were diminishing the value of resources because we’d gotten to the point, where I could not agree with Heather more, that proprietary licenses are far more complex than these. But the open source community is based on a confidence in the use of some shared resources in a frictionless matter to come together and to develop infrastructure that is absolutely essential to everybody else, including all these people who want to build business models on top of it.

And we as a community have a responsibility to preserve one, the expectations of those developers, and two, this unbelievable engine of creativity in infrastructure that has been built. And my concern about all of these is really going back to a time where people are afraid to use this stuff because it’s chaotic. And number two, where the new communities that come or the new companies and participants that come into this community think that creating something new, that doing something in a unique way, that losing the things that were the secret sauce on which all of this happened, that those are not essential to the magic that has happened. That’s what I’m concerned about: is losing that in the conversation.

And we have never been able to force corporations to do anything with their intellectual property, and we never will. There was a compelling and commanding necessity to use these assets that these developers built because they were so excellent. We do not want to lose the magic of that business model. I would also suggest to you that we have been through dual licensing models and other things for many years. I cannot identify very many of these absolutely fundamental assets that have driven the success that we’ve had. They came out of those models. Not that they’re not good models for some business, not that they don’t create employment, which is very important to me, not that they don’t do good things, but if that’s all we had we would not be celebrating peace today.

JIM WRIGHT: So I just want to flag one thing. Some of us still like dual licensing. But I guess the measures that I was talking about earlier. With respect to the technical measures that I’ve have witnessed here is merely that the idea that well-established open source projects may go closed source, may effectively go closed source at any moment, then requires us to undertake the potential obligation to maintain those things entirely on our own to be able to create security patches without support from the original development teams. The fear that is associated with that risk is very high, and the actual business risk is very high. I mean before I can pick up something, I need to know, or I need to at least know systemically as a whole, that these projects are not very likely to just shut down tomorrow to my teams.

MISHI CHOUDHARY: I’m just going to ask a few questions and then let you speak. And Heather and Sarah, the first question I will take this. It seems like it’s camouflaged proprietary licensing. We don’t have freedom zero in that sense. So why do the communities who have already built and who come to open source, because there are certain values, continue to work in these business models, because we’re kind of destroying the basic principles on which the communities rely on. And that’s why they’re interested in open source, that’s why they build it. And if this is the way we are going to make licenses, then why does the labor continue to work with the community here?

HEATHER MEEKER: Well, so, if you’re talking about Commons Clause, that is not camouflage proprietary licensing, it’s proprietary licensing, if the definition of proprietary is not open source. Actually I think that we have a real definitional problem in the community is that we don’t have a good word for something that’s in the middle. And unless it’s morally repugnant to you to do so, I would suggest that it would be great if we could come up with some more useful terms. I mean we can’t call it open source. Maybe we can’t even call it open. Maybe we can’t call it common. I don’t know. But there is something that’s different from an end user license for Microsoft Word. And it is here’s the source code, do whatever you want with it, but some kind of commercial based restriction. I actually think that’s different from what most of us think of as proprietary.

Commons Clause is not camouflage, it is proprietary. As to this sort of ultra strong copyleft question, which is really quite different, that has all the freedoms. There’s just an argument over the scope of copyleft. I think that’s actually a different discussion ,and I don’t know that it’s really accurate to call it camouflage proprietary. That’s really, I think, an argument about how broad should copyleft be in order to create a level playing field? But I’ll let Sarah speak to that.

SARAH WARD: Yeah, I mean, I would agree. I think, as I said, as a company, we thought we had three options. And I think that there’s a lot of skepticism, which is healthy around what we’re doing since we are a commercial enterprise. But from our perspective, we genuinely we do want to maintain that relationship with developers, and that is why we chose the path that we chose. I think, you know, it’s obviously going further than what has been done before in the open source community, but we wouldn’t have submitted it to OSI. We wouldn’t be going this way if we didn’t truly think that we are still trying to adhere to those principles and find a way to work with developers in the way that we have been in the past.

MISHI CHOUDHARY: So it seems like business judgments are driving certain decisions. Are we seeing a trend where perhaps copyright licenses will be written to address a very narrow range of competitors, like in this particular case?

SARAH WARD: I mean, I don’t know. I think in our case part of our motivation in doing this was obviously our particular business concern. Part of the criticism that we’ve gotten and part of the issue with the license is that we have actually tried to draft it so that it is more broadly applicable. And that’s much harder. I mean I’m not an open source expert, but I think that there are already open source licenses that apply differently to different use cases, and I’m not sure that that’s necessarily a problem.

HEATHER MEEKER: You asked about drafting things to go to particular competitors. I think what we’re going to see a lot more of is non-commercial type restrictions or something sort of similar. And just for those of you who have never sort of been through the process of say negotiating a merger agreement in the middle of the night, drafting things, definitions of things, like non-commercial is extremely challenging. The lawyers in the room who have advised clients on say Creative Commons have struggled with this as well. If you look at the guidance that Creative Commons gives on the non-commercial restriction, there’s pretty little. I’m not faulting them for that. It’s very difficult, but I think it would be worthwhile to come up with a community consensus on what that means. It might be very helpful to people. But from a pure drafting point of view, it’s actually a very challenging thing to come up with in a general case without saying specifically, you know, these people can’t use it, which is fundamentally, you know, it’s not robust enough. Anybody who’s ever done this in private practice knows that that breaks down any year because you can’t identify the people anymore and they all merge and change, etc. But I do think that some more consensus around what constitutes non-commercial might be helpful.

MISHI CHOUDHARY: Richard, you wanted to jump in earlier. Was it about when Heather said there has to be some definition or some other term?

RICHARD FONTANA: No, I wanted to make a point. One of the things I want to say is actually kind of related to what Jim was saying about the practical problems I think he’s seeing and the way he provides advice to his engineers. So this is more of, this is a RedHat perspective. RedHat can’t practically distribute software that’s only under OSI-approved licenses, because there are for for the stacks we ship, there’s lots of stuff, there’s hundreds of licenses that have never been approved by the OSI, have never been recognized as free software licenses by FSF, and there never will be.

It’s just there’s so much legacy stuff, but they all kind of conform to a certain pattern, a certain range of restrictiveness and permissiveness, and this makes me think of something that Max mentioned, the numerous clauses. Yes. This concept that if you apply to open source, this idea that what we think of as open source, legitimately open source, is a certain limited set of combinations of possible conditions and freedoms. For RedHat, that’s actually in an informal way, very important to our relationship with our customers. Our customers can’t, you know, practically be expected to read every line of every license of every piece of software, every single file or snippet of source code, that we ship in our stacks, but they need to understand and have comfort that we are committed to a kind of definition of open source and free software that is such that we, with maybe some rare exceptions, we will be only be shipping software that is under licenses that kind of conform to that sort of scope.

And when you start to see–I mean certainly when something like Commons Clause licenses become possible, as part of a kind of larger project community ecosystem, or in the case of the MongoDB license, the new MongoDB license, that license as it currently exists contains such a severe restriction that goes so far beyond a license like AGPL. Even though it only affects a kind of narrow scenario, this is a very practically difficult problem for our customers who are trying to understand the range of potential license terms that will be part of our stack. We can’t, we can no longer really say something to the effect that AGPL no longer represents the outer bound of what’s legitimately a copy left open source license, and so there’s a real practical problem for those of us who are in the kind of open source, big open source product distribution business, because suddenly customers are going to think that they really do need to understand every line of every license, which sounds like something that maybe they should do, but it’s actually commercially impractical in many respects.

EBEN MOGLEN: I think the important point here is that people are experiencing significant commercial disruptions from a massive alteration in the way world IT works that we made possible. We want to listen to the problems of the businesses. We always did want to listen to the problems of businesses. As has been pointed out, GPL 3 was made mostly by listening to all the businesses in the world that cared to talk to us on the basis that we would break no business model if it could be avoided at any cost. It’s true that Max Ochoa of TiVo didn’t think we really meant it, but we really meant it that we would break no business model that we could avoid breaking in order to achieve safety for users.

I think we are experiencing now a situation in which people who are suffering significant commercial disruptions wish to respond to those disruptions in whatever way is good for their business. That’s perfectly understandable. It should not come out of users’ rights. That is not the place where the relationship between software infrastructure makers and Amazon Web Services should be adjusted. Users’ rights should be regarded as the key reason that all of this works in the first place. And we should be extremely reluctant to subsidize commercial difficulties on the backs of users. This is where creativity is really required.

I do not think that the consensus in favor of FOSS is going to break down and we’re going to find ourselves in a world of non-commercial proprietary licenses. That’s not what’s going to happen. It’s not going to happen first of all because the social contract with workers is really important, and it is not clear that workers will agree to produce un-free software at the same prices that they produce free software. They receive an enormous wage from freedom which has transformed the work force around the world. And I think that’s still going to matter. And these are relicensing activities. These are not people building a better mousetrap and licensing it proprietary. These are people who are signing up to compete with themselves. That has a long natural history, and it usually works out badly.

The question is why do the forkers not fork given all the downstream uneasiness that people are experiencing. The minute there’s a fork underneath the licenses, all those downstream people can go away happy again. So, the market works, ladies and gentlemen, the market works. Those of us who made this stuff happen, we wanted the market to work. We’ve labored long and hard to make the market work. We want to labor long and hard to help the businesses that are struggling now with conditions that we helped to create. We think that’s part of our responsibility. But as a movement, I do not understand why we would engage in cheating on users’ rights in order to help businesses solve business problems. We never had to do that before. Why should we have to do that now?

MISHI CHOUDHARY: What does license stewardship mean in this context, now that we’ve established it, that there are different forces pulling everything in different directions? In such a case, what does license stewardship mean?

KAREN COPENHAVER: Looking at me, and I’m not a license steward [Laughing].

MISHI CHOUDHARY: LF does have a lot of projects, and there are principles.

MISHI COPENHAVER: There are principles, and Richard would be much better to talk about the OSI approval process as a means of establishing the validity of a particular license. I would say, again, focusing on these shared community assets and acknowledging the fact that we cannot limit or prohibit the use of other structures. But focusing on the preservation of these shared community assets, the work that’s been done that David was talking about in terms of taking those assets and maintaining their stability through an evolution process that is broadly disseminated for consensus purposes over a long period of time, without a declaration from one particular party or one particular area that says no we’re going to go and destabilize this, that process cannot be hurried and cannot be undervalued. But these shared assets need to be preserved.

And the OSI process is one piece of preserving the open source definition. I have to say in a lot of these conversations I think that there’s a confusion between the OSI definition for what a license is, and this broader discussion of what the expectations of developers are around what an open source development process is, and I think we should honor the developers’ expectations because we’re taking terminology that is very valuable to them and that they have their life’s work invested in, and potentially, you know, destroying the value of it. Because we just want to use the same terminology, because we want a little bit of the glitter to cover other things.

For the license stewards, I mean there’s issues about who wrote the original license a long time ago, and you know, are they the ones that maintain control? In certain situations, that’s obviously true. I mean Richard was very formal about his position with respect to the GPL. In other licenses that we’ve all used, there isn’t an obvious steward, and that’s raised some questions about the whole issue about what the MIT license means and what else. What those licenses mean is what each of us using those licenses, on code that we owned, intended it to mean. But will we know exactly what it means? Short of the litigation process where we have a court in a particular context, you know, with two parties who have very differing interests and are not at all concerned with how they’re impacting the overall community. They will determine what the license means in that particular instance.

I don’t think we run our communities based on that. I think we run our communities based on the developers’ expectations of what the environment is that they want to work in because every corporation that’s represented in this room is here in part because the developers themselves demanded this environment. The very best developers demanded this environment in order for them to work on projects within these companies.

MISHI CHOUDHARY: I have many more questions, but I’m being told in sign that we’re already late. I’m going to ask each of you just to summarize, starting with you Richard, and very short.

RICHARD FONTANA: Yeah, so, again, experimentation in how to draft free software and open source licenses is very valuable. I’ve tried my hand at trying to create a simpler copyleft license. I hope that kind of experiment continues. I think we also need to look at what copyleft should look like in an era of Cloud providers. However, again, this is something that has to be done publicly and multilaterally, shouldn’t be done by single corporations relicensing a very valuable project under a new license before it’s been kind of adequately vetted by the community and these boundaries that are policed by OSI and FSF and others like Debian and the Fedora project, the other distributions. This is very important. It’s very important to make sure that even though open has a kind of pure development process meaning now, it is very much tied in my view to the legal meaning, the license sort of meaning of open. And if we start to chip away at that, we’ve always been concerned about that getting diluted. And I would worry that the commercial advantages of open source development would start to be endangered if that happens.

HEATHER MEEKER: Well, first, Karen, thanks for mentioning that some of us have been spending decades talking people off the ledge on open source because it’s been most of my career. So those of you who don’t know me already maybe want to keep that in mind. I’m not here to say that, you know, we need to change open source, because I think it works great. But if you share an interests in, say, fixing proprietary licenses, or alternatively, you have some notions of what we might call something different, please, I would love to hear your input on it, because it’s something that I’ve been thinking about a lot lately and would love to get some community input on.

SARAH WARD: Yeah, I mean, I guess just in closing I would say on this issue, you know, I speak for one company, so that’s the position that we’re coming out with this, but I think that there is a threat here with the Cloud-era for businesses who are trying to operate as open source businesses in that environment. And while you know there’s issues with companies unilaterally making these decisions, I think there are a ton of businesses that are interested in this and are willing to be part of that conversation but have real business needs that need to be addressed in the interim while that public process is occurring.

JIM WRIGHT: I guess I’ll revert back to, I think that there are, you know, the existing models still work pretty darn well I think. For many of us the copyleft is functioning just fine, and we’re getting code contributions back. That said, there are challenges in the Cloud-era. Everybody’s are different. I think the reaction of the community should be to have–it has to be one at a time, to look at these. I think the experimentation is good, and with respect to what Mongo is doing, I think the willingness of developers to experiment isn’t something that should generate vitriol. But rather that we can continue to work on this as a community just like we work on the code as a community.

EBEN MOGLEN: Well you see how it is, even the fights sound different in an era of peace. I’m not going to risk delaying people’s lunch any further. Thanks to the generosity of the Open Invention Network, there is lunch for everybody, and I hope plenty of conversation about these and other subjects before we resume at 2:30. Thank you very much for being with us all of this time.