Enterprises Play Dirty

All right. Well, look at us. Uh last uh presentation of the conference at least on this track and still we have more than zero uh people which is great. Welcome everyone. Um let's start. [cough] So today's presentation uh is titled Enterprises Play uh Dirty. And before we start um I will uh actually show you some disclaimers and not really the legal kind although it's that as well. But first of all I will be naming um companies I will be naming companies that uh uh are deemed to be not playing fair with the open-source community. And I want us to understand that there are lots of great people behind these companies. great engineers even great decision makers and it's probably not always it's not about a person it's more about the organization itself and sometimes the circumstances so um so I wanted to um I wanted to make sure that that we start uh with this uh with this uh thought it's it's nothing personal and the second one is more legal um this presentation could pure fantasy. Uh it's merely a product of my imagination. You know, facts that are presented might not uh be uh actual facts. They might be totally made up. I may even be insane. We don't know. Um but the first and foremost, no one especially lawyers should take any of these things seriously. And of course we are going to talk about licenses and this is not going to be legal advice. So um [clears throat] just as a short intro my name is Peter Farush. I'm the CEO of Perona. Who's heard about Perona before? Any Perona customers? Okay. So uh I'm the CEO of Perona. Previously, I uh uh worked full-time as a co-founder of Farad DB, which uh by the way uh was sued by MongoDB. And by the way, MongoDB is a trademark of MongoDB, Inc. This is very important stuff, ladies and gentlemen. Uh I've spent 15 years in the open-source database world. I'm uh Hungarian and uh I'm glad uh that I can uh present this talk to you uh today. So our agenda uh we'll talk about the bait and switch. uh we will have some case studies Red Hat, MongoDB and several other companies who changed the license at some point and we are going to discuss how it happened and what were the what were the general reactions from the community or why these changes might have happened. Uh I'm going to talk a bit about Perona and how the community can fight back and then we will have a conclusion as well. So let's start. Uh this microphone is very distracting but yeah I just don't have the right ear for this. Um [clears throat] so I think many as many of us would agree that for decades we lived in simple times. As for me, when I started using open-source technologies maybe like 20 years ago, my understanding of open-source was, hey, this is something free. This is something that can be used instead of um instead of buying a Microsoft product or buying an Oracle product or just generally committing yourself to something you don't even know much about. Uh for me, open source was the vehicle of my experimentations. you know this is how I learned a lot about databases about operating systems and I'm sure that on this conference we all understand uh what this means when someone started talking about licenses I I was not even interested because for the most part in my mind opensource is a social contract and the understanding I have is this there's a vendor or a community that starts that's building great software, maybe not so great software, but software. And if that makes sense for uh some use cases, uh then the community gets built up around it and and it helps building the software and advoc advocates for for the project and in turn everybody benefits from from this. Today it's not as simple and this presentation is pretty much about this phenomenon where as for me I no longer think about open source as something as um simple as these statements here because what is um really happening here. So for vendors, for those who wanted to make money or wanted a sustainable project because let's not forget in order to be sustainable, you somehow need uh uh flow of resources, money or or engineering resources or other contributions. But for most vendors, opensource is all about the bigger pie. So you create a bigger pie with the help of the community. you create something way bigger than you could by yourself. Um this could be a result of uh others contributing to your code or just the adoption which comes from the trust the trust that this is open source software and if there's a big enough community around it then then then it will be it will be uh something that you can you can you can build on in the future. And then these [clears throat] open source vendors would monetize a fraction of the pi. Um so of course with open source the expectation that I'm going to build something which is going to run on everybody's phones or everybody's computers or be part of uh every infrastructure around the world running XY Z is not realistic. The understanding is that if you market your solution as open-source, then you're going to monetize a small fraction of the eye. But that's fine because what you realize hopefully is that even your slice would be even the slice you can monetize would be way smaller than if the than than than if you um wanted to build uh the whole thing without the community and then you thrive. Then you monetize 5% 10% 15% of the users of of your solution and and done with it. This this is the this is the open-source way except that the part where you thrive is nowadays being replaced with trying to eat the whole pie. So if we look at uh all of these uh companies or some of these companies, what we can find is that um they were all pioneers of their own um of their own uh uh areas. they either provided something entirely new to the market or they provided an open-source alternative like uh like Mo uh to something that was widely available as a proprietary product which is great. However, when their followership, their market, their user base starts growing, they realize that, hey, if everybody uses our solution, if there are hundreds of millions of users around the world using our stuff, then how come we are not a 75 billion company? How did that happen? And this thinking slowly but steadily I believe pushes them into a situation where they might um they might uh part ways with their open source strategy believing that what h what is happening to them is not fair. that their their ability to monetize only 15% of their user base is not something that that could um that could put them on a trajectory which is sustainable. Now some companies are a bit more straightforward with uh this uh uh understanding. Let's look at Devicheria, the former CEO of MongoDB. And by the way, MongoDB of course is a registered trademark of MongoDB Inc. very important ladies and gentlemen who said we didn't we didn't open source it to get help from the community to make the product better. We open source as a premium strategy to drive adoption. And this quote is powerful because it allows us an insight into how companies and even startups like what MongoDB was back then think about open source in general and think about what opensource is good for from their perspective. So after such a quote we can't just say hey we needed to change the license because it was no longer sustainable. What we can say is that they willingly went into this whole thing knowing that open source is just a vehicle for them to drive adoption so they can pull the rug later. The problem with this premium model is that it almost always ends with broken promises. So the premium model um has been sustainable for some companies for six, seven, eight, 10 years, but at the end of the day it almost always ended with uh crippled functionality, a change of license, change of terms and uh and things which we in the open source community did not appreciate at all. So let's look at the first one, Red Hat. And this is this is uh uh I think one of the most interesting ones here. So when I think of Red Hat, I think of a company that pioneered open-sourcebased uh distribution and and and a business built around open source in general. So for many many decades uh the deal was simple. Red Hat led the way with their uh with their releases of the OS and then the community like uh uh CentOS or later Rocky and Amal Linux followed and it was a um a symbiotic ecosystem. Then in 203 in 2023 um after I think the IBM acquisition uh Rat had decided to uh uh to put the source code uh behind a pay wall. So they didn't technically break the GPL, they didn't technically change the license, but they effectively put uh the source code under a pay wall and made it impossible for uh community projects to build uh one-toone compatibility with uh Redhead itself. What's worse though is that their communication um has been uh drastically changing over the years where words like freeloaders and other stuff was mentioned which the open source community did not appreciate at all. So um what I believe is that Rocky or Alma Linux are not clones of Red Hat. They are choices for the community. They are choices for those who might have different needs or different environments or different situations that would make Redhead Enterprise not a viable solution. And yet um and yet uh Red Hat uh decided that this choice should be taken away from the community which helped uh building Redhead's reputation and products uh for decades. So this is uh this is a um uh a pretty uh interesting one in terms of the communication as well. So freeloaders were mentioned as a as a as a word. Um so companies like MongoDB or others would often claim that they are protecting themselves from hyperscalers AWS, Microsoft or or or even Oracle. But what needs to be said here is that these licenses and these actions would not just harm uh Amazon or Google. They would harm the independent developments and uh developers and the internal platform teams probably even more than uh a large company with a with a lots of uh with lots of resources. So open source is not a business model. What we need to understand is open source is not a clear-cut plan for you to get rich with a with a very uh easy way of distributing your software. Um if you need to change the rules in the middle of the match, that means that something is wrong with your thinking. It's not that the freeloaders, the community uh wanted to to do any harm to you. The second uh example I brought to you and this is very close to my heart. As I mentioned to you, Farad DB, my uh uh uh the company I'm a co-founder of got sued by MongoDB after this license change. So MongoDB's path is even more interesting and it's interesting in a sense that they are the pioneers of the license change rockpool uh strategy. So what [clears throat] happened here is that in 2008ish they started developing these revolutionary NoSQL database and uh they became the number one NoSQL database open-source NoSQL database in the world. And of course they felt that if they are the most popular NoSQL database then they should be able to monetize maybe I don't know 80% of the pie or whatever. Um so after lots of developers decided to trust MongoDB as a product MongoDB Inc. decided to change the license and it created and adopted the serverside uh public license which requires anyone offering MongoDB as a service to open or SSPL or or well open source their entire infrastructure stack management tools building everything that is required to run MongoDB as a service which means that well It it ended up not being viable for many companies out there who built their infrastructure and the foundation of their um applications that required a very different approach compared to Postgress or relational databases on MongoDB and then they ended up with something that is well source available at at best. But MongoDB went further. So in the initial months or even years, MongoDB uh claimed that that the SSPR license should be an open-source license. It should be approved by the OSI and it should be something that is as good or even better as uh legacy open-source licenses which is funny uh because uh it does not comply with uh any of the requirements that uh an open-source license should comply with in terms of um in terms of not discriminating against uh any specific type of workload or user and in this case the SPL license would do that. So the OSI did not accept the SSPL license but MongoDB maintained that SSPL is going to be the vehicle which is going to make opensource sustainable and the keyword is always sustainability. Now when it comes to MongoDB, it is now a 20 3040 billion dollar market cap company. So I think that we they are way uh uh far ahead of the sustainability question and still uh they release their software with the SSPL and unfortunately the MongoDB uh way of relicensing became the blueprint for uh some other uh companies. Um, and this is the fiction part. Um, so I wanted to give you some insight into how this works uh in practice. Um, so you would think that something that was uh licensed with an open-source license is something that forever belongs to the community, at least the latest release or or or the concept. But in 2021, we decided to build an open-source alternative to MongoDB that is based on Posgress. And we implemented um parts of the MongoDB API um to make posgress compatible with MongoDB workloads. And MongoDB's reaction was uh vicious. So they sent season disease letters to us uh and even some of our users even users who did not know about Farad DB but learned about it uh uh from the letter MongoDB sent them stating that they don't approve this whole thing and that they they think that Farad DB uh is illegal. So they dragged us to court on patent and trademark violations for Faradb calling itself MongoDB compatible. And meanwhile cloud providers like AWS or Microsoft uh and some others provided similar compatible products but they were not open source. So, MongoDB only attacked the one open-source project that implemented the API uh compatibility, which means that the their problem is probably more than just AWS or Microsoft. Um, my personal opinion is that their problem is that they want to monetize the entire pie and they don't want to let uh open-source projects or competing products to appear on the market unless these are sold by um companies like the hyperscalers who would otherwise be MongoDB partners as well. So this whole experience at least what it teached me uh is that going back to my one of my first slides um opensource is not the same as it was 20 years ago. 20 years ago I don't think it would have been uh a legal risk for you to implement an open-source alternative to something. I mean at at the end of the day this is how Oracle started. This is how lots of large companies started uh that uh later thrived on the alternative they've they've uh built. But this is no longer the case today. And another fictional part of this presentation is that someone suing you should not even be right. Their claims should not even need to stand in court because a billiondoll company is always going to be able to send you so many documents, so many letters that you will not be able to keep up uh if you are uh if you're a bit smaller than a 2030 billion dollar company. [clears throat] So yeah, that's about MongoDB. Um uh minio so as opensource users you would think that uh how you how you pick an open-source project as your next element of your stack would be uh the community response to it. Mino had uh close to 60k GitHub stars. It had lots of followers, lots of contributors, I think a billion docker downloads and numbers that are pretty impressive. And Mino as the company is also a member of the CNCF. uh I personally met uh sea levels from Nino uh on various different opensource conferences where they presented similar presentations as I do uh when it comes to their belief in open source and and uh and uh and uh and the way uh and that the way is open. Now unfortunately um Mo decided to transition its licensing model from uh permissive license to AGPL uh in May 2021 and they stated that the reason behind this is because companies like Nutonics and Vea uh they would violate uh their attribution terms and uh and that some of these products are actually wrappers around Mino uh uh itself. And and after the license change uh they started uh complaining about some of the users by name on their blog saying that they are ready to remove the Apach uh to revoke the Apache license from these users simply because they don't uh comply with the terms of the license itself. Now there is a huge debate on hacker news and other uh platforms on whether Mo is right or or not. One thing is for sure, revoking the Apache license, blogging about your users specifically is not something we did 20 years ago uh in the in the open-source uh open source community. um especially uh that this kind of legal shaming would not help the cause of Mino as an open-source project. So after this whole thing uh um um unraveled um Mino uh uh basically maintain the enterprise version and the community version uh in parallel but slowly and steadily started removing features from the community edition. So what was a full-fledged UI to manage your OB object store uh quickly became something very crippled on the community side and after I think a year or so they uh abandoned the repository completely and nowadays Mino is uh a product that is only available to you uh for uh uh uh after paying a proprietary license and uh up to uh you thousands of dollars in in in support and uh and and other costs. So if you uh built your um your stack on top of Mino, you uh definitely did not appreciate this change in in approach. The next one is the radius license change which is well I would say that's a success story from the open source community standpoint. Um so Radius abandoned the uh BSD license uh um a couple of years ago and it actually adopted the SSPL license stating that AWS is killing us that uh this is not going to work. hyperscalers are running radius without contributing anything to to to uh radius uh radius itself and they of course realized this after radius became the global de facto standard for in-memory data. This did not happen five years before. This happened when the pi looked pretty uh pretty big uh already um by by by all means. So uh after this realization, Radius decided to change the license to SSPL. Uh it was pretty much the same as MongoDB. If you ran Radius as a service, then you needed to SSPL your entire stack. and they upheld this belief that this is going to be great for them for I think a little bit over a year. And the reason uh this did not go on for longer is because something uh happened on the market and that that something was Valky. So uh the community was quick to to uh to react and they forked uh Radius uh creating Valkyrie which was uh um uh a collaboration uh between um lots of uh different vendors on the market large ones and smaller ones as well. Perona was uh was uh one of them uh from the get-go. Uh and the reason I told you that I think this is a community win is because if you think about it, this did not happen with MongoDB. It did not happen with uh I think successfully with Mino either, but it happened to Rady's because the Rady's community was strong enough to react this way and to fight back and to make sure that um that uh they are not going to be perceived as freeloaders who are now out of the game from uh the perspective of Radius Inc. Um so they added AGPL after seeing the success of uh Valky and there was a I think a huge market loss for them uh after the SSPL SSPL move. The the difference between MongoDB and ready is striking in a sense that they both uh adopted the SSPL license. They both named similar reasons as to why they are doing this but the reaction was completely different and it's most likely it's most likely different because the radius community was a lot stronger when it comes to MongoDB and contributions to MongoDB. I mean MongoDB CEO uh the quote from uh him earlier might have been uh true in a sense that MongoDB built a lot of the MongoDB code base whereas with radius there were a lot more contributions. So a lot more uh contributors felt uh familiar with the project itself to to to continue. So if we are talking about sustainability, if we are talking about how uh these companies uh want to be billion dollar uh market cap uh bahamoths on the wings of open source, we also need to talk about how the user is hurt in the process because we hear about how they want to make sure that AWS is unable to monetize everything for free without contributing pack. But what we don't talk uh or what they don't talk very often about is that if you limit the amount of vendors, if you limit the amount of service providers for a certain technology, you're not only of course monetizing a larger uh part of the pie, if not the entire pie, but you also uh hike up prices on the market. um uh there is a slower fragment fragmented innovation uh and because that you have less options for as a service then you as a user would also be logged into a single this might be clear to you in this room maybe it's not but the interesting thing is that if you search on SSPL if you search on uh these new open-source licenses that are to fix the cloud provider problem. You have actual open-source users who would say, "Yeah, this is fair. This is great. This is the only thing they could have done." Not realizing that they are on the losing side of the equation, that they have less options, that they have less choices, that they have less than what they had before. And it's such an interesting uh thing. Forking is also a a problematic thing because on one hand it's great that now we have Valky. It's great that we were able to fight back as a community. It's great that uh we did not let uh radies get away with calling the community freeloaders and and and and do this whole stuff without any any any backlash. On the other hand, it splits developer energy. Those who contributed to uh to Reddius would now contribute to Valky. Uh they might be accused of uh using each other's source code. There might be lots of uh lots of uh drama around what is happening in each community which is just a lot of energy. If we would be able to spend this energy on innovation instead of instead of um instead of splitting the community into several different pieces, it would be a better uh better uh word and also it erodess trust. So the next generation of developers, would they care to to contribute to someone's project knowing that this might end up becoming a billiondoll company who would one day call them freeloaders for using the thing they helped to create? I mean, this is not something that's attractive as uh as a as a a concept. So after discussing uh all of these different license changes or in the case of Red Hat uh some uh you know uh other creative uh ways of uh creating uh uh a world where there are less choices uh for users. Let's talk a bit about how not to become exploited as a developer. So this might feel like a naive or conservative take, but if you have a good idea, if you have this idea where you can revolutionize XY Z where you can come up with this revolutionary new database or or or or whatever that should be opensource and should be uh should be something that grows uh as an open-source project. The thing you need to make sure you don't do is don't plan and take investment with the promise of a million% growth. Because you could be the uh biggest believer of open source. You could be someone who really believes that open source is just the right thing for you to do. But at the same point, you're pushing yourself into a situation where you might not have the decision anymore. You might have an investor or uh several other co-founders or or just uh um you know a situation where you can no longer maintain your beliefs. And this is almost always coming from the fact that you don't feel that it's fair that the whole world is running on your technology and yet you don't have a private island. Um if you um if you take uh any of these companies, I bet that all of them were started with uh with um open source in mind as something that they are going to stick to. Well, except for MongoDB where there's an admission that this was not the case but uh to each of their own. So instead of trying to fight on what is fair, let's suppose SQLite, it's on all of your phones right now. It's running on everything you own your car. Well, high chance that your car runs SQLite and uh many other things that that uh would not need a distributed higherformance database. And yet SQLite is still uh an open-source uh project and still something that is free. Um how you can benefit from your own invention, your own innovation is that if you are the number one at supporting, stewarding and running the the product because the pi is bigger uh due to open source uh and you need to accept that you will not be able to to monetize all of it. How not to become exploited as a contributor and user. Uh and this is this is a strange one. Uh because I believe that these rules of thumb changed over the years because 20 years ago you could be reasonably sure that if there's an open source license at play and there are people who believe in open source then they will most likely stick to that and proceed accordingly. Um but as of today it is a complex decision and there are lots of factors at play. For example, if the opensource uh product uh is multi-endor that's well obviously a great thing. Uh there are lots of service providers for MySQL for example. you can't end up in a situation where um it's only this or that who would be able to run MySQL as a service and therefore create competition for each other and posgress is an even better example because uh when it comes to posgress even the trademark and uh and uh the teams are well not owned by one big single entity that is there for for profits and nothing else. Another great thing is if the technology is based on an open standard. So if you look at relational databases, most of them uh would uh implement the SQL standard which means that they can't be uh as materially different as for example how MongoDB is different from the market. In the case of MongoDB which is a trademark of MongoDB Inc. In case you don't know, that's a very important thing. Um, they love this Uh, so MongoDB is not based on an open standard or any standard whatsoever. Meaning that uh whatever they do is going to be driven by them. It's not going to be driven by multiple vendors who belong to a standard standardization committee. It's basically them and any alternative you come up with is going to have to play catchup uh for a long long time with MongoDB until until it becomes an open standard which hopefully it it will become. So if the technology you are eyeing is uh based on an open standard that's that's a big win has a healthy community around it. Thinking back of the examples I brought, um, Radius, if you were a Radius user, you still have a reasonable chance that you're going to be able to migrate to something that is open source because there was a strong community around it. there was willingness to change the situation and make sure that this is not going to be the end of uh the in-memory uh database that b they built their their applications uh on and [clears throat] last but not least if it's hosted by a foundation like Eclipse or CNCF or the Linux Foundation like Valky another uh uh um another uh factor where Valky is a good example then of course that can give you confidence that this is not going to be a decision of someone at the corporate HQ uh when it comes to the greed uh and and the pi. So if some of the above are not true then you need to assess your your migration risk. You need to make peace with the fact that what you have today that's not something you you you might uh have uh uh tomorrow and uh short shameless plug here uh but I think this is not a sales slide. So what Perona does uh most of you were familiar with the company is that we innovate on top of strong uh open-source projects. What we basically do is we take enterpriseonly features such as some MongoDB enterpriseonly features or uh for posgress uh TDE and uh well contributing to Valky itself or very traditionally uh contributing to MySQL for 20 plus years. So we take enterpriseon features, features that would have been used to take more of the pi and release it as open-source software, which means that those who were losing options could still get some of their options back because we are here to to um to work on opening opening uh things up. Uh, and last but not least, uh, and this is a public service announcement. So, I'm not sure if you heard about Oracle's different way of handling my SQL. As of lately, there were lots of layoffs. Uh, for example, there were uh changes in how transparent Oracle is when it comes to the future of MySQL. So we published an open letter uh that is uh that advocates for uh creating uh trade association for my SQL. If you would sign the open letter of course if you agree with what we uh want to do here uh we would really really appreciate it and thank you very much if you if you if you do that. we already have more than 500 uh signatures and we are aiming for uh a thousand. So we want to bring my SQL um uh to a similar foundation as what we have for for Postgress. So with that uh thank you very much for your attention today. I know that this was a long conference. I know that this was the last session. I'm also terribly jet-lagged because I just arrived yesterday. So, uh I'm hoping that what I said was uh interesting to you. And if you have any questions, please let me know. [applause] Okay. You were first. Thank you for your talk. Uh so my question is um if I'm understanding correctly, the elephant in the room and the bottom line that I'm getting from your presentation is don't trust open-source projects whose governance depends on a company. >> I would say that it's a bit more nuanced than that. I think that there are many factors as one of the slides uh uh elaborated on that. I think there are fundamentally uh you know good companies you can't tick all the check boxes some of the open-source projects you choose would be single vendor or some of them would not belong to uh foundation and I think this is all good as long as you understand your risks. I would also say there's nothing wrong with proprietary software. So we are sitting here talking about open source but probably we're using proprietary software in uh different uh uh uh instances uh different uh parts of our professional or private life and that's fine. Um transparency is is key. uh you need to understand how that project looks like in terms of the maintainer's vision for the future. If it's not part of a foundation yet, but they intend to donate uh it to a to a foundation, that's fine as well. I mean, as long as as long as you understand where they are headed and you're not blindly going into it, then then you should be you should be fine. I think you need to trust open-source projects. I would still want to continue living in a world where we have more trust towards open source than proprietary. I think the takeaway here um and probably it's hard to see that after all these negative things but the takeaway here is that uh you just need to assess your risks but open source is still going to prevail over anything proprietary especially for infrastructure. So, I've asked some version of this question at conferences a couple of different times, and I guess I'll I'll say it in a little bit stronger way here. I keep wondering when do we as a community come together and start putting pressure on the license endorsement organizations like OSI to say if you have a project and it's under an open-source OSI approved license but you have a CLA that allows you to relic it to a non-open license then that project is not open source and we will not endorse it as such. It's a great it's a great uh well question but more like uh more like a suggestion. What I can tell you is that I was not overly happy with the OSI as this whole thing uh unfolded between Farad DB and MongoDB. Um, I hear a lot of uh talk from the OSI on AI for example, but do we have open-source licenses figured out for now? I mean, is there any kind of enforcement? For example, if I say today that the SPL or the BSL license is open source, I mean, who's going to stop me? And unfortunately, if I have more money than you, then my voice could be louder than anybody else in the room. And this is what happened with the SSP license where if you ask some people uh they would still think that the SSP license is open source even though uh even though it is not because MongoDB called it an open- source license for many many years and their voice was of course amplified by their marketing budget. So I completely agree with you. So I think there's a lot of work to be done I think by the OSI because I want to believe that we can stand behind the OSI on this and we can still trust the OSI but um I don't think that there is enough focus agreeing with you here on whether the current system works whether the current licenses or the way licenses can be enforced or the way how licenses can be assumed assumed even though there are important details ignored as the CLA um I think there's more work to be done for sure. >> So um you have >> I see a red hat shirt. >> Yeah. And disclosure I work for Red Hat. So >> but you're a good person. >> You have Well, that's that's debatable, [laughter] but um you you used the term freeloaders with Red Hat a number of times. Um, who at Red Hat ever called the community a freeloader? >> I can tell you that. Um, the source I have is pretty much the community discussion around Red Hat. >> Okay. So, that term was used >> this is the I would not expect this sentence on a corporate blog. Well, the the thing is that term was used in an article by Slate and another article by uh the Register when Mike McGrath posted his his uh blog post about the split uh with CentOS. So, um I would just say attributing terminology like that to Red Hat is inaccurate and unfair. Uh and so, you know, do with that what you will. The second question that I have is you said that um Red Hat had put the source for Red Hat Enterprise Linux behind a a payw wall. How much does it cost to get to that source? >> I think that is not a public information, right? >> Uh it's zero. I if you register for an account with developer.red.com that gives you access to Red Hat Enterprise Linux and also the source code. So again that's that's an inaccurate statement as well >> and I fully own if there are inaccuracies and I had a disclaimer in the presentation as well. You know it's pretty hard to understand all the nitty-gritty details when it comes to at least five license changes or you know stuff like that happening in the open source community. But let me um um let me ask something. So why do you think there was an uproar in the community after Red Hat had changed uh its approach? >> Sure. That's that's a fair question. And the uproar was because being good community members, we released all of the source code including all of the source RPMs for our flagship product for years and years and years, >> decades. >> Um yeah, decades. Um, when folks stopped using that source code as a I want to tinker and I want to make it better, but instead changed it to I'm going to use the source code to compete directly against Red Hat. We tightened up our subscription agreement. >> What is the problem? What is the problem with competition in this? >> There's no problem with competition, >> but you just said that they use the source for competition. Um, we have asked community members multiple times over for over a decade. Um, you know, if you want to use our source code, that's absolutely fine. We would rather you not use it to compete against us. Um, if you want to do something different and better, do it. That's what the community is about. That is why every single product that we have comes from upstream projects to which we contribute all of the source code. But um when it became, you know, instead of it being people being in the community with, you know, best of intentions, it turned into um you know, we're going to take all the work that you've done and all of the integrations that you've done and we're going to make it so that you don't get paid for all of that work. I don't think that that's reasonable. And in fact, if you read the GNU free software manifesto and there's an article on GNU.org that says, you know, the the assumption that you made about, you know, you're supposed to take a tiny slice. Read the documentation on the GNU website. It says the idea that, you know, you're supposed to make a minimal amount of money off of free software is a misconception. And in fact, the GNU Foundation says we recommend that folks make money off of open source so that they can continue to contribute. That's what we do. So would you say that there is uh there was less adherence to the license over the years and this is why redhead change >> well the license is the GPL or the Apache software foundation license or whatever >> those are the terms right so there's no other >> the commercial terms for a subscription are not related to the license if you get a subscription for developer.redread.com redhead.com at zero cost and you download the source RPMs and you distribute them. That is absolutely legal. That is not anything that we would say, you know, you can't do that under the terms of license. >> But then why the uproar? >> Uh because people stopped getting basically free rebuilds of a a Red Hat Enterprise Linux and we said, "Hey, we're doing the work. I think it would be really cool if you actually paid for the work." And um and again that is in accordance to free software foundations documentation. That's I mean they're the the earliest you know free software organization out there. So uh but people got upset because they weren't getting free stuff anymore and I get that to be clear. I get that. But you know with CentOS stream you get exactly the same build except for some minor version number differences. uh with Fedora you get what's coming in Red Hat Enterprise Linux all of those are freely available from Red Hat sponsored by Red Hat funded by Red Hat. So the this this whole this whole like oh you're you're obuscating the source code. No 100% of the source code for everything that we do is upstream. That's how we work. Now the integrations for some of the products that we do um that's not source code. That's how we build the products. That's not something that I think would be reasonably expected to be like, hey, give us give us your build system and your integration points. That's that's not what that's not part of the open source license. >> Well, what I want to say is first of all, I think that the community's opinion and I can only go by that would veer towards the understanding that I presented. Now you are you have a different understanding working at >> I'm biased. I'm the first one to admit >> you you might be biased but you might also be more knowledgeable on the actual mechanism that needed to be fixed in connection with whatever was right for Red Hat. What I would suggest is to be open about these points. >> I don't know how much more we can blog about it. I mean ser talk about [clears throat] the developer subscription. It is free you know zero cost. Um you can get rail today for free and run it on like 16 machines. >> I don't know I'm not part of that. as someone who was around when Linux just started um and a lot of the open- source licensing was just started um my uh singular observation as as opposed to a community observation is that uh I was very surprised that open source worked because in the United States it's a very capitalistic market. So I'm amazed that we've gotten this far and I think it's fantastic. Um, the one thing I've noticed with entities that uh have built uh a their livelihood off of some type of open-source model is they usually wind up coming into some kind of financial dire straits that forces them to change their ideals into something more businesslike. And um I think that that's what you've seen with Hashi Corp trying to change their license. Uh Red Hat, I mean that they started off as a service company and selling selling Linux on CDs and distributing those CDs and making money just on shovelware, so to speak. Not not saying that you're shovelware, just the ser the the the stuff. Um so it it's I the thing to keep a look an eye on in any open source model is how is that company doing and you know did they start with a good business model and are they willing to to stay true to their principles in that business model. I think you're Yeah, you're exactly right. And the license change is uh always I I don't think it ever stems from a belief. Hey, we need to change the license. Hey, we need to part ways with open source because we no longer believe in it. It's usually a financial or acquisition or investment related action more often than not, which is unfortunate. But as you said, the reality of running a running a business, I think the big question is uh can it be done in a way that is more honest with the community and maybe less disruptive? Are there ways to go into it easier and and uh and leave some some opportunity for the community to uh react like Valkyrie did for example. Um um I think uh you know there there's there there are always two sides. And I'm really happy that I'm not sure what your name is, but I'm really happy that you Thomas I'm really happy that Thomas uh came here and and and uh and um discussed uh his viewpoint. Probably not red hats uh but uh [laughter] disclaimer but but his viewpoint. Uh Sam, >> so uh the only the only uh observation that that that I have is that is that um yeah, I mean there were many people in the community who who would have liked Red Hat to have continued their their model that they've had since in inception of having um the having everything open sourced as well as having commercial services to improve their financial outlook. It's only when uh I think they were they were put under management of IBM that that's sort of changed. Um I don't know is if that was because of management of IBM. Um but >> I can just say that IBM is very hands off. >> Okay. But this sort of changed your the business model of Red Hat changed after >> we still provide open source software% openour. >> No, but the way the way that the way you have done business has changed we still offer exactly what we did when we started open. >> Okay. Well, I'm just meant to say that there were a lot of people in the scientific software development community who have changed from using Red Hat to now using say Abuntu uh because of the change. >> Were they using Red Hat or they using >> they were using a mixture of of both um mattering on what what it is where they have where they have it had it installed. Um but looking looking forward for for more so for the database uh community, it looks like Perona has done a lot of development with databases. Um, do you do you foresee that that developers will have a stake in keeping keeping a lot of the uh standards open and keeping a lot of the um the databases open uh going forward? Or do you foresee that uh because of the financial success of companies like that things will change uh uh in a negative way. >> I think it changed in a negative way and that's why this presentation uh uh is is uh uh you know the one I present. On the other hand, I think we might have gone to an extreme with the platforms at this point and how I see it is that more and more users realize that at least they need something hybrid if not onrem or a private cloud which means that there is appetite for open there is appetite for uh open-source technologies that would that would uh that would uh uh run uh their infrastructure. So I think that there is a lot of hope for open source and I think if anything these actions showed us what happens if a decision like this is made and what can the community do in case this happens. Valky is a very good example where as as you you you uh uh brought it up uh developers could do something about it and did something about it and ultimately the actions of Rady's the company that actually made that decision. Uh changing back the license shows that they might also agree that this was not the best uh decision they could have uh could have made which is a great thing. This is this is positive. This is a learning. This is something that we now know is possible and this is not um not uh impossible I mean to to to react. >> Thanks for the very interesting talk and the discussion. Um is there a risk that we perfect is the enemy of good in a way right? Um I think there's two there's two sides to this, right? On the one hand like contributions from Red Hat is probably better than um something that's completely closed sourced. On the other hand, we need to keep these companies accountable and say okay if you if you change the license or you change the deal if you rock pull the community like this that you know you can't do that. That's not good. So we we need to keep we need to balance these two things. And um I yeah that's just I'm not I don't know if you have how do we thread this needle basically? Well, I agree with you and uh Thomas is here from Red Hat who I mean I'm I'm really happy that there is a discussion because this is how improvement happens. Um I did not have a lot of fruitful discussions with MongoDB for example even though I had many and uh you know it's it's great to see that uh that uh some of these companies would engage in conversations with community. I totally believe from the redhead perspective that there were reasons. There are always reasons. Nothing like this would happen without a reason. The question is could this uh be done some other way in a way where the community also understands what happened and why and you might have blogged about it a lot. I mean not you but Red Hat maybe maybe it was you as well. >> Yeah. I I would I would also say that you know remember that community is a two-way thing. Um, by that I mean, you know, Red Hat, we contribute tons to the community. You know, I mean, they're paying for me to be here to teach people how to use open source and not Red Hat open source. I I always use freely available, completely, you know, open source stuff when I when I presented these. Um but you know when somebody who is a member of the community says hey guys you know repackaging our stuff and then you know saying that you're exactly the same when you're not but then you know saying you don't have to pay Red Hat for all the hard work that you that you've done. Um, can you like can you understand why that would be frustrating for for a commercial company? Like, hey, all this work that we've done and we've given the source code away for free forever even though we're not required to except for our customers. Uh, and then for us to say like, hey, you know, stop doing that, please. And the community th those members of the community saying, no, screw you. We're gonna we're going to do what we want even if it hurts you financially. um that you know that to me is a violation of community trust trust as well. Hey Red Hat, I know you've done all this really cool stuff, but you know we're gonna we're gonna make it so that you don't get paid for any of that work. That's not positive community interaction in my opinion. And to be clear, I'm not speaking for Red Hat. I don't speak for Red Hat. I'm just a community member doing presentations here. >> No. And thank you for your viewpoint. I think uh you know you're right that the community is a two-way thing and it's predominantly it's supposed to be a collaboration on the outcome. So if red hats well let's suppose this is redhead's position is that the rest of the community which redhat is a part of was not working towards a common success then obviously that's a problem that needs to be addressed. My question here is that was there enough discussion or was there a visible discussion that was able to solve this issue before anything happens? And to me it sounds like that discussion did not happen or not happen in a way that was enough to to um prevent the backlash. A and that's all I know. Um it's a good sign that there are two way discussions just like this one here. And you know if I can have one request for you please do a presentation on the red hat position on this. I mean it it it might be one of the most interesting you know uh decks I I I would expect here. >> I've known Thomas Cameron a long time. You just Thomas Cameron to express his opinion on something athletic and he will >> I I did not notice such a thing. [laughter] >> All right. Well, thank you very much everyone. Nice.