blog.kronis.dev

Software licenses and hyperscalers

Date:

Software licensing is a bit of a mess.

There's many different licenses out there that are meant to protect either the users of the project, the developers, or any corporate interests. Some licenses are proprietary and geared explicitly towards commercial interests, though others are meant to ensure the viability of open source projects, or just free software as a movement in general.

Generally, the open source ones fall into one of two camps:

In most cases (except for maybe LGPL), the copyleft licenses more or less "infect" the rest of your project and affect what you can do with the rest of it, which does matter a lot. There's also many others out there, but for now let's just focus on the well known ones. Because most of the examples out there kinda suck due to how non-specific they are, let's imagine some concrete situations.

What do the software licenses mean

Suppose I want to run an online file converter of some sort as a business: you subscribe to it with PayPal and in exchange can use an API where you upload files and get outputs. Let's see how the different licenses can alter my experience as a developer.

Let's say that I have a PDF file processing library that I do not change in any other way, merely include in my project, which is the most common case when it comes to dependencies (imagine your typical npm install, Maven, NuGet or any other dependency management solution).

How does this affect the license of my software:

Do I have to publish ALL of my source:

Now, let's say that I also have a DOCX file processing library, that I do change - maybe there are performance issues that I solve, or some usability problems that I want to address, data formats that need tweaking, anything really. I take their code off of GitHub, import in my own source management solution and do some changes to it.

How does this affect the license of my software:

Do I have to publish the changed library code:

Do I have to publish ALL of my source:

That turned out to be a lot of text, come to think of it, this would have probably been better served by a table:

software-license-table

To sum it all up, essentially:

So what are the problems with this?

Some personal gripes with the licenses

Firstly, the fact that I needed a table to even explain how these things work and even then I cannot be 100% sure that I haven't missed some nuance.

Secondly, while the idea of LGPL is nice, it essentially has legalese dig into the technical implementation details: suddenly, if I want to distribute a statically compiled executable, I need to think about also distributing the object files to comply with the LGPL's relinking requirements:

Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

and

The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.

For some languages like Go that isn't status quo. Do I even know how to get object files out of it, so relinking can be done? It might not be in the happy path of what most tutorials and tooling out there is geared towards, in some languages and stacks not that much consideration might have been given to the use case at all, it might not be possible altogether!

Does the user need to know the exact version and type of compiler used to be able to produce something that will work on a technical level, information that I now also have to give them not to be in breach of the license? You are also more or less obligated to share the actual instructions for building the app as well, giving anyone more insight into your build process.

The Apache license also demands that changes of what you've done be summarized in NOTICE files:

Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

a. You must give any other recipients of the Work or Derivative Works a copy of this License; and

b. You must cause any modified files to carry prominent notices stating that You changed the files; and

c. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

d. If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

That means that you also need to keep track of everything you change, in addition to distributing that information, a bit more process that's required of you by the license. Aside from that, just look at the above - lawyers might be used to that sort of language, but it feels straight up jarring to your average developer. It reads like language that's the equivalent of a line of code with a bunch of chained ternaries in it, utterly unpleasant.

That said, those are just personal gripes. The real issues are with the fact that depending on who you are, the license is hostile to you.

Why most licenses end up being hostile to you

You see, the licenses can be written to protect the users, or the authors of the software, maybe even to protect against corporate interests and such. The issue is that, depending on what you do, you might fit in any number of those roles at different points in time, meaning that software that might be great in your private life might be horrible at work (can't use it), or vice versa, some proprietary code that you could benefit greatly from work you could not use in any open source work that you do.

Proprietary code hurts users

Suppose that there's a lot of proprietary, closed source software out there. You cannot get access to the source code to fix the bugs, nor if some SaaS gets retired, can you keep using it - instead, it's gone. I might even use some drivers for printers or maybe, as a more modern example, a GPU as an example here - if they're just a blob for the computer to interpret, you aren't fixing bugs in that yourself, nor can anyone else do that. Alternatively, if we're talking about a web service of some sort, they might just decide to raise prices a bunch, or move from a traditional software model to a subscription based one, which you might not really consent to, but the end result is the same - you lose.

This is essentially what the free software movement is fighting against, to give more control to the users of the software, provided that the licenses are enforced in your country, instead of a company sneakily using a bunch of GPL/AGPL code without telling anyone. Even if not done maliciously, how much effort do you think actually goes into ensuring compliance in most companies, about having proper SBOM reporting, or even making sure that your developers aren't just straight up using pirated software? While I can say that the tooling is there thankfully, I seriously doubt that caring about intellectual property is a constant across all cultures (have a look here or here, though I don't think anyone is trying to document all the cases out there), but I digress.

