I definitely feel GPL has its own merits. It's time people recognize that.

They do. The merits are what make FAANG angry. They want the right to profit from your work without any corresponding obligations and GPLv3, AGPL, SSPL, BPL, etc. all deny them that right.

It's not really about profit. The GPL doesn't restrict that. It's about wanting to leech off of the FOSS community by turning other people's FOSS code into proprietary products.

By the way, the SSPL isn't free or open source, so lumping it in with the GPL and AGPL like that could easily mislead people.

My personal open source contributions will only be GPL. Damn the torpedoes! I will only contribute to lesser licenses if I am getting paid by a corp, which I do, and of course that software cannot be GPL'd.

deploying AGPL software is complicated

Not really, just push the tarball with sources to nginx when you deploy a specific commit.

yea this is definitely user friendly and realistic

If you make modifications, and deploy them in a way accessible to a given user, the changes must be made available to that user.

I fail to see what is unrealistic about that, or indeed user-unfriendly, unless you consider the user to be the developer and not the person on the other end of the wire.

Glad you agree.

You don't even need to do that immediatly afaik.

You can wait for the first person to request the source and do it then manually (or link to the nginx github).

Most likely that will never happen for most people who deploy it.

After all it's a pretty good price for what you are getting in exchange.

There are AGPL software vendors who think making HTTP requests to their AGPL software forces you to license the client as AGPL too.

Why do you say that? (Or to anyone, why do people think this?) I don't know anything about AGPL.

It's not complicated, unless what you intend to do when deploying AGPL software is actually to try circumvent the license in some way; e.g., you would like some proprietary modifications to be added but still comply with the AGPL requirements.

We can do whatever we like. You shared the source code and secrets for free like a naïve noob

The AGPL's extra requirements only apply if you modify the program. If you don't, then deploying it is just as easy as deploying an MIT-licensed program.

I believe that the AGPL has the same boundaries as the GPL that is if you for example run a nodejs server using a single AGPL package in your node_modules then users should be able to download the source code of your entire node app.

But now you're talking about using an AGPL library in your own program, rather than deploying just an AGPL-licensed program.

libraries are software

Yes, but my point is there's a difference between "just deploy their software" and "combine their software with your software and deploy the result".

I agree, but for example it is not obvious whether you can deploy mixed licenses with docker-compose.

When you include an AGPL library your program becomes a derivative work, so the rest of your program becomes AGPL-licensed as well. The boundaries of what part of the system should or should not be included are vague, because *GPL licenses are written with C semantics in mind. So, while having a library directly in the same running process definitely makes you work a derivative, it's not clear if you the same is true if the library is a part of a different process and your program talks to it via an IPC, a filesystem, a database, an API, etc. Depending of the interpretation you may have toped-source just a tiny part of your program running on a server, or all server-side and client-side code and all supplemental scripts, tools, etc. needed for the system to run.

So, it's legally ambiguous, and since no-one has legally tested the waters the interpretation of the license can be very different, but most people prefer to stay away from AGPL code altogether.

The variously GPLs have always received hate of different kinds, and time and time again it's proven why they have the clauses they do.

Reminds me of the picture of the smug cat surrounded by knives. GPL is that cat.

People say lawyers are assholes, but they don't think about why lawyers are assholes.

It's a lawyer's job to imagine the worst future outcomes and guard against them in the present.

Everybody focuses on "It's crazy you put that clause in there that was never needed," but few folks appreciate "Thank god we included that clause just in case."

Which isn't to opine there's a right or wrong, only multiple parties each negotiating (skillfully or poorly) in their own interests.

If you're a developer and don't want your code to slide into corporate controlled ownership... well, there are licenses for that.

https://github.com/readme/guides/open-source-licensing

https://arstechnica.com/gadgets/2020/02/how-to-choose-an-ope...

Yes.

As a rough analogy that my lawyer told me early on, lawyers are like software engineers, and the law is like the operating system. A good lawyer writes robust "code" designed to deal with edge cases and unexpected conditions gracefully.

I think every single one of my attorneys over the years has made it clear that if something is in the contract/license/etc, you absolutely have to assume it will be enforced, to the letter. No matter how stupid, no matter how unlikely. If it's written down, it was written down for a reason.

One of the worst mistakes you can make in life is believing anyone who says things like "oh, that's just boilerplate...we'd never act on it" or "don't worry, we would never enforce that" or similar. That's someone who is deliberately setting you up to get screwed.

