Postgres? They have a very specific governance model - a single company can not employ over 50% of the core contributors, to guarantee that the direction of the product is not taken over even by accident.
Is that really "outlier" behavior? More and more important open source projects are prominently backed by a single large tech company. React, TensorFlow, TypeScript, Go, etc.
If you just look at the last decade, there has been more important work done as "single-sponsor open source" than under the GPL.
Those projects have ultimately the interests of the corporations in mind not of the users.
Ever wonder why overcomplicated technical solutions are hyped so much? Why does everyone and their dog need to run Kubernetes? Why is it all Maschine Learning instead of good old fashioned methods that would do much better? Well those corporation have just the fitting cloud computing offering!
Sure many of them happen to be useful and are simply for increasing the prestige of the company but let's not act like it is a good thing.
Which leads to companies that do not (eg no CICD or data architecture standard) adopting tools that assume they do (k8s & tensorflow).
(And yes, I realize this is because most folks who work at the former aspire to jump ship to the latter)
Say what you want about Microsoft, but they do a much better job of meeting the customer where they are (dumpster fire) instead of where Microsoft is.
Simpler explanation than some nefarious plan. Software engineers love to play with the coolest new thing over working with some proven solution that might have worked well enough. I think these corporation just exploit that with cloud offering. They don't really get to pick what people like (they try but suck at it) but have the money and resources to exploit whatever ends up being the popular new thing anyway.
TensorFlow and Pytorch are similar. Yeah, people end up using machine learning a lot when they don't really have to. But researchers and developers can achieve a lot more when they don't have to reinvent the wheel, and machine learning has provided some really great things.
These corporations are eating the world. They need not keep their source code closed, we're all employees, generating revenue for them.
One of the only reasons to keep source code closed is to retain your competitive advantage. They need not that when there's no competition, or a very slim chance of some appearing one day.
I'm joking, but it sounds a bit more true than I expected. Also, mind you, I'd rather have them publish code than not.
I think "dystopian nightmare" overstates it. Monopoly control over particular technology is also a working definition of the the patent system. Hey, wait a minute ...
Like, it seems like it should be fine, given that TensorFlow is part of their core AI mission, and they're heavily invested in Go, and Android probably isn't going anywhere. But people once thought that Java and MySQL were safe in the hands of Sun, too.
The ultimate fate of the wave of companies switching to AGPL and similar licenses now will be the proof (or disproof!) of this.
But yes, on the whole it's true: most open source projects aren't SQLite, and most aren't going to many any money just because they are open source. Open source is a business tool.
But I do note that your examples are from quite a narrow sector. TypeScript, Go and React are all languages. TypeScript is a nice facade over JavaScript, and React is ... well, a very powerful DSL.[ß] Go is very much a Google project, developed perhaps more out in the open than in a traditional open-source sense.
As I understand, TensorFlow was originally an internal Google project, which they at some point decided to open up. It may have had something to do with their TPU cloud offering or not. If we wanted to compare low-level language or domain material, we should probably take a look at something like Boost. People who do C++ tell me that Boost is a pretty good approximation of C++ standards' evolutionary playground. And if we're going for new languages, shouldn't we also include Rust? It was backed and promoted by Mozilla, but how much of its development was driven solely by Mozilla, and how much was done by the interested community at large?
ß: Our frontend team will probably want to roast me for that one, but there isn't much visible JS left in modern React code. Not for my eyes, at least.
> ß: Our frontend team will probably want to roast me for that one, but there isn't much visible JS left in modern React code. Not for my eyes, at least.
Can you clarify what you're talking about here with regards to React? I can see calling JSX a DSL, but React is a language now? And there's no JS / TypeScript in your React code base?
In a way, it is. Whenever you write some module in your project, you're effectively designing a language. Every function you add is a new verb, every type you define is a new noun[0] - and the relationships between them form the grammar. It may sound trivial, but I think it's an important and underappreciated point. Modularizing and abstracting is done by building languages on top of other languages.
We usually make a distinction between what is a "library" or "module" and what is a "language", by... it's hard to capture the distinction exactly, but my guess is that we reserve the term "programming language" for languages that a) define a large, highly composable set of building blocks, and b) have complex translation into a lower-level language, ultimately yielding executable code. Whatever the distinction could be, in reality, it's a spectrum.
--
[0] - Well, a piece of a noun phrase. Maybe. I'm not a linguist.
I base my opinion on my own interpretation: for me modern React looks a lot like the offspring of QML and a flavour of Lisp.
https://www.cncf.io/people/governing-board/
they still do quite a lot of heavy lifting though in contributing to a variety of CNCF projects if you look at the numbers: https://all.devstats.cncf.io/d/5/companies-table?orgId=1
fiscally the impact would be a membership fee which is a small percentage of revenue
The organization is fairly well diversified in terms of members and revenue sources but we appreciate Google's continued support in helping the organization grow, we think it's benefited them in projects like Kubernetes where the work is done by a larger community all working together: https://www.cncf.io/cncf-kubernetes-project-journey/
K8s and Android have a major corporation backing them, which extracts value from them in its internal operation anyway. They are such products that using them by competition commoditizes said competition. Android on like 95% of phones outside China has very important proprietary parts, making it hardly compatible with a bunch of top-tier apps.
BSD OSes don't do excessively well, with regard to market share and mind share. They are reasonably healthy though.
All of the Apache projects (some to more/less an extant than others).
Most programming language implementations (e.g. CPython). Memcached. WireGuard. SQLAlchemy. Web Frameworks like Flask, Django, Rails, on and on.
There are many open source technologies that do not seek to capture the value they create with licensing hijinks.
I don’t think it’s an accident, that the ones that persist across generations are generally not structured as VC-backed firms, who care a great deal more about “value capture” than the average programmer capable of building such foundational systems. Usually “value capture” is correlated with “consumer harm”, and so they’re replaced over time.
From your example, K8s will definitely outlive Google. Hard to say about Android.
What leads you to say that? I wouldn't be surprised if kubernetes is dead in 20 years. I would be very surprised if google is dead in 20 years.
But I don’t think there’s a significantly-simpler, mature abstraction for doing container orchestration, than K8s.
K8s’ main advantage/stickiness factor, is how abstract and modular it is. It’s an opinionated Kernel that gets most things right and has a huge ecosystem of tools built around this kernel.
It has a very similar set of stickiness factors to Linux, imo, although the origin story couldn’t be more different of course.
I think if anything replaces K8s, it’ll take a Linux-like shape. But K8s gets enough things correct (licensing, api, modularity) that it’ll be hard to replace it wholesale.
What I was trying to say is that FOSS was never about capturing commercial value, and always about capturing the value of the freedom to inspect, share, and tweak.
In this regard, going AGPL is preferable to what Mongo or Elastic did. They basically turned to commercial "source-available" offerings, much like mainframe software from 1970s.
I totally agree that the “we are now AGPL” route is preferable.
FWIW MongoDB was already AGPL, but that wasn’t enough for them I guess, they wanted more money. Old HN thread on the topic: https://news.ycombinator.com/item?id=18229452
From my perspective, MongoDB (the company) “wins” by getting more people to purchase their product, and making MongoDB (the software) better is only one of the many possible dimensions to optimize in pursuit of this goal. When I see a license change by such a company, my null hypothesis is that somebody realized the marginal cost of changing their license would capture enough value (even if a smaller pie) to offset any potential harm to the community, brand, etc. It’s perhaps too cynical a view, and I’m open to learning otherwise.
I do agree that the AGPL is a mess, and there seems to be a consensus around this fact. It isn’t the correct license for a VC-backed firm trying to SaaSify a FOSS project, which is what MongoDB learned. And since SaaS is ostensibly its target audience, AGPL doesn’t come away looking great.
More broadly, I’m concerned for the developer productivity that’s wasted (from a humanity/society POV) in the corporate-driven pursuit of defensible and sellable intellectual property. Nothing wrong with making money, but I think it’s a tragedy that capital assets aren’t broken down, recycled and repurposed in the software world like they were in the industrial world.
From this angle, I view the GPL as a positive influence towards making our work less repetitive and more reusable. It makes me sad to see MongoDB move away from any GPL-based license, even when it’s in their shareholders’ best interest, because it means all the dev hours invested into MongoDB post-2018 likely will have been invested in vain.
But maybe I’m wrong and their new license means their software is still salvageable for the future, when MongoDB (the company) no longer exists! I’d love for that to be the case.
From reading all the press, it feels like MongoDB did not do this to garner more revenue but to instead prevent open-source parasites from causing MongoDB to lose money or even go out of business. When I read Eliot's posts in 2018, it feels like he's trying to stay in business, not be greedy.
From a commercial point of view, databases have been shown to need management. Maybe someday somebody will write a database that has a magic simple-to-use endpoint, stays up 100% of the time, and doesn't require a cadre of people dancing around the database chanting spells to operate it. None to date... So the cloud providers capitalize on that need, and wrap control planes around databases - often hurting the people who are working hard to innovate on that software - and deserve to be paid for their work.
As to harm to the open source ecosystem, cloud providers wrapping managed services around databases has been shown to stifle innovation on those open source products. I.e. why would anybody want to improve PostgreSQL or MySQL when Amazon Aurora PostgreSQL and MySQL exist, CloudSQL and Azure SQL all exist - and may or may not take the changes - and even when they do, it takes many months or years.
Finally, I guess I'm puzzled by your last two paragraphs.
You mention that "all the dev hours invested into MongoDB post 2018 likely will have been invested in vain" - why? They go into the community edition, which anybody can use. They go into the EA and Atlas version, which customers who want enterprise-quality software with enterprise-quality support can use.
Your discussion implies MongoDB's license (and Elastic and now a host of others) prevents people from contributing to MongoDB. It doesn't. Or that it prevents them using MongoDB as much as they want. It doesn't, with one exception - and that exception probably affects <0.01% of the users of the software. The MongoDB license (and the Elastic and TimeScaleDB and many other licenses) don't even prevent anybody from wrapping up the software into a cloud service and offering it for money. In fact, many companies (SAP, IBM, Tencent, Alibaba, to name a few, apparently do). It just means you have to talk to the company before doing it.
I personally love MongoDB and I think the SSPL ended up preserving the company and preserving innovation, which is good for the open source community. At least it's not a complicated mess like MySQL and MariaDB.
That said, I'd love to hear more about how SSPL actually damages anybody in a meaningful way. I haven't yet seen anything except a philosophical argument. I'd love to hear it.
I agree that, from a commercial point of view, databases have been shown to need management.
> As to harm to the open source ecosystem, cloud providers wrapping managed services around databases has been shown to stifle innovation on those open source products
I don't think we agree on this. I think PostgreSQL has improved dramatically in the past 5 years, coinciding with (but perhaps not caused by) its increased adoption by AWS customers. The more customers/users FOSS projects have, the more information they have to work with, and the more interested developers they have to draw contributions from.
But it's OK, we don't need to agree on this point. We can adopt the axiom "MongoDB is more innovative because they have a non-OSI-compliant license". Again, I don't think this is necessarily true, but I can concede it so it doesn't distract us.
> You mention <quote> - why?
The reason requires stretching our imagination just a bit, but I hope you won't see it as philosophical, since real people plan against scenarios like this. Let's say that, today, MongoDB the company is benevolent, and happy to permit anybody who asks to operate their software. Everybody's happy.
At some point in the future, there's some management change, and the company that owns this IP has decided that the best thing they can do is box-in the customers they have, and make other service providers' lives as legally difficult as possible, thanks to the license they switched to in 2018.
Now, in the future, if you want this database management service that we agree is important and necessary, and you don't want to use MongoDB's platform, you're out of luck.
If you stick to databases with an OSI-certified license, you never have to make contingency plans for this future. There will always be a vendor for code with this license, as long as there's sufficient customer demand, until time immemorial.
Because you can not control the tail risk of MongoDB becoming an Orcale-like company (or, for that matter, being acquired by Oracle), you can not rule out the possibility that all vendors will be excluded from offering MongoDB as a service. You need to plan for the worst case, and treat it as a time-bomb.
You might consider this a philosophical argument, but, practically, this is why OSI has rule #6, and it's why the SSPL (and Elastic License) are not OSI-certified.
> Your discussion implies MongoDB's license (and Elastic and now a host of others) prevents people from contributing to MongoDB. It doesn't.
Correct, it doesn't. It prevents them from contributing to software with a license that does not "Discriminate Against Fields of Endeavor" and does not "Restrict Other Software". Which again, doesn't seem like a bad thing today but opens up paths that are otherwise avoidable.
Even if we buy the innovation argument, and even if this change was made with the purest of intentions, it's noncompliance with OSI standards makes it not worth the tail risk for people who want to pick software today that will be serviceable in 15 years.
Sorry, but free software IS open-source software. I take issue with how you're presenting these. Perhaps a better term would be liberally licensed software, as opposed to copyleft.
Market share/mindshare is almost an inverse measure of quality at this point!
Not necessarily knocking it, though!
If you only compare things above a certain quality threshold, That's true of any creative endeavor. Not too many people will say that Mcdonald's has the best burgers, or the pop singer of the week is their absolute favorite.
license noob here - can you elaborate on why exactly it is so much better?
A key point there is that a user can use the software quite freely without restrictions only with the caveat that modifications have to be made available to users. (AGPL is slighqtly more complex)
Many of the "modern" licenses allow to look at code, but prevent distribution and/or modification and/or usage. They typically aim for any "proper" usage requiring a commercial license and not giving the guarantee that code can be fixed in case the original vendor stops working on it.
Most of the other licenses, I can't use in any of my projects without running into license compatibility issues.
A license that allows all typical freedoms except "use the software to start a SaaS using proprietary infrastructure" is fine by me.
So you're fine with a license that can't be used for SaaS. So basically you're happy for the commercial internet to be powered by proprietary software - with all that would mean for free software.
SSPL require to release source code for every piece of your infrastructure if your business model seems like Amazon. This is descrimination which both FSF and OSI are not allow.
Are you serious? Once you look past the most superficial level, they're not even close.
standards evolve over time, it was entirely possible that Grafana could have thrown its weight behind SSPL and helped legitimize it more.
Which would not have been a good thing in any way, so I'm glad they didn't do that.
I assume you mean the OSI. But it's not just them with a problem with the SSPL. Debian and Fedora both reject it too, independently, for being non-free.
I'm not sure I agree. Yes, standardization is a good thing and AGPL is the "known evil", but having read it I do think that it is a very very complex piece of text - personally I'd go so far as to say that it is close to incomprehensible and would prefer pretty much anything else.
But even aside from that the sheer number of companies that point blank ban AGPL licensed software from being used in their stack could be used as an indicator as well. Though this may be due to the common misunderstanding that it is a viral license, which just goes back to my prior point on it not being clearly worded.
I won't even mention alternatives, I'm sure they all have issues, it is a complex topic, but if it were up to me the AGPL would not be my first license choice.
I think the virality and companies not liking it is the license working as intended, honestly; it's supposed to be viral, that's the point of copyleft, and obviously companies take issue with that (although I agree that some of this might be misunderstanding scope / what it infects), but that's not a bug, it's the license doing its job and companies making decisions based on that.
As I said, I'm explicitly not mentioning any alternative here because they all have issues, but the AGPL's wording is much more complicated than most and that (perceived) insecurity around it is my main criticism.
Alternatively, catering to those companies wouldn't bring relevant benefits to the project anyway
With the AGPL that would require dual licensing, and that draws flak as well.
I think the notion that OSS means there cannot be any money involved simply cannot hold true anymore these days. Software has become extremely complex and requires dedicated developers working on it - and they need to eat.
We are currently seeing a lot of companies changing their licensing model for a reason - because there is not currently a middle ground between OSS and a working business modell that the OSS crowd doesn't hate.
That being said, I'd love to be proven wrong here!
I don't think it's a big loss though.
It makes sense to use attractive-to-end-users licensing at first and later switch to a license that helps lock in support bucks. Call it bait-n-switch if you like, but even the SQLite folks did it, only they didn't do it with the _license_ but with the _test suite_ -- either way they made it really difficult to play in their space and/or fork.
I don't think you'll see a lot of major projects under super-liberal licenses in the future. You will see such licenses for libraries and other components.
And that seems fine, at least if you subscribe to the Unix philosophy of composability. Honestly, I love Django, but for some projects I'd love even more to use just Django's ORM without all the other stuff (which I also like, but is irrelevant for some projects).
FreeBSD is 27 years old. Postgres is 24 years old. SQLite, which is placed in the public domain, is 20 years old.
You will forgive me not holding my breath.
The problem would go away if you renamed the license to something else. It's that stupid.
A lot of the flavor of the week licenses exist for this reason, as well as to address some of the weak corner cases of the AGPL.
For shrink-wrap software, GPL can be an issue. For hosted software, it’s generally not (which is why all the desire to make other licenses, including AGPL).
Too. Effing. Bad. These companies can either figure out how to work with FSF-authored licenses or they can go make their own alternatives. I have no sympathy for them.
Or for devs that make excuses for this attitude. They deserve to be force-pushed onto software like when Apple decided to ship zsh instead of bash because they didn't want GPLv3 in their OS. Or that whole Rails brouhaha last month.
Companies should not be trusted with permissively licensed software. You don't get to play shell games with public access.
There's not much else to it.
Even if true, why it is problem? Company so misinformed is not going to be helpful anyway.
I'm interested in what the 'weak corner cases' of AGPL are considering it was pretty much made to correct some weaknesses in the GPL.
"Both versions of the Affero GPL were designed to close a perceived application service provider (ASP) loophole in the ordinary GPL, where, by using but not distributing the software, the copyleft provisions are not triggered. Each version differs from the version of the GNU GPL on which it is based in having an added provision addressing use of software over a computer network. This provision requires that the full source code be made available to any network user of the AGPL-licensed work, typically a web application."
The non-Affero GPLv3 handles Tivoization, FWIW.
[0]: https://en.wikipedia.org/wiki/Affero_General_Public_License
If I use AGPL-licensed software in a SaaS type of environment, I still need to release the source-code even if I'm not distributing the software directly, correct?
In reality, your proprietary code can only be GPLed if you explicitly release it under that license.
What people are confusing is that it is a violation of the GPL to release binary code that links (statically or dynamically[1]) with GPL-ed code without also releasing that code under a compatible license. This is where the "viral" label comes into play, since the easiest way to link against GPL code is to just make your code GPL as well. But it _does not_ mean that if you mess up and release a binary blob with GPL code in it that you've given up all rights to the non-GPL parts.
[1] LGPL allows dynamic linking, plain GPL doesn't distinguish.
I have my own proprietary code. I decide to make use of GPL code. Then I distribute the binaries. Now I have to make the source available, correct?
This source that was just made available (that includes my "proprietary code" and the GPL library I used) needs a license. At this step, I already lost my proprietary code and made it public - which might be unacceptable for some, but that in itself does not make GPL viral. Now that I need to license the released code, what options do I have? Can it be less permissive than GPL? My understanding has always been "no".
Nope! That's one way to fix the licensing issue—but you're not forced to do that.
Another option would be to immediately stop distributing your binary and not distribute it again until you can replace or otherwise excise the GPL code that caused the licensing issue.
And how does immediately stoping distribution help, legally? If I have already distributed the binary, the recipients are already entitled to the entire sources, no? Or does GPL have a "I have learned my lesson" clause?
The correct answer is that your code stealing is not transforming the product into GPL or into my proprietary license. If I catch and ask for money from you you have more options with the GPL code then with my proprietary code. With the GPL code you can just GPL your code changes, maybe the entire product but you are not forced to pay me anything. With the proprietary license though you don't have the option and I can make you pay.
So if you like that much the "infectious" word, you should add an "optional" modifier , you can always not GPL your changes, remove the "stolen" code , pay damages? (not sure if this ever happened).
What I observer the issues with GPL like software is lazy developers and companies that would like to "npm install" solutions and skip doing the work.
Yes; if you're going to do this, then using AGPL is so much better than flavor-of-the-week license.
> If the core companies maintaining them did not do this they would eventually die and these projects would slowly rot.
It sounds like you're suggesting that anything but hard-copyleft is doomed to die out, which is a somewhat hard argument to make in a world with lots of counterexamples (postgres, the assorted BSD OSs, kubernetes, Android).