https://lwn.net/Articles/942346/
Notably, while AGPL is probably not the best license for unrelated reasons, most people do not have any conceptual qualms with the AGPL. I can not say the same for the pretend-open licenses that have been being pushed through with all of the usual excuses.
Also, robust open source projects have outside contributors. When you're contributing to an open source project under open license terms, it's mutually beneficial. But why would other companies willingly contribute to closed/shared source projects? What exactly is in it for them? Hence the resources that are being dedicated to OpenTF.
Some claim that if AGPL is very toxic, and that even viewing AGPL code might taint any project you work on later.
The reasoning goes that if you see something useful in an AGPL project and decide to use it (not copy and paste but actually recode it from scratch), the AGPL license follows that code in your head.
It's not dissimilar to a certain argument of patents. The more you read patents the more liability you potentially have in a lawsuit, so literally ignorance is bliss.
Google (and other large enterprises) definitely claims this, though honestly I think the main problem with the AGPL is the mechanism by which it works, not necessarily the idea behind it.
> and that even viewing AGPL code might taint any project you work on later.
Never heard this before. I also have no idea why this would be any different from other potentially-not open source software licenses.
> It's not dissimilar to a certain argument of patents. The more you read patents the more liability you potentially have in a lawsuit, so literally ignorance is bliss.
For patents I understand why this is the case even if it's not necessarily an ideal situation, but for AGPL it's still just copyright law at play, regardless of what the restrictions are. I don't understand how this differs from other licenses so strongly.
If code from agpl licensed product is found in a closed source SaaS offering, then the entire SaaS offering must be made open source.
Copying can be accomplished through either copy/paste or mental reading and retyping.
This is different from BSD where just the copyright notices need to follow the code.
You may be confusing the AGPL with SSPL. MongoDB switched to the SSPL from the AGPL, wherein terms were added that would imply that you essentially do have to open source the entire SaaS offering, not just the components that make up the program. Whether this is even enforceable or not is curious to me, because honestly, it seems dubious: how can a copyright license apply to other copyrighted works arbitrarily that are otherwise unrelated?
However, AGPL is even less stringent than it seems. Because it aims to be a copyright license rather than a contract, the AGPL is phrased in such a way that it is not "triggered" unless the code is actually modified[1]:
With the AGPL, there are two triggers that both have to occur for the source code sharing requirement to kick in:
1. You’ve modified the program.
2. You make the modified program available to people remotely through a computer network.
This is at least in part why the AGPL is arguably not that great, but it's a minor point in the grand scheme of things.[1]: https://fossa.com/blog/oss-license-compliance-expert-heather...
The usual somewhat pejorative figurative term used to describe the requirement for using the same license on derivative works is “virality”, in reference to being like a virus, not “virility”—“the quality of having strength, energy, and a strong sex drive; manliness”.
https://www.linkedin.com/in/vanlindberg/
Basically the license was read differently based upon the community -- particularly in subtle ways.
You can say, "Well... it's the GPL it means this and exactly this." But that presentation convinced me that different licenses can have different readings -- particularly depending upon the community.
It's worth noting this is google's take on it AGPL is here:
https://opensource.google/documentation/reference/using/agpl...
"...we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner."
For GPL, the main question is what constitutes linking. Let's read the text.
> The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
This does leave some room for interpretation, but the intent is pretty clear to laypeople: when you want to distribute a GPL-derived work, you have to distribute the source code in such a way that users are able to build install and run it, including any required subprograms. What this DOES NOT do is implicate other unrelated programs. A program that e.g. merely communicates with a database is not intended to be implicated here.
The thing about this that I think is important is that the GPL can only concern things that are plausibly possible to consider derivative works of the software, being a copyright license. Obviously, as a layperson, I do not know exactly what nuances and what range of opinions exist on what a "derivative work" actually entails. That said, it doesn't seem to be that controversial on it's face. I found this explanation from Adam Blaier of Brown and Blaier Attourneys and Councelers at Law[1]:
> Derivative works are new, original works based upon one or more existing works. In software and computer programs, this includes lines of code. Creating a software derivative work involves modifying the source code of an existing computer program either by revising it or translating it into another computer language. Simply linking to the existing original code in a library program without modifying it does not create a derivative work. Using a plug-in or a device driver also does not create a derivative work, even if you look at the program’s source code to determine how to use the plug-in or device driver.
Note that in this interpretation, merely linking to a program does not create a derivative work. In theory that would actually make a lot of GPL linking exceptions unnecessary, if I understand correctly. I presume that the FSF would disagree.
To me, that's the real gray area.
> It's worth noting this is google's take on it AGPL is here:
I worked at Google and went to their legal classes (the ones you have to take when you join.) It's FUD bullshit. Google's "legal stances" are motivated by their desires to uphold some kind of status quo. They leaned really hard on this when it came to their IARC and open source policies, and when I asked (multiple times) why they simply couldn't just be less strict than the law (since obviously, they do not have to choose to hoover up as much intellectual property from their employees as possible; they could always, y'know, decide a reasonable divide and put it into the contract) I never got a reasonable answer even one single time. I can't imagine, for the life of me, that this concept never occurred to anyone at Google. And you may think I'm being unreasonable, but every. single. time. this came up, there was a sob story about how they have to do it. They told people this, and most of them presumably just believed it without realizing it's totally within their power to just not handle copyright assignment that way if they don't want to.
So then why is Google so heavy on AGPL FUD? Simple. They don't want people to use AGPL. They want people to use Apache 2 because then they can do whatever they want with it. AGPL does technically pose some risks, but the risk is not that a judge is going to rule that the entirety of google3 has to be released under the AGPL license or something stupid like that. (Don't get me wrong, they can't use AGPL in their main monorepo, that'd be a terrible idea even with automation that ensures license compliance. But, the idea that they can never use AGPL ever at all is pure comedy. Sincerely.) Google's stance on AGPL is about as convincing to me as Nintendo's stance on the legality of emulators.
And don't think I'm some sort of stupid Stallman zealot, I use ISC license on nearly everything I release, because I simply don't give a shit. However, I find this degree of buying into FUD a little disgusting.
[1]: https://brownandblaier.com/blog/derivate-works-and-software/
> Simply linking to the existing original code in a library program without modifying it does not create a derivative work. Using a plug-in or a device driver also does not create a derivative work, even if you look at the program’s source code to determine how to use the plug-in or device driver.
This is clearly debatable. Tainted linux kernels are a thing. It's one thing if you distribute a kernel with a proprietary driver (nvidia comes to mind here). It's another thing if you ship a GPL kernel, and another if the user decided to taint their own kernel with a driver with a proprietary license.
The combined program here is the Kernel and the Nvidia drivers. You can't get around it even though the NVidia drivers are "weakly" linked into the kernel.
The question is at what point is "linking" established? During compilation? During dll loading? Or when you hit a rest endpoint?
Oh please, that's nothing but FUD. If this were true, then working on closed-source proprietary code for your employer would taint any project (open source or proprietary) that you work on later. Clearly that's not the case.
> It's not dissimilar to a certain argument of patents.
It's quite dissimilar. Patents and copyright are two very different legal regimes.
https://www.paulaoki.com/.admin/930108.oppose.html
So some of us thought this was a hilarious concept, and some joker printed up tons of mugs, tee shirts, and baseball caps which read MENTALLY CONTAMINATED, and they sold them at the Usenix conferences for a while. It was good for a laugh.
And that's why Linux won.
My friend at the time said Linux's codebase was terrible compared to netbsd....
I'd say it was a perfect storm in this regard. Sure, the lawsuit gave proprietary Unix a bad name. But that, in itself, wouldn't have been a death knell, if it weren't for these other practical factors.
How much did HC pay to use Go or Linux? Face it: we all free ride off others’ work, and in turn, they use ours. And look at how much amazing stuff we all have — for free! — because of it.
If Hashicorp wanted to stop “free riding” the solution was and is simple: don’t make Terraform open-source.
Open source works well without (much and often any) money involved. Businesses don’t. This is why open source is not an automatic business model.
Yours, someone who has spent the last 14 years maintaining a popular open source project mostly without any money and now with some donations.
In that regard our profession is a shame when comparing with other industries.
Everything we do is built on the shoulders of giants. If we’re very lucky, we’ll make something nice that others will want to build upon in turn.
As consumer from commercial software, and someone that has paid FOSS developers since the mid-90's, I am quite comfortable doing statements about people abusing other people's work.
I will give it 5 years time.
Yeah... that's not what you meant.
Virtually no one is actively disagreeing here with Hashicorp's right the charge money for the software they built. But it's just a different model, in which so many outside contributors would not have been... contributors.
So when yet another company finds out that when VC money runs out, someone has to actually pay for something, everyone gets the pitchforks.
Meanwhile in other professions, when someone does something for free, that is charity.
If you choose to license it under a permissive open source license, you go into that expecting you won't get paid.
For the record, I'm an open source developer myself, and do not expect to get paid for my work. That's fine, and I'm perfectly ok with that. What I won't do is wait for people to depend on my work and then suddenly change licensing in order to exploit them.
If HashiCorp didn't like that, they should have made TF proprietary in the first place. But of course they didn't do that: they knew that if they'd done so, they would have gotten very little traction. But now that many people and businesses depend on TF, they've decided to change the rules. Pretty scummy.
Now that they have gotten what they want (get big) they have decided to alter the deal. That upsets people.