Indeed. My mental rule of thumb is to assume that if we're at the point of a legal argument then bridges have already been burned and neither party is inclined to do any favors to the other. Ergo, the legal language is the only language that one can depend on.

Another of my attorneys favorite saying was "contracts aren't for when everyone is happy with each other".

My favorite response to that kind of comment (“we would never enforce that”) is to say: “well, perfect, then it doesn’t need to be in the contract”.

If they refuse to remove it, it’s because they want to retain the right to enforce it.

This is exactly right.

The only reply to those comments is "then remove it". If they won't, it ain't "just boilerplate".

Not necessarily. I recently reviewed a french work contract that included weird clauses. But after looking at the case law, it turns out they are illegal and thus void anyway if taken to court. In that case, there is no need to spend energy trying to get them removed: this may backfire and push the other party to write a new legal version that actually screws you. Sometimes it's best to accept a weird clause that you know will not hold up in court.

Wrong. Putting you in the situation where you have to go to court to defend yourself from an illegal clause is screwing you. And the assumption that just because one court say "that's wrong" automatically means the one your litigating in will too is comically bad.

The legal system isn't a computer that has deterministic outputs.

And the costs when you win can be the tens of thousands of dollars, even if you get awarded fees (which isn't guaranteed).

And when going up against an adversary with hordes of lawyers on salary, you don't want to end up in court.

This is France, it's "loser pays" territory, so you don't have the perverse incentive to enforce illegal terms through the threat of litigation.

I don't know which country you're in, but in France we have quite strict rules as to how some clauses must be structured in a work contract to be valid.

For instance an non compete clause which is not limited to a certain geographic area is invalid, period. Yet some companies apparently don't know this. They copy paste boilerplate which doesn't hold up in court.

And no court can rule against this as the supreme court has already decided what makes a non compete clause valid and it is very precise in the requirements.

I think what we're seeing is people want something in between. It's hard to codify social norms. Many devs I know don't want to deal with the additional work that a partial GPL ecosystem involve. Most don't even care that changes to their code are published. On the whole, they want others to be able to do what they want with the source. What they don't want is the project to be co-opted or to be put out of business by a service provider that's leveraging their presence elsewhere (e.g., an entrenched cloud provider adding a competing SaaS option).

AGPL is possibly the only one that could guard against the latter, but it brings with it other limitations the author may not want. It almost certainly cuts down on the pool of contributors. While it fixes one problem, it creates others.

I think the fundamental problem is that open source licenses apply equally to everyone and really only govern what you can do with source modifications. The proposed solutions seem to be of the form "make it onerous to use and sell commercial licenses on the side." But, I don't think that's really what many people want. They don't want something that restrictive for most parties, but "don't bite the hand that feeds" is hard to codify.

At the core of it, these folks want something that functions like open source for the majority case but affords protection in the extreme. It has little to do with the ideals of software freedom. For better or worse, the BSL attempts to address that problem.

I think we largely overestimate how much the average person even cares about open source. I can only speak to my own experiences, but most devs I know haven't even read the major open source licenses. And that extends to how they consume source. Plenty of them take code from public repos without any declared license. They crib answers from Stack Overflow without attribution. They never check the licenses of their full dependency graph. Unless the legal team requires explicit approval of adoption of new open source projects, they just don't care. What they want is something they don't have to pay for that they can easily modify and open source happens to satisfy that problem.

It'll be interesting to see how this plays out. I'm not sure the BSL will clear legal approval at many companies. So, for the companies using it, the license may not be more advantageous than GPL. After all, if devs can't use your software, you haven't really gained anything. But, I'm curious to see how this all plays out. It's the first concerted attempt at solving a problem that open source licenses don't solve sufficiently for many.

The AGPL doesn't prevent Amazon from competing with you if they wanted to (although they don't yet). There was an AWS employee just the other day saying that the AGPL isn't very hard to comply with. I'm sure that they could do that if they wanted and probably will do at some point.

https://news.ycombinator.com/item?id=37085386

Fair enough. I'm sure Amazon has a legal team that's examined this far deeper than I have. If that's the case, it furthers my belief that GPL-like licenses aren't really providing what many are after.

Yeah, what many are after is proprietary licenses, not open source ones. Any license that prevents the competition Hashicorp and others don't like just isn't an open source (as originally defined) license. As Drew Devault wrote, open source means surrendering your monopoly over commercial exploitation.

https://drewdevault.com/2021/01/20/FOSS-is-to-surrender-your...