Viral copyleft licenses hurt professionals and companies

Now, imagine that you're a typical 9-5 developer who writes software for a company. You really need that PDF or DOCX library because there's no way you're writing those from scratch, your abilities are just human and you have deadlines. Yet, there's also no way that you can use GPL or AGPL code in your project, because that would mean that you'd have to publish everything - which is completely unacceptable in most projects and circumstances. In other words, the license can also end up making you fail, both yourself professionally and your entire team/company that needs some code that solves the issue, but which you just can't touch. The same applies with consulting or similar use cases.

Suppose that some government, even my own, decided to use AGPL licensed code in their new tax system. It would be developed under your typical government oversight with public sector salaries and the average developers those can attract. Suppose they'd have to publish all of their source code and would do so.

Many will shout from the rooftops that "given enough eyeballs, all bugs are shallow" or that security through obscurity is bad, but the ideology misses the reality: consider the percentage of capable developers that will be interested in solving the bugs and vulnerabilities in some random software system that nobody cares about (and going through the process to merge the changes with a bunch of underfunded devs on the other side, maybe even without proper contributing guidelines) vs the percentage of malicious individuals or organizations that might earn some actual money by pwning the system and selling whatever data or exploits they find.

Essentially, these viral licenses would make a lot of the software out there less secure on the account of the insecurity now being visible and there being nobody who cares enough or has enough time or resources to fix everything: a very clear case of resource assymetry, where you would have a few defenders and plenty of motivated attackers.

Permissive licenses will make cloud companies freeload

Aside from that, many companies might actually not be opposed to shipping MIT, BSD and Apache 2.0 licensed code, except imagine that you're a popular database vendor that has just one such product. It gains a lot of attention, you're well liked and things seem to be going well. But then a cloud vendor that is 10x your size decides to offer a hosted version of your service, attracting a lot of your customers to their platform instead, probably earning millions in the process and you not seeing a single dime of that. In other words, they can take the code that you've written without giving anything back and benefit from that greatly.

In a perfect world, people would get along. Companies would be ethical - the cloud vendor would give you money for your troubles and for continued development, maybe a certain cut of the profits and you could also just give your software away because people would donate due to benefitting from it. It would be easy to do (which at least some people are working on and also this exists) and it would be as ingrained in the culture, as the tipping culture is in the US, maybe even a comfy little popup in your OS letting you know all of the cool software running on it and being able to just send an aggregated donation through PayPal that then gets distributed or what have you - not unlike in principle to how you can work on your environmental impact, though something that's offered to you and that you don't have to seek out.

But a perfect world would also have UBI or something like it, or ample government programs to support developing useful things for the society (which, again, at least some people are working on). Sadly, for the most part, that isn't quite the case - a lot of the open source software out there is developed more or less under the poverty line and can be a thankless job, which is how you get memes like this:

modern-infrastructure

(from XKCD 2347: Dependency)

I'm not even slightly exaggerating here.

Go read this, it has some more nice examples: Professional maintainers: a wake-up call

Furthermore, since companies seem to attempt to maximize profits at the expense of all else, they seem to have no qualms about capitalizing on someone else's labor, or even stealing ideas outright. The reality is that the licenses can't be written with a best faith interpretation and wishful thinking. Sadly, this also meant that we ended up with new licenses that make them be hostile to us in more cases than just the above.

But wait, it gets worse

The companies writing software very much saw the trend of these cloud companies, these hyperscalers, taking their software and earning the big money, arguably some of which should be theirs instead, because they're putting in all of the effort into creating the software. Lacking any other means of actually getting the money that might be rightfully theirs, some of them moved to a new class of software licenses - often no longer considered to be "open source", but rather source available and with other restrictions in place.

I will offer up only the relevant fragments from blog posts regarding them or license text to prevent this from getting overly long.

Either way, here's a few...

Server Side Public License

MongoDB moved from AGPL to their own license in 2018, claiming that even the boundaries of AGPL were being tested by other companies:

