We're getting close to full, so just filling seats in the middle, defragmentation would be nice. Just in case people come in late, we can direct them to a seat inside if I may put a stand. If everybody would just shift over a little bit to your left.

Yeah, that way. Because we let people off dial so they don't have to cross the speaker. Alright, so I am going to introduce our next speaker. My friend Eileen Evans is vice president and deputy general counsel at Hewlett Packard in

charge of cloud computing and open source. And before she went to Hewlett Packard, she was, I guess not immediately before, but for many years she was at Sun Microsystems where she had a lot of experience in Sun's involvement in open source software. And she's going to talk about licensing models and building an open source community.

Thank you Richard, appreciate that. So my role at HPE is a little bit unique in the sense that I lead our open source program office. I'll speak up. Okay, thank you for letting me know.

Continue, if you let me know if I don't project well enough. Can you hear me now? Okay, I'll try to speak louder. Okay, so my role at HPE is a bit unique in the sense that I lead our open source program office, which entails like compliance and our external outreach and community engagement,

as well as leading legal support for open source matters. I also lead legal support for cloud, but in terms of open source, my role is a bit unique within the company. And before, I've been leading open source now at HPE for a couple of years, and I've been with HPE for three years. About six months after coming into HPE, I had an opportunity to transfer into the

business and do a business role for six months. And that role presented itself in the cloud organization. And it was at that point in time when HPE was deciding to go with OpenStack as its cloud offering. So I had the opportunity to participate in that decision-making process and then transfer over to the business to do a six-month rotation into the business to really help

drive the community engagement and drive our participation in OpenStack. And for me, it was a great learning experience because prior to that, my role at Sun was in the legal department. And so I had really looked at open source before that, primarily from a legal lens.

And I'd been with Sun for nearly 12 years and had a great experience there, working with all kinds of open source projects from Java to OpenOffice to OpenSolaris across the gamut, MySQL. So it was a great experience, but I'd always sort of looked at things from a legal lens. So for me, transferring into the business, I think, gave me a new perspective on and

definitely broadened my horizons for the way that I look at open source and the way that I engage with communities. So for me, it was a great learning experience and it helped prepare me, I think, for the role when I had the opportunity to take over and lead the open source program office. So the topic today I'm going to discuss really is around licensing models and building

communities. So it's kind of tying those two areas of my experience together. And I'm going to try to keep the presentation part fairly short because I actually do want to solicit input from you guys. So heads up. So from an agenda perspective, I'm going to talk through sort of what I think at a very simplistic level what you need to build a vibrant and successful open source community

and then talk about, you know, the open source license and what role that plays in building a community. And then I want to kind of look at the lens of the landscape, and I know this is something that Bradley spoke about earlier, really sort of looking at the permissive license and how we're starting to see more projects as permissively licensed projects and see what impact that has and how that's shaping out.

And then also I want to solicit input about what your thoughts are in terms of sort of why that's happening as well as the potential impact of that longer term. So at a very simplistic level, I believe there's three critical components to build a successful and vibrant open source community.

First and foremost, I think you need a great technology. I also believe you need sound governance structure. And that's something we spoke about yesterday in the panel, the governance piece of it. And then third, I believe that the license also plays a role in that. You need a license that is perceived fair and perceived favorable within the community as well.

I mean, I recognize that these three are not created equal. I mean, clearly technology is the one that is key and the most critical component here. Because without a great technology, the governance model and licensing model are essentially irrelevant. With that being said, I do think that the open source license plays a role

in helping to build a community. It plays a role in adoption. I think it has an interesting role within that whole ecosystem that I want to talk about. And so for the purposes of this discussion, and I'm going to tee it up, and I realize I'm going to grossly oversimplify licensing models. And I'm going to grossly oversimplify them to all open source licenses

are either copyleft or permissive. And by copyleft, I mean you have a contractual obligation to contribute modifications back to the community. And in permissive, you don't have that contractual obligation. So I realize it's a gross oversimplification, but just bear with me as we talk through this because I do want to get some good feedback out of this.

So that being said, can a permissive license be used to build an open source community? The interesting thing is I was grappling with this question about ten years ago when I was at Sun Microsystems. I had the opportunity to help lead our efforts in open sourcing Solaris.

