And, if those projects had been licensed using AGPL, then Hashicorp would not be able to relicense this without negotiating a non-GPL license for themselves, first.
I don't understand why GPL gets so much hate on HN.
I don't understand why GPL gets so much hate on HN.
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).
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.
Why would you want to open a bunch of loopholes for very specific and complex cases?
Can you link to that requirement?
> prominently offer all users interacting with it remotely through a computer network [...] an opportunity to receive the Corresponding Source
Reminds me of the picture of the smug cat surrounded by knives. GPL is that cat.
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...
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.
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.
If they refuse to remove it, it’s because they want to retain the right to enforce it.
The legal system isn't a computer that has deterministic outputs.
And when going up against an adversary with hordes of lawyers on salary, you don't want to end up in court.
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.
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. For one, it changes the business model. Moreover, they don't want something that restrictive for most parties. It's just that "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 don't go through that exercise. What they want is something they don't have to pay for that they can easily modify; 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, the companies using the license may find it's not any 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 in a satisfactory way for many of us.
https://drewdevault.com/2021/01/20/FOSS-is-to-surrender-your...
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
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.
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".
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
https://wiki.debian.org/CopyrightReviewTools https://scancode-licensedb.aboutcode.org/
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...).
* 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.
Here's google's policy on it. https://opensource.google/documentation/reference/using/agpl...
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.
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.
And I don't think the MPL would even prevent them from selling their commercial products.
[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...
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.
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.
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.
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.
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.
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.
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.
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 could just whine at the developer, of course, for not making his day at a well paid job slightly easier.
But the only reason for such anti-GPL policies is so that the corporations can ensure their software remains proprietary, which is inherently wrong.
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?
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.