The SSPL builds on the spirit of the AGPL, but clarifies the condition for providing open source software as a service. The license retains all of the same freedoms that the open source community had with MongoDB under the AGPL: freedom to use, review, modify and redistribute the software. The only substantive change is an explicit condition that any organization attempting to exploit MongoDB as a service must open source the software that it uses to offer such service. This license change will not impact customers who have purchased a commercial license from MongoDB.

If you read the license, it pretty much reads like the nuclear option:

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

Essentially, we're not even talking about open sourcing whatever interacts with the MongoDB instance directly anymore.

You have an analytics or a reporting solution? You have to give up the source. Invoicing platform? You have to give up the source. Something for backups, or some DevOps automation? You have to give up the source.

Essentially, everything that runs your business and your MongoDB SaaS, which is kind of hypocritical, because I'm not seeing the MongoDB organization do the same thing, which, of course, is permissible, because they're the copyright holders. I'm not even sure how everyone is not saying that this is completely outrageous, because it more or less is - if you complied with the license and published everything, suddenly your company would have to deal with a lot of malicious actors, which would hack your systems with a dangerously high degree of success, at least in the case of most companies out there. Well, either that, or every single one of your marketing funnels or user acquisition mechanisms, analytics, or anything else would be put under a lot of scrutiny by the media that seeks flashy headlines for the sake of clicks. In most cases, SSPL is a non-starter, maybe that's the whole point.

The message here is clear - if you want to benefit from the software, time to buy their commercial license.

Elastic License

Elastic moved from a pure Apache 2.0 license to their own license in 2021 and with some further clarifications alongside SSPL, directly addressing what happened with AWS offering their software as a service:

So why the change? AWS and Amazon Elasticsearch Service. They have been doing things that we think are just NOT OK since 2015 and it has only gotten worse. If we don’t stand up to them now, as a successful company and leader in the market, who will? Our license change is aimed at preventing companies from taking our Elasticsearch and Kibana products and providing them directly as a service without collaborating with us.

Over the last three years, the market has evolved and the community has come to appreciate that open source companies need to better protect their software in order to maintain a high level of investment and innovation. With the shift to SaaS as a delivery model, some cloud service providers have taken advantage of open source products by providing them as a service, without contributing back. This diverts funds that would have been reinvested into the product and hurts users and the community.

We chose this path because it gives us the opportunity to be as open as possible, while protecting our community and company. In some ways, this change allows us to be even more open. As a follow-up to this change, we will begin moving our free proprietary features from the Elastic License to be dual-licensed under the SSPL as well, which is more permissive and better aligned with our goals of making our products as free and open as possible.

The Elastic License 2.0 applies to our distribution and the source code of all of the free and paid features of Elasticsearch and Kibana. Our goal with ELv2 is to be as permissive as possible, while protecting against abuse. The license allows the free right to use, modify, create derivative works, and redistribute, with three simple limitations:

  • You may not provide the products to others as a managed service.
  • You may not circumvent the license key functionality or remove/obscure features protected by license keys.
  • You may not remove or obscure any licensing, copyright, or other notices.

and their FAQ cleared up a point of confusion:

"I am building an application on top of Elasticsearch, how does ELv2 work for me?"

You may freely use Elasticsearch inside your SaaS or self-managed application, and redistribute it with your application, provided you follow the three limitations outlined above.

Eventually it also got AGPL floating in there somewhere, which makes things even more complicated, but it's a very clear move against hyperscalers, to protect their software. It is quite interesting that as time goes on, more and more licenses like these seem to pop up, from quite prominent companies and widely used software, clearly it's a widespread issue.

Business Source License

This one is a license used by MariaDB for their MaxScale product, which eventually converts to an open source license after some time has passed, usually something like 4 years:

BSL is a new alternative to closed source or open core licensing models. Under BSL, the source code is always publicly available. Non-production use of the code is always free, and the licensor can also make an Additional Use Grant allowing limited production use. Source code is guaranteed to become Open Source at a certain point in time. On the Change Date, or the fourth anniversary of the first publicly available distribution of the code under the BSL, whichever comes first, the code automatically becomes available under the Change License. The Change License is mandated to be GPL Version 2.0 or later, or a compatible license (i.e., the Change License is always an Open Source license that enables use of the software in a GPL project).

