Transcript: SESSION II: Peace and Its Dividends - “Current Legal Issues in FOSS”
November 2, 2018
Jerome Greene Hall, Columbia Law School
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 David Levine of Red Hat, Dave Marr of Qualcomm, Mike Dolan of the Linux Foundation, Keith Bergelt of the Open Invention Network, and Nicolas Schifano of Microsoft 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.
MISHI CHOUDHARY: Well, if sartorial choices would determine what our next topic is, then David is rightly dressed: red hat and a little blue inside. David Levine–it’s my very pleasure to introduce him. He serves as Red Hat’s Vice President and Assistant General Counsel with responsibility for the products, technology, and open source legal group. This is a very long bio…
DAVID LEVINE: You don’t have to read the whole thing.
MISHI CHOUDHARY: …and that’s going to be true for almost everybody who’s going to speak because you are very accomplished, and that’s why you are here! But David is responsible for managing the full range of legal responsibilities associated with Red Hat’s product and service offerings and business models, licensing of open source software, the creation and maintenance of Red Hat’s standard contract terms, and administering Red Hat’s anti-corruption compliance program. The rest of it you can read here, and he’s going to talk about the GPL cooperation and commitment because that’s one part of how we have reached this new consensus, which has been made possible by several developments, by a variety of efforts by different parties. So, here is David Levine.
DAVID LEVINE: Thanks, Mishi. As Mishi said, I wore my, , my blue underneath and my red on top. As you probably read, earlier this week Red Hat and IBM signed an acquisition agreement, but the idea is that Red Hat will continue. While it will be blue underneath, it will be red on the outside because we’re going to continue to be operated independently. So, very interesting news for the open source world. We’re still digesting it, but, so, more to come, but I think definitely very impactful.
Eben and Mishi asked me to talk about our work with the GPL cooperation commitment. What I wanted to do is maybe put this into broader context and to talk about what this means and what it really is because I think there’s a broader message here. And so, what I want to do is combine three presentations. So, one is the presentation that Richard and I gave last year about FOSS licenses as shared resources; the second, I want to pick up on a presentation that McCoy Smith from Intel gave the Linux Foundation member council event last month; and third, draw upon a number of presentations I’ve given around the GPL cooperation commitment and to talk about where this fits in the bigger picture.
FOSS licenses as shared resources. So, if you weren’t here last year, or you weren’t in Edinboro last week to hear Richard give another version of this, excuse me, the basic point here is that there’s this small number of license texts that we all share, we all rely upon. They govern large and growing bodies of software, and we all depend on these texts, but they’re subject to varying interpretations that require resolution. So, how do we collectively govern these shared resources, right? If this a resource that we all use, like natural resources, how do we govern these resources? What if a license requires additional interpretation? How do resolve an ambiguity? How do we address changes in technology that may affect the means of packaging and delivering software that affects how a license operates? Who should have the ability to make decisions and answer these questions? Should it be a troll, or a copyright troll, in the midst of litigation seeking monetary gain, or a company seeking commercial gain through strict license enforcement activities? Should it be a judge seeking to resolve a dispute between two parties? Or maybe we leave it to the license author to make decisions.
We know that there are existing methods for adding new licenses, and there’s criteria; there’s definitions that the Open Source Initiative has and that the Free Software Foundation has for defining open source and free software, so, if there’s a new license, there’s a governance process for reviewing and considering whether this license is appropriate for adoption. But what are the options for interpreting or amending existing licenses? This is what McCoy Smith had referred to as the “coming constitutional crisis.” One option is to simply amend the text. But this has occurred rather infrequently.
Here are three examples. How could this work in practice if we wanted to adopt a process for amending texts as questions arise or as changes in technology necessitate? And then, this raises questions about how would this be managed, and who would manage it. Should the license author have the sole and unilateral right to decide what’s appropriate and how and when to amend the text? What’s the role of license users? The thousands and thousands of licensors who adopt these same texts? Do they have a voice, and how do you…? How is there voice heard? What about the role of OSI and Free Software Foundation as license approvers? Should they play a larger role in license governance? So, option two is to rely on individuals to publish enforcement statements. This is similar to what the Linux kernel developers did. So, this is, obviously, flexible; it’s easy; you don’t have to get a consensus; licensors or companies connect unilaterally. But, ultimately, is it practical for answering the questions that I raised earlier? Do you have the risk of multiple or competing interpretations? And again, if what you’re trying to do is adopt a model of license governance that can get ambiguities answered in way that supports the whole community, I’m not sure that relying on this laissez-faire approach ultimately is the one to adopt.
What about, , litigation and bringing test cases? Is that an approach that could work for interpreting what a license means if there’s a substantial ambiguity? And I would argue that it’s not, so litigation, I think, is highly flawed in this context. While it could be good for resolving disputes between two parties, it’s very fact-specific. You’re relying upon two attorneys to brief and argue the case. The attorney’s role is be a zealous advocate for the client’s interest in that particular case, and a particular client’s interests may not align with all of the other users who use and rely upon that same license. It’s unpredictable, right? You have two parties; you have a judge; you really don’t know where it’s headed. Again, is this really the model you want to rely on? And the process isn’t always transparent. I mean, look what’s happened in Germany, right? German courts don’t have the same type of transparency that we may have here in the U.S. And ultimately, court decisions are impactful.
So, I guess, in my view at least, I think this is a dangerous tool, dangerous and blunt tool for license governance and not one that I would choose. So, option four is vote with your feet, avoid the problem. But this isn’t always practical. Lots of times, license decisions are made upstream. You’re not making a decision about whether to use a particular license. You’re relying on a larger ecosystem. And so, you can’t always vote in this way. And also, again, thinking about the point I made earlier about figuring, developing this broader governance model for solving questions. This a do-nothing approach, just avoiding the problem, and I don’t really see that as a solution, which brings us to, , option five, which,you’re not going to be surprised, is the one that seems most appealing.
It’s also one that seems to align best with the values and the approach that’s taken by open source communities, which is around collaboration. So, how do we collaborate around interpretation? And I think this is the best approach. Again, it’s, “How do we bring together interested parties to identify issues of concern, where we can together create greater clarity and predictability in enforcement, establish norms, address the technology issues, agree on resolutions, and act.” And, two examples, that come to mind immediately were the GPLv3 drafting process, which was very collaborative, and then, which brings me to, the third part of the presentation, which is the GPL cooperation commitment.
So, I think that this has been an interesting test case to watch. So, a year ago, when Richard and I gave the FOSS licenses as shared resources presentation, we’d been thinking about the cooperation commitment. And I think the kernel developers had just announced their adoption of something similar. So, let me kind of give you a little bit of history about what’s happened over the last year and how this has been an interesting model to observe. So, what is the cooperation commitment? How did this consensus evolve?
GPL, as we all know, has been the focus of most, if not all, enforcement activities, but we also know that GPL compliance can present many challenges. There’s hundreds and hundreds of pages of compliance guides that have been developed. We have an entire industry that’s developed to help companies comply. I mean, it’s challenging, but the GPL, or GPLv2 and LGPLv2 are uncompromising in the sense that there’s no opportunity to cure in the event that you’re in breach before the license terminates. With no opportunity to cure, you can have a situation where,a single, inadvertent act of noncompliance results in license termination. And all of a sudden, you’re a copyright infringer. So, what the GPL cooperation commitment has done is it introduces a cure opportunity that was borrowed from GPL version 3.
GPL version 3 introduced this, this idea of a thirty-day cure period with, also, a reinstatement period. And where did that go? So, starting with GPLv3, this consensus begun to develop about how to enforce GPL version 2. Several years ago, the Software Freedom Conservancy and the Free Software Foundation backported this GPLv3 cure into their GPLv2 enforcement and incorporated this as part of their Principles of Community-Oriented Enforcement. Then, last year, October of last year, the kernel developers adopted their enforcement statement that included the same concept. So, we saw this at Red Hat; we saw this happening and thought this was a great idea.
This is a way to, again, bring greater predictability into enforcement. It was an easy step. And so, we called up our friends at IBM and Facebook and Google, and, without thinking twice about it, four of us, within a matter of a week or two, were on board in November of last year; we announced that we were adopting this. And, in March of 2018, six more companies joined, including,Suse, Cisco, Microsoft, HPE, SAP, CA. And then, over the summer, we got sixteen more companies (I think it was sixteen), fourteen more companies, to join. These are big names, right, the ones in blue: Amazon, Intel, VMWare, NEC, Toyota. Again, this is happening…some of it is David calling around and speaking to many of you in the room, but then, this is beginning to happen organically as well. Next week, we’re going to make an announcement about, I think it’s seventeen more, companies who are joining. Again, a lot of big names here: Alibaba, Tencent, Wipro. I mean, so it’s not just U.S. companies we’re getting; companies from around the world, we have many industries represented here.
What have we accomplished? If you think about, this consensus that’s formed, we have, we’ll have over forty-two companies that have adopted the commitment. There’s also an individual commitment, and we have 250 developers who have signed their names individually. That’s in addition to the 300 developers that have signed the Linux kernel enforcement statement. So, I think we’ve… If you view this as problem, we’ve wrapped up a lot of Linux kernel code behind this commitment. So, seven of the top ten corporate contributors have signed up to participate, and,many of the large individual contributors as well. So, I mean, I would argue that,we’re really well on our way to establishing a consensus around how enforcement takes place.
The more interesting question is, “Okay, now what do we do? What does this mean?” Is this a method for thinking about how to resolve, the big questions about license interpretation? “What I think is interesting is you looked at that list of companies; we have,many substantial contributors who are now saying,”The GPL interpretation and stewarding the GPL is important to me. My business depends on it. I want to be part of the solution." So, how do we… How do we leverage this?Should there be other issues,that we tackle now? What are those issues? What’s the right process for identifying what comes next? So, to wrap up: I invite you to join me in that discussion, I don’t know the answer to that question is, and come back next year to this conference for chapter four. Thank you.
EBEN MOGLEN: We might not even be done with, for the say, with chapter three yet, but what I think we want to do is collect a couple of these talks because they will add up to something larger, which begins to approach, I think, the answer to David’s question. What is happening in consensus about how to make software is that we are learning that we also have consensus about how to achieve license compliance, which is part of what David is talking about, the other side of which is OpenChain, without which I think our future would be much more bleak, so I want to ask Dave Marr to come and talk about OpenChain.
I believe everybody knows Dave; you just may not know how long we have been working together. Sun Microsystems had great open source lawyers when the time was very young, and all of them were David Marr if they weren’t Damien Eastwood. So, David and I started working together over, well, I think it was Java, but it could have just as well have been Solaris or all the other just pathbreaking stuff you did. And then, we worked together at Juniper, and now at Qualcomm, where Dave is the Legal Counsel and Vice President who makes open source a Qualcomm thing.
The first person who wrote to me seeking to discuss the IBM-Red Hat was Dave’s boss, Don Rosenberg, my old friend who wanted to chat about the big news of the week on Sunday. Dave invented OpenChain. I know; I was there. We were sitting in a vending area at Qualcomm, and he said, “Why can’t we use the supply chain to make license compliance automatic everywhere?” And he was right. Dave, why don’t you tell them how the future works?
DAVE MARR: Thank you very much, Eben, for that very kind introduction. It is a pleasure to be here again, and I would say that Eben was one of the very earliest supporters of OpenChain, seeing as it was an opportunity for the industry, if you will, to find a way to almost like self-regulate and find, figure out, a good path forward, not just to do compliance, but do compliance well, and do it in a way where it would actually benefit a larger ecosystem, not just for corporations and enterprises, but also for the ecosystem around folks that can do consulting and education, training and certification.
So, where are we now? We’re at this point, an inflection point, in the compliance narrative, if you will, where there’s really no excuse anymore for an organization to not feel like they have the right tools to be able to build out a good open source compliance program? There’s a whole bunch of tools here that, this is just a view of it, but you have FOSSology; this is a tool that can back-surface the types of attributions and the types of licenses that are buried inside of a package. You have other tools as well, things like ScanCode. You have tools around ways to store and track and manage meta-information around software packages and things like sw360portal. Those are things that happen behind corporate firewalls, if you will.
But then, facing the community, the interface between organizations, you have SPDX as the lingua franca for how compliance information can be transmitted in a consistent way between organizations. You have TODO Group, which is a way for compliance offices to trade best practices and have a good form for communication. And on top of this, if you will, is trying to weave this together, is OpenChain, and the way that we’re trying to get that done is we ask this fundamental question: “How can I trust my supply chain? What are the things that I need in order to make sure that, provided things are being provided to me, under let’s say, SPDX, in a way where I can consume them well, how do I know that I can actually not have to do that work?”
And we try to answer that with three different pieces. One is we have a Specification for what a open source process really needs to look like, which includes management, within an organization, around compliance. We have a way for, when you do meet that Specification, to conform. And we have other supporting materials. Notably, there was this notion if the people generating that compliance information were not really trained that well on open source basics, how do you actually trust that data set? And so, we have Curriculum as well. But, the Specification, once again, it has these requirements for what a quality compliance program might look like. It’s got different pieces to it, but the training piece, which can also be automation, and we’re kind of evolving the spec that way. But there should be also a policy; there should also be a process, so that the resulting output can be relied upon.
So, the spec basically confirms that these pieces are there, but we also want to preserve flexibility, so that the way that you implement is not necessarily precisely dictated by the spec. There’s many ways to get that objective done. And the notion here is that by having these foundation common requirements, we actually have the basis for trustworthiness. Just this is a quick screenshot. When we have these conformance criteria, there’s a checklist. And we’re not trying to be tricky. There’s a bunch of questions that we ask. If you answer “yes” to all of them, then guess what? You conform. This is a quick screenshot of one of the slides from our Curriculum materials. All this stuff is under the most permissive content license that we could find. It’s a Creative Commons International zero license, 1.0, and it’s essentially,you are absolutely free; if you want to be the hero in your company and say, “Guess what? I came up with a great set of Curriculum slides for the company, you don’t even have to tell anyone at the company where you got them. All up to you. Again, it’s about building trust.
You have a number of companies that have donated content in this space and are helping to champion this cause. You have a lot of purchasing power that’s actually,commensurate here. Having signed up Toyota the year before, and other companies as well, there’s a lot of revenue that these companies pull in. And by influencing their own supply chains, there’s actually a lot of purchasing of power on the upstream side that can help influence what we believe good supplier practices ought to be. A number of companies have indicated that they have conformed, and we’re making great progress; we have a number of partners: Moorcrofts in the U.K., TÜV SÜD in Germany, respectively, as a supporting law firm and certification authority. We have signed up Toshiba. Welcome, Toshiba. More announcements there shortly.
We’ve added within active community members. Microsoft and Panasonic have offered great contributions, and we are going towards a formal standardization for this, so look for that as an ISO specification to get approved in a couple years. We’re not done yet. We’re going to enhance a Specification. We have gotten input that there’s ways for us to frame that Specification in a couple ways to make it a little bit more flexible to implement. We’re going to expand adoption. We’re going to add even more supporting tools and compliance materials to help people. And we’re going to also accelerate the overall economic opportunities. So, we believe that, certainly for product companies, getting compliance done well, but also efficiently, and at cost savings, there is a compelling value proposition there. But also, we believe that the ecosystem is at a point where it can support consulting practices, training, and third-party certifiers. So, we are certainly encouraging that for the ecosystem overall.
And so, look for more news here, but more members to join the board, more organizations to announce conformance, more partnerships. And we’re certainly not shy to,use our procurement power not just for enlightened self-interest but potentially to help build out understanding in the importance of compliance. And please, feel free to be part of this. Thank you very much.
MISHI CHOUDHARY: I don’t have Eben’s history, but I also have now over a decade of knowing people and working in this community. Those of you who know Mike Dolan, he is the very supportive VP doing a bunch of things at Linux Foundation, and the formal bio says he’s the VP of Strategic Programs responsible for collaborative Projects and Legal Programs at the Linux Foundation. He has helped form over 150 open source and open standards projects covering a wide range of technology segments. Everything we are talking about or hearing today, Mike has had some role to play, or not. Prior to joining the Linux Foundation, Mike spent eight, over eight, years at IBM in roles across systems. He has an MBA and a JD and a Bachelor of Arts in Economics. I’m not sure if he’s going to talk about all those, but he’s definitely going to tell us what other interesting things he’s doing at Linux Foundation, and how it’s contributed to building this consensus in the industry. Mike.
MIKE DOLAN: Thanks, Mishi. Let me see if I got… Alright, let me get my slides up real quick. Okay, here we go. So, I think the title of session two is “Peace and Dividends.” What happens when peace breaks out is kind of the theme of this session, and so I thought I’d give you a glimpse from our perspective in terms of what we’re doing at the Linux Foundation. There’s been a lot going on, in terms of new projects and things that we’ve been involved in. And I think it’s important to understand where all this is coming from and get a understanding of what happens when peace does really break out.
We have about 150 additional project communities in addition to the Linux kernel that we’re hosting at the Linux Foundation. Roughly probably about 30,000 developers are contributing to our projects in any time of the year. In the microcosm of open source that we play in, we are a small percentage of what’s going on. If you’ve read the recent GitHub Octoverse report, over ninety million projects are on GitHub now. That’s up forty percent from last year. They’re engaging multi-tens-of-millions of developers on a regular basis. The scale of what’s breaking out is tremendous.
The Linux Foundation, as a foundation, we’ve been growing as well. We’ve seen a number of things going on. We’ve learned as things start to expand, and as peace has broken out, we’ve learned to focus on things other than the license war of the day, or the competitive rivalry between so-and-so and so-and-so of the day. And what we’ve focused on since is governance. How are these projects governed? What is good project governance? What is control mean in the sense of an open source project? How do you scale engagement with developers and companies and communities, some of which who have very different interests in why they would be participating together? And when you look at the growth of all this going on, and it’s technology by technology, as many people refer to it, as project-this or project-that… But the reality is we’re transforming industries in many cases. We’re transforming how business is done. We’re transforming how the goods of tomorrow are created. And I think that’s a really compelling thing to understand.
We’ve looked at a number of projects that come to us as proposals; everybody has an idea of something they’d like to host at the Linux Foundation at some point, it seems, but there’s only certain things that we look for. Is it an open source license? Is this truly an open, openly licensed project? Is there an open technical governance around the project? Does somebody have a control point or something that they’re trying to secure that’s not a good fit for us? There’s a community of interested participants that actually want to participate with whoever is starting up this project. We look for a sustainable ecosystem, commercial dependency on these things. A number of projects fail. There’s multi-millions of projects, and there’s probably going to be multi-million projects that fail this year or that die on the vine in GitHub because no one is maintaining them or actively participating. Does that mean they were good projects or bad projects? No, but what we’re looking for is a foundation, is something that we can help sustain. And sustaining that requires people to be dependent on using the code. And then at the foundation we’re also looking at mutually controlled community assets, making sure that one organization or one person does not have control of where things go by means of ownership of a critical piece of the community’s asset.
We host different types of projects. This has evolved from when I started five and a half years ago. We host projects that start off as community technical efforts where a number of organizations or developers want to get together and work on something together. And we spin up a governance charter. We make sure we right down the IP policy in terms of how contributions are licensed and what your commitments and things are as you’re contributing. And this is important, because that provides that foundation for a very strong collaboration, especially when you start talking about working amongst companies, many of whom are competitors. And when you start to write things down, you start to put things together in a way that works, and ecosystem like groups here today have all been working for decades on solving the licensing issues and the other little wars that broke out, and you have peace, suddenly these companies are invested in these projects in a way that they may not have been five or ten years ago even. And when they’re invested in these projects, they want to make sure that these projects succeed.
And how do you help the developers on these projects succeed? You give them resources, things that they can use. Number one: many of the companies that are represented here, they employ a lot of these developers. That’s essential. If these companies didn’t employ developers, they wouldn’t be able to spend time on these projects. So, employment is a critical piece of this. But beyond that, companies provide funding into the projects, often that goes to development resources. Builders for projects: we’re building just about I don’t know many projects per minute at the Linux Foundation, but it’s quite a bit. We spin up virtual machines on clouds, and that costs money, and the developers are constantly testing what they’re doing. And so, they need resources for that. Sometimes they want to make people, help people, know about their projects. They want to market their project, give it awareness, help build that commercial-dependency ecosystem that then brings more developers back into the project ecosystem, which brings more patches, which brings more contributions and more beneficial bug fixes, and issues about security are resolved in a timely manner. These are all good things. And so, there’s a couple of models that we use for funding. Some,we’ll set up a project that benefits multiple technical efforts. We’ll call that an umbrella community model. Sometimes it’s just a funding model for one particular project, but, either way, it’s a way to put resources in the hands of the developer community that’s working on these things. And this has led to growth.
We are not unlike GitHub; we have seen a very high growth in demand in terms of hosting projects at the foundation. This is not just our ability to do this. It’s just a result of what’s been going on in terms of putting up collaboration in the industry. And when I sit back and I think, “What has really accelerating this growth?”, some of that would have naturally happened; I think that part of it is that in a model where you have a neutral, frictionless access to participate, and anyone can participate, a lot of opportunities open up. If you look at some of the ways traditional cross-collaboration between companies and organizations happened, and standards organizations, for example, you had to sign a membership agreement; you had to go through a lengthy process internally to get approval to participate; only certain people could participate. Our projects are completely open to anyone at any point in time to give a contribution and work in the technical community. You can earn a committer role or a seat at the table in terms of making decisions about where the project code base goes by making… We call it a do-ocracy, in terms of the people who do the work make the decisions. But this is not something that’s bound to… You’re only bound by the IP policy of contributing. And when the ecosystem around open source and all the lawyers here and those who aren’t here today and those who working on this ten years ago, when they figured out how to make the IP model for open source work and come to agreement on some of the basics, it opened up this frictionless access in a much bigger way. And I think we’re seeing the dividends of that, to use a phrase from the session title.
But when we look at enabling companies to also support these communities, “without pay-to-play” is one of the key principles of what we do. When we set an open source project up that has funding attached to it, that’s just a set of companies who are agreeing, “We’re going to contribute some resources,” and the developers are still going to go do what they do, and we’re not going to be able to tell them what to do. At no point can you buy a patch or buy the ability to influence a patch or buy a feature or tell developers what to do. That’s just not how open source works. We understand that, but if you put the resources in their hands, the ability to build and test a project, overnight, you can suddenly unlock a lot of collaboration. When you start going into the telecom ecosystem and understanding what the next-generation telecom infrastructure’s going to be, they can’t rely on just people on GitHub, just putting patches in and nobody ever testing it. They need a group model in order to test and see how those patches impact the overall system.
And I think what we also have seen is that a lot of these projects, a lot of these communities, are evolving into ecosystems where other matters become important to them. Certifications, professional certifications, being a Kubernetes-certified administrator, is an extremely important role in many data center employment opportunities these days. Training millions on edX and other platforms in terms of how to get started with some of our projects: I think our introduction to Linux edX module is… Roughly about a million people have signed up to take that training course. And then, commercial dependency in this model drives sustainability. And I think that’s an important piece of it. So, if piece is broken out, what are some of the things that could disrupt the piece? Where are some of the potential issues or concerns,from my perspective, just looking at what’s going on.
This is Mike’s opinion; this is not an official Linux Foundation statement. It’s not something I’ve vetted with hundreds of people, but I’ve had many conversations about what concerns people about where things are going. And I think that,one of the things I’m concerned about is,some are trying to disrupt the IP model. When lawyers ten years ago got together in a room and a lot of smart people weighed in on how things were working, not everything was exactly written down. It’s in a lot of heads. It’s in heads of many of the people sitting around this room today. There’s a new generation coming around, and they have new ideas; they have different ideas of what’s valuable in terms of their contribution relative to the contributions that might be coming from others. And so, we have a proliferation of disruptive licensing schemes.
You can look at it in any number of ways. I think we’ll be talking about commons clause and things like that later, and I’ll stay out of that fray, but you can look at, also, new models like coin-based contribution models or compensation models for developers, which turn the idea of open source into this more monetary, gig-economy type of model. And this gig economy is a little but different if you really look at it. You have a bunch of individuals contributing intellectual property into something, retaining ownership, and there is no corporate stalwart behind them. Large companies that played a significant role in open source do bring a little bit of stability to certain aspects of what this collaboration model is based on. When work for hire is no longer how the primary development model of how developers are engaging in a project, what impact does that have? How do you react to an open source dependency where this is not how most developers are contributing under? Then,there’s security. This year, I’ve had to respond to inquiries from the U.S. House of Representatives and the Senate on security, and is open source secure? How is open source handled from a security perspective? Our response to the U.S. House of Representatives is public, and you can go read it online, but the reality is what happens when uninformed regulators act in may times may be a kneejerk reaction, uninformed about how and why this open source development model has been successful and why we suddenly have peace.
If you look at some of the things that are going on around software ID’s, software bill of material requirements, things like that, they may be benign; they are also easy ways for people to disrupt and cause issues by inserting things unknowingly into requirements. And then, finally, just regulation in general. What happens when certain jurisdictions decide to change the rules? If you were paying attention to some of the things going on with the EU Copyright Directive in the last year, I think there is a number of concerns that were raised around open source and how that impacts it, in addition to many other issues with that. The Free Software Foundation Europe, I’ll give them credit for identifying the issue and trying to take a policy approach, but I will say, the Linux Foundation, this isn’t…Most of this is not our battle. This is not where the Linux Foundation is going to help and where we’re going to solve it. It’s going to be lawyers like you, lawyers at companies, lawyers at other industry efforts where policymaking it a little bit more of something that, what you do. It’s not something we do; we take the projects; we help these projects grow; we provide the resources and help for them to do what they need to do in order to engage and collaborate in a frictionless model. But there’s a number of other things out there that could potentially impact us on this front.
I just wanted to give this perspective; I was asked to talk about what happens what peace break out, and I hope you understand that peace is a good thing. Let’s try to keep it peaceful and not forget some of the underlying principles that got us here and what works.
EBEN MOGLEN: Thank you, Mike. I gather that everybody has gotten to where I think this all adds up. We have now begun to experience what can be done when there is consensus. We can converge GPL3 and GPL2. Richard and I thought, more than fourteen years ago now, that automatic termination was going to become a problem in a world of ubiquitous free software, and GPL3 termination was designed to eliminate a problem before it became bad.
But GPL3 wasn’t a perfect replacement for GPL2. Now we have the ability to amend the licenses by broad community consensus, and that’s what David was talking about. We have the ability to make industry pay for perfect compliance. We’re outsourcing to the people who have the money and the incentive, and we’re going to get it done. And that, from the point of view of somebody who used to have to try and figure out how to get some nickels and some dimes together in order to go and deal with abating bad actors, is an overwhelmingly positive dividend of peace. We’re going to get peacekeeping paid for by the people who have armies and money, and who could object to that? And we are going to be able to find consensus between trade association forms of project governance and non-profit, community-based forms of software project governance, which is going to allow any group of people in the world who want to make software together a range of possible ways of getting all their plumbing done for them, either by community-based organizations, or by industry-based organizations, as the nature of their project and the nature of their desires trends them. These things are possible because there is peace.
But peace, as Mike was just saying, is the work of diplomats. And I have just witnessed a diplomatic triumph that I want to pay particular tribute to, even though we’re behind schedule, and we’re going to delay people’s lunch, and we’re going to have a food fight before lunch, and all of that. But still, we need a quiet moment to appreciate the peacemakers, for they are blessed. I don’t need to introduce Keith Bergelt around here, of course, but I do wish to point out that the United States used to have a really good empire, full of really good diplomats who really understood people and things and policy problems, and Keith Bergelt, though he,he always looks like he never worked for the U.S. government in his life, was, in fact, a part of the greatness of the American empire now in decline. Think of us as having once possessed Keith Bergelt at the Tokyo embassy. You can understand why, in a world where we barely have ambassadors in some important places, it’s worth remembering he comes by his diplomacy, honestly. I skip over his hedge fund part of his life, when I think about this, because, of course, I don’t care whether hedge funds have good diplomats.
But OIN has been transformed by Keith’s diplomacy, and now OIN, through Keith’s diplomacy, is transforming our world. So, Keith is one half of this enormous diplomatic triumph, and Nicolas Schifano represents the other part of it here today. Nicolas came on my radar because he was for years a Microsoft policy guy in Brussels, and then in the United States. Those are the people whose batting order I used to have to keep track of, so he has no idea how much I thought about him back when we didn’t know one another. But now, as the person responsible for Azure IP assurance for all the customers in the world, he is, of course, a peacemaker, first a Microsoft peacemaker, and now part of this grand peace that brings us all together.
I can’t exactly explain what it feels like to be standing here, in my conference at Columbia Law School, welcoming Microsoft to FOSS peace, but you can understand how it must have felt in 1945, when people really thought that they could build a new world of liberal values and collaboration, and that the rich would pay for it. I’m reliving the dreams of a generation ago. Keith, come down. Nicolas, please come.
And this is history, folks. They will watch the newsreels of this great moment of the outbreaking of peace, and all I need to say is that swords have been beaten into plowshares. Spears have been beaten into pruning hooks, and here we are to appreciate it. I give you Keith Bergelt and Nicolas Schifano.
KEITH BERGELT: It is humbling, obviously. I think the first time I was here was before I accepted the role that I currently occupy, eleven and a half years ago. Coming to the event, listening to people in this room speak - obviously Eben - and learning about open source, having come from different set of backgrounds, having worked in technology for a long time, it was very informative and very confirmatory of the importance of open source - this elegant social movement that we’re all participating in.
The idea of self-regulation and self-organization, Dave talked about the self-regulating nature, and I think how appropriate this topic is and this union is with Microsoft. It’s not a union with OIN, necessarily. OIN is the vehicle to be able to create kind of a set of norms or code of conduct for what most people accept as to create authenticity within the community. To see the evolution, the point that - I’ve spoken probably six times since this was announced in the last two or three weeks - but no company has made a longer journey from being the most successful proprietary software company in the world to now being a company that is arm in arm, hand in hand with other companies to be able to create products, to deliver services to their customers, and to be able to tap into the creative vein that is open source. The title that Mike talked about, I think it’s quite interesting that John Knowles wrote a book called Peace Breaks Out. A kit if people don’t know it because they remember his famous, late-50s tome about Phineas and Gene: A Separate Peace. But Peace Breaks Out was about a generation of boys that were not able to fight against fascism, were not able to fight against the artificial controls that were being imposed on a world across the sea. In some ways, we’re now looking at this openness and freedom and the ability to engage all companies, and one of the most sophisticated technology companies in the world has now joined the fold. I think that to me is significant.
While I don’t allow myself the emotion of euphoria - just my nature, I’m not good with high highs and low lows - but I see this as significant, clearly for OIN, but it’s more significant for the community, and it’s incredibly significant for Microsoft as a company, because it shows their evolution. And it shows the inevitability, as I’ve always described to Eric Anderson and his predecessor leading the IP function.
Open source is inevitable for companies who want to compete effectively in a hyper-competitive world and participate in models that are really essential to deliver what your customers really want. I think it would be useful now if Nicolas could provide kind of a sense of how this evolution has worked, because this isn’t something that happened last week or last month. This dialogue with OIN has really been a three-year process. It intensified early in the spring, but having perspective from the inside to be able to share kind of this evolution and understand the changes inside Microsoft are, I think, important to be able to elucidate.
NICOLAS SCHIFANO: Thanks Keith. I think it’s, first, an honor to be here. I’m grateful for the invitation and the opportunity to talk today. Yeah. I think it’s not only a journey, and frankly it’s fair to say that we see Microsoft and ourselves as part of the community. This becoming part of a community all started many years ago, and we see OIN as one milestone in that journey. Frankly, all the milestones before, the work in Azure and in other places and the increasing reliance on Linux was another important milestone. Joining the Linux foundation not even two years ago, I think, is an important milestone. Shipping Linux in an IOT module, a thing called Azure Sphere, was - I think we discussed with some people here yesterday - that was, at least internally, a defining moment of “hey, that’s the future! That’s the present!” So, joining OIN is, in a sense, just a logical consequence of all these steps and of this increasing participation in reliance on the community. I think we are here now. We climbed this mountain. We’re at the top, so to speak. Past this big hurdle, at least from Microsoft’s perspective. We see ourselves deeply in that community. We see that the future of Microsoft is tightly coupled to the success of developers and their ability to collaborate, share innovation. And there is no real alternative for us. Working with developers, I think you see that with the work that’s going to happen with GitHub. Ensuring that developers have this ability to collaborate is really important, and that’s how we want to use the IP, as well: to actually enable that collaboration, to create this patent peace on these community projects. That’s really how we see our actions.
EBEN MOGLEN: I want to understand a little bit more about what it means from your point of view to have come into this broad church of ours. We had awfully sharp disagreements over the course of these decades. We were not easy in one another’s company. For us, I think, if I can speak from the point of view that was on the other side all that while, it’s easy for us. We have welcomed everybody. Everybody got here. Some people came into existence because FOSS made it possible for them to exist. Some came because they began to build devices which they wanted software commoditized to put into it, and our dear friends at Google offered them an opportunity to get into the game without a software ante. But never quite have we welcomed someone under these conditions. I feel no problem about euphoria. I just want to avoid triumphalism. I want to be modest and easy-going about this. I want not to do any crowing, lest I should have to eat crow at the other side. I know what we are welcoming. We are welcoming people who used to be our adversary and whom we now are delighted to know as friends. That’s a special and important feeling, and it’s part of why I’m a little sentimental about all this, because it is a pleasure to welcome an adversary as a friend.
From Microsoft’s point of view, is this a temporary business decision based on the political realities or the political economy of the cloud? Is this heterogeneity? Is the model of IT today and vertical integration might be the model again tomorrow? I don’t want to be in a marriage of love if this is a marriage of convenience, then I want to be convenient too. I tend to think that GitHub is the demonstration that you live in our world now and that we all are going to be good citizens of it together. That feels to me like the crucial moment in the process, but I would really like to understand Microsoft’s heart a little bit. I cannot, like George W. Bush, look into the eyes of Tsar Vladimir and feel his soul, and I certainly don’t know how the other guy feels, but I want to believe that we met in some honest, honorable way here. What is it like for Microsoft to be with us?
NICOLAS SCHIFANO: It’s a great question. I think historically Microsoft has been a developers’ company first. Along the way, that focus has maybe not changed but diminished a little bit. I think now we are kind of back there. It’s really about working with developers. So, from that perspective, I think there’s really a recognition internally that open source is the way to work with developers. That’s why you hear people like Satya, the CEO, saying Microsoft loves Linux.
It’s really about this change of culture around the way you engage around software, how you build software, and how you need to share innovation with the broader community to not only develop faster but also make sure that the innovation you share is of better quality. All these elements we view as really essential to be successful in this new age. Again, as we continue to build our reliance, as we continue to enable others to use these projects, being part of OIN, being part of all these projects - the GPL pledge and others, certainly there are more to come - now that we have turned this page a little bit, I think there are new issues that we need to think about. So that’s really where we are and where we want to go to: really work with the community to solve these new issues.
EBEN MOGLEN: Many people in the room remember when their companies were in that place. That’s not a new story. That’s how many of us came to be friends, colleagues, and comrades as we are. It’s part of why I’m not in a distressed or ironic or doubtful mood about where we are. We have real peace here. It is based on something that we can all understand. We’ve been through it. We all got into this place by some means that felt a lot like that. Keith, what do you think this means for IBM, other than the fact that, if Microsoft can take an OIN license, there’s no entity on earth than shouldn’t take an OIN license?
KEITH BERGELT: Yeah. I think for OIN this is not really a reboot, but it allows us to look at having accomplished a very significant goal, which is to bring in a company that - the triggering event for OIN’s formation was the SCO financing that Microsoft was doing and creating more FUD within the community. To go from there to where we are now, it’s clearly an important event. Perhaps, not to take a contrary view from Eben’s opening remarks, there’s still more work to do. There are aggregators on the patent side that have patents that are concerning to us, that read on the Linux system and in core Linux functionality. We want to be able to look at taking the OIN model and platform and, working with our member companies that have funded us, to be able to see how we can effect positive change there to reduce risk from patent aggregators.
Then there’s always the threat of copyright aggregation. I’ve never been individually concerned with Patrick McCarty and his behaviors, but I have been concerned about what they signify - that they lead to some people with more money, better lawyers who can actually aggregate copyrights, and create potential friction. The Microsoft signing gives us the opportunity, one, to sign companies that have been on the fence, that have been maybe hiding in plain sight previously and now are exposed because, as said, if they can make this journey, anyone can. I used to say if IBM can expose its massive patent portfolio and participate in this way, then anyone who has patents can. This just gives us another source of energy. The “knock-on effect,” or what I’m calling internally “the Microsoft effect,” we’ve already had 140 new licensees in the twelve working days since the announcement. That’s a bit more than we would normally have. We’ve been averaging 70 to 80 licenses a quarter for the past three years. We had done much more than that at certain points in our history, but this is the kind of exogenous force and factor that causes us to realize that we need to work doubly hard to grow the community. For every one of the companies represented here, we’re growing the community…
Our responsibility is to look at every ecosystem, every project that Linux Foundation manages and make sure that we’re including core code to protect those projects and project participants and reduce the friction that they might otherwise experience. So, for us, it’s an opportunity for us to pivot, to be able to broaden and open the aperture to be able to do more for the community to support patent non-aggression and, more broadly, IP non-aggression, and it’s an opportunity for us to build relationships new companies that have been on the fence. Rogers here and Alibaba just signed the OIN license. Ant Financial, which is Alipay, signed the license about three, four months ago. This is not an aberration. Tencent advised that they’re signing the license in two weeks. The movement is really in this direction. China we now have more licenses than we have in Japan, which is saying something because Japan is the most sophisticated open source company and the most experienced open source country in Asia. The Chinese movement: neutralization of potential risks from the massive patent filing strategies that are being promulgated there.
There are lots more things for us to do, and we’re going to do it arm in arm with our member companies, with our licensees, and we’re going to do it arm in arm with Microsoft. This is not just sign a license and then we don’t sue each other, we don’t support each other. We want to work with Microsoft to make sure that we can provide the benefits of our experience and guidance around activities and actions that could be taken to further continue the evolution that Nicolas talked about, and to ensure that value is created, because we can draw off the knowledge and experience that Microsoft has in rounding our experience in how we expand the Linux system definition, how we grow into new technology areas in much the same way that our relationship with AT&T is defining as a new licensee that came in earlier this year. These are critically important companies, and we don’t want to have them simply be part of a signatory group of companies but, rather, these are companies we do outreach with. I was just in Seattle two days ago. I think Nicolas and I were together last week in Scotland. We are looking to create more glueware so that this relationship is one that is defining for them and defining for us going forward.
EBEN MOGLEN: I’m going to state an ambition about what we can build on this peace just to add to the idea that there is more work to be done. I would like us now to be able, using this broad patent peace we see before us, to assure every individual FOSS developer and every non-profit project out there that they will not be the target of anyone’s patent aggression. This is basically true for all OIN licensees within the Linux system definition. And it is rational conduct for all the patent holders in the world now to permit that ungoverned and largely ceaseless form of innovation, which is out there in the individual developers, students, academics, teams, and non-profit community projects. They should have complete patent peace now. We are close.
No matter whether everybody makes an OIN license or there are a few hard-bitten naysayers out there should make no difference to every individual who is learning how to program and who wants to put some of her code into something that other people use. I would like to believe that it will be quicker to get to that state of complete peace for individual developers and non-profit projects around the world than it was for Keith to bring in Microsoft. Three years, he said. Three years.
My diplomatic goal here is three years from now every free software developer in the world will feel completely safe from the patent system, and those who benefit from patenting their technologies and monetizing their research and their projects and their products will feel completely safe in doing that, because they will know that that doesn’t interfere with their ability to gain positive returns on their research investments. That’s the goal I would like to see: the peace dividend out of this wonderful peace for all the coders around the world who are the client base I have been serving for decades now. I think that’s achievable, because peace makes peace; because when people behave responsibly and seek peace and seek justice for society, then you can build on top of it. That’s why law school exists.
Alright so lunch is being set up, which means we need to have our fight before we can have lunch. Thank you both very much.