And Solaris was Sun's operating system. And it was a really key and critical piece of technology for Sun. And at the time that I was grappling with this, I mean one of the business things that we wanted to accomplish there is we wanted to build an open source community around it. So that was one of the objectives in open sourcing. It was to build this community.

So we recognized that the licensing model would play a role in that. And at the time, I was really struggling with this question. And I spoke with a number of open source luminaries. I spoke with other lawyers. I looked at what was happening in the community. And I came to the conclusion at that point in time, ten years ago, that you could not use a permissive license to build a community.

And maybe, you know, I recognize I hadn't been practicing law that long at that point in my career. So maybe I looked at things from more of a black and white perspective. But that's what I believed at that point in time. I believe that you really, in order to build that strong, vibrant community, you needed copyleft. And so I came to it from that vantage point.

So then I've been struggling with this question recently. And thinking, is the same, you know, if I look at this question today, do I believe the same thing? Do I believe today that a permissive license can be used to build a vibrant open source community? And I think in order to answer that question, I started thinking about, okay, well, how can I help, you know, navigate this and answer this question?

And so I started speaking up. Okay, thank you. Speak louder. So in order to help answer that question, I wanted to look at sort of what was happening in the licensing model ecosystem in general. And then also what was happening in terms of vendor engagement with those open source projects. And then thirdly, what was happening in terms of contributions to open source projects?

So I was kind of looking at all of those in order to help me understand and better answer this question. So in terms of what's happening within the licensing landscape ecosystem in general, what I saw is I started looking at various survey sources. I looked at BlockDoc, Flosmole, and Google Code.

And what I saw was pretty interesting. Even though those three survey sources all used, you know, different methods, statistical samples, what have you, they were all to me either showing and demonstrating or supporting the same general trend that I thought was happening within the ecosystem, which was there was an increase in permissively licensed projects.

So again, what I was starting to sort of hear through anecdotal, starting to see was sort of, it was supported by the evidence as far as these survey sources as well. Now I recognize that, this is not to say the GPL is going away anytime soon because it's still, you know, in terms of absolute numbers, it's by far the clear winner.

However, I did find it an interesting trend. And so I thought, let me dig a little bit deeper and find out, you know, what else I can glean from this in order to try to help answer these kinds of questions. So in terms of, this was Aaron Williamson showed this at a recent Linux event. And I found this interesting as well because, you know,

on the GitHub part of what are these projects. And again, it's sort of demonstrating that we're having more and more permissive licenses out there. And there's sort of this increase in that. How do these figures account for forking? Can I take the questions for the end? Okay, thank you. And the next thing I started looking at was vendor engagement with these open source projects.

Because, and again, these statistical samples aren't great, but I was looking at 451 Group and trying to just, again, grasp a better understanding of what was happening in this ecosystem. And what I saw was, you know, there's this gradual shift in strong copyleft in terms of vendor engagement with these projects.

Gradual shift up until around 2006. 2006, 2007, we start to see a pretty sharp decline in the hard copyleft licenses in terms of vendor engagement. And around the same time period, this 2006, 2007 time period, we start to see a more significant increase in terms of permissive licenses

and in terms of vendor engagement with these projects. Can I ask you, what's the, what's the Oh, it's hard to read these. This is, oh, we have number of vendors and then those are the years. So I have a small, I apologize, a small graphic. You have expressed a, one of these preferences. Yes, in terms of, yes, preferences in terms of participating with projects.

Yes, exactly. So what do the vendors prefer to engage with? What kind of projects? Yeah, thank you. And a small font, so from the back, I apologize. And then the third thing I looked at was contributions. Contributions in terms of how are developers and companies contributing to these projects. And for the contribution piece,

I looked at a very small sample. I was looking at, trying to get, create, look at some of these similarly situated projects that are new open source projects. So what I looked at in this case was three cloud projects, similarly situated cloud projects, all open source. I looked at OpenStack, CloudStack, and Eucalyptus. So OpenStack and CloudStack

both permissively licensed. Eucalyptus Copyleft. A caveat and footnote is, is CloudStack actually changed its licensing model in 2012 from a Copyleft model to a permissive model. And so as I was kind of digging around that, I also found some interesting statistics around that, which were that the number of contributions