I don't actually have that much to say about this, except that I think the license itself is interesting, because it ensures that the software will eventually be open source, while at the same time protecting whatever competitive edge those initial years might give you. Of course, I don't really imagine that very many companies out there would want to start their commercial venture on 4 year old software, but since the term is something that the copyright holder can decide on, I don't think 1-2 years would be out of the question either.

What are the consequence of these licenses

No matter how you look at it, SSPL is the biggest case here and what essentially started the movement of protectionism against the hyperscalers, with quite a few prominent pieces of software adopting the same license:

For many companies out there, that's quite a large part of their software development stack and in many cases it takes that software off the table altogether.

But surely the community and organizations in question realized the perspective of the original developers and were accepting of this decision, right? Well, no. If MongoDB had fallen down and needed a bit of help getting back up, the reaction was more like getting kicked in the face again, it was very much the case for all of the software above: because in many cases, the maintainers felt that they had been contributing to an open piece of software (because they were) and then suddenly someone took their work away from them, or imposed restrictions to it that they no longer agreed with, something that was more or less forced upon them. In other words, they felt like they were just responding to being kicked in the face first, in kind.

Someone might say: "But hey, the old versions are still permissively licensed, you can just use those." That is patently false, because the statement is nonsensical: you don't get to just use old versions of software, versions that will no longer get updates and eventually will drown in CVEs to the degree where you won't be able to run them without ending up with a "surprise backup". Just ask anyone who wanted to keep using Windows XP how long their machine can be connected to the Internet before it ends up as a part of some botnet. Ask people who couldn't keep up with the updates to Log4j, just how well it worked out for them.

The forks

So what did the community and those aforementioned large companies do? Well, they did what nerds do when they get angry: they grabbed their keyboards and forked whatever they could fork, when there were no viable alternatives for the problem that they want to solve with the software.

It wasn't unlike what happened to Gogs and Gitea, or later Gitea and Forgejo. The irony of the same thing happening twice doesn't surprise me, but in the open source world, at least it's an option - if the userbase puts their foot down and decide that they want to govern and develop the project differently, they can go ahead and do just that.

The unfortunate part is that it might as well kill the company just trying to protect its own software from these large tech companies, which once more is the case of them not aligning with the ideas behind free software, because they weren't conceived in a world where your ideas will be blatantly stolen, or even the software you've spent years on, trying to build business upon, which is now just a click away in some large platform that will easily outcompete you.

When it happened initially with MySQL and MariaDB it seemed pretty good - it was a smaller group of developers and community members forking a project that now belonged to a large enterprise, but this time it went in the opposite direction. Of course that was before the SPAC and the mess that followed, but oh well.

MongoDB

Curiously, no big alternatives to MongoDB emerged, there was Percona Server for MongoDB but it never caught on that much, whereas AWS went with DocumentDB, maybe on the account of the popularity of MongoDB already declining, after the NoSQL boom more or less dissipated.

Elasticsearch and OpenSearch

Elasticsearch was also forked by AWS and became OpenSearch, licensed under Apache License 2.0. As with other forks, the functionality diverged slightly over time, but a good chunk of the community was definitely fragmented and the attempt by Elastic to reign in the competition didn't really work. Essentially, the previously free software didn't have any sort of a moat or any inherent difficulties that would prevent a fork from taking off. Furthermore, the Linux Foundation also got involved:

Today the OpenSearch project has significant momentum, with more than 700 million software downloads and participation from thousands of contributors and more than 200 project maintainers. The OpenSearch Software Foundation launches with support from premier members AWS, SAP, and Uber and general members Aiven, Aryn, Atlassian, Canonical, Digital Ocean, Eliatra, Graylog, NetApp® Instaclustr, and Portal26.

I guess is good for the users, but not so much the company that just wanted to exist, I can't help but to feel a bit sorry for them.

Redis and the forks

With Redis, a prominent key-value store, the consequences were even more significant, there were more numerous forks and alternatives:

The thing here is that if your software or product is simple enough (relatively so) to be replicated by others, even from zero, then you can't really be sure that you have that much survivability to it. That'd be more or less like me trying to create a social media platform and even if I have some good ideas, they'd probably quickly be "borrowed" by others relatively quickly - at the same time, I think that Redis is great software and have nothing against them.

Graylog and the alternatives

With Graylog, however, it seems that nobody really cared that much?

It appears to be a case of a fairly populated market with lots of options available for log management:

