Hacker News Reader

Comment by asim | Hacker News Reader

All of the most important software of our lifetime is going through this relicensing effort as the creators attempt to capture the value of what it enables. This is not some nefarious plan to screw over the community. It's a very measured and thoughtful way to ensure the long term progress and continuity of these projects. If the core companies maintaining them did not do this they would eventually die and these projects would slowly rot. Hopefully over time rather than having everyone choose their own licenses we end up with some form of standardisation.

View on HN

> Hopefully over time rather than having everyone choose their own licenses we end up with some form of standardisation.

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

Your choice of counterexamples highlights an important aspect. Three of the four are in fact outliers: Kubernetes and Android are both financially backed by Google. Android as a strategic advantage across a global market, Kubernetes as a plumbing layer enabling more businesses operate logically like Google. Sure, it's a CNCF product since 2016 or so, but it still enjoys Google's backing.

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.

Three of the four are in fact outliers: Kubernetes and Android are both financially backed by Google.

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.

A few monopolistic corporations having dictatorial power over key technologies is a dystopian nightmare.

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.

If we want to bark up this tree, a larger problem is FAANG inventing technologies that assume you have equivalent baseline competency and maturity.

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.

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

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.

Debugging Kubernetes does often feel like a dystopian nightmare, but you aren't forced to use it. I think it's a really good thing that this open software is available. As frustrating as Kubernetes is, for companies with medium-size or large-size deployments, it's really nice to have this level of orchestration software, and it's far better to have the option to use open source software than to be forced to roll your own because you have no alternative.

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.

> A few monopolistic corporations having dictatorial power over key technologies is a dystopian nightmare.

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.

> A few monopolistic corporations having dictatorial power over key technologies is a dystopian nightmare.

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

So TypeScript is Microsoft, and React is Facebook, but all the rest of those are Google. Shouldn't we be a bit concerned about that?

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.

I could add in Pytorch, VSCode, and Swift too. But yeah it's reasonable to worry a bit. It's great that competitors to Java and MySQL arose, and pretty much everything listed except Android (kind of a weird case) has a strong open source competitor.

You get it. Making lots of money cannot be a result of open source. But open source can be a result of making lots of money.

The ultimate fate of the wave of companies switching to AGPL and similar licenses now will be the proof (or disproof!) of this.

Sometimes open source helps. SQLite3 is a good example. Being open source (and very good) helped it become one of the -if not the- single most-used pieces of software in the world, but having a closed-source 100% branch coverage test suite helped establish a monopoly on development of SQLite3 and prevented hard forks. End result: big tech had to sign up for the SQLite Consortium. It's... not a unicorn, and I've not idea how much D. R. Hipp and friends get paid -- certainly they get paid enough to continue doing their awesome work, and maybe they get paid like the rock stars that they are, but probably nothing like what they'd be worth if they could really monetize SQLite3 and IPO. The SQLite devs are probably very happy, is my guess.

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.

Nitpick: SQLite is public domain[0], which is not open source[1].

[0] https://sqlite.org/purchase/license

[1] https://opensource.org/node/878

I don't care one bit about your nitpick.

