Well done to Redis for making this clear
I once believed that the OSD did a good job of defining the criteria for open source licenses. That changed by experience of how it's actually applied, how it fails, and how OSI fails to redress.
The more I dug into available mailing list archives, the clearer it became that the problem isn't new. It's not just strong copyleft licenses and the constant stream of human rights licenses. It's the FRAND standards patent problem. It's the license-or-contract confusion.
The situation now, as I see it, is that OSD is largely window dressing for OSI. The OSD is vague and incomplete, but sounds official and technocratic. So it functions as window dressing for the prerogative of those with sway at OSI, to call it as they see it.
On that note, the title of the article is misleading. Redis hasn't changed its open source license. Redis remains BSD-licensed. This article is about the change in the proprietary license of certain Redis Modules.
It's more like an especially generous version of shared source than open source.
You can mince words and make inconsequential adjustments to proprietary software licenses but they are still proprietary.
.Net Core and .Net Framework are separate implementations of .Net Standard.
I get that open source business models are hard, especially in an increasingly commoditized space like databases. Still, it rubs me the wrong way when a business wants the goodwill of open source, then tries its hardest to bend the rules in its favor.
Out of curiosity would the GPLv3 at least force providers like Amazon to release any modifications they make to FOSS stuff to turn it into a hosted/managed service? With things like Apache/BSD/MIT, does AWS currently mod stuff without releasing the results as FOSS? (Is Aurora DB really modified MySql or MariaDB under its core?)
But going back to the point, yes this clearly violates the spirit of what many in the 90s viewed as FOSS culture. You write it because it's fun and you want to share. If you can make money off of it, that's great. If not, whatevers.
The big players only open source middleware. Facebook will never FOSS messenger or any big critical parts of the platform itself. They only open the middle parts so other people can build applications dependent on them and the other big players.
I wrote about OSS both in the 90s and today a while back. It's kinda a log read though:
Money is air... without money good luck competing against other technologies.
I find that the OSS community is insanely naive about where OSS comes from.
There's this assumption that it just comes for free like manna from heaven.
I seem HN geeks (saying that in a good way) say how they want to use Firefox vs Chrome because Firefox is somehow less evil.
But where does Firefox get its money from? Google. Google gets its money from ads.
If you track down the source of all the OSS we're using there's some root source that most HN people would not be too happy about.
And the flip side is also true too.
I often hear people complaining about how they don't want to pay for apps and expect things to come for free.
This REALLY screws over a lot of ISVs that are literally just trying to build cool apps.
This is really a tragedy of the commons that we don't address very often.
Most billionaires have figured out some way to exploit this issue - much to our collective disadvantage.
At first the huge corporations saw OSS as a threat. Their model had been to spend money building software, then charge people for that software. Competing with $0 software scared them and caught them off guard.
Now the corporations and VCs figured out how to use OSS as a weapon. And it’s a deadly one!
The developer insistence on everything being open source means that it’s very easy for a large corporation to destroy a whole lot of ISVs by just releasing an OSS equivalent. VCs know this too.
OSS is used as a PR tool. Projects like React and Angular go a long way to making the parent companies look developer-friendly, even though many developers would normally consider those company’s missions against their values.
OSS is also a powerful way for corporations to commodotise their complements. You see this with the cloud vendors jumping behind Kubernetes to ensure Docker wouldn’t be the next Oracle.
Developers expect everything to be free and open source. We’ll end up in a world where the only programming jobs left will be at the corporations who weaponise OSS the best.
Considering that before "OSS" was big as it is now, many companies would refuse to fix their proprietary shit even if we were paying, fuck them. Even now the proprietary software I have to integrate is often basement level outsourced to 200 consultants trash. If anything, open source filters companies out those that are at least proud of showing their work.
That's so overly simplistic. Google tries to spy on everything you do. Mozilla limits their ad revenue to an activity where people are actually looking for something by giving info to a third-party, surveillance (err search) service. They also let you easily change it with a private one built in. They're also owned by a foundation aimed at doing good vs a publicly-traded company that seems to get more evil over time.
So, using and investing in Firefox exposes you to less risk, creates less evil in short/long term, and possibly does more social good. It's an objectively better choice for folks concerned about surveillance-based businesses.
There’s a reason Linux has been so successful even when Microsoft was vehemently against it with incomparable funds.
> But where does Firefox get its money from? Google. Google gets its money from ads.
> If you track down the source of all the OSS we're using there's some root source that most HN people would not be too happy about.
I use Konqueror, most of whose money comes from EU grants. I consider that a better source, and (not coincidentally IMO) it seems to result in a higher-quality codebase and a nicer program.
Who do you think pays for Debian? More generally it seems like while most US projects are corporate-funded, this isn't true for European OSS. A lot of OSS originates in (usually publicly-funded) academic projects and/or direct volunteering. Of course, those projects don't have the advertising budgets of corporation-in-all-but-name style OSS.
Making money is really a shorthand for sustainability. If developers aren't paid, their code can easily fall into disrepair which hurts all their users.
Out of curiosity would the GPLv3 at least force providers like Amazon to release any modifications they make to FOSS stuff to turn it into a hosted/managed service?
They may not make any modifications and those modifications wouldn't contribute to sustainability anyway. Developers can't eat contributions, so if a project is going to have any full-time developers then money needs to enter the system somewhere.
I agree with you, but I also work in a place where we operate 35 year old medical software that hasn’t needed a change in more than two decades.
I know that’s unique and most of the stuff we build today will be out of rotation and obsolete in 5 years, but maybe we should have a conversation about the sustainability of modern software?
I work in the public sector by the way, we operate around 10 different open source projects where I work, and we generally want them build to need as few changes as possible because developers are expensive. We do build for the web, as so many others, but we’ve actually achieved a ton of sustainable by using old slow moving techs like Django rather than more modern stuff.
The simple truth is that we wouldn’t be able to afford open source software if we build it like most people build software these days.
It's probably true that Amazon is able to accomplish this only through strong-arm tactics, but it also seems unfortunate that Redis Labs feels the need to resort to similar strong-arm tactics in retaliation. It doesn't invite anything besides more pressure from Amazon and companies like it. Nobody wins in this in this scenario, especially not the customers who now have no refuge because both competitive offerings are trying to rope them into participating in a turf war.
Potentially that shifts things from a good equilibrium where everyone reaps the benefit of many people contributing to the same projects, to a bad equilibrium where every major cloud player develops closed-source products separately.
I don't think it affects all open-source projects, particularly not small ones or ones where some is scratching their own it. But it's hard to build certain types of complex production-quality infrastructure without full-time employed developers working on it.
I agree, for many, though not all, developers and projects. Crucially, a lot of folks who can't currently afford to do free work for reputation or personal edification can't currently afford to release open source.
But I also think the money point emphasizes how unfortunate the term "sustainability" is. Typical software businesses don't seek sustainability. They seek profitability. Why should the developers they depend on settle for getting by?
"Profit" has a corporate, rent-seeking connotation to it. In my own side projects and writing, I've come to prefer "gainful", as in "gainful open software development".
Aurora is absolutely a fork of MySQL; they're careful never to explicitly admit this in most of their documentation and marketing but their CTO's blog links to a paper that mentions "obtaining significant throughput improvements over the base MySQL code base from which we started," and given how tightly they mirror MySQL with things like version numbers and goofy configuration flags that only exist for backwards-compatibility reasons, it would be hard to believe they built it from scratch.
GPLv2 and v3 both allow this because they only require source modifications to be made available when the resulting program is distributed outside one's organization. Since the public only ever talks to an interface and never obtains the binary, Amazon doesn't have to redistribute. This is not true of the AGPL, which has additional redistribution requirements meant to prevent (what copyleft activists perceive as) this kind of abuse.
There's an argument that since Amazon's changes are focused around integrating the storage layer with their particular infrastructure, the general public would find their changes useless even if they were to be distributed. Personally don't think this is terribly relevant to the larger discussion around licensing, even if it's true.
> This is not true of the AGPL, which has additional redistribution requirements meant to prevent (what copyleft activists perceive as) this kind of abuse.
It's important to note that the "kind of abuse" AGPL is fighting is denying the end user the four freedoms. Eg freedom zero: if Amazon shuts down aurora, you lose the right to run the program.
Upstreaming of modifications is kind of orthogonal to the GPL licenses - sure if A sells a program to B under the gpl, B modifies it and sells it to C, C will have the [ed: new and modified] source and may give it to anyone - including back to A.
But the main thing gpl tries to enforce is that C will be able to use and improve the program as needed.
The AGPL is a reaction to the rise of rent-a-program (SaaS etc) - where the user has very few of the four freedoms guaranteed - both if the provider goes bankrupt, and if the provider makes changes.
But which end user would that be? The end user of the licensed program is Amazon. They're the ones running the program and using it to provide database services to their customers. Those customers are end users of Amazon's database services, not a particular piece of software.
Correct. And well put.
Because we need money to live in our society right now.
I don't think GPLv3 will help, You need AGPL or even more aggressive licensing.
If you need a type of software system that requires 100k LoC of high-expertise code to get to a Version 1.0, you will need to spend millions of dollars. You can neither recruit non-experts to do a credible job, severely limiting the pool of people that could contribute in practice, and most people with a day job will be reluctant to spend the additional time required to write tens of kLoC of difficult, production-quality code -- man-years essentially.
And this ignores that most "high-expertise" software designers are prohibited from working on open source versions of what they do separate from their paying job. This is the reason, for example, that the myriad exotic high-performance database engines don't have open source equivalents -- only a handful of people know how to design those systems and their closed source work precludes participation in open source. But even if they could, the level of individual effort required will exceed what they are likely to want to do for free.
You don't have to be a founder, you just need to be an expert. In terms of career development, I think the ROI is better on joining an existing project. But "progress depends on the unreasonable" and some people become founders nevertheless.
That leads to a kind of cross-purpose incentives. It won't be in your interest to make the code easy to understand or adapt. It won't be in your interest to document how you go about fulfilling those needs. You may face conflict in promoting the availability of your own services through documentation or other materials about the open source project.
Puppet has an Apache licensed community edition, and they make money just fine. RedHat, Canonical, and so on.
Which I think is better. You might not enable FOSS devs to make much off their work, but you at least force companies to contribute.
Unfortunately, AGPL is full of loopholes, which are emerging now, because large enterprises with access to specialist legal talent are putting the microscope on licenses for projects like AGPL MongoDB.
MongoDB's counsel mentioned this directly in their statement submitting SSPL to OSI.
If small businesses can stay around while creating software that is open to use, and can be contributed to by the greater community, that will allow a lot more good stuff to be built and seems like a win for everyone.
Rubs me the wrong way when these same companies can just re implement the API and cause massive hurt to an open source competitor.
What do you propose in that scenario. Copyrighting api has never been a thing prior and likely wont be as soon as the whole affair is appealed yet again.
Why should you be able to control who makes a compatible part? Do you want your car company maximizing revenue by not allowing you to buy anything but new parts of their manufacture installed by their techs? Lets do it one better fueled by gas bought at a station willing to give the manufacturer a kickback. Perhaps to license the design of the pump connection.
This future is so fundamentally broken and stupid we would do better to abolish all forms of intellectual property rather than fall into this moronic trap.
DRM for machinery is absolutely already a thing.
What about shifting open source licenses so that duplicating an open source API in a proprietary product, or using a product that does so, is a violation of the license agreement?
Correct. But Redis Labs very visibly and substantially funds development of the BSD-licensed Redis core database.
Some of "open source hosting" companies did the same. I always think of Heroku hiring Matz, as an example.
Customers are paying them to maintain and operate the hosted version of these projects. That’s valuable in itself and should not be seen as stealing money from the software’s authors.
The open source issue is fixed, it is called AGPL.
However, the issue that Redis along many other suffering from is called brutal competition, it is not even just tech or open source tech, Amazon is eating everyone's lunch. I don't have any idea how this problem can be solved.
But, I know that restricting building API compatible software is not a solution, not a good one at least.
Letting anyone build API compatible software is a natural order of things that enables innovation and helps consumers avoid lock-in, specially with stagnated software, this is a big deal and something that we shouldn't give up, so on that topic, fark Oracle.
All the other big players like Google/Facebook will open source those middle pieces to help people who will make apps that will most likely have to interact with their platforms. They'll never release the source to actual end products.
Are there any examples where the middle-tier stuff is successful on its own as a business model? I guess you could say Redhat or Canonical, but even then they're developing a lot of commercial stuff around the core open source operating systems/distros .. things like Landscape. Also they got in early, years ago, and might be able to build a better foundation than more recent companies.
RedHat makes, for example, patches for kernel vulnerabilities, but they actually give that away for free. What they sell is a promise that when there's a new vulnerability, you can get a patch from them quickly.
They also spread this service across MANY different open source packages. Like you said, a company that just offered services around a smaller package would have to run a lot more lean and would probably be a risky venture.
What's preventing someone from freeloading? It sounds like regardless of whether you're paying, you can still get the patches.
It's much harder for freeloaders to accept feature requests from customers, for example, because that would result in a fork.
What's the joke where someone fixes some machine and charges $1000? Their cost breakdown was:
turning a knob: $1
knowing which knob to turn: $999
If you catch any bugs specific to your systems or need special feature Red Hat is always there to help because a lot of open source software developers are as well Red Hat employees.
If you use CentOS or whatever other RHEL-based distribution there is no support at all other the one community might provide.
That may be the case, but WorkMail is definitely not eating MSFT's lunch. Microsoft continues to be incredibly successful in enterprise
AGPL is also busted. It has its own loopholes, some self-imposed for nebulous reasons attributed to software freedom, some self-imposed due to FSF's peculiar stances on copyright law more generally.
Those limitations are starting to become practical, as big companies with legal talent actually start reading and analyzing the terms, as applied to important projects like MongoDB. Mongo alluded to those weaknesses in its submission of SSPL to OSI. I've written about them in slightly more detail:
It's certainly a solution. It's just a really really bad one that makes lock in obscene and would probably strengthen amazon.
AGPL has one major drawback though, it prevents free non-commercial use.
If I use ghostscript for a research data collection system, I have to open source the whole thing?
I wish there was a version of AGPL which exempted non-commercial use, as I doubt anybody means to force charities to pay up...
No, it doesn’t. It just requires that you release the source code of the modifications.
An open source licence can’t prevent any use, otherwise it would no longer be an open source licence.
AGPL is GPL + over the internet, not LGPL + over the internet.
If you do not like the obligation it places on you in exchange for using the work of other people then don't use it.
A library adopting the AGPL license has the effect of making it impossible for closed-source non-commercial projects to use it, even without modification.
> If you do not like the obligation it places on you in exchange for using the work of other people then don't use it.
Commercial projects can afford to pay, open source projects don't need to.
Charities, research institutions, etc can't afford to pay, and usually can't open source their projects.
If we move to an industry where AGPL is standard without any exemption for closed-source non-commercial use, we prevent the usage that nobody would object to.
That's what this entire thread is...
GPL says no usage without sharing.
LGPL says no modification without sharing.
AGPL says no usage without sharing.
We're seeing people move from LGPL to AGPL, which has generally unintended consequences.
It's not modifications, it's your entire application. AGPL doesn't have the linking exception.
Using an APGL library means I have to open source my account management code, or my data anonymisation system, etc.
Of course I'm perfectly happy to open source modifications, but that's not AGPL, that's LGPL (or ALGPL I guess?)
Assuming "community" means general open source devs/users, this doesn't speak for everyone. The (admittedly small) stuff I make open source is given to rich and poor, startup and big cloud company alike. I don't feel "taken advantage of" when my code is taken, used in secret, and nothing is given back. I'm glad I could help. Lots of the best open source software are just byproducts of the primary method of making money instead of its sole driver. All approaches/opinions are ok, but not everyone has this vindictive attitude towards how what you give away is used.
I have so much to say on this topic I could write a novel, e.g about commercial artists versus those who just want their art to be seen versus art commissioned with money obtained elsewhere. But in the most simple terms, at least with me, is I prefer to write and to use software with as few restrictions on/from others as possible. Can't feed my family on that of course and wouldn't try. If public domain were more accepted than MIT, I'd do it, but for now I just slap MIT on it and move on. If you make a million dollars on it, keeping changes hidden or not, good for you. I'm trying to do the same in my day job, the primary code of which is of course closed.
As for the prevalence of restrictionless licenses on non-hobbyist software, you can attribute that to their stewards simply recognizing the value of hobbyists working with it (the company reputation gained, the influence, bug finding, etc). People want fewer restrictions, companies want people.
The gpl was always about end user freedom. The bsd/mit is more about developer freedom. Neither guarantees upstreaming of changes - but many see the gpl as effectively requiring publication of changes. And it does prevent restricting such publication.
But if you develop a point-of-sale system (say) and sell it to a store chain - they might not have any motivation to publish the source - even if it includes a patched mysql, or some gpl code etc (maybe a patched Linux kernel?).
Now, the client has the source, and hire someone else to adapt the system as needed, or publish the source if they want. But the gpl doesn't demand giving anything back to the original authors.
How is bsd different? In that case the pos could be delivered without any source code. The client wouldn't be able to maintain it without help from the original vendor.
They also have no obligation to publish it. You are distributing the software to them, you have to give them the source code along with it. They are using the software, not distributing it further, therefore GPL does not require them to publish the source code.
(I'm not trying to argue with you here, as I think you know this - I just thing your comment does not make this detail clear enough. :) )
Commerce is a fundamental fact of life and for many projects an opensource approach just doesn't work, this a lot of people have to opt for closed source for business reason, but the very same people would like to leverage libraries and "open software". I do. And this is why everything I publish publicly is under a permissive license.
If you look at a company like Red Hat, they're focused on building things that will work reliably for the diverse needs of their thousands of paying customers. Whereas a lot of open-source contributions are really about solving the contributor's specific problem.
Sometimes if you get many people each making a contribution that scratches their specific itch you end up with something great. Other times it isn't cohesive.
If you make a new technology and an entity bigger than you comes along and makes profit, gives you no credit and contributes nothing in return, you are not going to be "glad to help", you're going to want something in return.
These companies do not contribute so they're required to adopt the new rules as a consequence. It's not fair Amazon profits off work others do entirely for free. They should be required by law to contribute a % of profits to the open source community, based on software they've used. Similar to artists being paid a % of streams of their music.
You use that NPM package? They have a donate button? You should be required to donate if you're a giant like Amazon/Microsoft/Google etc.
That's not true and the very point of my comment. To each his own, but no need to assume it of others.
a license with these terms wouldn't conform to any definition of open source or free software. if you want that, go for it, but if you've licensed something with any libre license you are already consenting to allow anyone use your software for profit as long as they meet the license terms. you may or may not agree with this state of affairs, but adding these types of restrictions/requirements also means that you aren't doing open source or free software anymore.
Commercial purposes requires compensation doesn't sound unreasonable.
My comment from another thread:
>As an outspoken critic of the original change, I applaud this move. I still wish it were open source, but this solves a lot of the confusing nomenclature I took offense with. Kudos.
That being said, this is some serious bullshit:
>But after the initial noise calmed down — and especially after some other companies came out with a similar concept — the community now understands that the original concept of open source has to be fixed
> By definition, an open-source license can’t have limitations. This new license does, so it’s technically not an open-source license.
So, is it true that HN now understands and is cool with Redis Labs "fixing" the concept of open source?
From reading previous threads on HN this seems like a mischaracterization, but it's quite possible I missed the relevant thread(s).
There's definitely not yet agreement on the solution, and Redis Labs alone is not going to solve it.
Roughly I think different people believe several things such as:
1.) The purity of open source (no restrictions on use) trump the needs of a company that does core development to profit, and so nothing should change.
2.) Its ok for companies doing core OSS development to "build a moat" that protects their revenue stream, but it shouldn't be done at the license level. Instead companies should look somewhere else like their expertise/reputation, building products on top of their open source code, etc
3.) Adjusting licenses is a reasonable way to allow interesting code to be available for use by anyone (under a not-quite pure open source license), and we are figuring out the best way to do that
That's been true since the MIT and Apache license came into existence.
Your third item just reeks of justification. "not-quite pure open source license" is nonsense. This is not an open source license, at its core. The goal here is to prevent use.
So I don't think the third is a valid option when we're discussing "fixing" open source. It's a valid option for protecting a companies revenue stream, but in doing so that company is no longer an "open source company" by definition.
Note that “source available” licenses aren’t new - they used to be the norm, even around the time the Free Software Foundation was started, and still are the norm in some industries. Even Microsoft will sell you a “shared source” license for some of its software. The defining feature of open source software is not that you can freely see the code, it’s that you can freely modify and use the code for any purpose.
The issue isn’t that these business models exist, it’s that there’s a new wave of companies that wish to take advantage of the vast amount of work that FLOSS advocates and activists have done over the decades in order to push proprietary software, and that’s not ok. This isn’t “fixing open source” - this is creating proprietary software using a proven business model and lying about what it is.
It’s not fixing anything, it’s just more arbitrary proprietary software.
Just don’t call it open source, and keep your hands away from the Apache brand.
Thanks! So it sounds like you're personally okay with this solution?
Let's just not confuse proprietary software with open source software.
I strongly disagree that this is a problem with the original concept of Open Source, and I strongly disagree that Redis's solution is applicable.
Redis is talking out of its butt with this claim. The solution it proposes is throwing the baby out with the bathwater -- saying, "we can't figure out how to fund Open Source, so let's just agree that it was a mistake and make something else that's vaguely adjacent to it."
I personally think it's massively egotistical for them to claim to speak for all developers, or even most developers. Redis hasn't proposed anything new or revolutionary. Source Available licenses have been around for ages. I don't see what's new here.
I personally feel like Redis is stepping into a general debate over Open vs proprietary software that is older than their company; and I don't feel like they're bringing anything new to the table. They've clearly decided that proprietary is the way to go. Now they're acting like this is some kind of significant decision, and that the entire Open Source ecosystem should change to accommodate and bless their specific business model.
It rubs me the wrong way. I often disagree with decisions that companies make, but this press release actually gets under my skin. I'm not dumb enough to try and speak for anyone else other than myself, but if their goal here was to spark dialog in the Open Source community, I am personally way less interested now in hearing what they have to say.
I applaud Redis Labs for not being one of the companies (such as MongoDB) that appears to be intentionally trying to muddy the waters by blurring the distinction between open source and proprietary software.
Consider this quote from RMS, in Copyleft: Pragmatic Idealism:
> I make my code available for use in free software, and not for use in proprietary software, in order to encourage other people who write software to make it free as well. I figure that since proprietary software developers use copyright to stop us from sharing, we cooperators can use copyright to give other cooperators an advantage of their own: they can use our code.
Changing the enterprise/closed license won't stop the cloud providers. Changing the open source license will: imagine a 4-part BSD that adds a license fee for organizations with over a billion in revenue. That goes to the heart of the problem and still lets everyone else use the software like it's a 3-part BSD.
If it is core tech to a business then why bother? Lots of cool projects don’t really get that many contributors. No point getting a community hooked on your software if you have to give it away and hope they’ll one day buy some services so you get paid.
All in all I foresee it becoming easier that source is kept closed for all things non-core to a business.
To prevent AWS and its ilk duplicating features of other's products but not really run (or pretending to not...) their software underneath.
I also hoped Morsi's tweaks to AGPL, the Lesser Affero GPLv3, would have become more popular.
It's written in everyday English. We've already had some great feedback from interested hackers.
I may be using this license for some projects going forward. :)
I'd also appreciate a note on GitHub about any projects using the license. Eventually, I'd like to add a list to the repo.
Seeing people move from LGPL to AGPL is very concerning as someone who is working for a charity.
What Redis Labs owns (and is distributing under this new proprietary license) is a set of modules that they developed for use with Redis. They aren't officially part of Redis.
"Redis Labs Changes Its Non-Open-Source License Again"
I don't see how these measures are practical either. Redis is much easier to do a cleanroom implementation of than MongoDB, so I doubt this kind of thing will produce any other kind of response from Amazon.
I don’t see how to make the first impossible without effectively using a proprietary license, and banning the second would hurt open source much more than it would help it