In other words, it's a bit like the above case with Redis, except nobody really needs to replicate your product verbatim, just something that is easy enough to switch to, especially with logging in particular having all sorts of facade libraries or generic implementations in front of it, given that the domain of shipping a bunch of information from your application to some storage and analysis solution isn't rocket science, even if it takes a good amount of work to get right.

What to do against hyperscalers

I'm seeing a pattern here.

Even if you have pretty popular software, if you try to pull anything funny with the license, the following will usually happen:

In other words, SSPL and the alternatives don't really work towards the stated goals and are more or less like shooting yourself in the foot. The correct thing to do here is to take the gloves off, but only towards the parties that you feel will directly harm your business, not just catch a big part of the community in the blast range of something like SSPL as collateral damage.

Meet the Anti-Hyperscaler Software License:

Take whatever license you desire as a base, this would work even with the more permissively licensed ones like BSD or MIT, or Apache 2.0.

Allow pretty much everyone use the software however they choose, EXCEPT for specific companies, to which a different set of terms will apply.

In the more permissive version of the license, allow the software to be used for internal projects within said companies BUT not for managed services.

In the more restrictive version of the license, disallow the company or any of its subsidiaries to use the software in ANY capacity.

Disallow any forks to change the license, for as long as your organization exists and has an interest in the project, or maybe take a page from BSL's book.

Now here's the interesting bit: name the exact companies. For example: "These restriction clauses apply to the following companies and their subsidiaries: Amazon, Google, Microsoft, Alibaba Group, IBM, Oracle, Tencent, ..."

That way, you choose exactly which companies are restricted and you can even write that the list may be updated in the future and that they must acquire a commercial license from you within X months of being added to the list.

That's it. The community members get to use the software how they please (outside of modifying the license), smaller companies can use the software and have a healthy ecosystem and roughly competitive managed offerings to whatever you might have, whereas the large hyperscalers are not allowed to even touch the software, should you choose to, unless they fork over whatever amount of money you demand.

I did offer up as much as an idea in a comment on a related HackerNews discussion, where it promptly got downvoted and didn't get much traction, the critiques I got being:

#1: No legal department will ever approve using software under a license like that. Who wants to risk being the next addition to that list?

#2: You could, but it still wouldn't be open source.

I think both of those arguments aren't very good.

Correct me if I'm wrong, but I'm not Amazon Web Services, nor have billions in revenue under my couch cushion. Statistically, neither are you. Nor will you ever be. Most businesses out there, I'd reckon that around 90-99% of them are far smaller in their scale and there's no reason for you to fear ending up on that list. And if you do? Just pay up. If you have enough money not to worry about software licenses, like those of the Oracle database, or any other piece of enterprise hardware bankrupting you, then you have no reason not to pay your fair share.

Secondly, it's not open source. Yes. That's correct. For most folks, it won't matter. It's been proven with plenty of the cases above, that open source doesn't really work in our current world and society, outside of rare exceptions. Even Linux gets most of its contributions from large corporations that have people be paid to work on the project. For example, let's look at the statistics for the 6.0 release of the kernel, helpfully summarized by LWN:

linux-kernel-employer-statistics

Even if you summarize just the top 20 most active employers, then you still get 90% of the total lines changed coming from them. Even in such a widely used open source project, at the end of the day, money still plays a role. If those big companies could move to a permissively licensed alternative and it'd give them a competitive edge, be sure that they would. In other words, practicality matters more than ideological stances and if source available licenses will prevent your company from dying, then don't try to go full Stallman and just do what works.

Furthermore, even a switch from something like Apache 2.0 license to this hypothetical anti-hyperscaler license would be a really tough sell, since if the users feel like some freedoms are taken away from them (even if not really, because they are not and will never be on that list themselves), they will still rebel and reject your software. Ergo, the license to protect yourself as the author of the software must be there from day 1.

Alternatively, you can do what Drone CI and lots of other software does: have an open core that lets most of the smaller organizations still find plenty of value in the software, but require additional enterprise features to be licensed. Drone's case is particularly interesting, because their Enterprise license has the following in it:

  1. You must limit use of this software in any manner primarily intended for or directed toward commercial advantage or private monetary compensation to a trial period of 32 consecutive calendar days. This limit does not apply to use in developing feedback, modifications, or extensions that you contribute back to those giving this license.

...