While I want to disagree with you on the general principle (and gen220's sibling comment points out several really nice longer-term examples), I will certainly admit that you have a point. Cloud providers eating the margins, investing in streamlined operations and in general making the earlier on-prem consulting work less attractive has had an effect.

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.

> 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.[ß]

> ß: 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?

> but React is a language now?

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.

That's not what was asked. The query was, 'Is React a language now', i.e. specifically React, not just a general query like 'In general, is programming a process of designing little custom languages to solve problems'.

So to answer explicitly: in many ways, yes it is.

There is JS/TS in the codebase, but a surprisingly large fraction of the UI manipulation logic doesn't bear resemblance to either.

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.

Replace React with angular, replace Go with .NET which is a platform, and it's not just the language entire stacks in .NET are available as OSS (fronted, backend, distributed computing).

Governance won't help if you have no contributors at all because there's no revenue coming in.

Also, the CNCF is essentially Google by another name.

Far from it. looks what happen with istio.

that for sure is false... Google helped start CNCF but now plays a small part in its governance, they are just one board member like the 30+ others... they have no special voting rights...

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

What happens to CNCF if Google backs out of it tomorrow? Including all funding?

you can see our finances here in the annual report: https://www.cncf.io/cncf-annual-report-2020/

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/

That's good, but Google is still the single biggest Kubernetes contributor. If they decided to take their ball and go home, it would leave the project in the lurch. It's a risk factor. Is it likely? No. But it's not outlandish.

Postgres looks like the only interesting entry here.

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.

SQLite, Vim/Emacs, Linux, everything in GNU coreutils.

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.

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

Frankly I'd be surprised if Kubernetes wasn't dead in 20 years.

Imho, K8s eventually evolves into an OS for running K8s, then gets productized on {non-x86-64}

not looking forward to the k8s-arm-soc enabled bootloader (tightly integrated to systemd of course) to run k8s-os to run k8s-system to run docker.

It’s just my opinion and I’ll be happy to be wrong (because it means something better will have supplanted it).

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.

I did not mean to say that open-source software (broadly, MIT-licensed) and free software (broadly, GPL-licensed) don't do well! They do, and I'm happy about it. Some have commercial entities around them, but most don't.

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.

Ah yeah! We totally agree! I was finding it hard to respond to your comment initially because I didn’t know which point you were trying to make, mentioning Android and K8s.

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

Why the toxicity? AGPL was deemed by many to not be clear about what it was trying to accomplish. As I read in the various exchanges and articles around the time SSPL came out, I think they were just trying to clarify AGPL, not getting any more restrictive than AGPLs intent. And how would moving from a license that said you couldn't run a service bureau for free to something that says more clearly that you can't run a service bureau for free make MongoDB more money?

Sorry you’re right, I was being petty. I’ll explain my perspective in hope that we can learn something from this, but being flippant like that wasn’t justifiable. That’s a lesson in itself! :)

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.

I really appreciate the constructive response back.

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 appreciate yours as well!

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.

I get your point, and thanks for the discussion. My thought is that even software with an OSI approved license can be moved to a non-OSI license at any time. So you can't actually insure against the dystopian future you are concerned about. The only way to insure against that is if the software IP is not owned by a company. It will be interesting to see how this plays out with TimescaleDB, Confluent, Starburst, Grafana, and a host of others - none of their code is owned by a foundation (like PostgreSQL is) but is instead owned by a company. And those companies have ( and will continue to ) do thing that protect their customers, employees, and stakeholders. Thanks for the clarifications - I understand now better the concerns of the OSI-favorable community.

> I did not mean to say that open-source software (broadly, MIT-licensed) and free software (broadly, GPL-licensed)

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.

Agreed; one is a subset of the other. I tried to say something like "open-source in general, and its more strictly licensed copyleft subset,..".

Well, OpenSSH for example is an OpenBSD project, so it's not like nobody uses their stuff.

Everybody does! Some likely even publicly deploy modified versions without upstreaming them. But the authors don't mind, and don't ask for payment.

"What people want" is not what I want.

Market share/mindshare is almost an inverse measure of quality at this point!

This is what might be described as the 'hipster' sentiment distilled to its base axiom.

Not necessarily knocking it, though!

It's only hipster sentiment if it is on principle ("this is popular -> I don't want it"). It sounds to me like just an observation in this case ("it so happens that the most popular things are the ones I want least"). The "almost" clarifies this.

Market share/mindshare is almost an inverse measure of quality at this point!

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.

> using AGPL is so much better than flavor-of-the-week license

license noob here - can you elaborate on why exactly it is so much better?

AGPL is a license qualifying the criteria of OSI's OpenSource definition and FSF's Free Software definition.

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.

Another major issue is remixing and license compatibility. AGPL is part of an ecosystem. Anything MIT, BSD, current GPL, etc. will freely mix with AGPL.

Most of the other licenses, I can't use in any of my projects without running into license compatibility issues.

