 So I have titled this The Legal Significance of OpenStack. I couldn't really think of a better title. I wasn't really sure what to talk about, Alice, and I need to speak on this legal track. I really like participating in legal tracks at technical conferences. I think that's really an important thing to have, and I'm very pleased to see this happening. So when I was trying to think about what to talk about, I realized that I've been giving talks at mostly tech conferences for a few years now, and they've been on various subjects, and I realized there's sort of a common theme, and I realized that the common theme had to do with the, basically I would say the relationship between corporations, corporate participants, and open source projects, and communities, and the idea of software freedom, and there's a sort of tension there, and that I hadn't really kind of thought of that before, but I think that's sort of a common theme that's been at the heart of a lot of the interesting policy and legal issues that ensourced ever since, well, really ever since joining Red Hat. So this is not an official Red Hat talk. If you wanna learn about Red Hat's relationship with OpenStack, I recommend talking to Perry Myers or stopping in the Red Hat booth. So this is just my personal thoughts, and you'll probably disagree with a lot of what I say. So, okay, so this is, and this is, you can, so at Red Hat, I kind of have a broad set of responsibilities and they kind of expand over time, but I mostly focus in the area of open source and also increasingly standards, and that's, you know, partially by choice because it's what interests me the most, and it's also kind of expertise, I guess I'm the subject matter expert in the Red Hat legal department on open source, and open source, of course, is very important for Red Hat, and has been throughout its history. So I thought I'd start out with a quote, and the one I initially thought of doing was, actually I remember when Rick Clark said on the OpenStack mailing list, what was it? I truly hate all this legal stuff or something like that, but because there actually isn't like, this talk is really about legal stuff per se, in a sense, I thought I would instead use this very recent quote from Lydia at Gartner, and this was sort of seen as this kind of anti-open stack kind of fud quote, but she says that there are people who have been misled into thinking that that open stack, because it's open source, it must be an open and widely adopted standard with broad interoperability and freedom from commercial interests, and this is sort of an odd statement because anyone familiar with open source would know that many, the most important open source projects do certainly have commercial interests behind them. On the other hand, there is a big difference between an open source project and an open standard, and I think Jonathan Brice, or someone associated with the OpenStack foundation and the project had a response to her points, and I think pointed out that, well, in a sense, what OpenStack wants to be is to become a kind of de facto standard. It isn't, you know, it's different from an existing standard. So she says, in reality, that the OpenStack is dominated by commercial interests. It is a business strategy for the vendors involved, and it's not the effort of a community of altruistic individual contributors. This is an interesting statement because it assumes that, I don't know if this is her view or the view that she thinks people being misled may have, but it assumes that there's an opposition between being an altruistic individual contributor to a participatory project that's somehow in conflict with there being a lot of commercial interest behind a project. And so that seems to kind of reflect a misconception about open source and maybe an out-of-date one, but there's also something true to it, and it kind of got me thinking that this is related to that common theme that I've been seeing over the past several years. So I believe that we're in this period now for about five years that's in open source that is different from the preceding period. And I think it's hard to see this happening at the time, but I think looking back, we see certain things that have happened that wouldn't have happened in the previous era. So this is, in the slide, I sort of set out how I kind of visualize or conceptualize the history of open source in a very kind of high level way. So open source, long before it was actually called open source or even free software starts out in this kind of pre-historical era. Before the 1980s, you had elite groups of programmers who were naturally sharing code with one another across institutions, usually universities and research divisions of big industrial companies, harbor companies usually. And this was a period in which that kind of collaboration was what I call a commercial. It wasn't, I wouldn't say non-commercial because that has certain connotations today, but it was assumed that software was not a commercial thing. It wasn't seen as an asset. This was a time before software was seen as a form of property that existing intellectual property law clearly applied to. I mean, I suppose trade secret law was the one that sort of seemed to be the most applicable. But for a long period of time, it wasn't clear that copyright applied to software. Certainly patents were assumed not to apply to software. This is kind of a U.S. perspective, but it's certainly true of the rest of the world as well. And that came to an end gradually during the 1970s, the end of the 1970s, in the U.S. certainly with some changes in the law in other countries as well. But also some business changes. So there was a process of what I think was called unbundling occurring in the software industry at the time. So the first commercial software ventures emerged in the late 70s. And it was sort of realized that you could have a business, a viable business around software that wasn't coupled to hardware. So this was something that gradually happened with some legal and business changes. And when that happened, that caused a reaction among developer communities that I think really led to what we now think of as the open source culture that is behind all the various open source products we have. So this was the, basically in the 1980s, we had this early era where it's now, basically developers who come out of this software sharing culture are trying to reconcile themselves to the fact that that law applies to software. And they have various views about this. Some of them are very hostile to this. Some of them see opportunities. Some of them see that sharing of code in a kind of public domain sort of fashion across institutions as they had been doing could be the basis for a downstream commercial ecosystem. So sort of a standard setting, like a view of what we would now call open source software. And I think that open stack kind of descends from that part of open source culture. This is when I think of that period and long ago in the 1980s, something like the maybe the X Window project that MIT started is something similar so that they were using very permissive license. One of the earliest open source licenses or free software licenses, very close to a public domain dedication. But this was also the period when there were other viewpoints. There were some developers who thought that commercialization was basically the enemy. And these developers really kind of, we think of as open source today doesn't really include that part of the culture. It still exists. There is a kind of non-commercial commons, if you will, I think, for example, often around gaming software. But this is not part of open source as we came to know it. But the other view that was very influential was the copy left view, the one that Richard Stallman championed. So Richard Stallman saw an ethical problem with the rise of proprietary software, the proprietary software industry. And he developed a concept that he called copy left, which was basically a way of using software licensing to try to preserve the free status. You can think of it as trying to perpetuate the public domain status that software in his world had had years before. And so we looked through that error and there was this debate over these two different approaches to licensing, because licensing was now being used by these communities. It basically adopted the legal techniques of commercial proprietary companies and found ways of using licenses to fulfill their policy objectives, which were very different. So that's sort of the 1980s and then in the 1990s, this sort of flourishes into this explosion of community projects, like Linux and Linux kernel project, like Linux distributions, like the Apache web server project. Just many, many, many projects emerge in that time. It was sort of a golden era of free software, as it was more commonly known then. The next period begins in 1998 and this, I would call the open source business bubble. So at that point, open source is named open source for the first time and it's marketed to business people, entrepreneurs, CIOs, and it becomes visible in a way that it hadn't before. And there's this exploration of different kinds of business models around open source that begins at that time in less several years. And this is a very strange error. This is the era, I mean, at the end of this era, I got started in doing legal work in this area. And so I have a kind of an odd take on it. I was initially very kind of attracted to it because of the sort of business enthusiasm around it. But I think that came to an end around 2007, 2008. And I think we're living in this different period now. I think it's sort of non-controversial that that open source bubble burst at some point around 2007, 2008 or so. And I think, so for all but that very first pre-historical period, there's always been this tension in open source or free software as it was previously known between the idea of software freedom, which is fundamental to the kind of licensing models and cultural norms that these developers and these projects had and commercialization. Because the common quality of both copy left and non-copy left licensing was a belief that commercialization was a right. There were different takes on whether commercialization should be restricted and how much. But commercialization was a goal of both of these camps. And but at the same time, there was always this natural tension between commercial interests getting involved in projects and the communities that developed the software. So I think it's been a common theme. But what's interesting about the bubble period is I think that some of these themes were suppressed in a sense, they were sort of swept under the rug. And I think what has been happening in the past five years or so is that these issues have come up again and they're being discussed more openly than they had been during that period of sort of irrational enthusiasm that preceded the current period. So I'm just going to talk about like some of the themes I see in having come up in the past several years. One that really sticks out in my mind, although we don't talk about it as much today, but was big around 2009, 2010, is this debate over open core and this kind of real kind of vocal backlash by many people involved on the policy side of open source against what was called open core. So open core, it was a term that quickly sort of lost meaning, but it generally meant a business model in which a company would have an open source licensed community addition often with kind of crippled features and then would make money by selling a more featureful proprietary version. So it was the latest of a kind of series of experimentations in basically proprietary software business models that had an open source element to it. So the earlier forms were sort of more simple, dual licensing open source and proprietary business models like MySQL was most famous for, but so open core was sort of a variant of that, that in a sense was becoming more popular around this time. And there was a big backlash in communities against this and I was quite struck by that. And I realized that open stack really comes out of that period, right? So it really originates in this in a way that I actually had not, I'm not sure I'd really appreciated so much until kind of looking back and seeing, kind of reading again about the origins of open stack. I think it's kind of well known that the part of the origin of open stack had to do with the frustrations that Chris Kemp and his collaborators at NASA felt in trying to contribute code to Eucalyptus, which had one of these open core models. I think a GPLV3 licensed open source version and then a sort of premium version that was proprietary. And they tried to submit patches to improve Eucalyptus and those patches were rejected because they would have enhanced the open source version which was going against the kind of basic premise of the model. And when open stack is launched as a project, this is something that I just found out recently or at least or perhaps I had forgotten about it but there was a document that the project, I guess I assume Rackspace and NASA worked on together and it's still available on the open stack website today and it's called What Does Openness Mean? And it's kind of a, it's as much of a political manifesto as any, as you know, Richard Stallman's GNU manifesto from the 1980s. It's a very, very interesting document and I think probably one of the most important legal policy documents that's been written in open source over the past, it's a very significant document and one of the points made in this document is this pledge that open stack will not be open core. So I think this backlash against open core is a key part of the origin of open stack. This pledge to not use a model like Eucalyptus was using or that what was then cloud.com was using sort of a similar approach. That open stack would be a pure open source project. It wouldn't feature any kinds of gimmicks in which the open source version, there would be a crippled open source version and then a for sale, more featureful version. It would be a collaborative open source project. So another theme and all these themes are kind of, it's hard to kind of separate them. They're all very closely related at least in my mind. Something that's been talked about a lot more recently and Alison Eileen referred to this is, the perception of a shift away from GPL licensing, which I think had had in at least the popular mind long dominated the view of what open source licensing was mainly about and towards more permissive licensing. And I've been giving a number of talks on this subject over the past year because it's so interesting to me to kind of explore whether there's really any kind of shift going on. And we don't really know, and that's why I have the question mark next to this. I have no idea whether there's a general shift away from the GPL or a copy left towards non copy left permissive licenses like the Apache license. But I think I see a shift going on to some degree in some context. And what I definitely see is that newer corporate initiated projects and open stack is probably a good example of this in the past several years have tended to be under permissive licenses, whether often the Apache license, sometimes a BSD license or the MIT license, but I definitely see a trend there. I don't have the data to prove this, but projects that I would have expected to be under GPL going back prior to 2007 or 2008, these are the kinds of projects that I'm seeing companies use permissive licenses for. And I think there are probably many reasons for this. Alice and Eileen talked about why open stack chose the Apache license and the fact that the Apache license is actually so fundamental to the project that it's baked into the bylaws into the IP policy such that you would need a super majority to make any change to it. So it's really a kind of fundamental constitutional piece of open stacks IP policy, more so than probably most projects that are now associated with foundation. So it's a very important feature of open stack. So why does open stack use the Apache license? Well, I mean the answer that is maybe the most obvious one is the one that Alice and Eileen talked about, which is that this license would encourage the broadest adoption of the technology, which was an obvious goal of the project. And that's, I'm sure that that was a main goal, but I have to think that part of it was also this part of this was related to this backlash against open core. So the open core models were based on copy left, open core as I define it at least. And these models and dual licensing in general kind of experience this fall from grace during this period. I think it fell into disrepute. It, as I said, this was a long simmering resentment against this kind of business model that I think became to be openly discussed during this period and the criticism came out in the open. And I think that that must have had something to do with any tendency we are seeing today towards the use of permissive licenses instead of copy left licenses like the GPL. So I think that that probably had something to do with it, especially when you consider the kind of open core, anti open core related origins of open stack as a project. And I think, you know, why would this be so? I think it's because, I mean my intuition is that that when you have a corporation starting a project where Rackspace had basically started open stack, you want to, if you want broad adoption, if you want to really build a community not all projects, not all corporate initiated projects have that goal, but if you want to build a community, you want to, you need to build trust among the participants. And I think at this point, for many, both corporate participants and maybe individual participants, the GPL and copy left license had gotten a bit tainted by the example of some companies that were seen as having misused it. And so permissive licensing like the Apache license has the effect of signaling trust by a corporation. It's basically giving up much more power than a corporation launching a project under the GPL and then maintaining very tight IP control over it so that an open core type or dual licensing business model can be pursued. So this idea that permissive licensing signals trust is at least my intuition, a part of what is going on in any shift of licensing trends that's going on. So using the Apache license as a form of giving up power in the GPL, obviously it gives up power to some degree, but using a permissive license gives up much more power because it gives every recipient of the software the right to proprietize it, much just as the initiator of the project at the right. So another theme of this period is what I've recently called license insufficiency, this perception that historically there was this view that what you need for software freedom is an open source license that has all the features of an open source license that gives you the right to fork and gives you all the freedoms associated with open source. And there was this emerging view that this is actually not good enough, that you need some kind of commitment to transparency and open development. And this has been talked about quite a bit over the past few years. You know, it's approached a sort of a suggestion that maybe our definitions of open source should be revised to take this into account. I talked about this a little bit at my talk at LinuxCon a few months ago. And this is something that also makes us think of OpenStack because OpenStack from the beginning has really had this dedication to openness in its development model. So the open design and collaborative development, this emphasis on meritocracy, sort of I think, you know, Apache style meritocracy, but these have been key features of the project from the beginning. They're even emphasized in that manifesto document that I referred to before. And they continue to be a feature of OpenStack. So, but the thing is this didn't eliminate all of the concerns within the OpenStack project about the existence of imbalances of power because this was a rack space managed. That was, you know, one of the motivations of course for forming the foundation, but even now in this post foundation formation era, I see some of these concerns still existing. I mean, I'm on the OpenStack foundation mailing list. So I kind of detect, I don't know if that's kind of representative of any particular viewpoints, but I detect some of this concern about power relationships still persisting. But this was certainly true for a long amount of time and it was one of the motivations for starting the process of moving the project from rack space to the foundation structure. Again, you know, related to these other themes is this idea that there's a problem with a fundamental problem with single entity control of products. This was obviously related to the concern about OpenCore. This is sort of related to the concern about misuse of the GPL or other copy left licenses and maybe the idea that permissive licenses are ways of building trust. So sure, be an issue and actually, so this is not a new observation at all because at the very dawn of the actual open source revolution, you know, in 1999, Jamie Zewinski, who was in his famous, another famous document, is his resignation letter from Netscape. He had the famous statement, you know, open source is not magic, pex he does. And what he was actually talking about in this document is he said, you know, he had such hopes for the Mozilla web browser as it existed at the time, this open source project that Netscape had launched. But at the end of a year, it was still really completely controlled by Netscape and that is not something that he had anticipated. He thought that it would become a very collaborative project in which Netscape would just become one of many participants and that did not happen. And he saw that as a failure. But this was, you know, this is maybe the end of that pre-business bubble period. So this concern, you know, wasn't talked about very much during the subsequent years but I think this has been more a concern that's been expressed in the open in the past several years. And OpenStack is one example of where it's come up. So there was, you know, in the very short but exciting rapid growth of OpenStack as a project, the concern about rack space, rack space's dominance of the project was voiced by many people. It was certainly a concern inside Red Hat. It, you know, for Red Hat, it kind of delayed our entry into the project, at least as I perceive it. It was a concern that if Red Hat got involved, we would not be treated as, you know, an equal participant on a meritocratic basis. And Red Hat had had that experience with some other open source projects in the past. So there was some, you know, history there that Red Hat did not wanna kind of repeat certain past mistakes. And at the same time, you know, Red Hat itself had been on the other side. I mean, many of the projects that Red Hat had initiated, open source projects remained and, you know, remained to this day to kind of dominated by Red Hat. So I think this, you know, looking at OpenStack actually had a very good effect on Red Hat, I think, because Red Hat realized, you know, it wasn't really so different from what it was criticizing. And at any rate, so, you know, OpenStack didn't really have this problem of lack of magic pixie dust. It very much had magic pixie dust, right? Because the project grew very rapidly. It attracted a lot of participants. But still this concern about control by rack space persisted and was one of the motivations for the transition to the foundation structure. So I think this was actually addressed a little bit by Alice and Eileen. But there's, you know, one aspect of why single entity control is a problem. I mean, part of it is that if you want to get, if you believe that the open source development model actually has software engineering benefits, you're not gonna get those benefits if there isn't diverse participation, right? I mean, that's sort of an orthodox belief, at least for large scale projects. I mean, it may not be as significant for small projects, which tend not to have large contributor communities by definition. But for big projects, it's really kind of obvious when there is one entity that's kind of controlling things or at least has unequal power relative to sort of external participants. And I think, you know, part of this is this idea that, you know, what happens if the company controlling the project is acquired. This was something that I think Alice may have mentioned. What happens, will the project die if that happens? I mean, this is really kind of a property rights theory. So, you know, the concern is that you need, for property to be secure, you need to know that it's gonna be around. And that has too much control over a project. Sort of ironically, that's actually a danger sign because it may mean that it's more likely that the project will disappear if that company ends its commitment or disappears or becomes acquired by some other company. I mean, we've seen some examples of this. Rackspace must have had this epiphany that they wanted OpenStack to succeed. And in order to make it succeed, they had to give up some power. And this is very difficult, you know, for companies to do. I mean, I've seen this, you know, in many ways I see Rackspace as kind of a mirror image of Red Hat because we've dealt with this at Red Hat as well. I mean, we start so many open-source projects, but I think we're often afraid of, naturally afraid of giving up control. And I think the experience with getting involved in OpenStack, as I've said, is it's been very viable for Red Hat because it has allowed Red Hat to kind of confront this on some level, you know? I think we're improving because of that. So Rackspace realized, and I think Lou Mormon actually said this at some point, that their goal was to make sure that OpenStack could survive without Rackspace, that Rackspace disappeared, this project would continue to be successful. So another thing that was a common theme during this period and really not so relevant to OpenStack is controversies around contributor agreements sort of erupted in the open. And I used to give, actually recently gave a talk on this when I was at OWF in Paris, but I've talked about this in the past and there's always been a controversial issue in open-source developer communities. And it all, again, relates to this problem of having a single entity, so the beneficiary of a contributor agreement will generally be seen as having, receiving power from external contributors to the product. So you have this imbalance of power. I mean, this was often a criticism of the FSF, actually, and still is, but later on became even more of a problem for corporate-dominated open-source projects. It's really not an issue for OpenStack. I mean, I don't see any, so OpenStack uses the Apache-style CLA's, and I think the only people who really criticized this were me and Mark McLaughlin, so I think most OpenStack participants are comfortable with this. So I think in this sense, Mark and I are the progressives. But it's not really such a big deal because I think these contributor agreements that formally give power to this inbound entity, whether it's a rack space or a neutral foundation, they're not so problematic when the outbound licensing of the project is permissive license because there's really not a lot of distance between the Apache CLA and the Apache license. So it doesn't raise the same kinds of issues that, say, using the Apache CLA would have if you had a GPL license project. That would be closer to copyright assignment, which is very controversial in open-source communities. So in a sense, it's not really surprising that this wouldn't have been a big issue for OpenStack or a controversial issue, as far as I can tell. I mean, I have heard some complaints about the red tape involved in CLA's, but I don't think that there's been that much of a fundamental policy objection to it from OpenStack participants. So another theme of this period, and I think probably the last thing I wanted to talk about is the whole idea of having a foundation be the home for a project. This is not a new idea at all. The Free Software Foundation was founded in 1985. The Apache Software Foundation goes back to, I think, 2000 or so. The goals of a foundation changed during this period, though, I believe. So if you think back to why the Apache Software Foundation was formed, I mean, apocryphally, it was that an IBM executive said, I can't make a deal with a web server. So it was just sort of this desire to have some formality around what were otherwise loosely affiliated groups of developers so that to facilitate commercial participation, you needed some kind of more formal structure. And that's still an important part of a function that a foundation can serve for a project that's associated with it. But I think what happened in this period that wasn't really true in the past was the idea of foundations as neutral territory for multi-vendor participatory projects. That this is sort of the identity that the Apache Software Foundation took on during this period that I don't think it really had in the early years of its existence. I mean, the Apache Foundation actually was sort of tainted by some of its associations with particular companies, right? And I mean, that still exists to some degree. And that's a problem with a number of open source-related foundations. But I think what we've seen in this more recent period is this very kind of frank observation that foundations, if they serve any really valuable role, it's to provide this neutral playing ground so that you know that, you know, at least formally speaking, participants will be treated equally, especially important for corporate participants in an open source project. And it's also related to this concern I already spoke of, which is the problem of what happens if the corporate founder goes away. So a foundation is sort of seen as maybe a kind of permanent home for a project. That corporations may be acquired and may change their priorities. They may give up on projects. But a foundation is a more of a longer, seen as a more longer lasting kind of home for a project. So there was an essay by Henry Gingo a couple of years ago that talked about this. And he attempted to show that, you know, most of the most successful open source projects had foundations closely associated with them. And I think I disagree with some of his methodology, but I think it's an interesting point that he was saying that for vendors who start projects, they want the projects to succeed. They really should cease kind of formal control over the project and try to move their project to association with a neutral foundation because that's experience has shown that a foundation, a neutral foundation is with good governance is likely to ensure the survival and success of the project. This is not, I mean, the idea of neutral foundations is sort of questionable because you can have corporate influence, undue corporate influence over foundations that's not transparent. So there's, my views on foundations have kind of shifted back and forth because of this concern that I've had that there can be kind of hidden corporate interests that are behind supposedly neutral foundations that are not really disclosed. But this wasn't really an issue of the OpenStack Foundation, which is sort of the last, I think it was the last slide I have, or second to last slide. The OpenStack Foundation is very interesting because it in a sense addressed a lot of these concerns in the way it was set up. So this sort of tripartite class structure was a reflection of, or an attempt to accommodate different interest groups, commercial and otherwise, that already had been forming around the project. So you had well-established companies, you had startups, and you had developers who were active in projects, generally working for these companies, but in a sense very much free agents. These were the kinds of talented developers that can easily move from company to company. So you have these different interests and these were accommodated in this three-part class structure of the foundation and its board. There were safeguards against so-called stacking of board members that were built into the foundation bylaws. And this is again to address the problem of undue control by any one company. There's a sort of elaborate separation of powers between the technical committee, which works in a kind of meritocratic fashion to control the technical operation of the project from the foundation board, which runs the promotional aspects and the IP management aspects of the project. So this kind of separation of powers is very unique and innovative structure, I think. It didn't really have much precedent. But maybe like the Eclipse Foundation, that was a case where IBM basically gave up power itself and evolved Eclipse from a project to a kind of multi-vendor participatory foundation. But I think much more so than Eclipse. I mean, it's a little too soon to say, but I think the OpenStack Foundation embodies a lot of efforts to address these kinds of concerns about inequalities or imbalances of power. The diversity of corporate involvement and the fact that it's under the Apache license is very relevant because it's relatively easy to fork a permissively licensed project, especially if participation is diversified, if you don't have talent that is concentrated in one company. So there is this kind of tension between the technical committee, in a sense, attention is not the right word, but sort of balancing of interests between the technical committee and the board that I think is key to how I think the foundation is going to be successful. So there have been concerns that I've observed, at least on the foundation mailing list, about aspects of how the foundation has been operating. So there were concerns about transparency or lack of transparency by the board. There were some concerns about the way individual membership, so actually at Red Hat, we were kind of critical of the open-endedness of criteria for individual membership. We had some concerns about that, but I understood that why Rackspace felt that this was very important. And in the end, I didn't really have a problem with it, but I think we're seeing sort of belatedly some developers who participate in OpenStack expressing some concerns about this because they're concerned about, I guess the issue is that statistics have shown that employees of particular companies tend to vote for their own representatives in the board elections. And I'll reveal it, I actually allocated most of my votes for Mark, so I'm as guilty of this. I'm an individual member of the OpenStack foundation, so I'm guilty of this myself, and I didn't think I was doing anything nefarious in that, but I understand the view, but the important thing here is actually that not that these concerns exist, but the fact that they're being discussed so openly, when in a previous period, this would have not happened on a mailing list. I've often thought, you know how the Apache Foundation says that if it doesn't happen on a mailing list, it doesn't happen. I've often thought that there are probably many conversations that have occurred around the Apache Foundation that probably should have taken place in mailing lists. And so I think that it's very healthy that OpenStack has this culture where these kinds of grievances or criticisms can be aired very openly and can potentially lead to reform. And so just to conclude, so what I've been saying is that I think that in the past five years, there's been a lot of very open exploration of what is the role of corporate participants in projects? There's been an open exploration of the problem of excessive single entity control over projects. And OpenStack is a product of this era. It comes out of this zeitgeist. It's problems and then it's successes illustrate many of these features. And I think the success of OpenStack, especially now that there's been this really nice transition from management by Rackspace to the foundation is really a model for future projects that have a similar kind of level of interest and level of participation by commercial entities. That this is really the right way to do things I think going forward. I mean, I don't know if we wanna have tons and tons of projects with foundations. I mean, that's something in a sense where we've been trying to move away from this kind of abundance of foundations. But I think the idea of attracting diverse corporate and commercial interests to a project, developing a kind of very healthy ecosystem with established companies and startup companies and then making sure that there aren't unchecked imbalances of power within the project, that there isn't undue influence by any one company, whether that's through licensing or through corporate governance means that this is really the right approach for a project of this importance and this sort of scope. And that is what I wanted to say. So thank you very much. Yeah, I've been sort of skeptical of that. I've given some talks on that subject, but I do think that it is, I mean, just based on what I see and what I see actually going on inside Red Hat and actually in my own head, I see some validity to this, at least for projects that are launched by corporations. I think that there's definitely that kind of trend going on. Actually, Mark influenced a lot of my views on it. Of licensing, do you mean? Yeah, I mean, I have thought about, like, for example, WordPress and Drupal. I think they come from an earlier era. I mean, that's basically my answer. Well, so my view is that I've seen open core sort of lost meaning once it became kind of a controversial issue. And I mean, recently, I don't think Sean Kerner is in the room, but he was here for some of the earlier sessions. He wrote an article recently, sort of, I think it was a plea to the OpenStack Foundation board not to make OpenStack open core. And so that kind of, I don't kind of accept that definition of open core. So to me, the key thing about open core is this kind of lack of equality or fairness so that one company, the business model is structured so that one company can use both the GPL and a proprietary license, much like traditional dual licensing business models. And everyone else is stuck with the GPL. And I don't think that the same problems that result from that exist when the open source project is under a permissive license. I think that's kind of a, I'm not, this is not an insight that I came up with, but I've heard other people express it this way. And I think that there's a lot of truth to that. The thing about permissive licensing is that every participant has the equal right to proprietize. So no one monopolizes the right to proprietize. And I think that's what keeps it in my mind from being at least the same kind of open core. Maybe it's a different kind of open core that's sort of a benevolent open core. Oh yeah, so yeah, that's sort of essential to the model. That there's one, that IP or copyright is flowing inbound to one entity. And so only that entity gets the right to be able to both license off or under the GPL to others and license a proprietary version to others. Everyone else is stuck with using the GPL. And that creates a kind of imbalance of power. I see it as an abuse of the GPL. Loic, who's in the back of the room, gave a talk at Fosdom earlier this year about GPL enforcement. The question was, is it ever, I forget what the title of the talk was, but it was a very good title. Something like, can a corporation force the GPL without being corrupt like my SQL? And that's like the best title ever devised for any talk. But that's kind of expressed as my view on the subject. That it's sort of, there's a kind of corruption that occurs when you have these kinds of business models that really perversely use, it's almost like taking the idea behind copy left and then doing a, which is described as a jiu-jitsu move and then doing a jiu-jitsu move on copy left. So kind of using copy left as a means of developing a proprietary software business model. That seems to occur when new projects are started by corporations, most of the copyright is gonna be controlled by the corporation even if they don't use these kinds of legal mechanisms to keep control. And sometimes it's an appearance of a problem. I think I've thought about this with Red Hat because we basically do not use these CLAs or copyrights. I mean, that's something that I have tried to make sure that we largely stick away from. We do, for legacy reasons in some cases. But still, I imagine that there's this signaling that goes on when Red Hat uses the GPL, do external participants think, Red Hat is trying to game the system the way so many other companies are. And so that's something that I've thought about.