There is just one underfunded organisation doing GPL enforcement, so adjust that picture to a worried cat holding just one butter knife and it might be more accurate. Hopefully their lawsuit against Vizio will mean user of GPLed binaries can sue for source code. So adjust the picture to roaming herds of cats with butter knives perhaps.

https://sfconservancy.org/copyleft-compliance/vizio.html

because people prefer not to pay back, GPL and AGPL has a cost that many consider to be limiting their ability to earn money based on it, so it gets hate.

its really quite simple, you're no worse off than if there were no GPL/AGPL to begin with, so just dont use it if you dont agree.

I personally am very concerned with the newer trends of going away from GPL, I think its gonna turn out bad for everyone

Stallman's foresight has been eerily accurate - look at what google's web environment integrity proposal to say the least.

It's time the OSS community stop making free software with a loose license such that control and ownership is taken from them, and for profit to be made without any give backs.

You don't need to "pay back" for a gift.

The problem is entitlement and thinking that anyone owes you anything after you have given software away to the world. It's no longer yours, there is no "back".

but its not a gift when its GPL, its distribution under certain terms, and to complain someone chooses GPL rather than BSD is not legit

GPL gets hate because it’s a self-killing license. Sure, it’s great idealism, but it just creates an incentive for any corporate interests to create either a closed source offering or a better funded competing OSS offering that can be commercialized.

If some software provides value, it will eventually be monetized in some form. It makes no sense for a corporation, whose entire existence is predicated on monetization, to see GPL software and say “I guess I’ll just stop charging for our products!” Instead, the completely predictable response is “this is valuable, but I can’t use it, so I’m going to make something like it that I can actually use”.

Like it or not, you cannot “hide” value from capitalism. The machine will find and extract value wherever it can. GPL establishes unrealistic ideals for software that are inconsistent with the reality of how and where it is used.

> it just creates an incentive for any corporate interests to create either a closed source offering or a better funded competing OSS offering that can be commercialized.

what's wrong with that?

If they produce their own version, then the world now has another piece of software, and this competition is going to make the ecosystem better imho.

The only problem with lenient licenses is that they allow leeching. MIT, eclipse, and apache licenses, all are basically allow free commons which others leech off as much as possible. The corps may continue to contribute, but only because they see value they could extract more than what it costs them.

I would say AGPL should be the _only_ license anyone contributing to OSS should pick. And if you own the project, make it dual licensed - a commercial offering, and AGPL. If said software is good, a commercial offering can be profit generating enough fund further development.

There’s nothing wrong with that, and there’s nothing wrong with people who want to build GPL software - do what you like, consistent with your ideals. This is really only in response to the perennial “why don’t more people use GPL” questions that seem to always pop up any time software licensing is discussed. It’s fine for some people, but there’s a reason corps tend to avoid it or have internal policies against using GPL software.

>why don’t more people use GPL” questions that seem to always pop up any time software licensing is discussed

millions of people use it. the perennial question is why does the license make people so unreasonably angry?

>there’s a reason corps tend to avoid it

it's the same reason they try to assign IP you dreamt up in the shower to themselves in perpetuity with no exceptions - a combination of corporate greed, hubris and lawyerly risk aversion.

I don’t agree with the greed and runaway capitalism that drives it, I’m just observing it exists.

People tend not to like it because it’s restrictive to the point of being off limits in many real world use cases. Bob works on the platform team at at GigaCorp. He’s overworked, and found a great OSS product that does exactly what he needs and could save him weeks or months of effort. Except because it’s GPL, he can’t touch it.

> save him weeks or months of effort.

so it's worth the time, and thus money to pay. Therefore, if he's got a brain, he would ask for corporate money to buy a commercial license, and do away with the risks of GPL.

Except he doesn't, because the corp (or he himself) believes that it should be free somehow?

Bob has a wonderful opportunity to channel GigaCorp's deep pockets and penchant for extreme risk aversion towards supporting open source.

Bob could just whine at the developer, of course, for not making his day at a well paid job slightly easier.

> It’s fine for some people, but there’s a reason corps tend to avoid it or have internal policies against using GPL software.

But the only reason for such anti-GPL policies is so that the corporations can ensure their software remains proprietary, which is inherently wrong.

I always wondered: is there actual study about this?

There is people arguing both ways with relatively good arguments, but what about quantifiable realities? As the author of GPL-licensed softwares, I didn't have much reasons to go that way or another, apart from hunch. Can we quantify those effects, so that we can properly align our licenses with the effect we want?