Notably AGPL is also DFSG free, meaning that AGPL licensed software can be included in Debian and its derivatives. I believe its also fine in other major distros (RHEL/SuSE etc).

I don't value OSI's stamp of approval since they were explicitly founded to coopt FSF's effort and make it more corporate friendly. Obviously corporate lawyers would disagree with me.

A license that allows all typical freedoms except "use the software to start a SaaS using proprietary infrastructure" is fine by me.

While there are significant ideological disagreements between the OSI and FSF, when it comes to FOSS licenses their definitions are mostly equivalent. There are very few licenses that are recognized by the OSI but not by the FSF, and vice-versa.

Proprietary infrastructure = All infrastructure essentially.

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.

That's pretty much the same as AGPL. A tell about OSI's biases is that AGPL and SSPL are basically the same but since Amazon's propaganda engine ramped up against SSPL it was labeled as somehow completely out of bounds.

How are they pretty much the same? AGPL only require the changes to the software itself to be shared under AGPL and it's apply the same requirement for everyone.

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.

> AGPL and SSPL are basically the same

Are you serious? Once you look past the most superficial level, they're not even close.

I don't care so much about the AGPL specifically, but it's a single known license, rather than every time I find a new project having to find out what "interesting" license they cooked up this time.

yes but afaict SSPL was kiiinda becoming a de facto "f off AWS" license that was generally becoming standard. thats all any of these vendors want, they're not coming up with new licenses just for shits and giggles.

standards evolve over time, it was entirely possible that Grafana could have thrown its weight behind SSPL and helped legitimize it more.

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

This would've been nice. I think we are not far from the OSI having to recognize that SSPL is the future whether they like it or not, and possibly moving from obstructionist to a more constructive point, where they help evolve the SSPL to address their concerns, while recognizing that it is a copyleft open source license.

A license doesn't get to be called open source just because it's popular. Look how popular Windows is. Is it open source too?

The only thing that differs between SSPL and the AGPL in terms of being open source or not is that one particular group of people has decided one is Open Source(TM) and one is not.

> one particular group of people

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.

But it is free. It solely conveys an expectation that you also release related tooling for free as well. If it's not a free license, the AGPL isn't either.

What's your definition of "free"? Because it's certainly not the same as the FSF's.

It closes the server loophole in which companies will use and modify Free software they're using just on their servers, but never make those changes available to clients, which is not restricted by just the regular GPL.

>Yes; if you're going to do this, then using AGPL is so much better than flavor-of-the-week license.

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.

The question is whether the alternatives are any better; IMO, this is unlikely (all the others I've seen make tradeoffs that I'd consider poor, personally).

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.

My personal opinion (and it is really just that - I cannot prove anything I say here) is that for a lot of those companies it is actually the risk of not being able to tell exactly what the AGPL would affect that is the main factor.

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.

If companies want to ban AGPL, well that's their perogative.

Alternatively, catering to those companies wouldn't bring relevant benefits to the project anyway

Arguably selling support/services to a company using that product would help pay for developers that work on the product, which to me sounds like a benefit.

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!

There are corps which have a (close to) blanket ban on AGPL, but still submit patches to open source projects. HP would be one of them.

I don't think it's a big loss though.

Open source is a business tool. There are many business models where open source can be useful. PG has such a vibrant user _and_ developer community that it pays to be a freelancer in that community and there's room for lots to play. SQLite3 is very much the opposite: it has _no_ developer community outside the core team, but the business model is the SQLite Consortium, which pays for the core team, and the closed-source test suite whose existence prevents hard forks.

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.

Anything not hard-copyleft (GPL, AGPL) or source-available (BSL etc.) is going to be embraced, extended, and SaaSified / paywalled. Eventually the open version might get abandoned since its authors will get tired of providing free labor to billion dollar cloud companies.

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.

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

> Anything not hard-copyleft (GPL, AGPL) or source-available (BSL etc.) is going to be embraced, extended, and SaaSified / paywalled. Eventually the open version might get abandoned since its authors will get tired of providing free labor to billion dollar cloud companies.

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.

I think that OSX co-opting BSD is a perfect example here, honestly.

