well the problem is that some companies who use the AGPL do actually write some fud about it.
i.e. if I use min.io agpl and the user never interacts with it, just my program, but I never even modified min.io and I just use the binary interface, I would never be subjected to the release my program's code, I would just need to give a link to the min.io source code that I used.
> You may not deploy it on a network without disclosing the full source code of your own applications under the AGPL license. You must distribute all source code, including your own product and web-based applications.
and they also kinda fork the license with this text:
> When using iText 7 Community under AGPL, you must prominently mention iText and include the iText copyright and AGPL license in output file metadata, and also retain the producer line in every PDF that is created or manipulated using iText.
I mean this makes it really hard to trust the license at all, what would happen if I build a sever that can modify/create/convert pdfs and release the source code and than I have another program that calls this server internally with a http client, is that still some kind of linking or is it more like mongodb?
I would happily build something with agpl when I could use itext/ghostscript and build something like minio which could than be used behind the scenes, but if that is not possible or if it is a grey zone than I'm not sure if agpl is a cool license at all. every company who uses the agpl writes something different about it, thats why an "official" clarification would be really really cool.
That’s one perspective and while I understand it it’s not one I’ve agreed with. An alternate view is that it forces all parts of your tech stack to be open sourced even things that have nothing to do with, or at most ancillary relation to the relevant service. OSS software is valuable but AGPL steps (in my view anyway) waaaay outside of what’s reasonable to try to prevent servicifying OSS. I think most companies would be fine with a GPL-like license that forced you to share the source for that code even if it’s behind a service. The viral nature of AGPL makes it toxic to almost everyone unless you’re willing to pay the copyright holders for special permission. That’s certainly fine but to me it’s less OSS and more like a viral source available license.
Not if you just deploy it as is, like a service. (which it's intended to) If you write an application which uses MinIO over HTTP, you have no obligation to release your application code.
AGPL is purposefully designed to eliminate the Embrace, Extend, Extinguish model of Cloud providers, where the provider embraces a popular open source projects, creates a "service" from it, extends that service in order to make their flavor non-compatible with out contributing upstream in an effort to extinguish the original project.
well the problem is that some companies who use the AGPL do actually write some fud about it. i.e. if I use min.io agpl and the user never interacts with it, just my program, but I never even modified min.io and I just use the binary interface, I would never be subjected to the release my program's code, I would just need to give a link to the min.io source code that I used.
however every company thinks in its own way:
https://itextpdf.com/how-buy/agpl-license
> You may not deploy it on a network without disclosing the full source code of your own applications under the AGPL license. You must distribute all source code, including your own product and web-based applications.
and they also kinda fork the license with this text:
> When using iText 7 Community under AGPL, you must prominently mention iText and include the iText copyright and AGPL license in output file metadata, and also retain the producer line in every PDF that is created or manipulated using iText.
I mean this makes it really hard to trust the license at all, what would happen if I build a sever that can modify/create/convert pdfs and release the source code and than I have another program that calls this server internally with a http client, is that still some kind of linking or is it more like mongodb?
I would happily build something with agpl when I could use itext/ghostscript and build something like minio which could than be used behind the scenes, but if that is not possible or if it is a grey zone than I'm not sure if agpl is a cool license at all. every company who uses the agpl writes something different about it, thats why an "official" clarification would be really really cool.
It's only not welcoming to those who wish to close the source.
It's the paradox of tolerance: you must not tolerate those who find others intolerable.
That’s one perspective and while I understand it it’s not one I’ve agreed with. An alternate view is that it forces all parts of your tech stack to be open sourced even things that have nothing to do with, or at most ancillary relation to the relevant service. OSS software is valuable but AGPL steps (in my view anyway) waaaay outside of what’s reasonable to try to prevent servicifying OSS. I think most companies would be fine with a GPL-like license that forced you to share the source for that code even if it’s behind a service. The viral nature of AGPL makes it toxic to almost everyone unless you’re willing to pay the copyright holders for special permission. That’s certainly fine but to me it’s less OSS and more like a viral source available license.
The point of GPL-alikes is to ensure user freedom: that the user can modify the code of any software they use.
If a company is intolerant of this, then the AGPL is intolerant of that company.
it stops low effort grifting of network-enabled open source for cash.
Alternative point of view: opensource isn't the same as freeloading
> Any derivative works of AGPL-licensed software must also use the AGPL.
It’s a viral license. It infects everything it touches.
Not if you just deploy it as is, like a service. (which it's intended to) If you write an application which uses MinIO over HTTP, you have no obligation to release your application code.
False
AGPL is purposefully designed to eliminate the Embrace, Extend, Extinguish model of Cloud providers, where the provider embraces a popular open source projects, creates a "service" from it, extends that service in order to make their flavor non-compatible with out contributing upstream in an effort to extinguish the original project.