and the number of contributors, particularly the number of contributors, there was a pretty significant increase in that year and a half period after they made the licensing model change, which kind of was contrary to what I honestly expected. So it was interesting. From that time period, it went from 50, approximately 50 contributors to 250. So a significant increase there.

And then with respect to Eucalyptus, it's kind of what I would have expected 10 years ago and it's what I expected now, which is basically that when you have a Copyleft project, you do have contributors and you do have that sense of community and you're building that collaboration and you're having the contributions back and you can witness by the number of commits, et cetera.

With Apache, the Apache 2.0 for OpenStack, this was the one I found really interesting because I'm very involved with OpenStack. I got involved with OpenStack pretty early on within HP and I had the opportunity to help set up the OpenStack Foundation and then I participate as a director on the OpenStack Foundation board as well.

So this one I'm pretty familiar with from the technology side, but for me it was interesting to look at this from the contributor perspective in the sense that I was, quite frankly, just somewhat amazed by the number of contributors, the number of commits, and lines of code contributed here. So again, it's not what I had expected. Instead, because if I looked at this

from where I was looking at the lens that I had 10 years ago, I would have expected that the numbers would be much lower because I think that's one of the things that, you know, when I was, quite frankly, at Sun and we were open source at Solaris, that was one of my concerns. I was concerned that if we, you know, put the code out there under a permissive license,

that we wouldn't build a community, we wouldn't get the contributions back. But I think this sort of shows that it can indeed happen. And I think I'm going to make a, you know, again, this is going to be a very simplified conclusion here, but I want to open it up for dialogue and I'm going to get some feedback on this.

So again, looking at the question I asked 10 years ago, today I think I would answer the question differently. And it's, you know, OpenStack is one single example. I recognize there's many, many open source projects out there, but for me, I'm looking at it through this lens and trying to make sense of it all. And I think, again, going back to the original one of those components that are needed, you obviously need a great technology,

which OpenStack is a great technology. You also need sound governance structure, which I think the project, they took that very seriously and created a very sound governance structure. I think it was a sound governance structure before it was turned over to a foundation too, to be honest. I mean, I think Rackspace did a number of things right in creating a project policy board and creating that technical meritocracy around the project.

But nonetheless, I think under the foundation, it is a sound governance structure with, you know, you've got a foundation, you also have a technical committee that really does run the technical piece of the project. And then the licensing model, I think, helped drive that adoption. But nonetheless, I think permissive license

can be used to build those kinds of projects and to drive that. So this is my last slide, but I do want to go back to a prior slide when I open it up for questions. But I think you had a question first. I'm sorry, first row. Apologize. I was just asking about the slide with the... You want me to go back to that?

Yeah. About how it was counting forks. Was it counting all of the forks of a particular project as one, or was it... Yeah, I think it was doing the top-level licensing. But the other thing that I remember from that survey as well, which I thought was interesting, because a lot of the projects on GET, my understanding is initially they weren't licensed at all. So what they did was they tried to compile,

and it was a smaller percentage, right, because they took a survey sample of those, and then what they tried to do is get the highest-level license, but it doesn't account for that, so no. So I mean, there's probably that piece of... And then what you were talking about with compatibility and sort of the licensing pieces of it, I think there's multiples of those. And Richard, I think you had a comment there. I think that was taken from Aaron Williams.

It was Aaron Williams, yes. And if that was the data that he did using Fossology, I think someone asked him the same question about whether this accounts for forks, and I don't recall the answer. You were at the talk as well, right? He said he did have some stuff to account for forks. Okay. That was his answer of what we were asking. Oh, okay. So, okay.

Great. I was just like, again, for me, I think it's new, and it's interesting, the shift. Bradley, do you have any comments in light of your talk earlier? I mean, I'd love to hear what you'd say. So I mean, I think that your talk sounds to me almost like you're making a defense of, yes, you could do a commune with permissive licenses, which I think is accurate.

I think that anybody who says you can't is in error. So I don't... Well, I believe you couldn't 10 years ago. I mean, that's, you know... Yeah, I mean, I think, my argument would be I think copulab builds better communities because it's a better constitution. I sort of see it, if you want to talk about governance, I see it that permissive license, like the Articles of Confederation, and sorry to be U.S.,