If you use a GPL library then your main work becomes GPL.

If you use a GPL library and don't make the main work GPL you're committing copyright infingement. Your work will never magically become GPL.

That's true -- well, you're obligated to release the work under GPL -- but quite a lot of libraries are LGPL licensed which allows a proprietary application to link to it.

We are talking about products here.

Problem: the letters "G, P, L" are toxic to a huge number of companies. This has nothing to do with the controversy around Stallman. It's because Microsoft spent over a billion dollars in the 1990s mis-educating the market that GPL software is "viral" and if present can "infect" non-GPL software with the GPL license.

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.

The GPL is neither long nor complex. If a company won’t use GPL software because of Microsoft’s efforts, but would use that software under an identical license called something else, I think that company will experience many other difficulties on their journey as well.

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

> Problem: the letters "G, P, L" are toxic to a huge number of companies.

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.

GPL is "toxic" to the companies I work at because using GPL-licensed code would force them to disclose the source of their proprietary software.

There's not much else to it.

> Problem: the letters "G, P, L" are toxic to a huge number of companies.

Even if true, why it is problem? Company so misinformed is not going to be helpful anyway.

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

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.

It doesn't adequately handle the SaaSification case, which is when someone hosts the software behind a paywall. It only handles the "Tivoization" case when someone ships the software inside a closed source box.

Are you sure? AGPL was written expressly to deal with SaaSification. Wikipedia seems to agree with me, at least[0]:

"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

GPLv3 also added patent grant which is super important if you deal with software built by corporations.

Isn't the purpose of GPLv3 to handle Tivoization and AGPL was made to handle server-side sort of use-cases?

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?

Correct.

It does not stop all those companies using linux. The Jeff Bezos days are over.

Curious about how the GPL is not viral... Unless you go through the hoops of making sure GPL code is sectioned (through a shared library or whatever) in your codebase, then your software becomes GPL, no? I mean sometimes you can avoid it so that the GPL project stands at an arms length to your own code but it is not always trivial. You just don't get to include the code in your project and not get "infected". The fact that you can sometimes circumvent the infection does not mean it is not viral because I believe it violates the "spirit" of the license anyways.

Your software never "becomes" GPL, no matter what. That's the problem with the "viral" label, it's somewhat of a misnomer that implies that anything that comes into contact with it gets infected and suddenly all your private IP _has_ to be released and anyone can just take it an fork it.

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.

Sorry I still don't get it. Please tell me which step I am getting wrong:

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

> Now I have to make the source available, correct?

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.

Eh, that is a bit dishonest argument. "I want to keep distributing, and I want to keep using this code" are the immutable assumptions of my argument. My point is, with those assumptions in place, there is no way to NOT propagate GPL in the entirety of the work - was my point. That is OK since GPL is intentionally made that way. Take it or leave it deal. No one is entitled to anything, if people want to distribute their work as GPL, that is up to them to decide after all. I am only discussing the virality aspect of it here as a separate fact.

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?

I think you are wrong here, if I have 2 files, first is GPL and the second is proprietary and you steal them from me and use them then what license is your code now ?

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.

> All of the most important software of our lifetime is going through this relicensing effort as the creators attempt to capture the value of what it enables. […] It's a very measured and thoughtful way to ensure the long term progress and continuity of these projects.

Ahem: Grafana Labs Brings In $50M Series B For Open-Source Developer Platform: https://news.crunchbase.com/news/grafana-labs-brings-in-50m-...

I completely support the right to chose your own license and how you want to sell and use your own code, but let's be honest here. This is done because investors have discovered that it's possible to earn money on services around Open Source products, and Grafana Labs has gone all-in on this approach. Now they need the relicensing in order for the business model to remain viable. We're lucky that the code remains AGPL, but notice that they are still not committed to ensuring that all the code will remain AGPL (i.e. they still want CLA so they can relicense later).

I agree.

AGPL is nice and all but for contributors this does not really matter at all because of the CLAs.

I will never contribute to projects which reserve the right to relicense, e.g. take ownership over my contributions, however small or big they are. I think companies will do the same.