Waiver: Individual and Small Business

Contributor waives the terms of rule 1 for companies meeting all the following criteria, counting all subsidiaries and affiliated entities as one:

  • worldwide annual gross revenue under $5 million US dollars, per generally accepted accounting principles

  • less than $5 million US dollars in all-time aggregate debt and equity financing

Contributor will not revoke this waiver, but may change terms for future versions of the software.

For what it's worth, there was still the Woodpecker CI fork, though I still use Drone for my personal needs, because they got no bad will from me for their licensing choices. If nothing else, those terms feel very much fair. And even as Drone is being retired in favor of Harness, I don't really feel like I've missed out on anything over the years I've been using the software, because even the free version had every feature I needed.

On the other hand, there's software like Mattermost, that more or less ruin the open core model: despite it being a great self-hostable alternative to Slack, you can't do more than 1:1 calls in the free version, nor can you have AD/LDAP sync of the users. That obviously sucks if you just want to have some software for your scrappy startup with like 10 people working in it, vs arguably the more sensible exemptions in other licenses for small businesses, maybe even a limit on the total user count, like Docker has done with Docker Desktop:

Docker Desktop is free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.

Otherwise, it requires a paid subscription for professional use.

In my eyes, there's nothing wrong with it, nor is there anything wrong with them imposing limitations for how often container images can be pulled from their Docker Hub, but there is definitely an issue when you cripple your software while claiming that it has a good free version.

Summary

I still very much believe that both software licensing and the whole situation around it is an absolute mess.

While these license changes do get a lot of negative attention, they still feel like something that is necessary to ensure the longevity of the companies actually developing the software.

Open source and free software are both nice, but due to the prevalence of hyperscalers and none of the companies wanting to give anything back to the authors of the software, some sort of protectionism is needed. The problem there is that any license changes or most community members (that are not causing the financial hardships) being caught in the blast range will lose a lot of goodwill and often will lead to the death of your software by being repeatedly forked, alongside your community and ecosystem.

To me, "source available" as a term seems to minimize all of the nuance, but licenses like BSL or even ones that have company size and revenue limits feel sensible. Not only that, but if you want to protect your software against hyperscalers while not harming the little guy (e.g. small to medium sized companies and competition that feels more fair), then I think that the gloves should come off and those large companies should be named directly within the licenses of the software you make, so only they get the more stringent restrictions on how they can use your software.

If AWS wants to swallow the entirety of your userbase with their managed offering of your software, they shouldn't get neither free beer, nor free speech, unless that speech is telling you that they'd like to license out a commercial version of your software and give you plenty of money for using it in their cloud offering, so it becomes fair.

I'm surprised that this stance isn't embraced more and even in regards to software development, open source devs do it for close to no money. As someone in a country where neither the salaries nor inflation are that good, it makes me wonder - are they just swimming in money to the degree where they can afford to do that? For example, when opening a GitHub issue on some project, I wonder why I don't get a bot comment along the lines of:

The current bug/improvement bounty for this issue is: 50 USD (link to contribute more)

Any committed bounties will be returned to you within 30 days if the issue isn't solved, whereas upon it being solved you will be able to vote alongside the other patrons about releasing the funds.

Any money held in the escrow doesn't contractually obligate the developers to solve the issue the exact way you desire to, but rather indicates to them the interest and commitment by the community - that the issue and its resolution matters to them.

But hey, maybe it's easy for me to say that, when the principles of free software never quite landed, given the state of Nvidia drivers and the state that trying to run a free software only OS or even IDE leaves my computer in: with the mouse and audio and Wi-Fi not working, as well as not being able to install plugins or even have features like the commercial IDEs have.

That is why I pay for the JetBrains tools and also don't shy away from using both Windows and the likes of Linux Mint with a bunch of proprietary software running on them when needed, alongside paying for the likes of MobaXTerm and donating to the likes of FreeFileSync. If they provide value to me, I will pay for them. That's how it should work.

I have donated money to open source projects in the past and see myself doing so in the future, but I won't lie in saying that trying to work on open source in most cases will often doom you to freeloaders, rude feature requests and poverty; unless you have enough time, energy and motivation to work on it after work hours pro bono, which I sadly do not.

At the end of the day, choose whatever license you think works best for you. As always, I just offer my thoughts and honest look on the state of the world, from my perspective.

Other posts: Previous »