Changing Open Source Licenses to Proprietary? Study Finds 'No Clear Link' to Increased Company Value (devclass.com)
- Reference: 0174993199
- News link: https://news.slashdot.org/story/24/09/14/0326201/changing-open-source-licenses-to-proprietary-study-finds-no-clear-link-to-increased-company-value
- Source link: https://devclass.com/2024/09/09/redmonk-no-clear-link-between-moving-from-open-source-to-a-proprietary-license-and-increasing-company-value/
> A report from developer-focused analyst Redmonk finds "there does not seem to be a clear link between moving from an open source to proprietary license and increasing the company's value."
>
> Senior analyst Rachel Stevens studied the question of whether the companies that changed from open source to proprietary licenses have since reported better financial positions. In particular, she looked at [2]MongoDB , which changed from AGPL (GNU Affero General Public License) to its SSPL (Server Side Public License) in 2018; [3]Elastic Co , which changed from Apache 2 to SSPL or Elastic License in early 2021; [4]HashiCorp , which changed from MPL (Mozilla Public License 2.0) a year ago, and Confluent, which checked from Apache 2 to its own Confluent Community License in 2018.
>
> [5]The report is too recent to take account of Elastic's [6]reversion to AGPL ; and the financial impact of that is of course yet to be known, though it is perhaps unlikely that the switch back would have been made if the company considered it detrimental to its finances. Rather, Elastic's latest licensing change reinforces the view that proprietary licenses are not necessarily more profitable... All the companies studied increased their revenue after their license change, Stevens said, but added that the rate of change was similar to that before the change...
>
> MongoDB [7]stated in 2018 that "once an open source project becomes interesting or popular, it becomes too easy for the cloud vendors to capture all the value and give nothing back to the community." Six years later, it remains the case that the large cloud vendors are highly profitable, but that these companies who changed their license are not. In February this year, Bruce Perens, creator of the 1998 Open Source Definition, [8]described open source as "a great corporate welfare program" and not at all what he had intended...
>
> The new Redmonk report suggests that such license manoeuvres are neither fatal nor beneficial to the finances of the companies involved — though there are so many caveats that it is impossible to draw firm conclusions.
The report's final sentence concludes that "there does not seem to be a clear link between moving from an open source to proprietary license and increasing the company's value."
[1] https://devclass.com/2024/09/09/redmonk-no-clear-link-between-moving-from-open-source-to-a-proprietary-license-and-increasing-company-value/
[2] https://www.theregister.com/2018/10/16/mongodb_licensning_change/
[3] https://www.theregister.com/2021/01/18/elastics_doubling_down_on_open/
[4] https://www.theregister.com/2023/08/11/hashicorp_bsl_licence/
[5] https://redmonk.com/rstephens/2024/08/26/software-licensing-changes-and-their-impact-on-financial-outcomes/
[6] https://devclass.com/2024/09/02/elasticsearch-will-be-open-source-again-as-cto-declares-changed-landscape/
[7] https://www.theregister.com/2018/10/16/mongodb_licensning_change/
[8] https://devclass.com/2024/02/08/preserving-the-magic-of-free-new-types-of-licenses-will-not-solve-open-source-business-model-says-percona-founder/
Such long-winded expression. (Score:3)
Put simply, moving from a permissive licence to a less permissive license didn't benefit the end users noticeably. Hang on, let me put on my "shocked" face...
8^O
Re: (Score:2)
dude, it's just another slashvertisement for the same charlat .... errrrm, software analysts that brought yesterday's programming language popularity poll. what would you expect?
Re: (Score:3)
> Put simply, moving from a permissive licence to a less permissive license didn't benefit the end users noticeably.
No, that isn't the point of TFA.
TFA says that changing the license didn't financially benefit the vendor of the software.
Too recent report (Score:2)
> The report is too recent to take account of Elastic's reversion to AGPL
Lol there's no such thing as too recent report.
The report is too *old* to consider Elastic's reversion to AGPL.
Or, Elastic's reversion to AGPL is too recent for the report to take into account.
And KDE is struggling (Score:2)
Despite 97% of the browser market using descendants of their code.
Re: (Score:2)
And so are/were Xerox, AT&T, Bell Labs, Sun... Financial success, I think is a black swan.
Re: (Score:2)
And if Konqueror/khtml wasn't open source / free software, Apple would have used Mozilla/Geko as the base for Safari.
Or if they closed it later, Apple would have continued to maintain their WebKit fork under the previous licence.
Is it the wrong question? (Score:4, Informative)
These restrictive licenses are targeted in one specific direction: Amazon and similar service providers which like to feed on, then extinguish, or at least cap the revenue or profitability of the very teams that create and maintain the software Amazon will profit from.
So the right question is, did the move to a license that prevent the leeching
- help Elastic and other companies stay in business and prosper? (yes)
- force Amazon to leech less, adjusting their cost to features ratio, cf outright stealing? (yes)
Companies that didn't switch to server-restrictive licenses are the comparison baseline, but they obviously considered their individual circumstances and acted accordingly. Meanwhile there are no two HashiCorp companies, one of which keeping the original license and the other switching to a restrictive license (and even if there were, market interaction between the two would make the comparison meaningless). So I'm skeptical about such studies.
Also, Elastic's switch back to full OS doesn't imply that it was counterproductive or neutral to switch away from it for a period of time, which, at the time, was perceived as a permanent change. Business is incredibly path dependent, and competitors and users take a sequence of reactive steps under limited information, and most of that won't automatically unfurl by switching back.
Re: (Score:2)
Nobody forced Elastic to use the OSS community and model to build their company.
They could have (tried to) built some proprietary closed stuff from the beginning and maybe it would have succeeded. More likely in that universe we'd instead be using some other open source free or Free search stack alternative that never developed in our universe because Elastic sucked all the air from that niche. (e.g how prob Apache https server would not have dominated it's era if Netscape server had been free. etc)
This i
It's not all about revenue. (Score:3)
The change to a proprietary license can be about reducing risk, particularly in competition that forks/reuses the open source to offer competing products. It's reductive to just ask "number go up?" and conclude all these companies made stupid choices. It would make more sense to look at the licenses case-by-case and get some idea of what each company was trying to protect. I doubt that any of them switched over to a proprietary license for branding reasons.
Well, study ignores an important variable (Score:2)
Admittedly, I only notice this phenomenon when it shows up on this site - but it does seem like these license switches are typically made by companies that are already struggling financially.
So while the study does show that, for a company that's already in bad financial shape, relicensing their products does not appear to be a panacea... we probably can't extrapolate it to the broader case.
Chromium (Score:2)
Chromium is open source and Google manages to keep everyone on Chrome despite a major competitor (MS) actively trying hard to vendor the same codebase. There's a lot more to monetizing and maintaining a product than keeping the source code private.
Re: (Score:2)
Well except for users of Apple products who use the project one level upstream.
The license is largely irrelevant (Score:2)
Where all these struggling businesses falter is that a third party is offering a better deal around the software. The software is one thing, but deployment, services and support another. Writing an application is step one, but after you need to make sure you are the go to source for all peripheral services. If a third party can do that better than you, you don't have your eyes on the ball. You can close the source, but then you need to contend with forks from the last FOSS version and the big guys pouring
increased value? money bonfire (Score:2)
I know a particular employer with over a billion in revenue, going to Azure which is hella expensive and regions they picked have been down for hours a few times over past two years.
Many models of VM can't have disk size or other parameters dynamically changed, DNS is lacking features, web app firewall a joke, serial console for non-windows that seizes up under heavy scrolling, no attaching ISO images...
Who pays premium for that garbage? The suits of course
Re: (Score:2)
The global Azure firewall is pretty nasty to deal with. Apps that worked fine in your own hosting start having issues as a result of closed TCP connections. The max you can set it for is 30 minutes. It's ultimately why I moved everything out of there.
When I had control of the source, I could patch to solve the problem by inserting keepalives. When I didn't, no go.
Re: (Score:2)
I've been a SaaS dev my entire career, and "the suits" have *always* been the ones making the purchasing decisions. This has remained true even across incredibly different verticals (I've done everything from supercomputers to real estate to genomic research). Rather than complain, I think smart companies embrace and make the best of it it.
"The suits" do listen to the people below them, to an extent, so your marketing people, PMs, etc. just have to triangulate. You try to get all the features and marketin
Retirement plan for FOSS devs (Score:2)
Hate to see it when FOSS team after team decides, after getting hundreds (?) to thousands (?) of hours of free code changes, beta testing and debugging from the FOSS community decide to monetize their solution.
One research angle would be to get a profile of the FOSS dev team, their ages when they convert to a 'monetize on the server' license.