If they would remove the CLAs, they would signal to companies and contributors that they are serious in providing an open ecosystem, to which other people contribute willingly "for free". But currently they are not, likely because they fear competition.

thanks for saying the AGPL is nice; we think it strikes the right balance.

but, i'm curious to understand your perspective here.

do you mean to say that you'd never contribute to an apache licensed project?

anything that is apache licensed can be relicensed by the project, even if there isn't a CLA

[note: am co-founder/ceo at grafana labs]

The problem is CLAs.

They are a much higher barrier to entry for a lot of contributors. No, they're not all the same, but they make it harder. Each CLA needs to be reviewed and approved by company lawyers. It's kinda like creating a brand new OSS license that way.

To use a concrete example, the Google open source CLA is awful. At my previous job our lawyers refused to sign off the Google CLA. One of my engineers wrote a patch that we wanted to get upstream. Since, it would be generally useful.

Basically, the patch could never be merged, because we had a legal stalemate between us and Google.

I would highly recommend using https://developercertificate.org/ instead. This is what we use for Prometheus. It's also used for GPL projects like Linux. It's simple, standard, and used widely.

Does clause (d) allow the project to relicense its code? Because as far as I understand, that is the reason that GNU tends to have CLAs on their projects.

I'm no expert in these things, but here's my understanding.

AFAIK, it's up to copyright assignment for re-licensing.

For example, contributing to Prometheus assigns all copyright to "The Prometheus Authors". The DCO just attests that it's OK to do this.

So, I don't think there's anything for or against re-licensing in DCO, it's just out of scope.

I as an individual on my free time would never sign any CLAs, but would be happy to contribute to Apache Licensed Projects.

Why?

Because CLAs make the sharing agreement asymmetrical. I want to provide my changes under exactly the same terms as you are providing your code. Additionally to the fact that CLAs are typically layed out in favor of the corporation and not of the contributor, they cause me to read that CLA, interact with it and most likely misinterpret it, because I'm a dev, not a/my lawyer. With common licenses I know what I'm getting and independent lawyers have created them, weighing the benefits of both sides.

Of course, the last argument is not really applicable if you depend on widely-known CLAs like the Apache CLA (I use widely-known because I have heard of it, but I really have no clue what it entails and have never signed one).

The issue of apache projects vs grafana is easy. I have never contributed to Apache projects and would hesitate to do so if I have to sign a CLA, but the issue is not as big because the License (AL2) of most of these projects already somewhat permits relicensing and AL2 is already a pretty weak license, because it is not infectious like the GPL family.

But allowing relicensing on an AGPL project means that if I change anything on your code then I have to publish it. If you change anything you don't have to publish your changes (because you can relicense). This is not contributing on equal terms, so I'm out.

Of course, one can also argue that you're doing much more work so the asymmetry is justified, but my work has not less value than yours and your benefit in this relationship already is determining where to go with the project.

That said, I am not a lawyer and my understanding of licenses and CLAs is very limited and could also be wrong. I'm not even accounting for different legal environments/jurisdictions here.

I think they are saying that they don't want to give the project owner permission to relicense their contributions to an incompatible license. Relicensing to a compatible license should be no problem.

do you think that earning money or having a viable business model is a bad thing?

look at our actions since the inception of the company, as well as our "big tent" philosophy; i think they speak for ourselves.

we built a sustainable business over the course of 4 years, prior to raising a dollar of VC money. we raised VC money to go even faster.

most of our VC money goes to paying our employees.

most of our employees are engineers.

most of what our engineers do is open source.

if we don't build a sustainable business, who will develop the software?

the overwhelming majority of development on things like grafana, loki, tempo are done by grafana labs employees. plus, we are the main contributors behind other OSS projects that we didn't create and don't own (like prometheus and cortex).

[note: am co-founder/ceo at grafana labs]

> do you think that earning money or having a viable business model is a bad thing?

Nope, but I kinda thought the whole idea behind open source is that no one company or group of companies/licensees gets privileged access to or control over the software, including any company that happens to have the same name as the piece of software.

