We Are Changing the License for Akka • Hacker News Board

Re: We Are Changing the License for Akka

#191

Post by whaleofatw2022 » Wed, Sep 07, 2022, 4:32 PM UTC

bmitc wrote: post #15

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.

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.

Re: We Are Changing the License for Akka

#192

Post by dllthomas » Wed, Sep 07, 2022, 4:32 PM UTC

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.

Re: We Are Changing the License for Akka

#193

Post by ccleve » Wed, Sep 07, 2022, 4:34 PM UTC

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.

Re: We Are Changing the License for Akka

#194

Post by gregwebs » Wed, Sep 07, 2022, 4:36 PM UTC

fatherzine wrote: post #179

haspok wrote: post #178

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 exa…

[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

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.

Re: We Are Changing the License for Akka

#195

Post by dllthomas » Wed, Sep 07, 2022, 4:37 PM UTC

piaste wrote: post #123

arinlen wrote: post #69

Earlier quoted context omitted.

> 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.

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 s…

> 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")

Re: We Are Changing the License for Akka

#196

Post by eecc » Wed, Sep 07, 2022, 4:38 PM UTC

Shareware is back (sort of.)

Not a bad thing per se, by the way…

Re: We Are Changing the License for Akka

#197

Post by xani_ » Wed, Sep 07, 2022, 4:43 PM UTC

Pre reading: Is it because VC funded company needs to show returns ?

https://www.crunchbase.com/funding_round/typesafe-series-d--...

post-reading: ...probably

Re: We Are Changing the License for Akka

#198

Post by pxc » Wed, Sep 07, 2022, 4:44 PM UTC

miragecraft wrote: post #184

kryptiskt wrote: post #67

Earlier quoted context omitted.

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 op…

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.

> 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.

Re: We Are Changing the License for Akka

#199

Post by xani_ » Wed, Sep 07, 2022, 4:48 PM UTC

ccleve wrote: post #193

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 a…

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.

Re: We Are Changing the License for Akka

#200

Post by robocat » Wed, Sep 07, 2022, 4:52 PM UTC

growse wrote: post #56

hiram112 wrote: post #43

Earlier quoted context omitted.

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.

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,…

> 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).