I’m not sure if there are studies, though it is probably something you could do. Maybe look at GPL vs MIT licensed software and see how each grows over time in terms of commits, lines of code, number of committers, number of issues, average time to close issues, total monthly downloads, etc. Of course metrics like these are pretty general, but at a large enough sample size I imagine there could be some observable patterns.

Of course, not everything is an optimization problem. So even if the metrics are better for x or y in general, people have their own reasons and beliefs about the world that might make one or the other better. I have generally felt that unless restrictiveness is important to you, minimally restrictive licensing is a good default choice.

Hacker news is a mix of venture capital and technologists, the AGPL3 is a wedge between those two groups needs and objectives.

For agpl specifically I believe it’s due to muddy waters surrounding the “derivative work” clause. Some companies have traditionally bent the definition (eg insinuating that api calls result in larger application fall under combined work) and it’s never been tested in court so understandably the lawyers do the lawyer thing and tell you not to use it

Yeah, but even stepping back there, lawyers are paid to prevent companies from entering those muddy waters as a risk to their profits.

Profit isn't a concern to someone who wishes to publish open source software, in fact you could say Open Source is an inherently socialist venture (your socializing the tools/means to do something).

The AGPL3 makes it more difficult for others with probably more means to profit on that work, so it's a net benefit to the folks who actually write code (and a detriment to those who would wish to exploit it).

Right so as long as food and shelter is not a concern AGPL is v good license!

Yep! I'd say 95% of open source is subsidized by those thriving rather than surviving, having the education/equipment/access/free-time to deliver open source software is a product of privilege and abundance.

Not only some companies - API calls being linking also seems to be the opinion of the FSF.

I mean I always though of AGPL as network-aware GPL so that makes sense to me. IANAL

I recall someone pointing out, AGPL only affects offering the same core functionality over network. So you cant monetize exposing as is. But you can use as a backend component. Lot of people miss that. I did too. IANAL.

That's the ambiguity I mentioned. Nobody actually knows. MinIO for instance thinks you're wrong.

garage a competitor with a rust code based think thats legal.

The AGPL revels in legal uncertainty and UX destroying demands (see FSFs "an agpl reverse proxy must first serve a notice it's AGPL before proxying onward").

I find the EUPL is a much better replacement for what a lot of people expect the AGPL to be, with the added benefit of being compatible with a bunch of other licenses by yielding when specific clauses intersect.

While I agree that it's legally murky in some respects, that seems like an opportunity (and a benefit to the writer of the OSS code) for a dialog between the maintainer and the user of AGPL code to ensure compliance.

Why would you want to open a bunch of loopholes for very specific and complex cases?

EUPL compatibility is not exactly "opening a bunch of loopholes". It's yielding to a very specific list of licenses, to very specific conditions that exclusively make the resulting license more strict (e.g. combining with AGPL basically turns it into an AGPL licensed work)

Ah, I'll admit I know a lot less about the EUPL, I'll do some further reading on the subject.

> see FSFs "an agpl reverse proxy must first serve a notice it's AGPL before proxying onward"

Can you link to that requirement?

That says a proxy could use a landing page to do that, not that it has to do it that way.

The underlying requirement of providing source to users is firm, though. How else will a reverse proxy prominently make a statement to networked users?

> prominently offer all users interacting with it remotely through a computer network [...] an opportunity to receive the Corresponding Source

https://www.gnu.org/licenses/agpl-3.0.html

Yes, correct. If this is their best shot at a solution, it doesn't bode well for their interpretation of the AGPL allowing any UX-friendly version of this, let alone a normally functioning API Gateway.

Because most startups can’t use AGPL. I had to provide audits of our licenses of libraries we use in our code base to investors and attest we didn’t have AGPL code in our code/software in our stack. This was at an e-commerce company and not a company that directly monetized software. Companies are free to choose whatever license but it will limit who can use their software.

> I had to provide audits of our licenses of libraries we use in our code base to investors and attest we didn’t have AGPL code in our code/software in our stack.

A little off topic, but how are these audits usually done? I'd like to familiarize myself

Not necessarily your specific case, if there's a resource online that'd be fine

We run a script that scans our source code and generates a manifest of all included libraries including license/copyright. Here's one of them:

https://github.com/nexB/scancode-toolkit

There are others, but scancode is probably the best one, their license database is truly huge.

https://wiki.debian.org/CopyrightReviewTools https://scancode-licensedb.aboutcode.org/

Fossa built a business around this: https://fossa.com/