I realize that “open source” and “free software” and other related labels mean many things to many people, and some people have very strong opinions about what does and doesn’t qualify, so I’m not trying to be prescriptive about what these terms “really” mean, but to me this is a pretty important almost self-evident part of it. If you want to sell proprietary software just do that!

> I kinda thought the whole idea behind open source is that no one company or group of companies/licensees gets privileged access to or control over the software, including any company that happens to have the same name as the piece of software.

That is not, at all, the idea behind open source. The idea behind open source is, basically, 'you are free to do whatever you like with the source code, as long as you credit us for our work and don't hold us responsible for any effects of using the work'. That's it. There is nothing about companies, corporations, licensees, who has control, who has what name, etc. All of that is irrelevant to open source at its core.

It's true that many people add on an open governance model (e.g. Rust) and mistakenly think that that is part of open source. It's not though.

> There is nothing about companies, corporations, licensees, who has control, who has what name, etc.

That’s exactly what I said.

It's quite different from what you said ;-)

I don't believe this is a realistic take on open-source. There's not a single successful modern OSS project that's not basically controlled by a single organization (or was not at some point in its conception). Control can take multiple forms: most of the time, it's directional to the project, since the roadmap of the company managing the project dictates what gets done. Sometimes, it's in the form of how you can use the project. The great thing is that you can always fork the project and create a version for which the new rules/direction does not apply. The challenging part is making that a project where active development is actually happening.

Certainly, there's things like the Linux Foundation that serve as places where projects can live without formal control by a single organization, but in practice, orgs that commit most of the code control things (for better or for worse - I'm not saying this is a good thing)

> I don't believe this is a realistic take on open-source. ... The challenging part is making that a project where active development is actually happening.

Well, yeah, that’s just the most obvious gut reaction everyone has when they first hear about open source software: Why in the world would anyone put work into software that’s free for everyone to use? My impression is that open source advocates have put tons of work into explaining why this can and does actually work and can result in software that’s better than proprietary alternatives.

I'm glad you were able to find a FOSS license that's able to support your business. I think grafana lab's use of AGPL will help encourage its adoption by other businesses wanting to make money in free software as well.

For other's who are interested, here's a faq from grafana including a discussion about "Why AGPL and not SSPL?": https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic...

Very much this.

As a commercial consumer of FOSS, AGPL has been troubling for me. As a non-commercial hacker, AGPL has been fine for me: GPL is fine here, and distribution as defined by SaaS or tarball is equivalent; I share back.

My opinions are that non-commercial FOSS projects probably shouldn't choose AGPL but that small-ish commercial FOSS projects (like Grafana, et al) probably should so that big commercial entities don't eat their lunch.

AGPL seemed like a tool that was mostly ahead of its time but is nice to have now.

Neither earning money nor having a viable business model are bad things, but that's about as straw as a strawman argument comes. A business model existed before these changes. As far as I can tell, though, it's not _captured_ the value that the founders and investors seem to think ought to be their wealth.

Grafana Labs and all these other companies have recieved both value add and goodwill free marketing from open source contributions and communities, and I don't see these companies being at all interested in figuring out who/what they've gained value from, beyond the currently existing company, in order to make a profit and benefit the founders and shareholders.

I'm not against AGPL. I'm against the relicensing of software made in good faith against one model of OSS being discontinued and basically forked by the most prominent for-profit company that have hitherto received the significant benefits of both contributions and goodwill that being more freely open source brings.

By relicensing you've probably significantly reduced the number of companies willing to run future versions of your software, and the number of companies willing to build businesses off of extending it and offering that value add, while still potentially contributing changes upstream. You're going to slowly eat away at that good will and the number of people asking for your product internally, since fewer and fewer people will remember the benefit from their last gig.

I could be wrong here, only time will tell, but I honestly don't think this is a move that increases the long term sustainability of your business model. If anything, I think it's going to be detrimental in the long term. Perhaps even in the short term.

Here is an analysis of the investment that grafana labs is putting into grafana:

https://public-001.gitsense.com/insights/github/repos?r=gith...