but like the Articles of Confederation, which was a very loose thing that was abandoned by the United States in the early days, and the U.S. Constitution much more like the GPL. It's a stronger binding force. Well, that's interesting. But it is an interesting one, yeah. Because the Article of Confederation was too loose. That's the point. It just allows, it allowed the states to do whatever they wanted,

sometimes bad things for the whole country. That's my point. I guess this analogy doesn't work. As a developer working in a GPL project, the people who take our project and then make their own products on it are required to push the source,

perhaps on the website or patches or things like that. They're not required to try and upstream them. The fact is that in practice, the thing that drives, in practice, the people in the core community don't go and take those patches and upstream them themselves, and the thing that draws the vendors from the patches is actually having to rebase to new ones.

Right, so that was my question too, because that's what I was thinking, was driving a lot of this is the technical debt. To finish what I was going to say, was that in normal kind of everyday when things are not going well, when things are not going well, functionally BSD and GPL essentially act the same. So the only difference actually happens

when things kind of go to hell, and there's a big difference of opinion, then if people want to, they can actually take the patches and upstream them themselves, or not. Does that make sense? That does make sense. So let me ask you a question.

Do you think a big piece of this then is because of that technical debt? Because in other words, it just makes it easier to contribute it back. Yeah, so basically the technical debt, as far as in my observation, people can disagree with me if you want, but in my observation, the companies that have, you always, if you don't have a product,

you have to do local patches because you need a new product, right? You have to meet your specifications. The thing that forces you to upstream that event is the technical debt you're basing. So it's, I don't think, in my project, I don't think I've ever seen someone from the community take a patch set that was published by someone

and upstream it themselves. It's always been the people who wrote the patch themselves are streaming it because of the technical debt. Also because of personal commitment to the open source way. Yes, yes, yes. Okay, thank you. I've asked myself if you could do this comparison.

I mean, if there is a vendor who has money and who's going to support the open source trend and trying to benefit from it, that they are, of course, putting a lot of money and building up a very good project infrastructure

and this is also very attractive for developers. And I think the most developers are not really thinking of the exact license term. They are thinking more about the technology and I think everyone has a bit different

motivation and I think when the figure of, let's say, a project with permissive licenses is rising, then it's more related to, let's say, the money which vendors are putting in open source technology.

That's a good point too. Okay, thank you. Regarding vendor involvement, we took another variable. This is basically what you say, the education of the project community, the education of the experience of the project vendor community. So if you look at IT, I would say, many users are well educated right now.

They assess open source well and they know what the value of this is. If you look at different communities, for example, the industrial world where I come from, it's a bit different and then people are more conservative regarding what they do and what they reveal, what they publish. So in this area I see the high value

of popular licenses that they remind, at least, the users, the companies who are using it, that they have to think about how to deal with this thing, how to use their own changes. They have to review it anyway and I often receive this kind of feedback, well, we have to publish them anyway, so why not work the upstream? Yes, okay. So now we may also do the upstream.

Right. So this is a kind of a reminder, basically, that this helps in this area. There are areas where we know what to do. Great, thank you. I have a feeling that not just, you said moving through missing licenses, why that's happening. Yeah, that's it.

I'm curious about that as well. I think it's very easy for developers to start a project and do a MIT or BSP because then you can just use the patch rules with some other license without having to be bound by the license. Oh, that's interesting. Okay, okay. Is that sort of well thought,

I mean, is that the common understanding, do you think, in the developer community? Because that's the thing that I find interesting. The company I work for, we did a project in MIT license because the partner we did it with might not be trusted. So maybe we just fork away or just move away from it and then have our own project.

Maybe post-source it even. Sorry guys. So I think it's just, Permissive also gives the permission to do whatever you want with it. Right, right. As a company, but also for the developers. Okay, thank you. That's very interesting, thank you. I need your five minutes. Oh, okay. Kevin? Sort of related to that,

I'm curious how this plays out over time because I think there are certain trends and different understandings in different communities about licensing and I was wondering if you looked at sort of this community growth over the life cycle of a project and maybe like, you know, compared because we looked at particular years for a particular project.

