I totally get this. I recently changed the license on my project from MIT to AGPL after getting a dm from someone interested in buying the project. I make absolutely no money at the moment, if anything I'm paying out of pocket for the domain, and don't think will any time soon. My only goal was to protect the project from getting commercialized by someone else. I've gotten questions about it and have been questioning whether I got too scared that someone might monetize what I worked so hard on.
Why we picked AGPL
171–180 of 312 posts
Re: Why we picked AGPL
#172Correction: they chose AGPL with a poison pill (CLA) so they can benefit from it and take it away whenever they want more.
And as a result free software was released to the world which everyone can freely use and modify under the AGPLv3 terms. And unlike permissive open source licenses, only the copyright owners have the right to sell proprietary versions. They maximized freedom and secured a business model in one fell swoop. People are only required to transfer copyright if they want to upstream their code, they can always keep their copyrights by maintaining a fork instead.
It's pretty much perfect. Stallman himself suggests selling exceptions to the GPL as a viable business model for companies, Qt being the number one example. I actually emailed Stallman and asked what he thought about this new AGPLv3 SaaS pattern, here's his reply:
> It is my understanding that as the copyright holders
> they have the right to do it without any problems.
> They leverage the AGPLv3 to make it harder for their
> competitors to use the code to compete against them.
I see what you mean. The original developer can engage
in a practice that blocks coopertation.
By contrast, using some other license, such as the ordinary GPL,
would permitt ANY user of the program to engage in that practice.
In a perverse sense that could seem more fair, but I think it is
also more harmful.
On balance, using the AGPL is better.Re: Why we picked AGPL
#173Earlier quoted context omitted.
I love single-license-per-project F/OSS companies like Red Hat, but they're rare. I'm attracted to companies who are so committed to F/OSS as a practice that their software is copyleft and they don't require a CLA. But dual-licensing is a tried-and-true strategy and the basic premise is very clear and very fair: share your downstream changes or pay a fee. And a CLA is required to make that work. Something commenters…
There are clear differences. [Let's say I am not a competitor and Amazonifying them] I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner. Even worse, let's say I am a paid customer for their support and run on their proprietary license…
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner.
You can fork it and use it in and as free software forever. This is only 'unreasonable' if you're a proprietary software vendor. The complaint of a proprietary software vendor strikes me as somewhat ironic here: what, the same deal that you give to your own customers for your own product is one you simply 'can't' take yourself because it's not 'reasonable'?
> If you are a sufficiently large commercial entity, you are probably wise to act as if it is proprietary.
But right about this. In the scenario you describe, you're a customer under the proprietary license— the kind of dependency your proprietary software product has on the software is the same kind it might have on any other proprietary software. The AGPLv3 version is not a backup option for you.
And it's true that the dual-licensing game the original vendor has set up is one that only they will ever be allowed to play.
If my company were considering purchased dual-licensed AGPLv3 software, I'd give advice like the following:
> It's great for the wider public that there is an open-source version of this exact same software our there. But what we're considering buying here is not that— what we're considering buying is proprietary software. For us, all that the availability of that open-source license means is that this is proprietary software whose source code would be easy for us to inspect, and that upstream might even accept our patches for issues that we encounter. I think both of those things are huge advantages! But if this vendor gets bought out or shuttered, we could potentially be left in the lurch much as we would if the software were exclusively proprietary. That's often an acceptable risk, in my opinion, and it's certainly one that our company has deemed acceptable with many past and present proprietary software purchases. But we should note that on the assessment: if we buy this, we're not buying or depending on open-source software; we're buying and depending on proprietary software.
All that assuming, of course, that the proposition is to use the AGPLv3 software in a user-facing, proprierary web service under the assumption that the copyleft component of the AGPL extends to that web service. If we were evaluating it for use in an internal service, where the end users are our own employees, or an external-facing service that we'd be comfortable releasing under the GPL, or we think that the way we want to use it would not require any license changes for us even if we take thw AGPLv3 version, I'd instead say something like
> Ask the lawyers as always, but I don't foresee any problems. I think this is great and I'd love to use it. If our legal people aren't used to considering copyleft licenses, can we have them consult with the FSF or the SFC or the EFF or something before they make a decision about this? Is that a thing?
Anyway, I agree with you about how being the customer (under the proprietary license) of a company like this is different from being the customer (for support services only) of a company who publishes permissively-licensed free software. I don't agree, though, that the dual-licensing thing is a trick! I think it's totally possible for everyone to go into that kind of arrangement eyes open and be happy with it. I hope and expect that's the goal for companies like that of TFA.
Re: Why we picked AGPL
#174Honest question: For the people not intending to "build a business on top of an open source library" but only intending to do something like "I just need this library to solve an issue in my work job" it's not simple to not touch it at all?
I had read a lot of conversations, and to be honest it's quite confusing for me the risk acceptance to have AGPL code in my codebase.
Re: Why we picked AGPL
#175Earlier quoted context omitted.
> The AGPL restricts use; it is an EULA It does not. You can absolutely host AGPL software as a service, you just have to share any modifications you made with those that use the service.
Sure, and you can absolutely use Photoshop, if you paid for it, and promise not to reverse engineer anything. Or, what do you think usage restrictions are or look like? If you don't share those modifications then you must not host that software such that it communicates with visitors; that's a restriction. The modifications that you are required to share cannot be any arbitrary modifications; anything you add has to…
Copyright covers four rights. The right to copy, the right to modify, the right to distribute, and the right to perform publicly.
The GPL places restrictions on a combination of the modification and distribution aspect, which says that if you modify the software and distribute it, then you must also include source code.
AGPL is more strict and says even if you just want to modify it and use it, you must supply the source code to the people who are using it. The important point here is that this is not triggering on use of the software (as EULA implies). It is only triggered after modification. And modification is something that is covered by copyright.
Re: Why we picked AGPL
#176It's a shitty license.
If you need to patch anything due to local requirements like the auth system you need to publish it which doesn't make sense at all.
Re: Why we picked AGPL
#177Earlier quoted context omitted.
https://www.gnu.org/licenses/gpl-faq.en.html "However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program." I think you can interact with GPL/AGPL and retain your code propietary by: - Don't…
You linked a more general FAQ for the GPL. Would you have a more specific quote or link for interactions with AGPL code?
AFAIK, the difference between AGPL is GPL is on what constitutes "distribution"; what constitutes a "derivative" is still the same.
https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
Re: Why we picked AGPL
#178Earlier quoted context omitted.
No, the whole idea of the AGPL is to make you release modifications even if you're not distributing (i.e. a web app). No modifications, no release.
The question isn't about modifications to the library/service itself, but whether with other code linking to it in any way is what you have considered a derivative work that should also be covered by the AGPL. For a library I'd say that was a definite yes. For a service it is someone's less clear, some provide connective tissue (language bindings or other access modules) under less strict licenses which creates an ob…
Well that's not Op's question. They're asking "if I use Minio in my stack without modifications (as a file server that my other services interact with via an API), do I have to AGPL all the stuff the touches Minio or not?" (Minio is basically a FOSS S3) [0]. You're asking about linking, which is covered in the FAQ [1]:
"You have a GPLed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program?"
"Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions."
[0]: https://min.io/
[1]: https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
Re: Why we picked AGPL
#179Earlier quoted context omitted.
> if I use Minio in my stack without modifications (as a file server that my other services interact with via an API), do I have to AGPL all the stuff the touches Minio or not No and it's spelled out very clearly in the license.
I think the length of this HN discussion is evidence enough that AGPL isn't clear. In my experience, organizations that use AGPL do so to 1) ward off an active non-paying community with its associated support cost, 2) claim open source to help convince you to buy their software/service, 3) hire skill-vetted programmers, 4) allow third-party security audits, and/or 5) avoid being jaded by someone that can market or ho…
It can also be evidence that HN posters have a poor understanding of GPL licenses. Pretty much all these questions are answered in the FAQ [0]. Your guess is as good as mine as to why people continually post random, uninformed, needlessly conservative takes on them instead of just doing a small amount of reading.
Re: Why we picked AGPL
#180Earlier quoted context omitted.
https://www.gnu.org/licenses/gpl-faq.en.html "However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program." I think you can interact with GPL/AGPL and retain your code propietary by: - Don't…
Github may have it wrong then? Their summary says: > Permissions of this strongest copyleft license are conditioned on making available complete source code of licensed works and modifications, which include larger works using a licensed work, under the same license. Note the last part: "which include licensed works using a licensed work"
Yeah I wouldn't rely on their editorializing. It's best to just refer to the FAQ [0], which covers these questions.