Switch to the impacts view and sort by "days active". I think it is safe to say, any developer with days active >= 25% is a grafana labs employee or somebody that really loves to contribute to grafana because they are being paid to.

> Now they need the relicensing in order for the business model to remain viable.

This is exactly what the parent is saying though. They're going through this process to ensure that their business remains viable and they can continue to build and support the project.

I still think this sentence here is not quite precise enough:

> All of the most important software of our lifetime is going through this relicensing effort as the creators attempt to capture the value of what it enables.

To me this sounds like the relicensing is done so that a few programmers finally can get paid for their hard labor while maintaining critical software we're all using. What's actually happening here is that some creators have convinced a few investors that they'll be able to give a huge return on invest by building up a sales department around the product. And now the realize that they're not able to accomplishing that with their original license.

It's a perfectly acceptable business strategy, but it's not necessarily the only way of running an open source project.

I'm still hoping that we (the open source community) can find even better ways of ensuring high-quality software remain open source without being so dependent on current mindset of investors.

Not remain viable. To maximize shareholder value. Nothing is arguing it wouldn’t be a tidy little business with the previous license.

This seems to lump relicensing to better FOSS licenses like AGPL in with relicensing to bad non-FOSS licenses like the Commons Clause, SSPL, BSL, Redis Source Available License, and Anti-996 License. You're right about the former, but the latter is screwing over the community.

Serious question: How is the community impacted by SSPl, BSL, etc? The average end-user who makes no modifications and is not reselling as-a-service is fine, there is no additional burden with either AGPL or the non-OSI-compliant licenses.

How does the AGPL screw over the community less than the other licenses? AGPL is problematic for a slew of reasons, lots of corporations (whether or not you agree that for-profit enterprises make up the bulk of the "community" is a separate discussion) disallow it entirely (mostly thanks to Google's precedent).

The community is impacted because there isn't an intellectual commons to build from.

The OSI or FSF-approved licenses form an ecosystem. I can have a project which mixes AGPL, GPL, and BSD code. I can make that part of the next version of Ubuntu. I can borrow bits of code. It all works together. If the goal is to have a computer running free software, AGPL builds towards that goal. If the goal is to use the code in new and unexpected ways, AGPL builds there.

The non-OSI licenses are walled gardens. Even the ones which nominally allow remixing require me to drop a few grand on a lawyer before remixing them (more grand if it's international).

AGPL is toxic to some corporations for mixing into their proprietary projects, but the commercial dual-license takes care of that. Most corporations don't mind spending money.

AGPL also gives a long-term sustainable pathway if the original vendor goes under or goes evil.

I don't see how AGPL is really problematic in any way for something like Grafana.

Most people, and companies, that use this will just run an unmodified Grafana container, maybe with some plugins (not of their own). AGPL doesn't come into play here (the software is not modified).

This change would really only impact a company that takes Grafana, puts a bunch of patches on top of it and wants to offer that as a SaaS. Those guys could still even do that, they'd just have to publish their patches. Or, quite possibly, just pay for a commercial license - a lot of GPL/AGPL software is actually dual-licensed, with more ore less "dowhateveryawant"-style, paid licenses.

All of this sounds fair to me.

Blocking competition among providers of your app as a service is a burden for users. Users would benefit from being allowed to use the provider which best meets their needs, rather than being forced to use the provider who happens to be allied with the copyright owner.

AGPL tries to ensure that third-party providers are at least sharing their development efforts to the same extent that those efforts were shared with them. AGPL doesn't try to give anyone an unfair advantage at providing the software as a service, not even the copyright owner.

And each one of them will be forked by the major companies that were supposed to pay.

> If the core companies maintaining them did not do this they would eventually die

Good riddance. Incumbents owned by corporations have too much control and prevent replacement projects from arising. When a community builds a solution, how it works is dictated by its users and developers, not profits.

If they don't, Amazon will gobble them up.

This is a good thing.

Linux being GPL 2 was great for computing when we had thick clients, but now everything is moving to the cloud. Companies can innovate on top of it and not really give back.

Reply on news.ycombinator.com