We Are Changing the License for Akka(lightbend.com)
lightbend.com
We Are Changing the License for Akka
https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka
356 comments
I think they clearly state that the fresh versions are not open source, they are "source available".
After 3 years since release the code automatically gets relicensed under Apache 2.0 and becomes open source. This is a nice provision that prevents the code from being completely lost if the company loses interest in it.
After 3 years since release the code automatically gets relicensed under Apache 2.0 and becomes open source. This is a nice provision that prevents the code from being completely lost if the company loses interest in it.
> I think they clearly state that the fresh versions are not open source, they are "source available".
To me it reads like they chose to switch to a proprietary license but don't want to be subjected to the natural consequences of betraying the trust of their userbase.
To me it reads like they chose to switch to a proprietary license but don't want to be subjected to the natural consequences of betraying the trust of their userbase.
isn't their point the breach of trust of large (>25mio revenue) business users of their software to not contribute financially to the developer staff (subscription)?
open source creators are systematically abused by large companies who free ride despite being able to financially contribute, and they just don't because they can.
"why give the creator a fair share if you can keep them alive with a few graceful breadcrumbs" seems to be such corporations way of thinking, highly profitable formally but the FOSS creators.
thus an agpl, thus the new Akka license.
open source creators are systematically abused by large companies who free ride despite being able to financially contribute, and they just don't because they can.
"why give the creator a fair share if you can keep them alive with a few graceful breadcrumbs" seems to be such corporations way of thinking, highly profitable formally but the FOSS creators.
thus an agpl, thus the new Akka license.
They state that BSL + Apache re-license after 3 years is "open source". It's not, it's delayed open source if anything. But doing BSL is not open source, at least as what we know open source to be today.
From my perspective the challenge is, what happens if there is a critical bug found after 3 years and you're on the Apache version? Do they backport the fix (out of kindness)? I've jumped through many hoops in the past to pay for fixes to older open source systems - because the systems weren't properly updated - to get a patch, and it was never easy (and fixing this yourself is nearly impossible if the bug isn't obvious, and you don't want to break things in such a core technology).
I believe a section of the FAQ mentions that the previous versions (released under Apache) will no longer receive any updates and you're not allowed to integrate the changes to the newer versions into the older codebase.
Yes but also they claim "We Believe In A Model Of Sustainable Open Source" where their actions say what they believe what you can't built Sustainable Business around Open Source and Source Available License is required.
I've seen companies claiming "but you can use our buggy unsecure code after 3 years" but reality I'm yet to see actually anyone using this with BSL software.
I've seen companies claiming "but you can use our buggy unsecure code after 3 years" but reality I'm yet to see actually anyone using this with BSL software.
> Just because you didn't manage to build a company around a Open Source library/ecosystem, doesn't mean Open Source is not sustainable. It just means that your company is not sustainable. But I guess it's hard to blame yourself when you see others using your code without paying for it.
This almost religious attitude makes no sense to me. Clearly other’s use of that code wasn’t very sustainable, since the author now says they will no longer maintain it for free. You’re essentially describing the “everyone looses” outcome that the OP wants to address, but you seem to think it’s a good outcome.
This almost religious attitude makes no sense to me. Clearly other’s use of that code wasn’t very sustainable, since the author now says they will no longer maintain it for free. You’re essentially describing the “everyone looses” outcome that the OP wants to address, but you seem to think it’s a good outcome.
The author is saying "we're the only major contributor to Akka, open source isn't sustainable!" without considering/trying to address why they are the only major contributor to Akka.
Plenty of big Apache projects have major contributors from multiple projects/ecosystems/companies, without having to change the license to something not Apache. Since it's clearly possible to have sustainable projects licensed under Apache, I'm saying that it sounds more like an excuse rather than a proper argument for the license change.
Plenty of big Apache projects have major contributors from multiple projects/ecosystems/companies, without having to change the license to something not Apache. Since it's clearly possible to have sustainable projects licensed under Apache, I'm saying that it sounds more like an excuse rather than a proper argument for the license change.
> Since it's clearly possible to have sustainable projects licensed under Apache
Just because it's possible for _some_ projects to live sustainable and be licensed under Apache, doesn't mean that it's possible for all projects to be developed sustainably under that license.
Just because it's possible for _some_ projects to live sustainable and be licensed under Apache, doesn't mean that it's possible for all projects to be developed sustainably under that license.
> doesn't mean that it's possible for all projects to be developed sustainably under that license
Absolutely, I agree with that, it doesn't give you the right to be sustainable, merely the chance.
What I find weird is claiming that Akka is unsustainable because it's open source, when there are others who are open source and sustainable.
Absolutely, I agree with that, it doesn't give you the right to be sustainable, merely the chance.
What I find weird is claiming that Akka is unsustainable because it's open source, when there are others who are open source and sustainable.
> What I find weird is claiming that Akka is unsustainable because it's open source
Akka is Open Source. Akka's authors feel that continuing the status quo is unsustainable.
Whether or not it's unsustainable because it's open source to some extent doesn't really matter – perhaps with enough elbow grease on their part they could drum up more community maintainers and make it both sustainable and continuously open source, but that would require putting in yet more uncompensated work on the hope that it might lower their burdens at some point down the road, and come with the issue that more volunteers mean more work trying to coordinate everyone.
Or they could just make it source available for the first 3 years and ask for money from the companies using it commercially – there's also no guarantee that this will work, but money will solve more problems in the short term, so I can understand why they made the choice they did.
Akka is Open Source. Akka's authors feel that continuing the status quo is unsustainable.
Whether or not it's unsustainable because it's open source to some extent doesn't really matter – perhaps with enough elbow grease on their part they could drum up more community maintainers and make it both sustainable and continuously open source, but that would require putting in yet more uncompensated work on the hope that it might lower their burdens at some point down the road, and come with the issue that more volunteers mean more work trying to coordinate everyone.
Or they could just make it source available for the first 3 years and ask for money from the companies using it commercially – there's also no guarantee that this will work, but money will solve more problems in the short term, so I can understand why they made the choice they did.
Here is Akka's dependency specification: https://github.com/akka/akka/blob/main/project/Dependencies....
How many of these would have to opt for this source available approach before Akka would no longer be sustainable?
How many of these would have to opt for this source available approach before Akka would no longer be sustainable?
> Clearly other’s use of that code wasn’t very sustainable, since the author now says they will no longer maintain it for free.
You are not entitled to ongoing, continued maintenance of any FLOSS project. If you have such needs, you can get paid support or fork the project and maintain it yourself.
You are not entitled to ongoing, continued maintenance of any FLOSS project. If you have such needs, you can get paid support or fork the project and maintain it yourself.
> You are not entitled to ongoing, continued maintenance of any FLOSS project.
If it were just no longer being maintained, nobody would be nearly as upset. But it is still being maintained; it's just no longer FLOSS.
If it were just no longer being maintained, nobody would be nearly as upset. But it is still being maintained; it's just no longer FLOSS.
Those who would have been less upset by it becoming no longer maintained can simply fork and proceed as if that were the case.
No, because the existence of the proprietary competitor to the fork will make it harder to gain traction.
Plus, it’s a legal madness when a fork starts implementing features available in the BSL version, even if those are written in a different way.
The version prior to license change is as open source as ever and unmaintained.
It is open source for me as I will never earn more than US $25 million in annual revenue. If I ever do, I will gladly pay them.
I disagree with the idea that the only correct definition of open source is the one that favors big tech monopolists.
Times have changed compared to when the open source movement started. Not many people would have imagined that the monopolists would weaponize open source like they do now. They are not the first company to adapt their license to the changing circumstances, see Elastic.
I disagree with the idea that the only correct definition of open source is the one that favors big tech monopolists.
Times have changed compared to when the open source movement started. Not many people would have imagined that the monopolists would weaponize open source like they do now. They are not the first company to adapt their license to the changing circumstances, see Elastic.
> Not many people would have imagined that the monopolists would weaponize open source like they do now.
What do you think "weaponize open source" means? It doesn't look like it means a thing, and lounds like a poor attempt at shoehorning "weapon" in a discussion on how a potential user's income is something noteworthy.
What do you think "weaponize open source" means? It doesn't look like it means a thing, and lounds like a poor attempt at shoehorning "weapon" in a discussion on how a potential user's income is something noteworthy.
The cloud giants have gigantic moats in terms of infrastructure, marketing, process, and so on.
Traditionally, one of the best paths for an upstart company to challenge an established giant was to develop superior technology. Indeed, this is how some of the cloud giants themselves got their start against the dinosaurs of the day.
But in a tech culture where open source is not just common but expected, this path is severely hampered. A lot of tech users won't even consider your fancy new technology if it isn't open source, but if it is, then the giants can put it on their platform and make your customers into theirs.
This is what "Microsoft loves open source" means. When they had the (commercially) superior tech, they disparaged open source as nonsense so they wouldn't be asked to share. Twenty years later, when they realized that there was more and better tech out there than they could hope to produce, they aligned and supported that very ideology so that "we have Redis" or "we have Akka" wouldn't be a competitive advantage anymore.
Ultimately, it's a twist on the old "commodify your competition".
Traditionally, one of the best paths for an upstart company to challenge an established giant was to develop superior technology. Indeed, this is how some of the cloud giants themselves got their start against the dinosaurs of the day.
But in a tech culture where open source is not just common but expected, this path is severely hampered. A lot of tech users won't even consider your fancy new technology if it isn't open source, but if it is, then the giants can put it on their platform and make your customers into theirs.
This is what "Microsoft loves open source" means. When they had the (commercially) superior tech, they disparaged open source as nonsense so they wouldn't be asked to share. Twenty years later, when they realized that there was more and better tech out there than they could hope to produce, they aligned and supported that very ideology so that "we have Redis" or "we have Akka" wouldn't be a competitive advantage anymore.
Ultimately, it's a twist on the old "commodify your competition".
First let’s put things in perspective. According to public statements last year by the former CEO of AWS and the current CEO of Amazon [1][2], only 5% of all IT spend is directed toward any cloud provider. There are plenty of opportunities with businesses that don’t host infrastructure in the cloud.
Also, when was the last time an “upstart” challenged a giant successfully?
- Microsoft has been a “giant” since 2000
- Apple became the worlds most valuable company in 2011.
- Google has been the go to search engine at least since the early 2000s
- Amazon has been dominant in its field at least since around 2000.
[1] Jassy is my skip^9 manager
[2] https://accelerationeconomy.com/cloud/amazon-shocker-ceo-jas...
Also, when was the last time an “upstart” challenged a giant successfully?
- Microsoft has been a “giant” since 2000
- Apple became the worlds most valuable company in 2011.
- Google has been the go to search engine at least since the early 2000s
- Amazon has been dominant in its field at least since around 2000.
[1] Jassy is my skip^9 manager
[2] https://accelerationeconomy.com/cloud/amazon-shocker-ceo-jas...
I don't think that the Akka license change is aimed at cloud providers. Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala [1]. It's not possible for AWS to offer their own "Akka service" the way they offered Redis as ElastiCache. This change affects companies that build software using Akka. For example, here's a case study regarding an oilfield services company that uses Akka:
https://www.lightbend.com/blog/low-cpu-utilization-fortune-5...
[1] As found on https://akka.io/
https://www.lightbend.com/blog/low-cpu-utilization-fortune-5...
[1] As found on https://akka.io/
> if it is, then the giants can put it on their platform and make your customers into theirs.
The AGPL already solves this. Whatever secret sauce the giants add to do that, you can just take it and add it back to your original program.
The AGPL already solves this. Whatever secret sauce the giants add to do that, you can just take it and add it back to your original program.
Their secret sauce is "we have a Borg Cube's worth of datacenters, so we can run the same code as you at a lower price".
The AGPL does nothing to prevent that. They aren't modifying Akka, they're just running it on a superior platform.
One license that does force the giants to share (the software part of) their secret sauce exists and is called SSPL, the one the MongoDB guys came up with.
The AGPL does nothing to prevent that. They aren't modifying Akka, they're just running it on a superior platform.
One license that does force the giants to share (the software part of) their secret sauce exists and is called SSPL, the one the MongoDB guys came up with.
> One license that does force the giants to share (the software part of) their secret sauce exists and is called SSPL
That's exactly what the AGPL does. You just claimed it doesn't prevent cloud providers from running the software at low cost on their own datacentres.
That's exactly what the AGPL does. You just claimed it doesn't prevent cloud providers from running the software at low cost on their own datacentres.
The AGPL only covers modification to the software itself. So Amazon can take free code, sell it as a slickly-packaged service, and not need to share anything.
The SSPL says that if they do so, they need to share the code they use to make it run as a service.
They still retain their massive hardware and organizational advantages, but it does mean that at least every user has access to the code to make their "Akka Service" as good as Amazon's.
The SSPL says that if they do so, they need to share the code they use to make it run as a service.
They still retain their massive hardware and organizational advantages, but it does mean that at least every user has access to the code to make their "Akka Service" as good as Amazon's.
> So Amazon can take free code, sell it as a slickly-packaged service, and not need to share anything.
Right, because they didn't change it. So what would there be to share anyway? 'Go to https://github.com/akka/akka'?
> but it does mean that at least every user has access to the code to make their "Akka Service" as good as Amazon's.
That code is meaningless. In this scenario we already established that Amazon is selling an unmodified copy of Akka as a Service (which, by the way, we will revisit this point later). And we already established, in your own words, that it's not about the code:
> Their secret sauce is "we have a Borg Cube's worth of datacenters, so we can run the same code as you at a lower price".
So what would the SSPL require, they publish their deployment scripts to their cloud datacentres? Like I said, that's meaningless.
> "Akka Service"
Final point. There's no such thing as an 'Akka Service'. Akka is a bunch of libraries. You link it into your JVM application. You don't run Akka separately, so by definition you can't offer it as a service (even if you're Amazon).
Hence my suggestion of AGPL, and heck let's be generous, let's add a commercial use exception for businesses with less than $20m revenue, similar to what they're doing now with the BSL. Except with my suggestion the software would stay as strong copyleft, most businesses would be happy with the commercial use exception, and a few would have to pay their fair share.
[1] https://news.ycombinator.com/item?id=32751373
Right, because they didn't change it. So what would there be to share anyway? 'Go to https://github.com/akka/akka'?
> but it does mean that at least every user has access to the code to make their "Akka Service" as good as Amazon's.
That code is meaningless. In this scenario we already established that Amazon is selling an unmodified copy of Akka as a Service (which, by the way, we will revisit this point later). And we already established, in your own words, that it's not about the code:
> Their secret sauce is "we have a Borg Cube's worth of datacenters, so we can run the same code as you at a lower price".
So what would the SSPL require, they publish their deployment scripts to their cloud datacentres? Like I said, that's meaningless.
> "Akka Service"
Final point. There's no such thing as an 'Akka Service'. Akka is a bunch of libraries. You link it into your JVM application. You don't run Akka separately, so by definition you can't offer it as a service (even if you're Amazon).
Hence my suggestion of AGPL, and heck let's be generous, let's add a commercial use exception for businesses with less than $20m revenue, similar to what they're doing now with the BSL. Except with my suggestion the software would stay as strong copyleft, most businesses would be happy with the commercial use exception, and a few would have to pay their fair share.
[1] https://news.ycombinator.com/item?id=32751373
> Ultimately, it's a twist on the old "commodify your competition".
I think you're thinking of "commodify your complement"? Commodifying your competition would seem to be a bad thing, as prices drop for something that substitutes for what you're selling. Might work in particular luxury/Veblen goods, but seems likely to be less of a thing? (and certainly a different thing than "commodify your complement")
I think you're thinking of "commodify your complement"? Commodifying your competition would seem to be a bad thing, as prices drop for something that substitutes for what you're selling. Might work in particular luxury/Veblen goods, but seems likely to be less of a thing? (and certainly a different thing than "commodify your complement")
You are quite correct, sorry for the typo.
Companies like Amazon offering open source software as a hosting service can out-compete any other companies offering the same just based on market position.
Liberal open source licenses are the perfect weapon for the monopolists because they ensure an "equal" playing field, meaning they have access to the same tech that smaller companies have. All things being equal, they can always crush the competition with their market position.
Liberal open source licenses are the perfect weapon for the monopolists because they ensure an "equal" playing field, meaning they have access to the same tech that smaller companies have. All things being equal, they can always crush the competition with their market position.
> Companies like Amazon offering open source software as a hosting service can out-compete any other companies offering the same just based on market position.
Can you please explain exactly what's wrong with that? I mean, the whole point of FLOSS is to ensure everyone has the right to access, fix, and alter the software. Why do you feel anyone's revenue is relevant?
> Liberal open source licenses are the perfect weapon for the monopolists because they ensure an "equal" playing field, meaning they have access to the same tech that smaller companies have.
Your comment makes zero sense. FLOSS is about ensuring the right to use, fix, and alter software. It's not about people with a axe to grind about competitors providing a better service.
The only weapon I see here is people trying to abuse the concept of FLOSS to complain about their inability to profit from other people's software because others do a better job.
Can you please explain exactly what's wrong with that? I mean, the whole point of FLOSS is to ensure everyone has the right to access, fix, and alter the software. Why do you feel anyone's revenue is relevant?
> Liberal open source licenses are the perfect weapon for the monopolists because they ensure an "equal" playing field, meaning they have access to the same tech that smaller companies have.
Your comment makes zero sense. FLOSS is about ensuring the right to use, fix, and alter software. It's not about people with a axe to grind about competitors providing a better service.
The only weapon I see here is people trying to abuse the concept of FLOSS to complain about their inability to profit from other people's software because others do a better job.
> The whole point of FLOSS is to ensure everyone has the right to access, fix, and alter the software. Why do you feel anyone's revenue is relevant?
Not being relevant isn't the same as not being important.
The aims of FLOSS are good thing, and they are successfully achieved when every computer in the world runs 100% FLOSS code.
But if all code is FLOSS, then the cloud giants can sleep unchallenged, because they have the best machines to run the same code as everybody else. This is an entirely unintended side-effect.
If you consider it an undesirable side-effect as well (and I do), the BSL and similar licenses are a reasonable next step. They preserve the social benefits of open source licenses, while leaving room for upstarts to build a small moat to challenge the cloud giants' gigantic ones.
Not being relevant isn't the same as not being important.
The aims of FLOSS are good thing, and they are successfully achieved when every computer in the world runs 100% FLOSS code.
But if all code is FLOSS, then the cloud giants can sleep unchallenged, because they have the best machines to run the same code as everybody else. This is an entirely unintended side-effect.
If you consider it an undesirable side-effect as well (and I do), the BSL and similar licenses are a reasonable next step. They preserve the social benefits of open source licenses, while leaving room for upstarts to build a small moat to challenge the cloud giants' gigantic ones.
> They preserve the social benefits of open source licenses
What benefits? By not being FLOSS they just removed most of the rights and freedoms that users would have with the software.
What benefits? By not being FLOSS they just removed most of the rights and freedoms that users would have with the software.
I don't think this level of absolutism is justified. I think that it's a stretch to define cloud providers as "users" in the first place:
What is Akka? A distributed messaging platform.
If you want to use Akka to move messages, then the SSPL is just like the AGPL to you. (Even if you're Amazon! No discrimination against trillion-dollar companies!)
If you want to use Akka and Akka's code to learn how messaging work, then the SSPL is just like the AGPL to you.
If you want to use Akka's code as a starting point to author your custom messaging platform, then the SSPL is just like the AGPL to you.
When is it not like the AGPL to you? Only when you don't want to actually use Akka yourself, but you want to charge others a fee to let them use Akka on your server.
In that case, and only in that case, SSPL says "you are not a user of this program and are not entitled to the Four Freedoms". I find myself in agreement with that assessment.
EDIT: I originally mentioned the BSL in this thread, that was a mistake. The BSL (free except for users >$25M) is a non-free license that I consider legitimate and understandable and better than almost any other non-free license, but less than ideal. The SSPL (free except for cloud providers) is the non-free license that I find most acceptable, to the point where I think AGPL projects will make the world a better place by switching to the SSPL.
What is Akka? A distributed messaging platform.
If you want to use Akka to move messages, then the SSPL is just like the AGPL to you. (Even if you're Amazon! No discrimination against trillion-dollar companies!)
If you want to use Akka and Akka's code to learn how messaging work, then the SSPL is just like the AGPL to you.
If you want to use Akka's code as a starting point to author your custom messaging platform, then the SSPL is just like the AGPL to you.
When is it not like the AGPL to you? Only when you don't want to actually use Akka yourself, but you want to charge others a fee to let them use Akka on your server.
In that case, and only in that case, SSPL says "you are not a user of this program and are not entitled to the Four Freedoms". I find myself in agreement with that assessment.
EDIT: I originally mentioned the BSL in this thread, that was a mistake. The BSL (free except for users >$25M) is a non-free license that I consider legitimate and understandable and better than almost any other non-free license, but less than ideal. The SSPL (free except for cloud providers) is the non-free license that I find most acceptable, to the point where I think AGPL projects will make the world a better place by switching to the SSPL.
As established in my earlier comment, your original premise and your entire argument is incorrect. Akka is not a 'messaging platform'. It's a bunch of libraries that you link in to your JVM app. No one (well, no sane person) would try to 'charge others a fee to let them use Akka' on their server because technologically that doesn't make sense. It's akin to charging people a fee for a service to concatenate strings together. Hence as you can see, the SSPL is not an appropriate fit for Akka anyway.
[deleted]
> about competitors providing a better service
The point is you can NOT outcompete Amazon on that as a smaller company. They have economics of scale on their side, brand recognition, marketing budget, the whole AWS ecosystem that locks developers in. Even if you offered a better and cheaper service (which is not really realistic) then most customers would stick to AWS because they are hosting everything else on it and it is easier that working with multiple providers.
Are you not aware how monopolists work?
The point is you can NOT outcompete Amazon on that as a smaller company. They have economics of scale on their side, brand recognition, marketing budget, the whole AWS ecosystem that locks developers in. Even if you offered a better and cheaper service (which is not really realistic) then most customers would stick to AWS because they are hosting everything else on it and it is easier that working with multiple providers.
Are you not aware how monopolists work?
> The point is you can NOT outcompete Amazon on that as a smaller company.
It looks to me that AWS only has around 30% of the cloud market, and CloudFlare is outcompeting AWS in some market segments oddly enough due to things like CloudFlare Worker's, which are developed from the V8 engine which is as FLOSS as it gets.
It looks like behind the thin veil of a badly formed "unfair competition" argument, there's only an irrational concern that revenue should be tied to rights to access software developed by a third-party.
It looks to me that AWS only has around 30% of the cloud market, and CloudFlare is outcompeting AWS in some market segments oddly enough due to things like CloudFlare Worker's, which are developed from the V8 engine which is as FLOSS as it gets.
It looks like behind the thin veil of a badly formed "unfair competition" argument, there's only an irrational concern that revenue should be tied to rights to access software developed by a third-party.
I think "smaller" there is supposed to mean "on the small end" and not a direct comparison to Amazon. CloudFlare is not an example of such a company.
> irrational concern that revenue should be tied to rights to access software developed by a third-party
It's the rational concern that major developers of widely-used software should be paid.
> irrational concern that revenue should be tied to rights to access software developed by a third-party
It's the rational concern that major developers of widely-used software should be paid.
And yet there's plenty of competition in the network infrastructure market, including by smaller players. You think DigitalOcean and Hetzner are not in a closely related market to AWS or Azure?
Time have changed and it is well possible there is a need and room for source available licenses.
Open Source is established term which offers specific freedoms which brings specific benefits (and challenges) to businesses.
While many Venture funded companies might want you to believe they are being unfairly taken advantage by the clouds it is not the full story.
Elastic for example relies on A LOT of code contributed by community, which were contributing because they could use end result under Open Source License.
Elastic changing the license changed relations here to you contribute to create the product BUT you do not get all the rights to use it any more.
In Elastic case in particular large number of cloud solutions were build which embed their solution (arguably same as Elastic embedds Lucene) who could not use Elastic after license change.
Open Source is established term which offers specific freedoms which brings specific benefits (and challenges) to businesses.
While many Venture funded companies might want you to believe they are being unfairly taken advantage by the clouds it is not the full story.
Elastic for example relies on A LOT of code contributed by community, which were contributing because they could use end result under Open Source License.
Elastic changing the license changed relations here to you contribute to create the product BUT you do not get all the rights to use it any more.
In Elastic case in particular large number of cloud solutions were build which embed their solution (arguably same as Elastic embedds Lucene) who could not use Elastic after license change.
We've had Source-Available licenses for years (MS-PL for instance, as well as many various ones from Sun/Oracle, etc.)
There's basically been a resounding "Meh" about them and the people who work on software that adopts them generally move to an open fork or the project perishes (see also the fate of Solaris, Illumos, and Oracle.)
There's basically been a resounding "Meh" about them and the people who work on software that adopts them generally move to an open fork or the project perishes (see also the fate of Solaris, Illumos, and Oracle.)
Quite. Proprietary source available projects are 'meh'.
In the past few years, it seems several notable company-backed projects have switched from the Apache licence, to some proprietary licence. I'd much prefer if instead they tried switching to a strong copyleft licence. (Granted, 'delayed open source' is far better than 'never open source'.)
In the past few years, it seems several notable company-backed projects have switched from the Apache licence, to some proprietary licence. I'd much prefer if instead they tried switching to a strong copyleft licence. (Granted, 'delayed open source' is far better than 'never open source'.)
At my previous company, we evaluated Akka to solve some queuing problems in one of our products. Akka would have become one more embedded component of a much larger product, selling >30M USD/year.
At the current price tag (USD $1995/core), Akka would have been prohibitively expensive. Akka pricing does not make sense for OEMs.
Luckily, other features were always more prioritary than moving to Akka, otherwise we'd be in trouble.
At the current price tag (USD $1995/core), Akka would have been prohibitively expensive. Akka pricing does not make sense for OEMs.
Luckily, other features were always more prioritary than moving to Akka, otherwise we'd be in trouble.
If you earn $25 million in annual revenue and have tiny margins or many cores, you may not be capable of paying $2000/year/core.
[deleted]
It all started with Scala which was a decent, functional Java (at the time) and then they formed a commercial organisation called "TypeSafe" around it. Then it took on VC money and then also renamed itself to "Lightbend" (for some reason). In this time, Akka which was one of the special library of Scala was also included in the Lightbend fold with many of the prominent devs.
While I understand that open source developers also need to make money, I do not think this mode of operation is my favorite. When a programming language / library / tool takes on VC money it is just inevitable that they will need a mode of revenue in the near future and this is one way to do it.
Anyways, between this and the Scala 2 -> 3 migration, I do not think I would recommend Scala to anyone now or touch it myself.
While I understand that open source developers also need to make money, I do not think this mode of operation is my favorite. When a programming language / library / tool takes on VC money it is just inevitable that they will need a mode of revenue in the near future and this is one way to do it.
Anyways, between this and the Scala 2 -> 3 migration, I do not think I would recommend Scala to anyone now or touch it myself.
> It all started with Scala which was a decent, functional Java (at the time) and then they formed a commercial organisation called "TypeSafe" around it. Then it took on VC money and then also renamed itself to "Lightbend" (for some reason). In this time, Akka which was one of the special library of Scala was also included in the Lightbend fold with many of the prominent devs.
IMO Scala still is a great functional alternative to Java. But this narrative you're laying out here is misrepresenting the reality. It's true Akka was a good way to get Scala adoption, but that stopped being the case a long time ago. Today, despite being still a bit niche, Scala has many other big Scala projects and frameworks that hold its weight.
And, by the way, the Scala 2 -> 3 migration is being wonderfully executed, as it's been designed. No other high level language at this point promises the same set of binary compatibility (even across 2.13 and Scala 3) as Scala does, e.g. it's much better than Java, Python, Rust, etc.
IMO Scala still is a great functional alternative to Java. But this narrative you're laying out here is misrepresenting the reality. It's true Akka was a good way to get Scala adoption, but that stopped being the case a long time ago. Today, despite being still a bit niche, Scala has many other big Scala projects and frameworks that hold its weight.
And, by the way, the Scala 2 -> 3 migration is being wonderfully executed, as it's been designed. No other high level language at this point promises the same set of binary compatibility (even across 2.13 and Scala 3) as Scala does, e.g. it's much better than Java, Python, Rust, etc.
Totally agree. Akka was a huge selling point for Scala. It's a huge loss for the ecosystem. Akka isn't "just" a library, it's a programming model. A lot of software is built around that model and it's going to be a painful effort to get rid of it. It made itself irreplaceable and now they're pulling the plug.
There will just be a fork under a different name, starting from the last freely-licensed version. Right to fork is integral to FLOSS, specifically to protect against the whole "suppliers take the ball and go home" scenario.
Who will maintain it though? It's true that Lightbend is doing almost all of the development. There is no one else who knows the code base and no one willing to learn it, since Akka is pretty uncool nowadays.
Also, Akka is rare technology -- there aren't many well functioning actors and transactional memory implementations in the world. The number of people who can continue maintaining this, is small, and such people are mostly making lots of money doing other things already, I'd think.
GP zozbot234, I'm guessing an OSS fork will go mostly unmaintained or start to source code rot, even if "maintained".
GP zozbot234, I'm guessing an OSS fork will go mostly unmaintained or start to source code rot, even if "maintained".
It isn't lost though is it? Just slightly delayed. Honestly this seems like the lightest possible "our developers need to eat" solution out there. More relaxed than GPL or AGPL or open core. If you're against this then honestly I think you're an unrealistic radical who can be safely ignored.
You're right, my statement came from a lot of frustration. I still think it's a hit for the Scala ecosystem.
The trajectory of Lightbend has been raising doubts for a while, some would argue since the renaming.
One important change coming with Scala 3 is precisely that its future doesn't depend on Lightbend's financial success anymore.
One important change coming with Scala 3 is precisely that its future doesn't depend on Lightbend's financial success anymore.
> The trajectory of Lightbend has been raising doubts for a while, some would argue since the renaming.
Definitely. I remember some of us Scala early adopters being concerned about the nonsensical name change, and being assured by others that nothing fundamental was being changed, that Lightbend was "a more user friendly name than TypeSafe" (as if the notion of type-safety was a barrier to entry for goddamn Scala, for crying out loud).
Seems we skeptics were proven right.
Definitely. I remember some of us Scala early adopters being concerned about the nonsensical name change, and being assured by others that nothing fundamental was being changed, that Lightbend was "a more user friendly name than TypeSafe" (as if the notion of type-safety was a barrier to entry for goddamn Scala, for crying out loud).
Seems we skeptics were proven right.
How so? Aren't they the most significant contributor by far?
Not directly no. The last major contribution from Lightbend employees was the big collections rewrite in the standard library (shared by Scala 2.13 and 3.x). The Scala 3 compiler and core tooling is developed by the LAMP, the Scala Center, VirtusLab and a few other people. Lightbend is maintaining Scala 2 compilers (2.11, 2.12, 2.13).
They've always floundered around trying to find something that stuck that could also have a path to profit.
Being around the edges of the tech orgs that went in early on Scala it often felt like the Scala ecosystem initially thrived (the likes of Twitter releasing genuine quality oss in particular) despite the lack-lustre job of Typsesafe / Lightbend to cement themselves at the center.
With play being given to the community, lagom being underwhelming and a bit of a catch-the-wave thing, it's only really Akka that endures on top of the core language, which isn't really a great showing after so long.
Being around the edges of the tech orgs that went in early on Scala it often felt like the Scala ecosystem initially thrived (the likes of Twitter releasing genuine quality oss in particular) despite the lack-lustre job of Typsesafe / Lightbend to cement themselves at the center.
With play being given to the community, lagom being underwhelming and a bit of a catch-the-wave thing, it's only really Akka that endures on top of the core language, which isn't really a great showing after so long.
They also developed Slick, which has been abandoned for a while now, unfortunately.
> they formed a commercial organisation called "TypeSafe" around it. Then it took on VC money and then also renamed itself to "Lightbend"
My alarm bells were ringing as far back as that name change. Everyone I knew who used Scala thought the name change was silly and foreboding of bad things. "TypeSafe" has a nice, technical ring to it, and it embodied what we thought Scala was all about.
Now, "Lightbend". Talk about a fluffy, meaningless, VC-friendly name. It sounded ominously wrong back then. I guess we skeptics were proven right after all these years...
My alarm bells were ringing as far back as that name change. Everyone I knew who used Scala thought the name change was silly and foreboding of bad things. "TypeSafe" has a nice, technical ring to it, and it embodied what we thought Scala was all about.
Now, "Lightbend". Talk about a fluffy, meaningless, VC-friendly name. It sounded ominously wrong back then. I guess we skeptics were proven right after all these years...
It's such an absolutely terrible name too. Could nobody at Typesafe come up with something less generic and soulless? Really astonishing how you can fuck it up so badly.
I’ve never quite understood the amount of rancor that changes like this elicit here. It seems like people come out of the woodworks acting like they have been personally affronted by this, or that this is somehow directly affecting their lives.
Is everybody here (planning on?) using this software to build companies with more than $25 million in revenue… and they can’t use something else with a more permissible license… and don’t think they could or should pay a licensing fee when they (inevitably?) hit that revenue target?
Is everybody here (planning on?) using this software to build companies with more than $25 million in revenue… and they can’t use something else with a more permissible license… and don’t think they could or should pay a licensing fee when they (inevitably?) hit that revenue target?
Bait and switch is never nice, whether Google does it or putative open source projects. A lot of developers work for companies that has more than $25M in revenue, and now a ton of them is going to get shit from management because they added this cuckoo egg dependency back when it used an open source license.
I have no problem with companies using whatever license, I do have trouble with them getting traction being open and then turning around as soon as they can squeeze a little money out of the people who were fooled.
I don't use Akka, but I feel the pain of the people who did that and now has to tear the thing out. Because I don't see how anyone would want to use it, that pricing is completely ridiculous. No one should pay per vCPU, much less those extortionate amounts.
I have no problem with companies using whatever license, I do have trouble with them getting traction being open and then turning around as soon as they can squeeze a little money out of the people who were fooled.
I don't use Akka, but I feel the pain of the people who did that and now has to tear the thing out. Because I don't see how anyone would want to use it, that pricing is completely ridiculous. No one should pay per vCPU, much less those extortionate amounts.
Bait and switch?
They will be free to continue using the version of Akka they currently use. If there was ever any assumption of future free versions, without remuneration, that was misguided. Akka could have been abandoned at any moment.
If management blamed me for the company blissfully reaping the benefits of open source, I would be glad to work elsewhere. The customers of Akka have gotten exactly as much as they have paid for.
They will be free to continue using the version of Akka they currently use. If there was ever any assumption of future free versions, without remuneration, that was misguided. Akka could have been abandoned at any moment.
If management blamed me for the company blissfully reaping the benefits of open source, I would be glad to work elsewhere. The customers of Akka have gotten exactly as much as they have paid for.
> I don't use Akka, but I feel the pain of the people who did that and now has to tear the thing out.
Did you feel their elation at being able to use Akka for free? They can, as long as they stay on the Apache versions.
> Bait and switch is never nice
I don't see any bait and switch here. If you can find Akka devs saying "we'll let you use this for free forever and we'll keep updating it for free forever" then I'll eat it, but until then, this is just how software licensing works.
Did you feel their elation at being able to use Akka for free? They can, as long as they stay on the Apache versions.
> Bait and switch is never nice
I don't see any bait and switch here. If you can find Akka devs saying "we'll let you use this for free forever and we'll keep updating it for free forever" then I'll eat it, but until then, this is just how software licensing works.
Is it really bait and switch if the company has a contributor/committer license agreement in place?
Having that license made it clear the company want to reserve the right to change the license, including going to closed source if they decide to.
Plus, you made it sounds like an open source project has a moral obligation to the companies that uses it for free. That seems backwards.
Having that license made it clear the company want to reserve the right to change the license, including going to closed source if they decide to.
Plus, you made it sounds like an open source project has a moral obligation to the companies that uses it for free. That seems backwards.
> Is it really bait and switch if the company has a contributor/committer license agreement in place?
Even without the CLA, it was permissively licensed. Having your code rolled into a proprietary product is always a possibility you're consenting to when you contribute code under such a license.
Even without the CLA, it was permissively licensed. Having your code rolled into a proprietary product is always a possibility you're consenting to when you contribute code under such a license.
$2k per vCPU is 16k for a pretty standard 8 core ec2. The ec2 itself might cost ~$300 a month or $3600 a year. Where the hell did they come up with this pricing model lol.
This comment is really buried in the discussion. $2000 per vCPU for a library is absolutely insane pricing, unless you're running Akka on a single bare metal server, this is a non-starter for anyone.
Really unsure what Lightbend is trying to do here, this seems like the death of Akka.
Really unsure what Lightbend is trying to do here, this seems like the death of Akka.
> unless you're running Akka on a single bare metal server
A tiny single bear metal server, at that; most server hardware I use has 48 cores!
A tiny single bear metal server, at that; most server hardware I use has 48 cores!
Running it at Raspberry Pi would cost you 8k.
There is like nothing where that would be cheap. Even if you looked for something that has very high IPC and clock rate.... the CPU with that will have at least 4 cores if not more.
There is like nothing where that would be cheap. Even if you looked for something that has very high IPC and clock rate.... the CPU with that will have at least 4 cores if not more.
Sounds like Oracle.
I'm 99% sure they got this pricing model from their current contracts for support contracts with enterprise companies.
>A lot of developers work for companies that has more than $25M in revenue, and now a ton of them is going to get shit from management because they added this cuckoo egg dependency back when it used an open source license.
No, they're just going to not bump Akka until they can either find a replacement, or accept a new version with a new license. You do not need to bump it every month, you can live with half a year of not patching it while you make your decision.
Additionally, your company is making 25 million in revenue, they can afford the extremely minimal cost. Not accepting that cost shows the company for what it is, a bunch of leeches.
No, they're just going to not bump Akka until they can either find a replacement, or accept a new version with a new license. You do not need to bump it every month, you can live with half a year of not patching it while you make your decision.
Additionally, your company is making 25 million in revenue, they can afford the extremely minimal cost. Not accepting that cost shows the company for what it is, a bunch of leeches.
Like, have you even looked at those prices? $2K per CPU isn't extremely minimal for anybody. If you have a hundred servers with 16 CPUs that's $3M. For just a library.
Speaking of a bunch of leeches.
Speaking of a bunch of leeches.
If you've built your entire company around a single library that does all the heavy lifting and you need a hundred servers with 16 CPUs to run just that, why do you think you're entitled to not pay your fair share for it ? Clearly, you chose Akka because it was valuable enough to allow you to bring your company to that scale.
If half of your company is based around gluing together a bunch of things that can only run because of Akka, it is fair that you pay half of your revenue to the people who actually make your company work.
If half of your company is based around gluing together a bunch of things that can only run because of Akka, it is fair that you pay half of your revenue to the people who actually make your company work.
> Clearly, you chose Akka because it was valuable enough to allow you to bring your company to that scale.
If that selection was made when it was being given away for free, it's rather hard to make the determination.
> If half of your company is based around gluing together a bunch of things that can only run because of Akka, it is fair that you pay half of your revenue to the people who actually make your company work.
And half to Linux, and half to GNU, and half to Apple, and half to your compiler of choice? There are a lot of critical pieces of infrastructure; I'm not really sure that this line of reasoning holds up very well. Unless of course, you think this one library is so magical that it deserves more money than all the other critical components.
If that selection was made when it was being given away for free, it's rather hard to make the determination.
> If half of your company is based around gluing together a bunch of things that can only run because of Akka, it is fair that you pay half of your revenue to the people who actually make your company work.
And half to Linux, and half to GNU, and half to Apple, and half to your compiler of choice? There are a lot of critical pieces of infrastructure; I'm not really sure that this line of reasoning holds up very well. Unless of course, you think this one library is so magical that it deserves more money than all the other critical components.
It's a library. I don't need hundreds of servers to run the library. I need hundreds of servers to run the applications that have it as a dependency.
Imagine if something like gRPC was priced like that.
Imagine if something like gRPC was priced like that.
Yeah, or spring (vmware), or guava (google), or react (facebook), or dozens of other common dependencies.
Thankfully I have managed to avoid Akka in our products but the precedent being set here is worrisome.
Thankfully I have managed to avoid Akka in our products but the precedent being set here is worrisome.
It’s usurious to charge $3 million for the privilege of making $25 million?
What is a not-leech price for critical infrastructure that allows you to generate $25 million? $1?
What is a not-leech price for critical infrastructure that allows you to generate $25 million? $1?
> I don't use Akka, but I feel the pain of the people who did that and now has to tear the thing out.
I highly suspect very few will ahve to tear it out. It'll cost more money to replace than it would to pay license fees for many companies. Developer time costs money.
> Because I don't see how anyone would want to use it, that pricing is completely ridiculous. No one should pay per vCPU, much less those extortionate amounts.
These are companies making lots of money. The license fee isn't that much when it comes to the amount the company is making.
I highly suspect very few will ahve to tear it out. It'll cost more money to replace than it would to pay license fees for many companies. Developer time costs money.
> Because I don't see how anyone would want to use it, that pricing is completely ridiculous. No one should pay per vCPU, much less those extortionate amounts.
These are companies making lots of money. The license fee isn't that much when it comes to the amount the company is making.
> I highly suspect very few will ahve to tear it out. It'll cost more money to replace than it would to pay license fees for many companies. Developer time costs money.
That is the strategy companies are using to monetize these sort of projects. Give it away for free and then charge when a company has to make the choice of spending money to get rid of it and to replace it or to just pay for it. The lesson to take away is that any open source supported by a company will potentially become something that will have to be licensed commercially, so if anything will create an incentive to not use open source.
That is the strategy companies are using to monetize these sort of projects. Give it away for free and then charge when a company has to make the choice of spending money to get rid of it and to replace it or to just pay for it. The lesson to take away is that any open source supported by a company will potentially become something that will have to be licensed commercially, so if anything will create an incentive to not use open source.
Indeed, and that's predatory behavior and it hurts the open source community because of the mistrust it sows.
Bad news. And people here are asking where's the bait and switch? Amazing.
Bad news. And people here are asking where's the bait and switch? Amazing.
Technically they make a lot of revenue. The $25M threshold isn't a threshold on profitability, just company size. They could be losing money.
It's funny to see how HN flipped on this subject. My company was stung by Handsontable switching to a proprietary license https://news.ycombinator.com/item?id=19488642 and the top comment back in 2019 was "Great to hear".
Your company wasn't stung by it. You chose to get stung by it. Just pin your version and live with it. If it's such a critical piece of your business, either pay a fair price for it, or make it yourself.
So you are basically saying "don't use open source software". Great.
"Pinning your version" forever isn't a viable strategy in lots of cases.
"Pinning your version" forever isn't a viable strategy in lots of cases.
No, I'm saying to not be a leech.
I apologize, my reply was uncharitable. You are right that private companies should stop being leeches and give back to the community.
I just wish we all collectively made FOSS work, because to my mind it's the greatest development in computing history, instead of going the proprietary road once again. Which I think is bad for all of us, even if short term it might look like a solution.
But yes, leeching is a problem.
I just wish we all collectively made FOSS work, because to my mind it's the greatest development in computing history, instead of going the proprietary road once again. Which I think is bad for all of us, even if short term it might look like a solution.
But yes, leeching is a problem.
It's not the change, it's the way the sell it. If they have just been up front about it ("Look, OSS isn't working for us so we are going to take it closed source.") then there would be much less drama. Instead they always try to weasel-word how they believe they are still open source when they are not in a lame attempt to not scare away their contributors.
Completely agree. The wording and justification is just terrible.
I was once working for a company who had stellar growth to $100M+ revenue and millions of users, started with a "open source" framework for distributed caching, needed to buy the enterprise version for support, the vendor got bought up by a large evil enterprise and the licensing costs got 10x without pre-warning, and it was a very complicated task to get that core technology pulled (mostly because it was too complicated, but also because it was to expensive) out over years, replaced by Redis.
I would be very careful to use "open source" technology from companies that depend on sales from this piece of technology. Did this particular piece help get the company to $100M+? Yes, and people too often forget where technology got them to, when blaming said technology. Could something other have work too? (Yes, see Redis)
I would be very careful to use "open source" technology from companies that depend on sales from this piece of technology. Did this particular piece help get the company to $100M+? Yes, and people too often forget where technology got them to, when blaming said technology. Could something other have work too? (Yes, see Redis)
> I would be very careful to use "open source" technology from companies that depend on sales from this piece of technology.
I feel your comment is a gross misrepresentation of the problems posed by replacing a FLOSS license like Apache with a proprietary one.
Software that was released yesterday under a license like Apache will remain FLOSS today, and usable under the exact same terms. Subsequent releases won't, but the one version you've been using to sell your product/service will remain usable under the old terms.
I feel your comment is a gross misrepresentation of the problems posed by replacing a FLOSS license like Apache with a proprietary one.
Software that was released yesterday under a license like Apache will remain FLOSS today, and usable under the exact same terms. Subsequent releases won't, but the one version you've been using to sell your product/service will remain usable under the old terms.
I've used many open source projects in the past, several of them had critical bugs, that did not get fixed (e.g. either the core developer abandoned it, or the BDFL said WONTFIX). A software without someone fixing the problems is - YMMV - too risky to use. And fixing a bug on your own in something complex and complicated like Akka without breaking things is no easy task (essentially creating and maintaining your own fork).
To me chosing an open source framework to base my future on the framework needs a healthy community of committers.
To me chosing an open source framework to base my future on the framework needs a healthy community of committers.
> I've used many open source projects in the past, several of them had critical bugs, that did not get fixed (...)
And that's perfectly fine. FLOSS assures you have access to the source code so that you can dig in and fix any issue you feel strongly about.
What FLOSS does not grant you is a right to demand maintenance and unpaid work from third parties.
If your view on FLOSS is so militant about the right to maintenance,you should also be mindful of the fact that it's you and people like you who are expected to do said maintenance.
And that's perfectly fine. FLOSS assures you have access to the source code so that you can dig in and fix any issue you feel strongly about.
What FLOSS does not grant you is a right to demand maintenance and unpaid work from third parties.
If your view on FLOSS is so militant about the right to maintenance,you should also be mindful of the fact that it's you and people like you who are expected to do said maintenance.
"If your view on FLOSS is so militant about the right to maintenance"
No it isn't, and I've never said so. I've created several open source projects which got quite successful without taking money or the intention of taking money and gave maintainance as I saw fit.
"so that you can dig in and fix any issue you feel strongly about."
Trying to fix critical bugs twice, because their was no support, without being able to fix them, I think this often is delusional. Even finding people to pay willing to fix such bugs is a challenge (but we did pay several $10k to people for fixing bugs). But as I've said, YMMV and you might have been able to fix critical bugs in something like the storage backend of MySQL, I probably can't without breaking things.
There is a difference between fixing a missed edge case in a date formatting library or a race condition in a MySQL backend.
No it isn't, and I've never said so. I've created several open source projects which got quite successful without taking money or the intention of taking money and gave maintainance as I saw fit.
"so that you can dig in and fix any issue you feel strongly about."
Trying to fix critical bugs twice, because their was no support, without being able to fix them, I think this often is delusional. Even finding people to pay willing to fix such bugs is a challenge (but we did pay several $10k to people for fixing bugs). But as I've said, YMMV and you might have been able to fix critical bugs in something like the storage backend of MySQL, I probably can't without breaking things.
There is a difference between fixing a missed edge case in a date formatting library or a race condition in a MySQL backend.
Hey, at least you could try, right? Try fixing bugs in any ordinary proprietary, non-FLOSS software - or even worse for that matter, a SaSS ("Service as Software Substitute") offering. It's pretty much impossible, by definition.
Infinispan and Red Hat being bought by IBM?
The reason it brings people out of the woodworks is the way that it erodes trust. How many more people will decide that they deserve more money, and relicense their software, leaving me in a bind? I used to know that software licenses were generally stable, and an Apache2.0 project was safe to use, and I could contribute and use the software knowing generally that my contributions would be part of something that continued to become greater over time.
Now, I don't know if I can contribute (which includes usage, because the more I use it, the better I understand it and the more confidently I can recommend it and help others to use it) to software that's trying to do the OSS paid support model, because that company might decide at any point that they're not "getting enough value" and relicense to terms that don't work for me, thus causing me to need to either live with the software as is, no bugfixes or new features, or rework it out of my architecture.
Now, I don't know if I can contribute (which includes usage, because the more I use it, the better I understand it and the more confidently I can recommend it and help others to use it) to software that's trying to do the OSS paid support model, because that company might decide at any point that they're not "getting enough value" and relicense to terms that don't work for me, thus causing me to need to either live with the software as is, no bugfixes or new features, or rework it out of my architecture.
This is where I don’t fully understand what “trust” means here. It kind of sounds like it’s “trusting” that users will be able to profit from the software in perpetuity at the expense of the developer.
Isn’t one of the core ideals of FOSS forking? If you’re certain that no other person could possibly fork a piece of software and provide bug fixes and new features, isn’t that a tacit admission that the primary maintainer is the only person on earth that could do so?
If I were the only person on earth that could write a bit of software, I would not do that for free. It would be downright weird and entitled to expect that from me.
If I wasn’t the only person on earth that could write such code, I would happily watch and encourage the people that prefer to have an Apache 2.0 licensed derivative of the original work.
Isn’t one of the core ideals of FOSS forking? If you’re certain that no other person could possibly fork a piece of software and provide bug fixes and new features, isn’t that a tacit admission that the primary maintainer is the only person on earth that could do so?
If I were the only person on earth that could write a bit of software, I would not do that for free. It would be downright weird and entitled to expect that from me.
If I wasn’t the only person on earth that could write such code, I would happily watch and encourage the people that prefer to have an Apache 2.0 licensed derivative of the original work.
Interesting that you went to profit immediately. Much of my use of OSS is personal and for fun and because I believe it makes the world a better place that I can run things like Linux and postgres and get so much out of my computer that would never be possible if I had to pay for all of this. Furthermore, I don't like doing things many different ways, because it's a waste of time and energy, so I try to bring my experience with me when I work somewhere. And I give back in the form of my own free and generously licensed software contributions.
Akka may have been steered by a group of people incentivised financially to support it, through support agreements or whatever, but it currently has 774 contributors. And frankly, never would have become what it is if it started closed source. Probably wouldn't have gotten off the ground honestly, as something open source would have eaten its lunch. I don't use it, but the idea that I can use something anywhere in perpetuity is part of why I choose to use and give back to FOSS. Many feel the same.
Sure. Anybody can fork the software and maintain it. I love that OpenSearch did exactly that when Elastic decided it wanted money for something built on the efforts of a community. But I also know that forks are another waste of energy. Maintaining two branches that do similar things is silly if I can let you do your job while I do mine. I'm not maintaining my own OS, or my own database, or my own terminal, etc etc. Add to that, how many individuals would be willing to fork when one branch has demonstrated a willingness to make choices in favor of money? It makes me wonder if they'll also push for patents or law suits against those who might add features to Akka Prime or some cleverly named fork.
Frankly, I don't use Akka and I'm definitely not going to now, so as far as I'm concerned, Akka is more than welcome to sign their own death warrant. But this trend of building software with community contributions and then trying to profit from it is worrisome and frankly, pretty close to theft. I don't see any of these companies retroactively paying their contributors, so it's definitely not about "what's right." It's a cash grab branded as sustainability, and it has a chilling effect for me, that pushes against the ideals of OSS.
Akka may have been steered by a group of people incentivised financially to support it, through support agreements or whatever, but it currently has 774 contributors. And frankly, never would have become what it is if it started closed source. Probably wouldn't have gotten off the ground honestly, as something open source would have eaten its lunch. I don't use it, but the idea that I can use something anywhere in perpetuity is part of why I choose to use and give back to FOSS. Many feel the same.
Sure. Anybody can fork the software and maintain it. I love that OpenSearch did exactly that when Elastic decided it wanted money for something built on the efforts of a community. But I also know that forks are another waste of energy. Maintaining two branches that do similar things is silly if I can let you do your job while I do mine. I'm not maintaining my own OS, or my own database, or my own terminal, etc etc. Add to that, how many individuals would be willing to fork when one branch has demonstrated a willingness to make choices in favor of money? It makes me wonder if they'll also push for patents or law suits against those who might add features to Akka Prime or some cleverly named fork.
Frankly, I don't use Akka and I'm definitely not going to now, so as far as I'm concerned, Akka is more than welcome to sign their own death warrant. But this trend of building software with community contributions and then trying to profit from it is worrisome and frankly, pretty close to theft. I don't see any of these companies retroactively paying their contributors, so it's definitely not about "what's right." It's a cash grab branded as sustainability, and it has a chilling effect for me, that pushes against the ideals of OSS.
>Interesting that you went to profit immediately. Much of my use of OSS is personal and for fun and because I believe it makes the world a better place
Akka’s new license only charges entities that are making $25 million dollars per year. I do not think this impacts hobbyist’s ability to play around with it, so yes, profit is a very obvious point to bring up. The only limitation is literally on organizations that are massively profiting off of it.
It’s also “interesting” that you didn’t address my questions aside from:
>I also know that forks are another waste of energy.
That is not knowledge that I share. I was under the impression that lots of good software has been built by forking other good software but maybe I’m wrong!
>Frankly, I don't use Akka and I'm definitely not going to now, so as far as I'm concerned, Akka is more than welcome to sign their own death warrant.
Why on earth are you so enthusiastic about this software then? Are you shelving your plans to build a $25 million per year business on top of this software? Is that what normally happens when you play around with OSS for fun?
As for their death warrants, I hope they sign some big fat checks instead of doing free work to impress random people that have a convenient quasi-religious morality of “money for me but not for thee”
Akka’s new license only charges entities that are making $25 million dollars per year. I do not think this impacts hobbyist’s ability to play around with it, so yes, profit is a very obvious point to bring up. The only limitation is literally on organizations that are massively profiting off of it.
It’s also “interesting” that you didn’t address my questions aside from:
>I also know that forks are another waste of energy.
That is not knowledge that I share. I was under the impression that lots of good software has been built by forking other good software but maybe I’m wrong!
>Frankly, I don't use Akka and I'm definitely not going to now, so as far as I'm concerned, Akka is more than welcome to sign their own death warrant.
Why on earth are you so enthusiastic about this software then? Are you shelving your plans to build a $25 million per year business on top of this software? Is that what normally happens when you play around with OSS for fun?
As for their death warrants, I hope they sign some big fat checks instead of doing free work to impress random people that have a convenient quasi-religious morality of “money for me but not for thee”
It's a problem for people who use Akka already, not those who won't adopt it. The choices are to rewrite the service, pay a massive licensing cost ($2k _per core_!), or live with 3-year old releases with no security updates. It's very disruptive.
I hear you, but this was always the deal. If anyone ever said, "and we can use this for free forever and it will be updated for us for free forever" they were wrong.
Akka devs are 100% within their rights to set the terms of use for their product and thus their work. There was no bait and switch here. This is just how licensing works.
Akka devs are 100% within their rights to set the terms of use for their product and thus their work. There was no bait and switch here. This is just how licensing works.
I agree. It's still a very disruptive change for enterprise Akka users.
but is it more than $2k per core disruptive? if so, why not just pay up, and not have the disruption?
Sure? Which option is better totally depends on your use case. If it's a microservice running on 500 cores ($1M/year licensing), and a rewrite would cost 1 person-year (say $300k), then the rewrite is clearly worth it. But if you're running on 10 cores, and a rewrite would take 10 person-years... then it makes more sense to pay.
This is where I’m confused. Are the average current users of Akka making more than $25 million in revenue? Or is the average Akka user on track to hit $25 million before they can figure out costs or other options?
The users I know personally work on internal services in large companies. They didn't necessarily choose it, some did but some just inherited a codebase and have to deal with it. I work in a large company though, so I have no idea if this is average or just my personal bubble :)
I think people don’t take the license of projects they use seriously. The license allows such relicensing.
Use a copyleft-licensed project with outside contributors if you want the project to stay free.
Use a copyleft-licensed project with outside contributors if you want the project to stay free.
I don't think the license is too important as there's always a chance the software gets abandoned instead.
Rather look at how many organizations are paying for contributions. If it's all resting on a single back there's increased danger.
Still, the only way to guarantee continued development is paying for it (or doing it yourself).
Rather look at how many organizations are paying for contributions. If it's all resting on a single back there's increased danger.
Still, the only way to guarantee continued development is paying for it (or doing it yourself).
The problem isn't usually charging for something, it's when the price model changes in a fundamental way. Especially when the pricing model scales in a way that is very expensive for some subset of users. Pricing models contain assumptions about how people use the software, you can easily get priced out if you use it in a bit of a different way than usual.
If you have all the information about the pricing model up front you can make good decisions about using the software or not. If the pricing model changes your decisions can get invalidates and might require serious effort to remove the dependency on that piece of software.
If you have all the information about the pricing model up front you can make good decisions about using the software or not. If the pricing model changes your decisions can get invalidates and might require serious effort to remove the dependency on that piece of software.
> I’ve never quite understood the amount of rancor that changes like this elicit here.
It's bait and switch, and nobody likes that. They used a true open source license, earning them developer good will, until it stopped serving their purposes. It also undermines open source as a concept.
It's bait and switch, and nobody likes that. They used a true open source license, earning them developer good will, until it stopped serving their purposes. It also undermines open source as a concept.
Because we're unselfish? Society would be a way worse place if nobody ever opposed anything bad unless it harmed them personally.
As a data point, this change will mean a lot of work for us (we built cluster discovery on top of Akka Cluster at Neo4j). I'm not thrilled, but I respect their right to make these changes, and personally think that BSL with a timed revert to Apache 2.0 is a meaningful compromise.
Enterprises have to be sustainable. If you're furious with Lightbend for making this change to protect their bottom line, then you can always fork one of the last open source versions and maintain/fix that yourself. But most people won't do that, because if they did they'd likely have been active contributors to the project before now, reducing the ongoing maintenance burden on Lightbend and potentially avoiding them feeling the need to close-source in the first place.
Enterprises have to be sustainable. If you're furious with Lightbend for making this change to protect their bottom line, then you can always fork one of the last open source versions and maintain/fix that yourself. But most people won't do that, because if they did they'd likely have been active contributors to the project before now, reducing the ongoing maintenance burden on Lightbend and potentially avoiding them feeling the need to close-source in the first place.
Neo4j made a similarly deceptive play with their "open source" product, did they not?
> Production use of the software requires a commercial license from Lightbend
I.e. it's not free anymore. That's what the title should say, instead we get an history lesson.
I.e. it's not free anymore. That's what the title should say, instead we get an history lesson.
It's not free any more for companies >$25M in annual revenue.
It's not gratis anymore for companies >$25M in annual revenue. It's not free as in speech anymore for anyone.
If we consider the idea of "free speech FOR x" then is it really free speech for nobody? Most people can do anything they want with it.
I can't combine it with GPL'd programs.
Not even locally?
And even then that's mostly because the GPL won't let you. You can combine it with MIT license programs, right?
And even then that's mostly because the GPL won't let you. You can combine it with MIT license programs, right?
> Not even locally?
So much for freedom to distribute, I guess.
> And even then that's mostly because the GPL won't let you. You can combine it with MIT license programs, right?
How about this instead? I can't release a free derivative work of it.
So much for freedom to distribute, I guess.
> And even then that's mostly because the GPL won't let you. You can combine it with MIT license programs, right?
How about this instead? I can't release a free derivative work of it.
If we go back to "free speech for [category of people]", then you can release a derivative that's free for most users and all individuals. That's part of why I find that wording interesting. It's not free to everyone but there are often legal restrictions even on GPL code...
> there are often legal restrictions even on GPL code
The difference is that they don't restrict freedom, but rather the power to withhold freedom from others: https://www.gnu.org/philosophy/freedom-or-power.en.html
The difference is that they don't restrict freedom, but rather the power to withhold freedom from others: https://www.gnu.org/philosophy/freedom-or-power.en.html
No I mean like export and patent and anti-circumvention and author's rights. Things that restrict freedom.
Can you give an example of GPL'd software that actually has such restrictions?
Cryptographic libraries might be okay right now but traditionally have had very widespread export controls. So, linux kernel and basically anything doing crypto. Anything with german authors has irrevocable control tied to that. If there's a GPL program that decrypts blurays it's likely a violation of the DMCA, not sure if one exists right now.
For patents, there's tons. x264 is an easy one.
For patents, there's tons. x264 is an easy one.
The license change is prominent in the title, even if digging into the exact price and terms part comes a few paragraphs down.
History lessons are always weird in these kind of announcements, but I think this one isn't that bad or deceptive in its approach.
History lessons are always weird in these kind of announcements, but I think this one isn't that bad or deceptive in its approach.
To everyone who thinks that $2k/vCPU is a lot of money, it's not.
First, if you're running it on an 8-core server, that's $16k per year, which is about what many companies are paying for an enterprise support contract. It's not much when you consider that it gives you access to Akka engineers at the cost of 1/10 of an FTE.
Second, the $2k number is a list price. All large enterprise deals are negotiated, and nearly all are discounted from the list price. Akka probably won't discount small deals, but they'll be forced to discount larger ones if the buyer has an alternative. Plus, the buyer will demand SLAs, dedicated support, and will often demand changes to the license and custom work on the software itself (tweaks to make it work with X, etc.)
Akka and their larger customers will make it work. The purpose of this license change is to give Akka the ability to get their customers to the table in the first place.
First, if you're running it on an 8-core server, that's $16k per year, which is about what many companies are paying for an enterprise support contract. It's not much when you consider that it gives you access to Akka engineers at the cost of 1/10 of an FTE.
Second, the $2k number is a list price. All large enterprise deals are negotiated, and nearly all are discounted from the list price. Akka probably won't discount small deals, but they'll be forced to discount larger ones if the buyer has an alternative. Plus, the buyer will demand SLAs, dedicated support, and will often demand changes to the license and custom work on the software itself (tweaks to make it work with X, etc.)
Akka and their larger customers will make it work. The purpose of this license change is to give Akka the ability to get their customers to the table in the first place.
> First, if you're running it on an 8-core server, that's $16k per year, which is about what many companies are paying for an enterprise support contract.
Which is exactly why this is so unreasonable. The minimum spend for the "standard" license is 40 cores -- which means you're paying at least $80k/yr for a support contract which won't even assign you an account manager or guarantee a response any faster than "4 business days" (yes, really). And as you scale up, it only gets more expensive, and you don't get anything more for your money.
Which is exactly why this is so unreasonable. The minimum spend for the "standard" license is 40 cores -- which means you're paying at least $80k/yr for a support contract which won't even assign you an account manager or guarantee a response any faster than "4 business days" (yes, really). And as you scale up, it only gets more expensive, and you don't get anything more for your money.
I did not see the part about the minimum spend. You're right; they'll probably run into significant resistance on that from the smaller customers.
An 8-core server? Please. Just my team uses 70 vCores (peak) in our Kubernetes cluster. Without a custom licensing agreement that's $140k/year. The whole company is bound to pay well over $500k/year.
Furthermore, most people here (as usual) seem to be completely ignorant about what Akka is. The vast majority of Akka users only ever interact with Akka through other libraries that depend on it: Akka-HTTP, Akka-Streams, Alpakka Connectors, etc. Hardly anyone actually uses Akka actors directly, the Akka Cluster platform or recently implemented distributed programming features (like Akka persistence) that makes up the business model of Lightbend. It's essentially a runtime system; an implementation detail. It's no surprise that none of these users ever make contributions back to a software that is so far removed from business code.
Furthermore, most people here (as usual) seem to be completely ignorant about what Akka is. The vast majority of Akka users only ever interact with Akka through other libraries that depend on it: Akka-HTTP, Akka-Streams, Alpakka Connectors, etc. Hardly anyone actually uses Akka actors directly, the Akka Cluster platform or recently implemented distributed programming features (like Akka persistence) that makes up the business model of Lightbend. It's essentially a runtime system; an implementation detail. It's no surprise that none of these users ever make contributions back to a software that is so far removed from business code.
Since they aren't charging any companies that make less than $25 million a year this sounds reasonable.
Most folks here don't seem to grasp the cost of most enterprise software, Oracle has been charging 10x this for decades now.
https://www.oracle.com/assets/technology-price-list-070617.p...
Most folks here don't seem to grasp the cost of most enterprise software, Oracle has been charging 10x this for decades now.
https://www.oracle.com/assets/technology-price-list-070617.p...
If you think from a different perspective that may be not reasonable. Consider a company that has multiple sources of income. One of the sources uses Akka and brings only, for example, 2.5 million a year. And now the expenses of running it will grow considerably, it may even become on the verge of sustainability because total income of the company is more than $25 million. It's not very reasonable in this case. That's why usually vendors have different plans to choose from.
You can buy a hell lot more computing at 2k/vCPU to offset performance tho.
And hiring a consultant for few months to fix your performance problems is also a hell lot cheaper than paying that much per core, forever.
> Akka and their larger customers will make it work. The purpose of this license change is to give Akka the ability to get their customers to the table in the first place.
Translation: They depend on our software enough that the rewrite is no alternative, they don't have enough onboard talent to fork it, and they have enough money to pay the price.
And hiring a consultant for few months to fix your performance problems is also a hell lot cheaper than paying that much per core, forever.
> Akka and their larger customers will make it work. The purpose of this license change is to give Akka the ability to get their customers to the table in the first place.
Translation: They depend on our software enough that the rewrite is no alternative, they don't have enough onboard talent to fork it, and they have enough money to pay the price.
I had used akka several years before for a commercial project. It worked wonder for me. Personally I have no issue with their change of license. Author has authority, as simple as that. I'm willing to pay for something useful. People seem to take a moral high ground when it comes to software.
If someone decide to make some useful project opensource. Full respect. If they changed their mind later to make the project proprietary, still full respect. It's like some kind neighbour decides to clean the street for free because it makes the neighbourhood cleaner for everyone. We are not in position to demand the status quo but be grateful of.
There are many projects I would happily pay for. Nginx, zeromq, django, react, elasticsearch, to name a few.
If someone decide to make some useful project opensource. Full respect. If they changed their mind later to make the project proprietary, still full respect. It's like some kind neighbour decides to clean the street for free because it makes the neighbourhood cleaner for everyone. We are not in position to demand the status quo but be grateful of.
There are many projects I would happily pay for. Nginx, zeromq, django, react, elasticsearch, to name a few.
The "moral high ground" is a recognition of the true dynamic in open source.
What really happens is:
1) Project is open source
2) People use the project because it is open source
3) People contribute bug reports and fixes, creating value and improving the open source project because it is open source
4) People spread the word about the project, free marketing because it is open source
5) Maintainers decide to relicense, privatizing the value created by the community.
The "success" was a social phenomenon, not merely the efforts of the maintainers.
Relicensing is a betrayal of the community that was built around the software.
What really happens is:
1) Project is open source
2) People use the project because it is open source
3) People contribute bug reports and fixes, creating value and improving the open source project because it is open source
4) People spread the word about the project, free marketing because it is open source
5) Maintainers decide to relicense, privatizing the value created by the community.
The "success" was a social phenomenon, not merely the efforts of the maintainers.
Relicensing is a betrayal of the community that was built around the software.
I think it's simpler than that, just from their relicensing FAQ: https://www.lightbend.com/akka/license-faq
> Akka requires significant investment in order to maintain its position as a preeminent distributed systems runtime. Many organizations have adopted Akka and are seeing significant benefits for their organizations.
> However, in recent years an increasing number of those organizations have elected to self-support without either contributing back to the community or by investing in annual subscriptions. We have an ambitious roadmap for the future of Akka and require a way to fund and sustain that development.
> We believe that larger organizations that are seeing business benefits from Akka should contribute to the ongoing health and evolution of the project.
They need money to continue development, and the current model isn't generating enough revenue for them to stay in business.
> Akka requires significant investment in order to maintain its position as a preeminent distributed systems runtime. Many organizations have adopted Akka and are seeing significant benefits for their organizations.
> However, in recent years an increasing number of those organizations have elected to self-support without either contributing back to the community or by investing in annual subscriptions. We have an ambitious roadmap for the future of Akka and require a way to fund and sustain that development.
> We believe that larger organizations that are seeing business benefits from Akka should contribute to the ongoing health and evolution of the project.
They need money to continue development, and the current model isn't generating enough revenue for them to stay in business.
> organizations have elected to self-support
That is the conundrum of Open Source: Great open source software will be so easy to maintain that everybody can do that for themselves. Therefore the economic incentive for Open Source authors is to create software which requires maintenance.
Either way, someone has to pay in the end, either for the license, or for the maintenance. There's no free lunch.
That is the conundrum of Open Source: Great open source software will be so easy to maintain that everybody can do that for themselves. Therefore the economic incentive for Open Source authors is to create software which requires maintenance.
Either way, someone has to pay in the end, either for the license, or for the maintenance. There's no free lunch.
> They need money to continue development, and the current model isn't generating enough revenue for them to stay in business.
But if they had started with a proprietary license, it's likely Akka wouldn't even exist today. So they are now piggybacking on the success brought by using an open source license.
But if they had started with a proprietary license, it's likely Akka wouldn't even exist today. So they are now piggybacking on the success brought by using an open source license.
The real question is wether they will actually generate more revenue with the change or perhaps less. There's always some fork on the old licence and it wouldn't be the first time that the fork eventually surpasses the original. Even amongst those who paid for support before the change, some might not be willing to commit to a future of not having a choice.
Yep, they couldn’t say: ‘we thought about relicensing but given a few people on HN would be upset about it we just decided it’s better to shut shop.’
The code that community contributed remains open source, you generally can not retroactively make stuff not-open. What Akka here is doing is removing themselves from the open source project and making their further contributions closed. The open source community is free to continue as they want.
There are many reasons to be open source. To solve actual problem, to engage with developer, to solicit ideas, to invite public audit, to gain publicity, among many other reasons. I respect and admire all the people who decides to create, open source or not. Author bear all the consequences of their actions, open source or not.
Contributions are not all equal, some people might feel more entitled because they made significant contribution in a project. The same people are also those who are most capable of forking. Do it by all means.
I am grateful that open source projects exist. But their "turning around" doesn't make me less grateful.
I am grateful that open source projects exist. But their "turning around" doesn't make me less grateful.
People who give their labor away for free aren’t entitled to anything. They should stop engaging in the farce that is open source these days if they feel that strongly about it
I view open source as a key question around maintainability, and access to talent with experience.
When I see open source projects getting relicensed, I automatically assume there is some monetization campaign underway which exploits the community's contributions.
When I see open source projects getting relicensed, I automatically assume there is some monetization campaign underway which exploits the community's contributions.
> If they changed their mind later to make the project proprietary, still full respect.
If "they" doesn't include all previous contributors, I can see an argument to the contrary.
If "they" doesn't include all previous contributors, I can see an argument to the contrary.
You don't get to say both:
"FOSS is just not a good business model. But when making decisions about what libraries to use, or where to invest my time, such concerns are simply not my problem."
and:
"It’s morally wrong to make the product popular, by advertising it as Open Source / Free Software, and then doing a reversal later."
If their business model isn't your problem, then what you think about their license isn't their problem.
"FOSS is just not a good business model. But when making decisions about what libraries to use, or where to invest my time, such concerns are simply not my problem."
and:
"It’s morally wrong to make the product popular, by advertising it as Open Source / Free Software, and then doing a reversal later."
If their business model isn't your problem, then what you think about their license isn't their problem.
The key word here isn't "license", it's "advertising".
> their business model isn't your problem, then what you think about their license isn't their problem.
The problem is not the license but the switch of it after they benefited from being Open Source
The problem is not the license but the switch of it after they benefited from being Open Source
The "Tragedy of the Commons" is not the same thing as the "Free-Rider Problem" - in the former case, individual overuse is the issue, where in the latter (as in F/OSS) the problem is the failure to muster the necessary resources.
Tragedy of the Commons is essentially impossible for software, which can be copied and redistributed an unlimited number of times. If the supply is not limited, it can't be disproportionately abused by certain entities and the supply depleted.
It can easily be a thing in systems of which software is the major component (most notably SaaS), but as you say it it's at best unusual and probably impossible for it to apply to the software itself.
Man, this is so disappointing.
Sure, there are probably businesses out there whose entire livelihood is built on akka, and I get that the creators might be upset that they're not contributing to the project. But there are a lot of other businesses out there where this might be a great solution for a very small part of the problem space, and they are just never going to use this tech now. A few years ago I used akka at my current gig for a project that ended up fizzling, and had always hoped to re-introduce it if another appropriate opportunity emerged. This change makes that a non-starter.
I also think this is a big blow in terms of the future of computing. The actor model is so useful, and it's taken so long to come close to mainstream. And now the biggest implementation shoves a giant stick in its own spoke.
Sure, there are probably businesses out there whose entire livelihood is built on akka, and I get that the creators might be upset that they're not contributing to the project. But there are a lot of other businesses out there where this might be a great solution for a very small part of the problem space, and they are just never going to use this tech now. A few years ago I used akka at my current gig for a project that ended up fizzling, and had always hoped to re-introduce it if another appropriate opportunity emerged. This change makes that a non-starter.
I also think this is a big blow in terms of the future of computing. The actor model is so useful, and it's taken so long to come close to mainstream. And now the biggest implementation shoves a giant stick in its own spoke.
The biggest and most battle tested implementation is certainly Erlang OTP and not Akka. I'm actually happy more attention will be given to ol' boring Erlang now.
I guess I shouldn't have said that without checking, I'm not sure who's on top. My point still stands though. Most dev shops are already operating on the JVM, trying out akka was a much easier sell than adopting BEAM. Whether or not akka is more widely deployed than erlang, IMO akka was driving more adoption of the actor model.
I have been a strong supporter of free software (GPL) and open source since Linux was created and remain so. The company I started and system we created, ClearHealth, was the only open source EMR to receive the necessary federal certifications and other partner certifications (SureScripts, Payers, DEA, etc) to be used in real large scale institutions. Unfortunately the fact that is was open source, the cons dramatically outweighed the pros in terms of contracts (it is difficult/complicated to get sole source contracts typical for software when you are open source) and investment (health tech investors at the time all wanted lock in).
We were fortunate to have a strong business model around our healthcare management operations that had nothing to do with the EMR but if I had to do it again speaking from a business standpoint only, I don't think I would do it as open source that way. As recently as 5 years ago open source was viewed with extreme suspicioun if not outright disdain in the largest health institutions, I think that is changing but still has 10-15 years to go.
We were fortunate to have a strong business model around our healthcare management operations that had nothing to do with the EMR but if I had to do it again speaking from a business standpoint only, I don't think I would do it as open source that way. As recently as 5 years ago open source was viewed with extreme suspicioun if not outright disdain in the largest health institutions, I think that is changing but still has 10-15 years to go.
I only worked with the Akka ecosystem a little, but if I had made a major career or business investment in it I'd be pretty unhappy about this. There's nothing wrong with closed source software and I want the authors to make money. It's changing the terms on users that pulls the rug out from under people.
It is not changing the terms for the users of the current version of AKKA. You will be free to use your current version with whatever terms you already have.
You can fork the current version, that's the whole idea of Open Source. But you cannot take away the rights of the AKKA team to create their commercial "fork" either. That much was clear from the beginning I assume. License does what it says it does, it doesn't give you free access to all future forks.
AKKA coming out with a commercial license does not make things worse for you, you can keep on using what you have under the license terms attached to it.
Imagine if AKKA STOPPED making any software. Would that be morally wrong? They are not doing that but they will be providing more software with a different license. Take it or leave it, or fork the existing version with the same license. Ah the beauty of Open Source.
You can fork the current version, that's the whole idea of Open Source. But you cannot take away the rights of the AKKA team to create their commercial "fork" either. That much was clear from the beginning I assume. License does what it says it does, it doesn't give you free access to all future forks.
AKKA coming out with a commercial license does not make things worse for you, you can keep on using what you have under the license terms attached to it.
Imagine if AKKA STOPPED making any software. Would that be morally wrong? They are not doing that but they will be providing more software with a different license. Take it or leave it, or fork the existing version with the same license. Ah the beauty of Open Source.
I'm not talking about legal rights. Surely they've managed the contributor agreement to make this option possible. However, they also built a community around open source software and there's more to that relationship than legalities.
> AKKA coming out with a commercial license does not make things worse for you
If I had invested my career in becoming an advocate for their product I'd now be worse off. It can't be introduced without going through legal and procurement. I can't take it home and build a small business without wondering what next year's pricing model will be.
I hope Akka's owners succeed. I also hope none of the tools I invest my time learning and introducing at work do this.
> AKKA coming out with a commercial license does not make things worse for you
If I had invested my career in becoming an advocate for their product I'd now be worse off. It can't be introduced without going through legal and procurement. I can't take it home and build a small business without wondering what next year's pricing model will be.
I hope Akka's owners succeed. I also hope none of the tools I invest my time learning and introducing at work do this.
If you had invested your career in AKKA I would feel your pain and disappointment, and the feeling of being cheated with lofty talk about open source.
But you might still have a strong career in supporting customers who use the commercial version of AKKA, they are the ones who could pay your salary. And you could fork it, and be the leader of that community. Until perhaps you decided to make a commercial fork as well. :-)
I think it is in a way a good sign when an open-source project creates a commercial fork of itself, it shows there are paying customers for the software, it validates its existence.
And I think it shows these guys believe in their product.
But you might still have a strong career in supporting customers who use the commercial version of AKKA, they are the ones who could pay your salary. And you could fork it, and be the leader of that community. Until perhaps you decided to make a commercial fork as well. :-)
I think it is in a way a good sign when an open-source project creates a commercial fork of itself, it shows there are paying customers for the software, it validates its existence.
And I think it shows these guys believe in their product.
That’s going to pull the rug from underneath the whole of Scala ecosystem. There are so many major top level Scala libraries using Akka one way or another.
Basically, anything containing Akka at those new versions cannot be used without breaking Akka license.
Basically, anything containing Akka at those new versions cannot be used without breaking Akka license.
Not entirely true, Play framework for example will continue to depend on Akka without restrictions placed on its users -- mentioned in the blog post, see "usage grant".
Okay, so Play Framework has this grant now in place. But everything else? Each and every maintainer is required to request such grant, and Lightbend needs to agree. Friction, a lot of friction.
The problem with what’s happening is that for software in Scala, as soon as I see Akka anywhere in my dependencies, I have to assume license violation. Of course, I can check if that particular dependency has a grant. But will there be a formal method to validate this? Will automated license scanners be able to infer this?
Another point… what does the grant actually imply. Is there some sort of way a product with Akka-dependent dependency supposed to be used? Will people be able to work around BSL by pulling in a dependency that brings Akka in just as a mechanism to sneak Akka itself in? That would be a silly oversight by Lightbend[1]
[1] the faq answers this: “ I am using Play and parts of Akka that are included with Play? If you are using Play and are directly using Akka components as part of your implementation you will be required to have a license for production use.”
As someone who came to Scala from Erlang and adopted Scala because of Akka, … it’s disappointing. Fortunately alternatives exist and hopefully someone will adapt them for Scala. Here’s one: http://docs.paralleluniverse.co/quasar/. This is used by Clojure’s Pulsar Erlang-influenced actors. For me, this is the end of the road for Akka in any future Scala code. It’s a shame because the technology is great. However, maintenance is going to become a hassle.
From an observer’s perspective: Typesafe, later Lightbend, never managed to find a great fit for themselves. They always kept developing Akka and promote Akka-based systems like all the alpakka stuff, http, streams. People used it because it was Apache 2.0. Now, everyone who uses Akka, and wants to continue using it, has a liability on their hands. What about all contributions submitted under the old license? The FAQ doesn’t specify if existing code will be BSL and convert to Apache 2.0 in 3 years (or maybe more, faq says each version may have its own convert date…), or only new code will be BSL. Depending on the answer, some contributors may feel a bit let down: https://github.com/akka/alpakka/graphs/contributors?from=201.... They all contributed under Apache 2.0.
So many questions, it’s a minefield. In my head, this is a minefield worse that AGPL. Their faq says a company with a revenue below USD25m/annum receives a free license. What if said company sells to a USD100m business and is using Akka indirectly? Forget about direct, explicit use. What if a product uses stuff indirectly?
The problem with what’s happening is that for software in Scala, as soon as I see Akka anywhere in my dependencies, I have to assume license violation. Of course, I can check if that particular dependency has a grant. But will there be a formal method to validate this? Will automated license scanners be able to infer this?
Another point… what does the grant actually imply. Is there some sort of way a product with Akka-dependent dependency supposed to be used? Will people be able to work around BSL by pulling in a dependency that brings Akka in just as a mechanism to sneak Akka itself in? That would be a silly oversight by Lightbend[1]
[1] the faq answers this: “ I am using Play and parts of Akka that are included with Play? If you are using Play and are directly using Akka components as part of your implementation you will be required to have a license for production use.”
As someone who came to Scala from Erlang and adopted Scala because of Akka, … it’s disappointing. Fortunately alternatives exist and hopefully someone will adapt them for Scala. Here’s one: http://docs.paralleluniverse.co/quasar/. This is used by Clojure’s Pulsar Erlang-influenced actors. For me, this is the end of the road for Akka in any future Scala code. It’s a shame because the technology is great. However, maintenance is going to become a hassle.
From an observer’s perspective: Typesafe, later Lightbend, never managed to find a great fit for themselves. They always kept developing Akka and promote Akka-based systems like all the alpakka stuff, http, streams. People used it because it was Apache 2.0. Now, everyone who uses Akka, and wants to continue using it, has a liability on their hands. What about all contributions submitted under the old license? The FAQ doesn’t specify if existing code will be BSL and convert to Apache 2.0 in 3 years (or maybe more, faq says each version may have its own convert date…), or only new code will be BSL. Depending on the answer, some contributors may feel a bit let down: https://github.com/akka/alpakka/graphs/contributors?from=201.... They all contributed under Apache 2.0.
So many questions, it’s a minefield. In my head, this is a minefield worse that AGPL. Their faq says a company with a revenue below USD25m/annum receives a free license. What if said company sells to a USD100m business and is using Akka indirectly? Forget about direct, explicit use. What if a product uses stuff indirectly?
Agreed, was just pointing out that the grant escape hatch exists. More projects in the ecosystem may follow suit, or not -- we'll find out soon enough.
2000 USD per core per year.
https://www.lightbend.com/akka
https://www.lightbend.com/akka
$2000 USD for companies earning more than $25M USD Revenue per year.
However, it's quite telling that the new blogpost discusses the new pricing but never actually shares the pricing, but only shares the condition for when it's free (as in gratis). Do lightbend themselves think its expensive?
However, it's quite telling that the new blogpost discusses the new pricing but never actually shares the pricing, but only shares the condition for when it's free (as in gratis). Do lightbend themselves think its expensive?
If you need to know the price then I doubt you are Akka's target customer.
It’s a waste of time for me to evaluate something whose cost definitely won’t be approved. $25M revenue doesn’t mean a company is actually profitable yet.
What? Their target customer should be the one who has to pay, otherwise they are gonna focus on acquiring customers that won't pay? How does that make sense?
It means that they are targeting enterprise customers.
And for them the price is irrelevant if it solves their problem.
And for them the price is irrelevant if it solves their problem.
$2k once per year is irrelevant for enterprise, but not $2k per core. With bigger deployments that's more than the entire dev team's salaries.
Lets say a 16 core machine costs 20k with associated costs (share of router, etc). This is a pretty high price for a machine, but isn't entirely insane.
Your akka license now costs €32k per year. Meanwhile if you are doing standard five year deprecation your 16 core machine is 4k. This means you are paying 8x the cost of the machine itself for the software license. An important software license but not one that is a full complete piece of work.
I could understand paying this much for software like Wowza where it is a "complete" solution for a problem. Where you are buying a full piece of software, but not a developer framework.
Your akka license now costs €32k per year. Meanwhile if you are doing standard five year deprecation your 16 core machine is 4k. This means you are paying 8x the cost of the machine itself for the software license. An important software license but not one that is a full complete piece of work.
I could understand paying this much for software like Wowza where it is a "complete" solution for a problem. Where you are buying a full piece of software, but not a developer framework.
How is it irrelevant? Operating a single node would be $10k+ per year. That makes no sense for a large corporation to adopt. They’re better off rewriting the entirety of Akka.
[deleted](1)
Yet another "We're saving Open Source by Ditching Open Source" announcement.
Open Source license does not fit every business model, in fact models around true Open Source were always hard, really hard.
Yet lets be real and call things the way they are - you decided what Open Source is not right business license for your project and choosing to use Proprietary (Source Available) license instead.
Yet lets be real and call things the way they are - you decided what Open Source is not right business license for your project and choosing to use Proprietary (Source Available) license instead.
Pre reading: Is it because VC funded company needs to show returns ?
https://www.crunchbase.com/funding_round/typesafe-series-d--...
post-reading: ...probably
https://www.crunchbase.com/funding_round/typesafe-series-d--...
post-reading: ...probably
All companies need to show returns, otherwise they run out of money and die. Not sure what VC funding has to do with this except, perhaps, making the "live open or die" model seem attractive at the start.
Privately owned companies just need modest returns. VCs tend to demand lavish returns.
I would argue that akka is successful because of the permissive licence. Now that that's changed, it will create growing space for other projects.
Other projects in the Scala world are already out there. I used the whole Akka shebang at my previous job (streams, persistence, cluster sharding, ...) and I would argue most people don't need that. It encourages over-engineering and you can usually do the same thing with simpler libraries.
Now, Akka came out at the right time and deserved to get popular. It's built on a solid and battle-tested foundation and there is a real community-driven ecosystem around it, or at least there was. It totally made sense. Also Lightbend was on a seemingly good trajectory, and Akka looked like a safe bet.
I guarantee there are small teams out there, at big companies making well over $25m, who are probably overstretched already and now need to plan an unexpected migration. I love Scala but the maintenance burden is real.
Now, Akka came out at the right time and deserved to get popular. It's built on a solid and battle-tested foundation and there is a real community-driven ecosystem around it, or at least there was. It totally made sense. Also Lightbend was on a seemingly good trajectory, and Akka looked like a safe bet.
I guarantee there are small teams out there, at big companies making well over $25m, who are probably overstretched already and now need to plan an unexpected migration. I love Scala but the maintenance burden is real.
I would say it helped with early adoption. But at this point, it's got quite a bit of adoption. It's proven and for companies making over $25 million a year a proven piece of tech is generally more likely to be used than an unproven one.
imo this is probably the most comprehensive usage of bsl so far. cockroach and couchbase use it to exclude dbaas, and mariadb only uses it for non-core features. lightbend has put everything under bsl. this includes the core actor system that a lot of companies use.
i can think of a few companies whose total spend with this license would justify a two pizza team to maintain a fork of akka or replace it outright.
i can think of a few companies whose total spend with this license would justify a two pizza team to maintain a fork of akka or replace it outright.
I’m actually a big fan of the BSL license, as if it gains popularity for commercial software there would be a lot less risk of vendor lock-in like with Adobe and Autodesk.
I don’t mind paying for good software, but too many companies abuse their market position once they get big.
I don’t mind paying for good software, but too many companies abuse their market position once they get big.
Yea, this is the licensing I think we should have in place of many open source licesenses. I'm going to be using it with my commerical software very soon.
It's easy to dictate morals for others. How about let oss be voluntary and thank people for giving what they did in the past?
Build a free bridge across a river, which allows a town to grow on the other side, then shut down free access to the bridge. The builders are entitled to do this, but doesn't make it the right thing to do.
Nothing was taken away from the town and the people on the other side of the river. You can still use the free bridge. The license change only affects future new bridges but anybody is free to use the before-the-license-change-bridge exactly in the same way as they used to.
Build a free bridge across a river, leave it in place and invite others to maintain it. Build a separate toll bridge.
What is the problem with wanting to be paid for your labor?
The example is flawed. What really happens in open source is that the users contribute bug reports and fixes, then the project maintainers privatize the use after extracting value. Should the users who contributed code and issues be paid as well?
For better or for worse, the success of many large open source projects is driven by a community of evangelists that just wouldn't exist if the project weren't open source in the first place.
For better or for worse, the success of many large open source projects is driven by a community of evangelists that just wouldn't exist if the project weren't open source in the first place.
Could update the example by saying that the villagers have been contributing to bridge maintenance before it went private.
O&M of a thing, often outweighs the initial cost of bootstrapping it in the first place.
The longer it runs, the more this is true.
The longer it runs, the more this is true.
So you mean everyone that contributed when the project was FOSS should be paid for their labor when this ceases to be FOSS?
I really don’t understand how licensing works, but doesn’t the Apache 2.0 license essentially mean “anybody can do anything they want with this code”?
If that is the case, wouldn’t that right also apply to the primary maintainer/owner of the copyright or is it just the users that have that privilege?
If I were concerned about somebody eventually monetizing a product that I contributed to, I wouldn’t contribute to anything.
If that is the case, wouldn’t that right also apply to the primary maintainer/owner of the copyright or is it just the users that have that privilege?
If I were concerned about somebody eventually monetizing a product that I contributed to, I wouldn’t contribute to anything.
I don't understand how your question leads from my comment. I didn't say anything about there being something wrong with being paid for labor.
More like putting an elevator in a building then cutting power when someone is in it.
I hope this works out well for them.
One issue with the BSL is that old versions of the software are open source. So, with this change, you can still use a 3 year old version of Akka for free. Does akka change rapidly enough these days to justify the price?
One issue with the BSL is that old versions of the software are open source. So, with this change, you can still use a 3 year old version of Akka for free. Does akka change rapidly enough these days to justify the price?
That’s the benefit of BSL license - it forces the developer to continuously deliver value in each release because they are competing with themselves from 3 years ago.
Presumably the issue for enterprises is security patches. If you use a three year old version of code which the source is available for inspection, the likelihood you are using already-compromised code is high.
I read this whole discussion. Here's what I think.
What I realized is that there are two groups of people here.
One group considers Open Source a religion. The other thinks of it as business.
The "religion" folks liken Open Source to the work of saints and prophets. The creators of Open Source do it because they love the work and helping people. And it's not cool if they stop being saints one day, much like the actual religious people wouldn't like seeing their icons turn into something else.
The "business" bunch say there's freedom in Open Source to change anything on a dime, including for money. The fact you offered software as an Open Source is a strategy, and no matter how much it helped and how many people and for how long, you absolutely have the right to nail them one morning.
What I would say here is this:
Open Source was a reaction to actions of Giants, like Microsoft, Oracle and others. That's all it was. It was the Software Woodstock, which then turned into goo and spilled everywhere. Now, we're all snickering and crying from joy in the back of our heads whenever we get some cool piece of Open Source software. It's like God granting wishes.
And nowadays, Open Source is a big business with the currency made of influence and worship of followers. And just like real religion, there's a hat on a pew where money somehow shows up every Sunday, at least for those whose gospel greases the wheels of commerce.
That said, it's high time to at least acknowledge this, rather than endlessly wax philosophical about the Soul of Open Source.
And what about the millions who labor in and around Open Source, and don't even get recognition? They count on Divine Accounting to give them their fair share back one day. But they're getting restless.
So in short, Software Woodstock has turned into What The Hell Is This. But it's just Religion and Business, all wrapped together.
And with ominous clouds of resource scarcity, inflation and geopolitics from hell, it will soon turn into Check Please! Time to separate Religion from Business. It's all Business, folks!
What I realized is that there are two groups of people here.
One group considers Open Source a religion. The other thinks of it as business.
The "religion" folks liken Open Source to the work of saints and prophets. The creators of Open Source do it because they love the work and helping people. And it's not cool if they stop being saints one day, much like the actual religious people wouldn't like seeing their icons turn into something else.
The "business" bunch say there's freedom in Open Source to change anything on a dime, including for money. The fact you offered software as an Open Source is a strategy, and no matter how much it helped and how many people and for how long, you absolutely have the right to nail them one morning.
What I would say here is this:
Open Source was a reaction to actions of Giants, like Microsoft, Oracle and others. That's all it was. It was the Software Woodstock, which then turned into goo and spilled everywhere. Now, we're all snickering and crying from joy in the back of our heads whenever we get some cool piece of Open Source software. It's like God granting wishes.
And nowadays, Open Source is a big business with the currency made of influence and worship of followers. And just like real religion, there's a hat on a pew where money somehow shows up every Sunday, at least for those whose gospel greases the wheels of commerce.
That said, it's high time to at least acknowledge this, rather than endlessly wax philosophical about the Soul of Open Source.
And what about the millions who labor in and around Open Source, and don't even get recognition? They count on Divine Accounting to give them their fair share back one day. But they're getting restless.
So in short, Software Woodstock has turned into What The Hell Is This. But it's just Religion and Business, all wrapped together.
And with ominous clouds of resource scarcity, inflation and geopolitics from hell, it will soon turn into Check Please! Time to separate Religion from Business. It's all Business, folks!
I fully support their decision to change their licence, but they could be a bit more honest about their intentions.
"the Apache 2.0 model becomes increasingly risky when a small company solely carries the maintenance effort". Really? Then why are you reverting to that licence after 3 years?
Other projects changing the licence have at least spelled it out honestly: Cloud companies like Amazon are seen as parasitic and the developers of highly successful open source projects want a slice of the pie.
"the Apache 2.0 model becomes increasingly risky when a small company solely carries the maintenance effort". Really? Then why are you reverting to that licence after 3 years?
Other projects changing the licence have at least spelled it out honestly: Cloud companies like Amazon are seen as parasitic and the developers of highly successful open source projects want a slice of the pie.
Does Akka.NET have any licensing dependencies on Akka?
I wonder if this will push people there (please go to F#) or Elixir and Erlang.
I wonder if this will push people there (please go to F#) or Elixir and Erlang.
Maintainer of Akka.NET here - we're not really affected by this change.
1. We're still porting features that are all licensed under Apache 2.0, as other comments have mentioned. 2. None of Akka.NET's source code has been authored by Lightbend and we certainly don't fall under their Contributor License Agreement (CLA.)
The copyright headers of the Akka.NET files includes a Lightbend attribution currently, but we've included that in there largely out of an abundance of caution - and it's actually a little erroneous for us to do that since many of the files in our projects don't exist in the original Akka source.
Our source was contributed to the .NET Foundation years ago - so I'll ask their OSS counsel if there's anything we need to do differently going forward to keep our source germane under Apache 2.0.
1. We're still porting features that are all licensed under Apache 2.0, as other comments have mentioned. 2. None of Akka.NET's source code has been authored by Lightbend and we certainly don't fall under their Contributor License Agreement (CLA.)
The copyright headers of the Akka.NET files includes a Lightbend attribution currently, but we've included that in there largely out of an abundance of caution - and it's actually a little erroneous for us to do that since many of the files in our projects don't exist in the original Akka source.
Our source was contributed to the .NET Foundation years ago - so I'll ask their OSS counsel if there's anything we need to do differently going forward to keep our source germane under Apache 2.0.
That’s great! Hopefully this means some JVM developers will move over to .NET.
Akka.net is a bit behind from the scala version in features...
This will make it more difficult to catch up however, as the JVM version and code is obviously used as a starting point for bringing functionality over. The main part of it I can think of that was home-grown was the original Akka.Net Split brain resolver, but once light bend open sourced theirs, the project ported that over anyway.
This will make it more difficult to catch up however, as the JVM version and code is obviously used as a starting point for bringing functionality over. The main part of it I can think of that was home-grown was the original Akka.Net Split brain resolver, but once light bend open sourced theirs, the project ported that over anyway.
My understanding is that the .NET version is a port and only related in the style/approach. However, if I was them I'd consider renaming the lib. Looks like the name "Akka" is tainted at this point.
So presumably 2.6.20, released yesterday, is the last free version: https://akka.io/blog/news/2022/09/06/akka-2.6.20-released
I wonder if this is mainly aimed at Java Akka use.
In my humble opinion, Akka is becoming less relevant in Scala community. I don't see new projects picking it up as there are better alternatives.
In my humble opinion, Akka is becoming less relevant in Scala community. I don't see new projects picking it up as there are better alternatives.
What are the alternatives?
Depends on what we are replacing.
From what I have encountered: Akka was mostly used as Http server (akka-http). There is Http4s which can replace that and I think is great. Also its easy to use it with tagless final or zio's IO.
Actors computation model depending on use case can be replaced with message brokers or Scala libraries. Like cats-effect or zio for composable concurrency primitives and fs2/zio-streams for stream computations. I know there are actor use cases beyond that, but I am yet to encounter project these days where picking akka would be my first choice.
I have nothing against akka and I definitely enjoyed developing with it 5 years ago.
From what I have encountered: Akka was mostly used as Http server (akka-http). There is Http4s which can replace that and I think is great. Also its easy to use it with tagless final or zio's IO.
Actors computation model depending on use case can be replaced with message brokers or Scala libraries. Like cats-effect or zio for composable concurrency primitives and fs2/zio-streams for stream computations. I know there are actor use cases beyond that, but I am yet to encounter project these days where picking akka would be my first choice.
I have nothing against akka and I definitely enjoyed developing with it 5 years ago.
If you want Scala-specific and production grade... hmmm...
So there is Loom comig from one side, and effect libraries like cats and zio from the other side... great promises, but would I trust them with production code?... Hmmm...
But there is always the option to lean back on Java and Spring and JEE - the old and boring but tried and tested ways on the JVM.
So there is Loom comig from one side, and effect libraries like cats and zio from the other side... great promises, but would I trust them with production code?... Hmmm...
But there is always the option to lean back on Java and Spring and JEE - the old and boring but tried and tested ways on the JVM.
You can absolutely trust them with production code. Disney Streaming (CE and ZIO) and ITV (just CE) run them
akka-core or the libraries built on top of it?
Would have been nice to have some lead time. I feel like the sudden change is too bait and switch.
Can someone explain how this sudden change of license is even possible (legally)?
I mean, what if I contributed to the project back when it was Apache licensed, in good faith that my changes would be freely available (as in free beer)? Now they decide that they ask money for something that includes my contribution? Don't they have to ask for the contributors permissions to be able to do that?
(Just a hypothetical example, I am not an Akka contributor.)
I mean, what if I contributed to the project back when it was Apache licensed, in good faith that my changes would be freely available (as in free beer)? Now they decide that they ask money for something that includes my contribution? Don't they have to ask for the contributors permissions to be able to do that?
(Just a hypothetical example, I am not an Akka contributor.)
[Not a lawyer] That's what CLAs are for. As a prerequisite of having your PR accepted, you grant the mothership corporate entity the rights to do whatever they want with your contribution, including asking money.
https://opensource.google/documentation/reference/cla
https://cla.opensource.microsoft.com
https://opensource.google/documentation/reference/cla
https://cla.opensource.microsoft.com
To elaborate on this, a CTA would directly transfer the contribution of the copyright to the project. A CLA is much more common than a CTA. A CLA is more complicated: the submitter maintains the copyright, but a sublicense is granted to the project. That sublicense grants rights similar to having copyright, one of them being the ability to relicense. It is possible for the CLA sublicensing agreement to restrict the ability to relicense, but most do not do that.
Apache 2.0 is a permissive license, so if you contributed to the project under the Apache license you gave them permission to use your code in closed-source projects (as long as they follow the terms of the license, such as giving you credit).
Of course, they can't un-license code that they've already released, but they can re-release the old code under a new license, and ship all new code under that new license going forward.
Of course, they can't un-license code that they've already released, but they can re-release the old code under a new license, and ship all new code under that new license going forward.
I'm not a lawyer and I haven't read the Apache license lately, but I think it's a permissive enough license that they probably can sub/relicense it as long as they keep everybody's copyright notices intact. That is, effectively just leave all the code under the Apache license but also add additional terms and conditions because it doesn't prohibit that. This is in sharp contrast to, say, GPL, which would have prevented such a maneuver. (Or, as a sibling, notes, if they required a CLA then they legitimately have the ability to relicense everything at will.)
Yeah, in the meantime I did find the word "sublicense" in section "2. Grant of Copyright License" of the original text. Fair enough.
It's not just about revenue generation. I bet they are doing this to prevent Amazon from deploying a version of Akka as a service on AWS.
This doesn't really make sense. Akka is a framework/library, not something that could be offered as a service, anymore than you could have "boost as a service" or "numpy as a service".
I think that makes this change worse, though: it means that the new license will infect many more projects--like Spark, for example. And they won't even be making security patches to existing versions available under the old license. "Nice project you got there, it'd sure be a shame if some unpatched security flaw came along and ruined it," they're saying.
edit: I wasn't aware, but Spark stopped using akka several years ago. But the basic point still stands.
I think that makes this change worse, though: it means that the new license will infect many more projects--like Spark, for example. And they won't even be making security patches to existing versions available under the old license. "Nice project you got there, it'd sure be a shame if some unpatched security flaw came along and ruined it," they're saying.
edit: I wasn't aware, but Spark stopped using akka several years ago. But the basic point still stands.
> I bet they are doing this to prevent Amazon from deploying a version of Akka as a service on AWS.
Yes, it's pretty clear they no longer want to participate in the Open Source ecosystem, as allowing people to run the software however you see fit is a integral part of Open Source, together with being able to modify and reshare said software.
Yes, it's pretty clear they no longer want to participate in the Open Source ecosystem, as allowing people to run the software however you see fit is a integral part of Open Source, together with being able to modify and reshare said software.
They're releasing everything as Apache on a delay. That's definitely participating.
> allowing people to run the software however you see fit is a integral part of Open Source
Does that depend on whether you consider corporations to be people?
> allowing people to run the software however you see fit is a integral part of Open Source
Does that depend on whether you consider corporations to be people?
> Open Source ecosystem
Free money and labor for Amazon ecosystem.
Honestly I'd love to see a license that was "Apache for everyone but Amazon (or other $100B+ companies and their subsidiaries)"
Open source is being weaponized in ways that Stallman never predicted.
Free money and labor for Amazon ecosystem.
Honestly I'd love to see a license that was "Apache for everyone but Amazon (or other $100B+ companies and their subsidiaries)"
Open source is being weaponized in ways that Stallman never predicted.
> Free money and labor for Amazon ecosystem.
"Free software for everyone" is precisely what Open Source is
> Honestly I'd love to see a license that was "Apache for everyone but Amazon (or other $100B+ companies and their subsidiaries)"
Yeah, that's basically what the BSL license Akka is moving to is. Only projects earning over X amount per year need the business license, for others it's free.
"Free software for everyone" is precisely what Open Source is
> Honestly I'd love to see a license that was "Apache for everyone but Amazon (or other $100B+ companies and their subsidiaries)"
Yeah, that's basically what the BSL license Akka is moving to is. Only projects earning over X amount per year need the business license, for others it's free.
That's more or less what SSPL is. The problem is the OSI and FSF are basically religious pharisees, so dedicated to their texts, they're missing the actual point. People backing the OSI/Amazon over Elastic/Mongo/etc. are literally killing open source.
> People backing the OSI/Amazon over Elastic/Mongo/etc. are literally killing open source.
AGPL, the license Mongo was originally under, isn't used in reality to prevent deployed applications from hoarding changes; rather, it used to scare commercial entities away from deploying your code. With a commercial CLA providing exclusive code ownership, it allows you a legal club to block others, even other contributors, from competing against your current business interests.
It is licenses like the AGPL and commercial CLAs which have been killing open source and free software, because they destroy motivation for any significant third party contributions and the resulting emergent ecosystem around a project. It reduces the idea of open source and of free software down a lot closer (in my opinion) to source code escrow.
MongoDB didn't want any Amazon changes to be contributed to the project. They wanted to block another commercial entity from offering a service based on their IP. From an open source perspective, I don't take their side any more than I would take Amazon's.
AGPL, the license Mongo was originally under, isn't used in reality to prevent deployed applications from hoarding changes; rather, it used to scare commercial entities away from deploying your code. With a commercial CLA providing exclusive code ownership, it allows you a legal club to block others, even other contributors, from competing against your current business interests.
It is licenses like the AGPL and commercial CLAs which have been killing open source and free software, because they destroy motivation for any significant third party contributions and the resulting emergent ecosystem around a project. It reduces the idea of open source and of free software down a lot closer (in my opinion) to source code escrow.
MongoDB didn't want any Amazon changes to be contributed to the project. They wanted to block another commercial entity from offering a service based on their IP. From an open source perspective, I don't take their side any more than I would take Amazon's.
AGPL is an actual FLOSS license though, SSPL is not. And Amazon (or any other entity) would be quite within their rights to publically deploy AGPL software as long as they merely published the changes in the deployed version. There's no requirement for such changes to be accepted by upstream.
Really? I think Akka is far too niche for that to be likely.
If that's what they cared about, they could have copied what ElasticSearch did, and switched to a Server Side Public License (SSPL).
While the SSPL should be recognized as a copyleft open source license, since the OSI has refused to accept it, it's not really any different than the BSL at this time. If the OSI did their actual job, and promoted open source and helped foster a business-friendly open source license that prevented Amazon from sherlocking everyone, it'd probably see major adoption.
Copyright/copyleft licenses deal with your ability to publish the original work or derivative works, as well as performances of the derivative work.
SSPL requires you to publish items which may be non-derivative work on certain kinds of performances. Further, it does so specifically to be punitive against certain kinds of use (e.g. use by a competing company).
Because of the requirement to release so much non-derivative work under SSPL, including infrastructure you may not have written yourself or own copyright to, it is likely infeasible for one to be conformant to that provision.
SSPL requires you to publish items which may be non-derivative work on certain kinds of performances. Further, it does so specifically to be punitive against certain kinds of use (e.g. use by a competing company).
Because of the requirement to release so much non-derivative work under SSPL, including infrastructure you may not have written yourself or own copyright to, it is likely infeasible for one to be conformant to that provision.
The Problem with SSPL is, it triggers at runtime. Most OpenSource Licensens trigger at compile time. GPL ... you pull in GPL Code, compile it, your code becomes GPL. SSPL? Triggers at runtime if you run it as a SaaS, not really making clear what counts as SaaS, not really making clear what counts as a third party, etc. Thats the reason it should NOT be recognized as a open source license.
Arguably AGPL also triggers "at runtime", based on public performance of the covered work over a computer network.
> the SSPL should be recognized as a copyleft open source license
How do you figure? I don't think it should.
How do you figure? I don't think it should.
Who is ever going to use Akka after the "3 years"? It says a lot about the company. An despite the fact I love the technology and its community, I wouldn't recommend it anymore, at all. The pricing is simply not right.
I mean, it came so suddenly that you literally have no choice than to pay for at least 1 year, before you port your services to something else (if you can, at all), unless you want CVEs going wild in your production systems.
I wonder what's their long-term vision? Getting rid of Akka as the main business model (subscriptions / support) and focus on something that is maybe based on Akka (I guess Kalix and similar cloud-only services)?
Well, if that's the case, it's a brilliant idea: squeeze as much money now as you can, pivot your company to something different. (SAAS, yay, another one)
Unethical? Maybe yes, a tiny bit.
I mean, it came so suddenly that you literally have no choice than to pay for at least 1 year, before you port your services to something else (if you can, at all), unless you want CVEs going wild in your production systems.
I wonder what's their long-term vision? Getting rid of Akka as the main business model (subscriptions / support) and focus on something that is maybe based on Akka (I guess Kalix and similar cloud-only services)?
Well, if that's the case, it's a brilliant idea: squeeze as much money now as you can, pivot your company to something different. (SAAS, yay, another one)
Unethical? Maybe yes, a tiny bit.
Isn't Akka an important component in various Scala projects like Apache Spark? What are they supposed to do?
Other libraries depending on Akka shouldn't have to change, as they are merely published as "libraries", not deployed to "production".
Libraries generally never have "annual revenues more than US $25m", so it should be free for them to use the code as well.
Realistically though, they force you to contact them to get a "Additional Use Grant" in case you want to use Akka for other open source projects:
> I use Akka for an OSS project. What does this mean for my project?
> The license offers a customizable “Additional Use Grant” that grants production usage for other OSS projects including Play Framework.
> If you are running an OSS project using Akka, please contact us at [email protected] and we will do our best to continue to support your project.
I wish them luck on their endeavour, but I know what I'd do if I was building a OSS project needing distributed actors, and it's not to send them an email asking if I could please use their software.
Libraries generally never have "annual revenues more than US $25m", so it should be free for them to use the code as well.
Realistically though, they force you to contact them to get a "Additional Use Grant" in case you want to use Akka for other open source projects:
> I use Akka for an OSS project. What does this mean for my project?
> The license offers a customizable “Additional Use Grant” that grants production usage for other OSS projects including Play Framework.
> If you are running an OSS project using Akka, please contact us at [email protected] and we will do our best to continue to support your project.
I wish them luck on their endeavour, but I know what I'd do if I was building a OSS project needing distributed actors, and it's not to send them an email asking if I could please use their software.
And if the library using akka is in production? Presumably then fees time, as otherwise a thin shim called 'akkalib' that forwards calls would be an escape hatch.
I guess that depends if other libraries are fine with only having commercial users willing to pay that much for using Akka. (E.g. since GP mentioned Spark, doesn't that have quite a commercial ecosystem around it that probably won't be happy to suddenly pay thousands per node extra?)
Akka's new license is highly likely incompatible with the Apache Software Foundation requirements for third party licenses. "Additional use grant" might mean a OSS project does not have to pay, but it still puts heavy restrictions on forking that project.
So Apache projects depending on Akka, like Flink or Spark, will probably have to fork it or be stuck on the current version.
So Apache projects depending on Akka, like Flink or Spark, will probably have to fork it or be stuck on the current version.
Spark doesn’t use Akka since 1.6.
Clearly the OSS developers don't have to pay something per core. The risk would be that anyone with a production Spark or Flink cluster now has to license Akka, e.g. those products are themselves not open source anymore.
Akka is an ecosystem on its own. There's no Akka in Spark, Flink, Kafka, nor at the other end of the Scala spectrum, in FP libraries in the Typelevel or Zio ecosystems.
Akka is a part of Play though, which has been abandoned by Lightbend.
Akka is a part of Play though, which has been abandoned by Lightbend.
What do you mean no Akka in Flink ? https://github.com/apache/flink/blob/master/flink-rpc/flink-...
Thanks, I stand corrected.
So iiuc code using the play framework is permitted to use akka (because it's built on top of it) without paying?
[deleted]
I have a side project in data management that I have worked on for years (https://www.Didgets.com) and it is finally reached the point where it is an MVP with real value. I have considered adopting an open source license for it, but there are so many to choose from (I read somewhere that there are over 100 accepted kinds of OSS licenses).
Stories like this one make me nervous about choosing the wrong one. Once you let the genie out of the bottle, there is no putting it back in. You can change the license for future versions, but some big company has the right to fork your code at that point and bury you with their superior resources.
How do you choose a good license without shooting yourself in the foot?
Stories like this one make me nervous about choosing the wrong one. Once you let the genie out of the bottle, there is no putting it back in. You can change the license for future versions, but some big company has the right to fork your code at that point and bury you with their superior resources.
How do you choose a good license without shooting yourself in the foot?
AGPLv3 or GPLv3 is a good choice to ensure that all changes stay out in the open. Then the competition becomes who can change the code faster and reach more customers.
>Then the competition becomes who can change the code faster and reach more customers.
That is not very reassuring advice for a small developer who has limited resources. By opening your source code, you have just given up any head start you might have over the competition. They now have access to every line of code you spent hours agonizing over to get it right. Now they can out market you and leverage their vast resources to steal away any of your potential customers.
That is not very reassuring advice for a small developer who has limited resources. By opening your source code, you have just given up any head start you might have over the competition. They now have access to every line of code you spent hours agonizing over to get it right. Now they can out market you and leverage their vast resources to steal away any of your potential customers.
How will this affect open source projects that have Akka as a dependency? Flink? Spark?
I planned to write a series of articles about how to build distributed applications on Akka Clustering, now, there's no need for that. I wish I didn't recommend Akka to my friends.
Thanks.
A few (probably naive) thoughts:
- I will be excited to see if a new jvm actor system emerges as a competitor. Or perhaps a fork.
- I would be excited to see more consideration given to Elixir and OTP, where previously Akka may have been favored.
- I will be excited to see if a new jvm actor system emerges as a competitor. Or perhaps a fork.
- I would be excited to see more consideration given to Elixir and OTP, where previously Akka may have been favored.
I feel sorry for anybody who ever used this.
it’s basically a cc by-nc? https://www.draketo.de/light/english/politics/free-culture-d...
NC covered works trick people into investing in a dead end.
They can do that, for sure. It is legal and I don’t see reason to complain. You cannot trust a project to stay free if it is licensed without copyleft or requesting that you assign them your code without guaranteeing that it stays free.
NC covered works trick people into investing in a dead end.
They can do that, for sure. It is legal and I don’t see reason to complain. You cannot trust a project to stay free if it is licensed without copyleft or requesting that you assign them your code without guaranteeing that it stays free.
You'd have to pay me to use it.
Yeah, as far as actor systems went, it's no Erlang. The same "DON'T BLOCK, IT'LL DO BAD THINGS BECAUSE IT BLOCKS THE THREAD" approach that you find in things like Vert.x.
Letting my actor's function block was the best bit about Erlang.
Letting my actor's function block was the best bit about Erlang.
Does DCO prevent this kind of thing from happening? I think moves like this demotivated and discourages a lot of potential contributors and spreads fear. That's not a good thing.
Imagine a contributor who's first contribution to Open Source was this project. I am not sure he'd be very happy about a move such as this (or maybe he won't care).
Imagine a contributor who's first contribution to Open Source was this project. I am not sure he'd be very happy about a move such as this (or maybe he won't care).
Not having CLA or equivalent prevents this kind of thing. DCO is for projects that want minimal legal process without copyright assignment. For the record akka has CLA.
CLA is sort of neutral in this regard. You can have DCO-style CLAs with incoming == outgoing licensing, where the contributor and the project organization end up with the same rights. But like with DCO, switching to proprietary is still possible in principle if the license is sufficiently permissive. And admittedly, such symmetric CLAs are somewhat rare; DCO has mostly taken over this space.
It's hard to want to build anything on open-source when you see stuff like this. Every open-source project is surrounded by people and corporations trying to charge you rent to use it.
Is it clear which exact OSS components will get the license change?
For example, is akka-http [0] part of these changes?
[0] https://github.com/akka/akka-http
For example, is akka-http [0] part of these changes?
[0] https://github.com/akka/akka-http
Yes. It is very clear. They have changed the license in the repository: https://github.com/akka/akka-http/commit/3e82a2811e853ece3b4...
tl;dr: It's changing from the Apache License, which is FOSS, to the Business Source License, which is neither free nor open source.
Hopefully someone starts a copyleft fork of the last FOSS version of Akka and drives Lightbend out of business with it.
Hopefully someone starts a copyleft fork of the last FOSS version of Akka and drives Lightbend out of business with it.
To be fair, after 3 years it reverts to the Apache License. I don't think there is much reason for a fork. It is like Ghostscript has always done. I can understand the change might feel a bit sour, but wanting to drive them out of business is a bit much I think. Also, this software sounds like it is mostly used by big companies, they can pay up to keep this software going.
Or the three year statement is to discourage a fork and in three years' time they'll reconsider that part and keep it closed.
The reversion to Apache is part of the BSL license, including the specific timeline of the reversion. So although they could decide later on to change the license again (for example, making it completely proprietary), all of the code released under the BSL will eventually become open source.
> It is like Ghostscript has always done.
No it isn't. Releases of Ghostscript are entirely FOSS from day 1. There's a huge difference between a FOSS project that sells exceptions, and a proprietary program that businesses have to buy a license for to use it all.
No it isn't. Releases of Ghostscript are entirely FOSS from day 1. There's a huge difference between a FOSS project that sells exceptions, and a proprietary program that businesses have to buy a license for to use it all.
You are very welcome to invest your own resources to maintain this.
[deleted]
[deleted]
Great, one more reason to invest in modern open source Java 17. No more of these risky frameworks.
Yet another sign that the pre-FOSS models of Whateverware are back.
As it happens, everyone doing free beer software at the kolkhoz isn't sustainable.
As it happens, everyone doing free beer software at the kolkhoz isn't sustainable.
I contributed a bit to Akka over the years, both in terms of commits (nothing huge but a few here and there) and in terms of community building. I introduced a number of developers to the Actor Model and did several presentations on how cool Akka Streams was, to several hundred people. I'm not "akka royalty" but I _was_ an Akka proponent. I definitely consider this a big middle finger and am pretty sad about what I and others are being forced to do as a result of this.
I don't care to debate open source or license changes, I care mostly about the developers this affects. I care about the people who I got excited about using the actor model with Akka now having to put in a serious amount of effort to rip it out. Mostly these people are at places I no longer work and just inherited codebases where akka happened to win the particular decision on the project. In most of those projects, it could just as easily have been Spring, or Dropwizard, or Kafka Streams, or dozens of other libraries and frameworks.
For those of you who work for companies that don't have over $25m in revenue, please never choose Akka. A company looking to acquire your company is going to do their due diligence looking for poison pills, and Akka became one of those today. For those of you who work for companies making over $25m in revenue, you probably know that the way scaling works, your company is very likely to have a loss rather than a profit. You're also likely to have lots of people in accounting, and requisition, and many levels of management, and not a single one of them will ever consider $2k per vCPU for even a second.
Most companies that have that much revenue are building on pretty rough margins that have gotten a lot rougher this year, and the expectation from the market is to start showing a profit right away. Many companies are finding smaller margins at the same time, and working with a scale of many tens of thousands of vCPUs running in cloud environments, earning only a small amount above the opEx (or maybe even below) of the cloud bill.
These companies are also likely to have to follow regulations like SOC2 or SOX, and have requirements for patching CVEs, so it isn't an option to just keep the same version of Akka once a CVE has been discovered. This is particularly true if you're using akka-http as those servers might be handling traffic that isn't even going through a WAF. Developers in this situation are going to be absolutely screwed. There's no way the company will justify a license that costs more than the physical hardware something is running on, but there is no way they can just not upgrade, either. Maybe the company decides that it'll license, and only have to lay off 50 people as a result. Maybe the company decides it'll fork and 5 people have to maintain that fork until the company can migrate to something else. I know if I were one of those people, I'd quit. I think the best scenario here is to just drop everything you were doing, and either rewrite your akka components or try to swap in something like ZIO and hope you can complete the project before a big CVE hits.
And if a >8 CVE does hit Akka soon, maybe that would be a good thing, as it might foster the creation of one particular fork that could actually gain traction, rather than a diffuse set of hundreds of forks that never gain critical mass.
I don't care to debate open source or license changes, I care mostly about the developers this affects. I care about the people who I got excited about using the actor model with Akka now having to put in a serious amount of effort to rip it out. Mostly these people are at places I no longer work and just inherited codebases where akka happened to win the particular decision on the project. In most of those projects, it could just as easily have been Spring, or Dropwizard, or Kafka Streams, or dozens of other libraries and frameworks.
For those of you who work for companies that don't have over $25m in revenue, please never choose Akka. A company looking to acquire your company is going to do their due diligence looking for poison pills, and Akka became one of those today. For those of you who work for companies making over $25m in revenue, you probably know that the way scaling works, your company is very likely to have a loss rather than a profit. You're also likely to have lots of people in accounting, and requisition, and many levels of management, and not a single one of them will ever consider $2k per vCPU for even a second.
Most companies that have that much revenue are building on pretty rough margins that have gotten a lot rougher this year, and the expectation from the market is to start showing a profit right away. Many companies are finding smaller margins at the same time, and working with a scale of many tens of thousands of vCPUs running in cloud environments, earning only a small amount above the opEx (or maybe even below) of the cloud bill.
These companies are also likely to have to follow regulations like SOC2 or SOX, and have requirements for patching CVEs, so it isn't an option to just keep the same version of Akka once a CVE has been discovered. This is particularly true if you're using akka-http as those servers might be handling traffic that isn't even going through a WAF. Developers in this situation are going to be absolutely screwed. There's no way the company will justify a license that costs more than the physical hardware something is running on, but there is no way they can just not upgrade, either. Maybe the company decides that it'll license, and only have to lay off 50 people as a result. Maybe the company decides it'll fork and 5 people have to maintain that fork until the company can migrate to something else. I know if I were one of those people, I'd quit. I think the best scenario here is to just drop everything you were doing, and either rewrite your akka components or try to swap in something like ZIO and hope you can complete the project before a big CVE hits.
And if a >8 CVE does hit Akka soon, maybe that would be a good thing, as it might foster the creation of one particular fork that could actually gain traction, rather than a diffuse set of hundreds of forks that never gain critical mass.
Shit, the poison pill and CVE SOC2/SOX/PCI issues are super insightful. I hadn't thought of that . Great comment.
The insane cost of licensing, and the speed of this change makes it plain in my mind that Akka is a ransom note with the first CVE that is discovered, and a poison pill for any smaller company hoping to get investment or acquisition. These seem like the actions of private equity trying to get a quick buck prior to liquidation. I think Bonér should be ashamed of himself.
[deleted]
"Akka: enables organizations to execute their most digitally transformative strategies, no matter how complicated"
Thanks video
Thanks video
It’s too bad they didn’t lookup what BSL is, but it’s the Boost license and a super liberal(explicitly keeping source attritubtion) vs whatever this is.
Does this affect akka.net?
Maintainer of Akka.NET here - I don't think so. Posted another comment earlier in the thread with some more details.
Create a sub company with no revenue. Problem solved.
> Sadly, open source is prone to the infamous “Tragedy of the commons”, which shows that we are prone to act in our self-interest,
Like, when somebody releases something open source, then notice that they can actually make money out of it and they change the license at the last minute. Oh the hypocrisy.
Seriously if you're bothered by people making money out of your product, keep it closed source, nothing wrong with it. On the contrary a plague of the latest years is this pressure that everything should be open source: it doesn't need to. If you're not comfortable with it, keep it closed source.
But if you decide to open source something, keep your promises, no matter what.
Like, when somebody releases something open source, then notice that they can actually make money out of it and they change the license at the last minute. Oh the hypocrisy.
Seriously if you're bothered by people making money out of your product, keep it closed source, nothing wrong with it. On the contrary a plague of the latest years is this pressure that everything should be open source: it doesn't need to. If you're not comfortable with it, keep it closed source.
But if you decide to open source something, keep your promises, no matter what.
> But if you decide to open source something, keep your promises, no matter what.
Presumably all older versions of the software that were Apache licensed remain so. They are switching to BSL (closed, but source available and each revision switches to Apache licensed 3 years later) going forward.
I don't see how this is worse than keeping everything closed source from the start, which is your suggestion? Shouldn't we be thankful for all the work they've done so far for free, and if somebody doesn't like the new licensing model, then they can fork it from the last Apache-licensed version and keep going from there?
Presumably all older versions of the software that were Apache licensed remain so. They are switching to BSL (closed, but source available and each revision switches to Apache licensed 3 years later) going forward.
I don't see how this is worse than keeping everything closed source from the start, which is your suggestion? Shouldn't we be thankful for all the work they've done so far for free, and if somebody doesn't like the new licensing model, then they can fork it from the last Apache-licensed version and keep going from there?
No, because it’s a bait and switch. They attracted a bunch of people to use and contribute to their software because it’s open source. Almost all of them do not have the capacity to maintain their own individual fork of the software. It’s like if you decided to carpool with someone and halfway through they parked the car at the side of the road and switch into another car, leaving you with the original one. I mean, hey, they’re giving you a car to finish your trip! But what if you don’t know how to drive? What if you didn’t plan on spending your next twelve hours focusing on the road? People usually don’t expect their open source software to suddenly go closed source out from under them, just like they don’t expect their carpool buddy to bail on them halfway through the trip.
Anybody using a current version or older under an Apache license can continue to do so, as far as I can tell.
Nobody using a free version of any software should expect some benelovent 3rd party to continue fixing bugs and making improvements for free, even if you enjoyed that privilege before.
Nobody using a free version of any software should expect some benelovent 3rd party to continue fixing bugs and making improvements for free, even if you enjoyed that privilege before.
Your point is valid, but isn’t what I was getting at, because it’s largely equivalent to a maintainer just dividing yo wind down contributions to some software they made. This is something we generally consider to ok, although some exceptions exist.*
Here, the project is actually taking part of the community with it, fracturing contributions and the people who work on it. Going back to the car example, it’s like you have a couple of people carpooling and you each take turns buying snacks to share so you’re not hungry during the trip. Now the two people will go in the new car, or their own vehicles, and now you have to buy snacks entirely by yourself, there’s no pooling anymore. This is stretching the analogy a little bit, because you can copy software and not snacks, but a lot of people contribute to open source because, well, if everyone contributes a bit they all benefit from the community pool of code in the future. If I submitted code to this project while it was open source and now to my access to the shared benefits of an open source project is gone, because I have to use the old code pre-relicense, then I’d be kind of upset.
*Name squatting, actively attempting to advertise an unmaintained project, other forms of essentially false advertising nonwithstanding
Here, the project is actually taking part of the community with it, fracturing contributions and the people who work on it. Going back to the car example, it’s like you have a couple of people carpooling and you each take turns buying snacks to share so you’re not hungry during the trip. Now the two people will go in the new car, or their own vehicles, and now you have to buy snacks entirely by yourself, there’s no pooling anymore. This is stretching the analogy a little bit, because you can copy software and not snacks, but a lot of people contribute to open source because, well, if everyone contributes a bit they all benefit from the community pool of code in the future. If I submitted code to this project while it was open source and now to my access to the shared benefits of an open source project is gone, because I have to use the old code pre-relicense, then I’d be kind of upset.
*Name squatting, actively attempting to advertise an unmaintained project, other forms of essentially false advertising nonwithstanding
True, but this misses the point about why a lot of people bother to contribute to OSS in the first place.
A thriving OSS project is more than just the software, it's a community. People contribute features and bug fixes upstream so that everyone else can benefit, because in return they also get the benefit of others contributions. It's a body of collective endeavour. There's a social contract.
Taking an established, OSS project and closing it destroys that community. Sure, it's legal, and everyone can continue to use the version they're currently on, but something dies, and trust is broken.
A thriving OSS project is more than just the software, it's a community. People contribute features and bug fixes upstream so that everyone else can benefit, because in return they also get the benefit of others contributions. It's a body of collective endeavour. There's a social contract.
Taking an established, OSS project and closing it destroys that community. Sure, it's legal, and everyone can continue to use the version they're currently on, but something dies, and trust is broken.
> Taking an established, OSS project and closing it destroys that community
No. If there is a vibrant community of developers, then that community can make the decision to fork. From the OP it seems like there is no community, just enterprise users that do not “give back” open source, which happens.
Even without the community, those enterprise users can create a new community of users to keep the current version maintained.
A similar situation occurs when a library supplier company goes under - which is one risk you take on whenever you depend on a commercially developed library (whether FLOSS or closed).
No. If there is a vibrant community of developers, then that community can make the decision to fork. From the OP it seems like there is no community, just enterprise users that do not “give back” open source, which happens.
Even without the community, those enterprise users can create a new community of users to keep the current version maintained.
A similar situation occurs when a library supplier company goes under - which is one risk you take on whenever you depend on a commercially developed library (whether FLOSS or closed).
This is very cynical view. Why would you expect a community to form around product led by a leadership with such an attitude?
Changing license mid-flight is an attempt to reap benefits from existing community, but not providing the benefits the old license provided.
Changing license mid-flight is an attempt to reap benefits from existing community, but not providing the benefits the old license provided.
What promise are they not keeping? The existing versions are still available as open-source. The Apache license does not require them to continue to release subsequent versions under the same license. The GPL does, but by not releasing under the GPL in the first place, they were clearly not making that promise.
> change the license at the last minute.
This is after 13 years of support not "last minute".
This is after 13 years of support not "last minute".
[deleted]
> But if you decide to open source something, keep your promises, no matter what.
I don't understand the sentiment of "once something is OSS, it has to be so forever". They owe you what exactly? More of their free time & money to hold up something you call a "promise" but is just their choice of license made many years ago?
They are being reasonable about it, you still get the source, you can still use it for free on a revenue < $25M. Companies making significant amounts of money now have to pay for it, instead of freeloading.
Its fine to spend your nights and weekends on passions projects when your young, its also fine to demand money for shouldering much of its development when said project grows large many years later and you have obligations towards your family. Its called being an adult.
I don't understand the sentiment of "once something is OSS, it has to be so forever". They owe you what exactly? More of their free time & money to hold up something you call a "promise" but is just their choice of license made many years ago?
They are being reasonable about it, you still get the source, you can still use it for free on a revenue < $25M. Companies making significant amounts of money now have to pay for it, instead of freeloading.
Its fine to spend your nights and weekends on passions projects when your young, its also fine to demand money for shouldering much of its development when said project grows large many years later and you have obligations towards your family. Its called being an adult.
> I don't understand the sentiment of "once something is OSS, it has to be so forever". They owe you what exactly?
If I contributed to the project, I did so under the premise of the LICENSE that was active when I contributed. If I didn't like OSS, I wouldn't have contributed to a OSS project. Them changing the license is a middle-finger to me as a contributor.
> Its fine to spend your nights and weekends on passions projects when your young [...] Its called being an adult
With all due respect, fuck you. Equaling "open source" to "young people can waste their time" and "software needs to earn money" to being an adult is a really shitty opinion to put out there.
Me (40+ years old) and many others do open source because we want the world to be about more than just money. Just because you cannot understand that nor want the same thing, doesn't mean that we're wrong and you're right.
If I contributed to the project, I did so under the premise of the LICENSE that was active when I contributed. If I didn't like OSS, I wouldn't have contributed to a OSS project. Them changing the license is a middle-finger to me as a contributor.
> Its fine to spend your nights and weekends on passions projects when your young [...] Its called being an adult
With all due respect, fuck you. Equaling "open source" to "young people can waste their time" and "software needs to earn money" to being an adult is a really shitty opinion to put out there.
Me (40+ years old) and many others do open source because we want the world to be about more than just money. Just because you cannot understand that nor want the same thing, doesn't mean that we're wrong and you're right.
> If I contributed to the project, I did so under the premise of the LICENSE that was active when I contributed. If I didn't like OSS, I wouldn't have contributed to a OSS project. Them changing the license is a middle-finger to me as a contributor.
No, you contributed under the premise of the LICENSE that was active when you contributed _and the CLA they made you sign before they accepted your PR_, which said that they're allowed to change the license later on if they feel like it. If you think that the company changing the license for future versions is a middle finger, you shouldn't be contributing to projects that make you sign CLAs.
No, you contributed under the premise of the LICENSE that was active when you contributed _and the CLA they made you sign before they accepted your PR_, which said that they're allowed to change the license later on if they feel like it. If you think that the company changing the license for future versions is a middle finger, you shouldn't be contributing to projects that make you sign CLAs.
Sorry, I was responding directly to the claim ""once something is OSS, it has to be so forever". They owe you what exactly?" without thinking about Lightbend in particular. If you sign a CLA saying they can change the license later on if they so wishes, they are of course free to do so.
How is that morally different from your contribution being used by non-contributing companies to turn profit.
The existing codebase stays OSS, and can be forked. The work they put in starting now, is going to be proprietary for three years.
It feels like a stupid change anyways, as companies can just keep using the old OSS version.
The existing codebase stays OSS, and can be forked. The work they put in starting now, is going to be proprietary for three years.
It feels like a stupid change anyways, as companies can just keep using the old OSS version.
> If I contributed to the project, I did so under the premise of the LICENSE that was active when I contributed. If I didn't like OSS, I wouldn't have contributed to a OSS project. Them changing the license is a middle-finger to me as a contributor.
Whatever you contributed is still available as OSS (the previous version with the old license). Just fork the project and compete with them if you think you can do it better. Lightbend seems to think they can't keep developing OSS Akka in a way that would make them money and thus the change.
Whatever you contributed is still available as OSS (the previous version with the old license). Just fork the project and compete with them if you think you can do it better. Lightbend seems to think they can't keep developing OSS Akka in a way that would make them money and thus the change.
You contributed under the Apache “LICENSE”, which allows them to do exactly what they did. This is hardly a subtle detail, it’s one of the major characteristics of the Apache license.
If you did not like this, you could have chosen to only contribute to projects whose licenses do not permit this, e.g. those licensed under GPL.
Were you unaware of this?
If you did not like this, you could have chosen to only contribute to projects whose licenses do not permit this, e.g. those licensed under GPL.
Were you unaware of this?
Of course they are allowed to change the license to whatever they want, or start adding bugs on purpose to the software if they so wish, anything is possible with the various copyleft licenses.
It's legal, yes. If it's nice towards contributors of past versions, is another thing.
It's legal, yes. If it's nice towards contributors of past versions, is another thing.
No, that's exactly my point, Apache is _not_ a copyleft license.
Under the GPL, you cannot change the license in a subsequent version. You must continue to license any derivative works, including subsequent versions, under the GPL. If someone wants to ensure that the projects they're contributing to remain open-source, they should limit their contributions to GPL projects!
The Apache license does not require you to license derivative works under the same license.
This is why people have strong opinions about different licenses, because some of them provide stronger guarantees than others. If someone ignored these "details" and is now disappointed that they didn't understand what it meant, I don't think that's anyone's fault but their own.
Under the GPL, you cannot change the license in a subsequent version. You must continue to license any derivative works, including subsequent versions, under the GPL. If someone wants to ensure that the projects they're contributing to remain open-source, they should limit their contributions to GPL projects!
The Apache license does not require you to license derivative works under the same license.
This is why people have strong opinions about different licenses, because some of them provide stronger guarantees than others. If someone ignored these "details" and is now disappointed that they didn't understand what it meant, I don't think that's anyone's fault but their own.
[deleted]
"Like, when somebody releases something open source," ... to get traction and own the market (and sometimes, don't know here, get free work) as a business strategy, not for the greater good.
what's the greater good anyway? back to nomadic live off the land no money no capitalism?
can a business strategy align with some version of the greater good?
how much alignment is needed?
can a business strategy align with some version of the greater good?
how much alignment is needed?
No alignment is needed. The referral to "Tragedy of the commons" [1] makes it sound as the primary goal of open sourcing was the common good.
[1] https://en.wikipedia.org/wiki/Tragedy_of_the_commons
[1] https://en.wikipedia.org/wiki/Tragedy_of_the_commons
There is also a challenge in compensating the former OSS contributors who made the community around the product a success...
[deleted]
The commercial license is $2k per vCPU LMAO, aka an 8 core node would cost $16k annually to operate. This is about to be an absolute shit storm, don’t see how this will make a lick of financial sense for corporations to pay this.
I have limited experience, but had some licensing costs in my budget over the years, and $2k/vCPU seems to be at the lower end of such systems. The lever some companies pull is to let you pay for test and developer systems. Then $2k/vCPU gets expensive very fast (from another comment it sounds that you only pay for production systems).
It can add up quickly if you use a couple of libraries and also have to license the OS and perhaps other software. Some proprietary software companies can be quite aggressive with what they consider as cores, e.g. if you have a large VMWare Cluster they consider every single CPU of that cluster for license costs, not just the ones the software runs on - because you could potentially scale the system up or down or do a live migration.
I'm not sure how that would even work with cloud providers, at the worst you would have to pay for the max number of cores you have used in a year (however, it's not even clear what a core is in that context with SMT and preemptable cores).
I'm not sure how that would even work with cloud providers, at the worst you would have to pay for the max number of cores you have used in a year (however, it's not even clear what a core is in that context with SMT and preemptable cores).
Yes I had dealings with two in particular which are very agressive.
It’s free for companies with less than 25m annual revenue, just so you know.
Today.
[deleted]
A lot of “open source means I get to use the software for free and tell the authors what to do, forever, while not contributing a thing in return” in this thread.
That's bullshit and you should know it. The owners got a shitload in return with developers investing time and money into learning their product and suggesting it be used, fueling any side-businesses that the Akka folks had. This was never open source in the true spirit of open source and yet they touted this strong brand.
The same thing has happened several times, especially in the database space. Use the "fake open source" strategy to lure developers and then bait and switch. It's good business, but disingenuous. They remove a core implied premise, akin to a lie. If they were upfront from the beginning regarding eventually cashing in with heavy fees or cutting off contributions, community, etc, then it would be a very different case and there would have been no deception. This is deception.
The same thing has happened several times, especially in the database space. Use the "fake open source" strategy to lure developers and then bait and switch. It's good business, but disingenuous. They remove a core implied premise, akin to a lie. If they were upfront from the beginning regarding eventually cashing in with heavy fees or cutting off contributions, community, etc, then it would be a very different case and there would have been no deception. This is deception.
Anyone working on an Apache-licensed project should expect this might happen, since it is explicitly allowed by the terms of the license. If they are going to get upset about it they could decide to only contribute to GPL-licensed software?
[deleted]
[deleted](1)
Translation: "I'll never pay for software and maybe Akka should never have been created in the first place."
You forgot to translate first part: "Hey we are _giving_ this software as open-source. Build with us, build on us. Help us beat commercial libraries."
Hey, don’t forget that half of Scala ecosystem is built on top of Akka one way or another.
It seems to me that open source/ free software might be in its death throes.
Can anyone name a recent open source library or program that is widely used and community controlled beside Linux?
Open source now mainly serves as a way for trillion dollar companies to pool resources to develop software they all need and minimize how many developers they need to hire (see Linux).
We have seen again and again how open source developers and maintainers are giving the short end of the stick and have seen over and over again companies try to have make an open source business model and fail. RedHat is basically the exception that proves the rule.
Can anyone name a recent open source library or program that is widely used and community controlled beside Linux?
Open source now mainly serves as a way for trillion dollar companies to pool resources to develop software they all need and minimize how many developers they need to hire (see Linux).
We have seen again and again how open source developers and maintainers are giving the short end of the stick and have seen over and over again companies try to have make an open source business model and fail. RedHat is basically the exception that proves the rule.
If we are using Linux as a time frame reference then quite a few. PostgreSQL, Apache web server, python, and Blender are all younger than Linux.
Are you sure? PostgreSQL/Postgres was started before 1986 as successor to Ingres, while Python was released in February, 1991 (vs Linux in September, 1991), based on the older educational programming language ABC. Moreover, Apache httpd was based on NCSA Mosaic released in 1993, but it isn't clear when development started.
Sure, no I used Wikipedia's Initial release dates. It says Postgres 8 July 1996, Apache http server 1995, Blender January 2, 1994.
I guess I miss remembered python I thought it was 93 for some reason, maybe that is java.
I guess I miss remembered python I thought it was 93 for some reason, maybe that is java.
a way for trillion dollar companies to pool resources to develop software they all need and minimize how many developers they need to hire
I don't see any problem with that as long as the companies are paying the developers, which they are in most cases. Major open source like Linux and k8s haven't been developed by volunteers for decades.
I don't see any problem with that as long as the companies are paying the developers, which they are in most cases. Major open source like Linux and k8s haven't been developed by volunteers for decades.
> Can anyone name a recent open source library or program that is widely used and community controlled beside Linux?
I'd answer the opposite question. What do I use in my daily work that isn't open source? Sure there's binary blobs/drivers here and there, and whatever the cloud providers are keeping to themselves.
But c'mon, all the languages, the build tools, web frameworks, libraries, databases (sql and non-sql).
I'd answer the opposite question. What do I use in my daily work that isn't open source? Sure there's binary blobs/drivers here and there, and whatever the cloud providers are keeping to themselves.
But c'mon, all the languages, the build tools, web frameworks, libraries, databases (sql and non-sql).
> Sadly, open source is prone to the infamous “Tragedy of the commons”, [...] This situation is not sustainable and one in which everyone eventually loses.
> So what does sustainable open source look like? I believe it’s where everyone—users and developers—contributes and are in it together, sharing accountability and ownership.
> This means that companies using the software for profit need to give something back, either code, documentation, community work, or money. In sustainable open source, participants feel the need and moral obligation to contribute.
They even go so far to say they believe BSL to be Open Source, which means they fundamentally misunderstand the idea behind Open Source:
> We believe the BSL 1.1 with our open source grants and Apache re-license is a form of productive and sustainable open source.
They also seem to not know of any big Apache projects that are sustainable, even though there are many examples out in the wild. Apparently none of those projects are sustainable, just because Lightbend didn't manage to actually get major contributors to their own project?
> Apache 2.0 is a very liberal license well suited for early, small open source projects establishing community.
> With Akka now considered critical infrastructure for many large organizations, the Apache 2.0 model becomes increasingly risky when a small company solely carries the maintenance effort.
Just because you didn't manage to build a company around a Open Source library/ecosystem, doesn't mean Open Source is not sustainable. It just means that your company is not sustainable. But I guess it's hard to blame yourself when you see others using your code without paying for it.