Relicensing: When Your Open Source Tool Turns to the Dark Side
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 39 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/67234 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS Backstage 202212 / 39
2
9
11
15
26
30
36
37
00:00
Open sourceDoubling the cubeGoogolElasticity (physics)SoftwareOpen setServer (computing)Strategy gameRevision controlBlogFraction (mathematics)Programmable read-only memoryWeb pageDependent and independent variablesField (computer science)NeuroinformatikLatent heatLocal ringOpen sourceElasticity (physics)Projective planeObservational studyCASE <Informatik>Sound effectSelf-organizationComputer configurationCore dumpLogin2 (number)State observerDatabaseRevision controlDifferent (Kate Ryan album)Stack (abstract data type)HypermediaZoom lensPhysical systemLine (geometry)Right angleSoftware developerWordAnalytic setPoint cloudMathematicsFlow separationOSI modelMessage passingDuality (mathematics)Multiplication signComputing platformSoftwareOpen setCodeLibrary (computing)Client (computing)Computer animationJSONXMLUML
07:33
Open sourceDuality (mathematics)Axiom of choiceCodeCommunications protocolPoint cloudProduct (business)Elasticity (physics)Distribution (mathematics)FAQModul <Datentyp>Mach's principleScale (map)Revision controlCapability Maturity ModelClient (computing)Open setLattice (order)Elasticity (physics)Open sourceProjective planeDescriptive statisticsLoginMessage passingCodecRemote procedure callComputer configurationSinc functionLibrary (computing)Client (computing)Revision controlMathematicsData loggerState observerBeta functionCodeControl flowSoftware maintenanceCASE <Informatik>Open setVirtual machineObservational studySoftware developerGame controllerZoom lensNoise (electronics)Military baseFront and back endsVulnerability (computing)DialectGastropod shellService (economics)MereologyCartesian coordinate systemStack (abstract data type)Domain nameSpherical capConnectivity (graph theory)GUI widgetCentralizer and normalizerOperations support systemGoodness of fitBitAdditionElement (mathematics)Beat (acoustics)SequelForcing (mathematics)OracleWebsiteOSI modelMusical ensembleRight angleLine (geometry)Server (computing)Metric systemComputer fileProcess (computing)Computer animation
16:26
BlogGoogolCodeComputer networkSoftwareLink (knot theory)Exception handlingWhiteboardEuclidean vectorRevision controlLoginProjective planeTracing (software)FreewareKey (cryptography)Elasticity (physics)Term (mathematics)Sheaf (mathematics)Sound effectSoftware developerSI-EinheitenComputer networkSource codeProduct (business)Service (economics)Software as a serviceCore dumpConnectivity (graph theory)Open sourcePoint cloudException handlingCASE <Informatik>SoftwareDenial-of-service attackGraph coloringObservational studyGoogolCodeMetric systemOperations support systemSquare numberInstance (computer science)SurfaceInternetworkingOSI modelInfinityPerspective (visual)Loop (music)NeuroinformatikSoftware development kitComputer animationSource code
22:22
Plug-in (computing)Cloud computingRevision controlOperations support systemProjective planeSingle-precision floating-point format1 (number)Open sourceSoftware maintenanceDifferential (mechanical device)Flow separationProduct (business)Information securityDependent and independent variablesConfluence (abstract rewriting)CodeCASE <Informatik>Computing platformSelf-organizationMultiplication signComputer hardwareSoftware testingDialectObservational studyMixed realityShared memoryBusiness modelBlogBuildingExtension (kinesiology)Functional (mathematics)Open setSuite (music)Computer animation
28:19
BuildingOpen sourceQR codeSelectivity (electronic)AutomationBlogCodeBusiness modelProjective planeComputer animation
29:14
MereologyDependent and independent variablesData structureContingency tableCore dumpContent (media)MultilaterationCollaborationismBitInformation securityProjective planeAdditionElasticity (physics)Business modelSelf-organizationMultiplication signControl flowCASE <Informatik>Office suiteLogic gatePoint cloudTwitterLogicDifferential (mechanical device)MathematicsPlanningInterior (topology)Musical ensembleService (economics)Extension (kinesiology)Open sourceCovering spaceFlagComputer animation
33:26
Differential (mechanical device)CodeContent (media)Price indexOpen sourceMeeting/Interview
34:07
Open sourceComputer animation
Transcript: English(auto-generated)
00:04
So, very excited to be here and amazing talks, whoever followed the previous lectures, I think it will fit nicely into this one, so I'm sure you'll see the relevance. And I would like to talk to you about a very interesting situation.
00:21
Imagine waking up one morning to find out that your beloved open source database, or any other library or tool at the heart of your system suddenly changes its license. At my company, we faced that twice over the past year alone. It was a painful and insightful experience and that drove me to suggest this talk topic.
00:45
I called it, when your open source turns to the dark side. So, I'll go over our story with Elasticsearch re-licensing. And then I'll zoom out into several different case studies from the past year or so
01:05
of open source turning to the dark side. Going non-open source, going copyleft, going rogue, different case studies. And then I'll talk about learnings, both for using open source, for vetting a new open source for a company, and for building open source.
01:24
And let's start with a few words about myself. My name is Dotan Horovitz. I'm a developer advocate at Logz.io. At Logz.io, we provide the cloud native observability platform that's based on popular open source tools such as Prometheus, Jaeger, Elasticsearch,
01:41
OpenSearch, and so on. That's why it's relevant for my company as well. I've been around quite some time. I'm an advocate of open source and communities. I run the local CNCF chapter in Tel Aviv, the Cloud Native Computing Foundation. So, you're welcome for our meetups if you're around.
02:02
I also have a podcast, Open Observability Talks, about open source based observability and DevOps. And in general, you can find me everywhere at Horovitz. And let's go straight to our own experience. It's been the beginning of last year, 2021.
02:20
It was the second week of January as everyone's getting back from the New Year's vacations, kickstarting a new year. And one morning, a bomb dropped on us. Elastic, Elastic Envy, released an announcement saying essentially that they're going to change the license
02:44
of Elasticsearch and Kibana from Apache 2.0 to dual license, SSPL and Elastic license. If you've attended the previous talk, you probably heard a lot about that. So, I'm not going to drill into that much. And it's going to take effective the upcoming minor release 7.11.
03:07
So, back then, we were 7.10. 7.11 came out three weeks later, I think, less than a month. It's going to be there already a done deal. For those who are not familiar, ELK Stack or the ELK, it's a very popular open source stack for a search and log analytics
03:24
that's based on Apache Lucene open source. Elasticsearch is the database. Kibana is the UI. And then you have Logstash and other pieces for ingestion, instrumentation like Filebeat and client libraries and so on, all of which used to be Apache 2.0 licensed.
03:43
As I mentioned, I work at Logz.io. So, we provide an observability platform that's built on Elasticsearch and Kibana. So, Elasticsearch database is at the core of our system. It's a critical system. We've been investing in tweaking and optimizing Elasticsearch and Kibana
04:02
for use case for years. So, you can only imagine the impact seeing this announcement suddenly one morning. It was, in fact, even more confusing because the announcement was titled doubling down on open. So, I don't know, maybe we've missed something here.
04:22
Also, if you read the announcement right on the first paragraph, you can see this license change ensures our community and customers have free and open access to use, modify, redistribute, collaborate on the code. So, you know, free and open, maybe it's not an issue.
04:41
Maybe the relicensing is okay. Maybe SSPL is open source software. Spoiler for those who were in the previous talk probably know the answer. And also, by the way, MongoDB is licensed SSPL. So, I don't know, maybe everything is okay. It wasn't just us being confused. It's the community and following that
05:04
and all of the free and open messaging that got everyone confused. The OSI, the Open Source Initiative, the organization behind the definitions of open source and the different licensing establishment released an announcement declaring that SSPL is not an open source license.
05:25
It does not comply with the open source definition. It discriminates against specific fields of endeavor. And essentially, it's, as it said, a Foxpen source license. So, the relicensing move obviously created a lot of shock,
05:47
not just for us, for the entire community. The community was at turmoil. You got lots of responses, no thanks. You know, doubling down is not open at all. People said Elasticsearch and Kibana are now business risks.
06:05
Elastic promises open, delivers proprietary, even angry bunny rabbits, which is really spooky. So, really, a lot of turmoil there. And shortly after, obviously, the users started calling for forking the project to keep it open source.
06:25
I can tell you, we at Logz.io, in my company, we immediately started looking into that and discussing with other community members and exploring this option and being very clear that we think that this should remain Apache 2. Licensed for big organization, AWS,
06:45
released an announcement that they're going to be stepping up to fork and to make sure that it's truly open source. You got, you know, on the social media, whoever followed, so the sentiment was very clear. People preferred an open source AWS fork
07:04
over an Elastic SSPL version and that they will move to a fork as soon as it's available. So, the spirit was very much back in January along these lines.
07:21
So, what happened with the re-licensing and what did the community do and did the fork happen? I'll get back to that later, I promise. But first, I want to step back and connect back also to the previous talks here on the FOSS Backstage.
07:42
So, what is open source anyway? Because we all know OSS licenses, you know, Apache, MIT, BSD, GNU, as approved by the OSI. Lots of talks, lots of material about this, the licenses, also today we've heard. But my question is, is having open source license enough to qualify an OSS project?
08:07
And I hope that you started getting the message from even from this small example that I gave that open source is more than just a license. The question that you need to ask yourself is, is open source enough?
08:22
And also, what prevents a project from changing license? And who can change the license? The OSI has a very nice slogan on its website, you can see that here, a screenshot, guaranteeing the hour in source. And I like that because this is the essence of what we need to ask ourselves.
08:43
We need to ask, who is the hour in source? Who governs the open source? And there are essentially three options there. The vast majority of projects out there are projects run by individuals.
09:03
Popular example, they could be individuals, but it could be even one or two, but still it could be massive, like cURL, that is, I think, like one maintainer and used by millions of devices, and from your washing machine to your car. It could be Log4j, we all remember all the noise around the vulnerability discovered,
09:23
the Log4 shell recently, and through the vulnerability, the CVE, we just realized how many use Log4j, like over 8% of all the packages in Maven Central have had dependency on this vulnerability. And it's maintained by two people, two maintainers.
09:43
So this is the vast majority, individuals. The other option is open source run by vendors, and we've seen the examples like ElasticNV that is behind Elasticsearch, mentioned Grafana Labs that is behind Grafana
10:00
and Locky and Tempo and others, and MongoDB and many other examples of vendor-owned open sources. And lastly is foundations, like Linux under the Linux Foundation, Kubernetes under CNCF, that's affiliated with the Linux Foundation, Apache Kafka, and many, many others.
10:21
And the foundation open source, again, lots of discussions on that. I'm not going to delve into that, but generally the benefit is that it's vendor neutral, it's multi-vendor or multiplayer. You don't have one to own it and to take control and very organized governance around this and very transparent.
10:41
So now that we understand very shortly the options of who owns, who owes the hour in source, let's go looking into three case studies of open source turning to the dark side. And the first one, I'd like to discuss open source going non-open source.
11:03
And for that, I'll go back to what I started talking about, Elasticsearch case study. So we saw already the announcement about re-licensing Elasticsearch and Kibana from Apache 2.0 to SSPL.
11:24
And Elastic explained that it does that to fight off competitors, primarily AWS, that had commercial offerings based on the open source, while Elastic invests the vast majority to develop the open source, so to prevent free riding. Again, lots of discussions around that,
11:41
so I'm not going into that part now. And just to be fair, Elastic Envy is not a small company in itself. It's a public company. It's traded on NASDAQ. It's 8.3 billion US dollar market cap. So that's it. And it didn't end up with that re-licensing. All the rest of the components in the ELK stack
12:02
remained Apache 2.0. However, they started introducing breaking changes to enforce them working with an official certified distro of Elasticsearch. So for example, if you use FileBit agent
12:22
for reading log files and sending the logs to remote Elasticsearch cluster, then suddenly, starting version 7.13, you had little checks for which version is the backend cluster, and if it's not officially supported, then it will just break.
12:41
It will not work, the thing that worked before stopped working. So we had that with all the bits, FileBit, MetricBit, PacketBit, whatever. Also with Logstash, also users started detecting that in the client libraries. These are the libraries that you use to instrument your code base to send directly from your application.
13:04
So starting version 7.14 and others people started noticing similar checks. I think that the best description for those who are not from the ELK stack domain is this description that says, imagine Oracle's MySQL team
13:20
deciding to fix a MySQL client library so that they could only connect an official MySQL version, so it doesn't stop working with MariaDB, Percona, and others. That's essentially the impact. And by the way, very, very important, the breaking changes did not only break for not working with other distros like AWS and whoever,
13:42
it also broke the compatibility with older open source versions. So if you used to work with an Elasticsearch version 7.10 or older, it will stop working with the open source versions there as well. So it was very, very problematic for the community. So as I mentioned before,
14:00
the community started calling to create a fork called OpenSearch. It was led by AWS, together with Red Hat, SAP, Capital One, and Logs.io. And you'd say, okay, so what's the problem? Just hit the fork button, right? It's an Apache 2 project. But it appeared not to be that easy at all.
14:22
What you can see here is the OpenSearch community updates from the forking work, and you can see as soon as the developers started working on that, they realized quickly that Elasticsearch and Kibana code bases are entangled between Apache 2 and the Elastic's XPAC proprietary license,
14:42
including, by the way, embedded XPAC license checks. So the team found itself pulling proprietary and open source apart and sometimes even traversing line by line, very tedious. In addition, they also inside, they found embedded Elastic marketing and branding elements, RSS feeds, pop-up messages, dial home features,
15:04
telemetry fetched from the OSS to Elastic's servers, use of widgets that are not open, and so on. If you want to, by the way, to hear more about the process, I'd highly recommend you to check out the Open Observability Talks podcast.
15:21
It was an episode I did with Kyle from AWS, where it very nicely outlines the journey that was taken to actually make this fork happen. And luckily enough, OpenSearch was released in April in beta and in July in GA, which is less than half a year
15:41
since the bomb dropped on us, on all the community. That's very, very impressive. And since it was released, many moved from Elasticsearch to OpenSearch, including big names such as Dow Jones and Goldman Sachs and Pinterest and SAP and Zoom and Rackspace.
16:01
Amazon, of course, moved its Amazon Elasticsearch service to OpenSearch. We at Logz.io moved to OpenSearch, so it was really an interesting experience. So Elasticsearch was an example of an OSS moving to a non-OSI license,
16:21
to a Foxconn license, which is a clear case of turning to the dark side. But remember what I said before. Open source is not about OSI licensing. Things can happen even within OSI licensing realm. And for that, I'd like to talk about an example of going copyleft.
16:41
And for that, I chose the Grafana case study from, again, the past year. Grafana, for those who don't know, is a very popular open source for metrics, dashboarding, and monitoring. It's Apache 2.0 licensed, backed by Grafana Labs. They also offer Loki for logs and Tempo for traces.
17:02
And April last year, I told 2021, less than a year ago, Grafana Labs announced re-licensing Grafana, Loki, and Tempo from Apache 2.0 to GNU AGPL version 3. And it also did that to fend off competitors leveraging the open source,
17:22
so to fight off free riders or something like that. Now, it's important to say AGPL version 3.0 is an OSI approved license that meets all the criteria of free and open source software. So what's the problem, right? But it is a problem. It's a new reality.
17:42
People discovered that the OSS tool that they use is suddenly an infectious OSS, a copyleft license. And what does that mean? Again, they touched that on the previous talk, so I'll do that very briefly. And I'm not a lawyer, so again, I'm putting it in layman terms. But in general, I took the example from Google, Google open source policy.
18:03
It's publicly available. And Google, for instance, doesn't allow AGPL use. It says very clearly that it's simply the risks who overweight the benefits, heavily overweight the benefits. And why is that? The fact is that using AGPL software with modifications
18:21
requires that anything it links to must also be licensed under AGPL, or the attack surface, if you'd like. So it spreads virally, so to speak, which means that if you modify AGPL code or any copied or derived pieces from AGPL license code, you're at risk of needing to, you're exposed.
18:43
And in fact, some say that even dynamically linking DLLs may be prohibited or under this restriction. And moreover, this is triggered if the AGPL software is interacted with through a computer network. That's section 13 of the license that means that you don't even need to,
19:05
the product or the service to actually be distributed to customers. So in Google's case, or any SaaS software as a service in that case, the core products are services that users interact with over the internet, right? So AGPL is effectively render the business risk.
19:24
And it's not just these cases. Even if you use that internally only, internal systems purely, you still, for example, have contractors or vendors interacting, then from the license perspective, they're users. So if they interact with some AGPL modified code base,
19:45
you may find yourself needing to expose your full source code to a contractor you didn't even intend to expose to, or something like that. So it's not just, even for internal use, it's very problematic. And it's not just problematic for vendors like Google and others,
20:00
it's also problematic for other open source projects because of the license contamination issues. So for example, the CNCF, the Cloud Native Computing Foundation, we issued a special guidance following this relicensing saying that projects under the CNCF should switch to alternatives
20:20
or freeze the used version and not upgrade to the relicensed version or ask for exceptions. So it is a problem also for open source projects. So these are cases of going copyleft for Elasticsearch and Elastic and Graphana Labs, but it can also happen not just with vendors,
20:42
also with individual contributors, which leads me to the case of open source going rogue, the case of two popular NPM packages, colors and Faker, both MIT licensed. I'm sure that you'll all agree a very permissive license and both maintained by Merak Squares, which on January 5th this year,
21:03
just a very short while ago, three months ago, he deleted the source code of Faker and published the empty package to NPM as version 666, very symbolic. And essentially,
21:21
Faker receives like 2 million weekly downloads and it's very popular also in JavaScript and Node.js projects. So you can just imagine what happened to those who upgraded the version automatically. And it didn't end with Faker. Three days later on January 8th, 2022, he published a version of colors, version one for one,
21:43
where he committed an infinite loop, essentially, which creates a denial of service to everyone who runs that. And the colors, open source is much more popular than Faker. It's like 20 million downloads a week,
22:01
a very key component in JavaScript and Node.js ecosystems, more than 4 million other projects on GitHub. So you can imagine the ripple effect that it immediately created, including, by the way, to AWS CDK, the Cloud Development Kit, so not just small projects indeed.
22:22
And the community reacted immediately. Within a few hours, NPM had rolled back the rogue release. And maybe more interestingly, GitHub suspended his account in response, which is a controversial move by GitHub. Let's admit he owns it. You can ask, why can't he do whatever he likes with it?
22:43
So I'm not going down this. This is a separate discussion. But it's definitely, let's say, a challenge to some of the assumptions we have in the open source community. And Mark Rowe wrote a very interesting blog post where he described monetizing open source as problematic.
23:02
And he explained, like the title says, that he's been working very hard on that. He hasn't seen any monetization. Large organizations have been capitalizing on it, and he hasn't seen any, and they haven't contributed to the project. Again, very similar to what we've heard before. So we saw case studies from past year or so
23:21
on open source turning to the dark side, you know, going non-open source, going copyleft, going rogue. What can we learn from these cases? I'll share learnings for building an OSS, for using OSS, and for vetting new OSS for your companies. And let's start with building open source.
23:44
If you're building open source, remember, open source isn't a business model. It's not a problem of the commercial vendors, as we've seen. It's a problem with a commercial incentive. OSS isn't a business model.
24:02
If you take one thing out of this talk, take this one. If you're a vendor, if you choose the OSS path, you should build a sustainable business model. Those who don't end up in conflict between the open source community needs and the business ones end up re-licensing defensively,
24:23
just like what we've seen and the claims we've seen. Others use open source. Also, your competitors, that's OSS premise. So make sure you create differentiation on your cloud service. There was a very interesting talk earlier today, so again, I'm not going down this, but definitely a point.
24:42
And if you're a maintainer as well, if you decide to open source a project, don't expect material compensation. Yes, even if the large corps are going to benefit from it. There are enough opportunities out there to get paid for dev. That's not it. Or establish a vendor entity around open source, like Confluent for Kafka, Chronosphere for M3 and many others.
25:05
And of course, if you go down this path and then go back to my advice for vendors, that's for building open source. If you use open source, here are a few tips to keep safe. First, manage your third-party licensing exposure, just like you do for a third-party security exposure.
25:23
Prefer the least restrictive licenses, look for license contamination issues, and take care with automation. Make sure that you do license compliance checks before updating third-party. Don't do auto updates with your CI CD without any safeguards.
25:40
Just think about those updating automatically from Elasticsearch 7.10 to 7.11 minor release without checking the license and what happened there. Another tip is code smells that can signal upcoming relicensing. It can buy you some time to act proactively. Like if you remember in Elasticsearch and Kibana,
26:01
mixed code licenses, telemetry, dial home and things like that, I think about the just hit the fork test. So obviously, you don't need to actually fork, but if you are familiar with the code base and you see that it's going to be very tricky to fork, that should be a code smell for you. And if you find yourself needing to tweak the open source
26:25
to suit your needs, prefer extending the functionality with plugins over downstream code modifications because vendors will more easily block you from modifying code with licensing rather than extensions via plugins.
26:40
So that's for using open source and for vetting new open source for your company. Here are a few things to consider. First, very clearly, which OSS license? Prefer Apache 2, MIT, BSD, the least restrictive. But also don't forget who's behind the open source,
27:01
preferably not a one-man show. That's a bottleneck and a very dangerous path. If it's a vendor, remember that license may change if a conflict comes into place. So prefer foundational open source to be the safest and the most transparent one. Also understand what's the governance policy
27:20
for foundational or others. How do they ensure no single entity grabs control? What's the promotion path to becoming a contributor, becoming a maintainer who can review, who can approve PRs? Ultimately, who can decide on relicensing as well? And if you look for a safer path, you can also always consider vendors
27:41
supporting the open source with their distros, you know, packaging of the upstream project that is delivered as a product that includes usually an indemnification, so effectively an insurance policy from these lawsuits and all of these legal mess, including support and certified-to-run hardware platforms.
28:00
That's for the on-prem preference. For those who go for managed, you have SaaS offerings for the open source. And remember, on the other hand, that using vendors may involve some delay in getting the latest from the upstream, so important to check. So just to summarize what we've seen, we've seen that open source is more than a license.
28:24
We've seen that open source can turn to the dark side. It can be relicensed. It can go rogue. So you need to select open source wisely, which license was behind the project, which governance policy, and so on. You need to use open source wisely, manage the licenses,
28:40
don't automate updates without safeguards, code smells, and build open source wisely. Remember, open source isn't a business model. I've written, by the way, a blog post about it. I called it, Is Vendor-Owned Open Source an Oxymoron? So you're welcome to scan the QR code or just Google it up. I take this discussion a bit further
29:02
with regards to the vendor-owned open source. And most importantly, this takeaway. Always ask yourselves, who's the hour in source? I'm Notan Horvitz. Thank you very much. And may the open source be with you.
29:20
And I hope there's time for questions there. Yeah, thanks for this amazing talk. We technically don't have time, but we actually have time because there's a break upcoming now. And I would say we just take a bit of that break for you to answer a few questions.
29:41
Okay, the first one is, Is documenting licenses and monitoring changes part of a company's SPOM? What are the department's roles in a company responsible for identifying and mitigating the impact of license changes?
30:01
For example, a contingency plan, security, the OSPO, who was in charge of that? That's a very extensive question. I'll try and cover, but maybe we can carry it on on the breakout room later. I can say very shortly that
30:20
I look at it very much like, I mentioned that briefly on the talk, I look at it like people look at security. Because I'm giving that as an example just because security is much more evolved in many of these organizations. So it's really dependent on the size of the organization and the structure of the organization who will take ownership of that
30:40
if it's under the chief data officer or chief CISO or the CTO or whoever. I'm not going into the roles because it's really dependent. But the very important thing is that there is very clear gating and very clear safeguards, especially, and again, because of the trend to go to the lean, agile movement and doing automation,
31:03
this should be an integral part of the release pipeline. You don't automatically upgrade to the latest without safeguards on the security. Do the same on the licensing. Make sure that you have, and obviously not everything can be fully automated, so at least raise a flag. Just compare. If the license is identical, go ahead with the automation.
31:23
If the license is changed, raise an alert and have someone look into that and see what the implications are or something as simple as that. If you have more elaborate automation, that's fine, but just don't neglect to look into that. I guess about roles, it's really dependent on the organizational structure.
31:42
If you have OSPO, I think this definitely should be done, at least in collaboration with, if not owned by, definitely. Okay. Another question is maybe a bit of a look into the crystal ball. What are other projects that you see
32:02
that might be at risk of changing the license like Elastic did? Well, I'm not a prophet, so it's very difficult to say. Some said after the Grafana Labs re-licensed its projects to AGPL that it will be just the first stage and additional re-licensing will come later down the road.
32:23
I don't know if that's going to be the case or not. I can say that I would use the same sensors. Instead of crystal balls, I can equip you with the advice that I gave on the talk, maybe elaborate a bit more about that. Try and see if the vendor behind,
32:41
if you use a foundational open source, you're much more in a safer ground. You know that there is a clear governance, you need to open the governance and see, but probably you're in a safer ground because the neutrality is baked into the governance. And by the way, there were re-licensing also under foundations,
33:01
like in Eclipse, there was some re-licensing. So it's not that it's not there, but the logic should be more consistent and transparent. And then the question is if the vendor behind it is one that creates differentiation on its cloud services, if they manage to build a sustainable business model that is independent of the core value of the open source,
33:23
then it's less of a risk of being in contention between the open source and the commercial needs, let's put it this way. So if you start feeling that they don't have much of a differentiation and added value on top of that, that's, I guess, something that could be a signal.
33:40
Another one that I said, for those who are involved in the open source themselves, like people developed on Elasticsearch or people develop on Grafana or things like that and know the code intimately, as I said, sometimes they can detect some code smells that can give them a sense that at least it might happen. So these are the indicators, the senses that I would put out,
34:01
at least for the stack that you use in your house or that you're vetting now to adopt.