So I'd be curious to see how it played out over time. Yeah, I think that's a really good point, Karen. That's something I thought about as well. Like how, because I recognize like right now using OpenStack as a single example. Right now, you know, it's a very popular project. It's doing quite well. The community and everyone is getting along, right? I mean, what happens if that somehow at some point in the future that's no longer the case?

It's like, then I start to think, okay, how would, you know, how it plays out because it's under Apache versus if they had licensed it under a different licensing model. How would that play out long term? And that's something that I'm, you know, very interested to kind of see how this all plays out. But again, I kind of look at it from the perspective of,

you know, hindsight is 20-20. I wonder what we're going to see, you know, five, ten years down the road. But it's a really great point because I've thought about that quite a bit. Bradley, you can make a comment about that. Well, yeah, and also because both Aaron and Fontana said my last comment was weird and crazy, so that analogy doesn't work. But I thought of a better way to,

a concrete example to explain it. I think when you're talking about core, what developers consider the core application, I think there's not much difference because of the point you were making over there about the not wanting to rebase. But most software systems these days have some way of putting add-ins of some sort that aren't part of core, plug-in architecture or something like that. And that's where Copyleft really has value

because that's often a different community. So you have the core community, which OpenStack has as part of the OpenStack foundation and so forth. But I know OpenStack, you can do add-on modules and so forth. And that, I would expect, this is pure speculation, that that community will slowly be a slightly different community. And that community will be one mostly of proprietary add-ons, whereas in OpenStack or GPL,

those add-ons would have to also be GPLed. So while your main community, the core community, may hum along just great indefinitely, the plug-in community may become a proprietary ghetto. That's an interesting point. So are you trying to say there that license is the best force in the market to keep the community together? Well, but to keep those ancillary communities, right?

I mean, firewall used to talk about this onion of Perl, right? And Perl was GPL. So do you know that OpenStack has other forcing factors that help keep our community together? I don't know, but I've seen it fail in other permissibly licensed projects. But I don't know specifically enough about the OpenStack community, say. What do you think? I think if people have enough incentives to be involved in the community,

there's so much going on here that being inside the community, it's just... But you can be both at once, right? You could be developing, if you have a good separation of APIs, you could be off writing proprietary plug-ins and be part of the core community simultaneously. Yeah, but we don't encourage that behavior necessarily, but it's not, we don't use the license. Everybody, many companies are already doing an OpenStack. You know what I'm saying? Don't keep the APIs stable.

Yeah. That's what LVM says, too. I'm skeptical. What drove OpenStack to allow it to become permissive? Well, it was actually before my time, but I can tell you the history. I'm out of time. Two minutes. Why don't you repeat the question before you do the answer.

Okay, the question was, what drove OpenStack to choose a permissive licensing model? And it was before my time, before I got involved in the project, because they actually open sourced it in July 2010, and it was a joint project between Rackspace and NASA, federal government. And they actually chose, the reason they chose Apache is because they wanted to drive adoption.

And they believed by choosing a permissive license model, it would enhance and drive adoption and increase that. So that was the primary reason. At least that's what I've been told. Actually, so there was another reason. There was a lot of criticism of Pucalyptus at the time, I remember from giving that talk at the OpenStack summit last year.

Pucalyptus, would you add on that slide? Pucalyptus had GPLv3 and a model controlled by one company. The predecessor of CloudStack was very similar, used GPLv3 initially. And I think OpenStack wanted to distinguish itself from these companies that had business models that were being heavily criticized at the time,

what were called open core business models. So I think that was part of it as well. That's an excellent point, Richard. So it was partially reactionary as opposed to being done on the merits? No, it was a political act. I would say progressive because these uses of GPLv3 by, I mean it's related to that point that the 451 group made

about single vendors, multiple vendors engaging in projects under permissive license. Pucalyptus was not a multiple vendor project. Neither was CloudStack or cloud.com. These were very much controlled by one company. I mean Rackspace had that role to some degree in OpenStack, but it was evolving towards a multi-vendor product.

And I think that was what their goal was on some level. So we're out of time, but let's let Eileen get the last word because it's her talk. So do you want to sum up or anything? Thank you.