The less automated version is a list of requirements to the effect "list all the OSS libraries you use and their licenses" are pushed down to each team and someone spends a day or 2 going through their code base. Usually that amounts to looking at a lock/dependency file and finding the software's license online.

You can also run an audit against your artifact store/cache if you have one. JFrog Artifactory has built-in tools for auditing dependencies (and can act as a pull through cache) so you can run reports that way but it can be harder to tie dependencies to what's using them.

Back when I worked at Chase, it was against company policy so use 3rd party dependencies that weren't in their internal components database. Part of getting something in the components database was establishing an owner, the license, and the version (basically a paperwork/approval process). In addition, part of the deploy process was running a vulnerability check against your dependencies using some proprietary enterprise software that tracked CVEs and could (somewhat...) parse what dependencies an application was using (ideally, automatically...).

We had to do this at Raytheon, too, and when someone asks why government projects take so long and run over budget, this is at least one reason. We had a mandate from our government customer to reuse code originally written by Sandia national labs to avoid rewriting functionality that already existed, but because this was code created by researchers in a much lower security environment, it had hundreds of open source dependencies, and we needed to get approval for all of them, which consisted of exactly this process, except we had to submit one set of requests to Raytheon's corporate approval folks and one set to the customer's security team. The corporate approval is almost totally pointless, because if they deny something, but the customer says to use it anyway, the customer decision always overrides the corporate decision. The project doing this was an attempt to accomplish three things at the same time:

* Migrate a legacy GEOINT system from on-prem hardware to Amazon C2S (the CIA's private version of AWS)

* Migrate the distributed runtime from Apache Felix (a Java OSGI implementation) to Kubernetes

* Split the algorithmic part of the processing flow from the metadata retrieval and orchestration part and assign the algorithmic part to another contractor (which was even more pointless, because that contractor just sub-contracted the actual development work back to Raytheon because we were the only people on the planet with a realistic level of expertise to do it)

This went about as well as you might expect, with roughly zero people on the project knowing anything about how AWS worked, zero people knowing anything about how Kubernetes worked, C2S having a barren subset of AWS services, and the FOSS approvals taking nearly a year to work through the backlog before that part of the team could do anything except prototype shit in an isolated sandbox.

So yeah, I left years ago, but I think they finally ended up delivering a small subset of the originally intended functionality something like three years late.

The AGPL itself certainly has no rule against any startups using it. Where specifically does the prohibition you're talking about come from?

Because it infects code even if you don't modify it. You could just be using an API of an AGPL service, and it will hit your code. Its universally banned not just startups. I don't know of any organizations that allow it in their code base. If you want people to use your code, don't AGPL it.

Here's google's policy on it. https://opensource.google/documentation/reference/using/agpl...

> Because it infects code even if you don't modify it.

No it doesn't. The extra section of the AGPL that the GPL doesn't have explicitly says it only applies if you do modify it.

> Its universally banned not just startups.

You linked me to the rule that it's banned at Google, but still not to the source of any rule that it's banned at any startups.

How about this: There are AGPL software vendors who think making HTTP requests to their AGPL software forces you to license the client as AGPL too. To avoid their lawsuits, companies forbid internal use of AGPL software.

7-day-old comment, but the company I work for (not a startup) flat-out bans creating a dependency on AGPL code.

They were licensed under MPL, which would have also prevented a relicense like this without the CLA.

And I don't think the MPL would even prevent them from selling their commercial products.

With the CLA in place, it doesn't matter. All contributors already gave hashicorp a broad license for everything that they don't already own, so hashicorp has license to largely do whatever regardless of what license they use to offer it to others.

Only the code in HashiCorp's own code is covered by the CLAs, not the code in the third-party dependencies it has. If said dependencies used copyleft licenses like (A)GPL instead of pushover licenses like MIT, that would have prevented what HashiCorp did.

The CLA was put in place in December of 2018 [1]. Presumably contributions made before that were under inbound=outbound terms [2], meaning the contributing author licensed their exclusive rights under MPL 2.0, which is a file-based copyleft license. (see the chart at [3]).

[1] https://www.hashicorp.com/blog/introducing-a-cla

[2] https://docs.github.com/en/site-policy/github-terms/github-t...

[3] https://en.wikipedia.org/wiki/License_compatibility#Compatib...

The projects license is of no concern at all here. Licenses do not bind the owner of the code. Hashicorp required a CLA before contributing, so they own the copyright. They can change the license at any time as they see fit.