4 ms·

It might be GPL but I would guess it's not AGPL. AGPL requires you to open source the code to run the service. They've not done that. Their legal people are lik

by mfer 7y ago

It might be GPL but I would guess it's not AGPL. AGPL requires you to open source the code to run the service. They've not done that. Their legal people are likely on top of this. It's not hard to run a SaaS and avoid all AGPL

pas 7y ago
How does "linking" works in this regard? If I have an internal AGPL service do I have to open source that too? I mean my end users never interact with that service. They interact with a - let's say - proprietary one. And that service is the client to the AGPL service. Or anything AGPL touches turns into AGPL? What is considered touching? If I use an AGPL firewall do the packets turn into AGPL? If I use an AGPL log aggregator? Or an AGPL centralized identity management thing every other service that auths turns into AGPL?
- megous 7y ago
  https://www.gnu.org/licenses/agpl-3.0.html https://www.gnu.org/licenses/agpl-3.0.html 13
  - pas 7y ago
    https://news.ycombinator.com/item?id=20122666 https://news.ycombinator.com/item?id=20122666 Furthermore the combining with other works is not clear in on GPL3 cases. When combining happens and when doesn't? What happens if I combine it with proprietary software?
- jsty 7y ago
  This is half the reason why many large companies have prohibitions on using AGPL code - no one is quite sure exactly what counts as 'interacting remotely', and thus what would be in scope for the source release requirements. In the absence of any case law to clarify the situation, many orgs just prefer not to bring in that uncertainty in the first place.
  - bitL 7y ago
    Usually AGPL products are dual licensed, allowing development of sustainable free software businesses, so I suspect the real reason is that companies simply don't want to pay for commercial licenses.
    - mfer 7y ago
      Companies often pay for commercial licenses and to use SaaS. Just look at the number of companies paying for Oracle or support from a GNU/Linux vendor like Ubuntu or Red Hat. I wonder if it's about control. With a SaaS you can switch to a competitor. It's possible to switch between GNU/Linux distros and the companies that support them. Change is possible. This can protect you from a vendor tanking or who has bad behavior. Oracle is an outlier. They aren't going away. There's enough business to keep them around. And, many companies are trying to get away from them slowly. When you have an AGPL and commercial dual license it puts that vendor in control. Do big businesses like putting others in a position of power and control over them? If that business is small or a startup do they want to have that as a hard dependency? Is it a risk to the big business? This isn't about paying for commercial licenses. It's about risk mitigation. Something big businesses do a lot of.
  - AnthonyMouse 7y ago
    This is the section about "interacting remotely": > Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph. So that's about who you have to give the source code to if you modify the program, right? But isn't the salient point there that it only matters if you make modifications? Why should anybody who is using the software unmodified care about that at all? And all the stuff about "what is linking" would be the same as it is for the ordinary GPL, would it not? The "Source Code" section of both licenses are word for word identical, anyway. It all seems like a lot of FUD from people who don't like the AGPL because it requires them to follow the spirit of the ordinary GPL when they actually do make modifications but then use them in a public-facing service instead of distributing them as a software product, i.e. when it does exactly what it's intended to do.
- no_identd 7y ago
  Unfortunately the FSF neglects to offer something like a "Lesser AGPL", see the discussion in this Github issue for some details on that: https://github.com/moll/node-pg-error/issues/1 https://github.com/moll/node-pg-error/issues/1 It also seems worthwhile to examine the differences between the APGL and the recently introduced (and much critiqued, albeit I find somewhat unfairly, in some aspects) SSPL: 1. https://news.ycombinator.com/item?id=18352171 https://news.ycombinator.com/item?id=18352171 2. https://news.ycombinator.com/item?id=18301116 https://news.ycombinator.com/item?id=18301116 The above should let you find the answers to your questions, but I'll use this comment to also point to some less on topic but still very much related to licensing granularity matters. Compare the various FSF licenses to the OSET license: http://www.osetfoundation.org/public-license http://www.osetfoundation.org/public-license Two specific things I find rather atrocious about all the FSF licenses seem easiest to highlight by pointing out what the OSET license does to explicit avoid these pitfalls: 1. "Sovereign Immunity. Contracting with governments brings up a special issue that doesn’t apply to anyone else: normally, if you grant a license to government, you may not be able to sue for a violation because governments can be immune from legal claims. We ask recipients to waive this restriction, so there is a remedy if the recipient does not abide by the terms of the license. See Section 9.2 of the OPL" 2. "The OSET Foundation (then the “OSDV Foundation”) attained its full tax-exempt status under 501(c)(3) of the Internal Revenue Code declaring us a public charity in the 3rd quarter of 2013. In the course of seeking this status, as part of a negotiation⁴, we agreed to make certain changes to the license to ensure that our source code is free for everyone to use. Section 5.3 of the 2.0 license now requires that a licensee who does not abide by the terms of the license must make the Covered Software available in Source Code Form on a publicly available computer network for a period of no less than three (3) years. This goes beyond the source code delivery requirements of standard open source licenses. Section 5.4 reserves the ability of a licensor under our license to seek injunctive relief for violation of the terms of the license. It is not clear at this point whether a court could, under applicable law, order a violator to release source code. But we cannot control the law, only our license. Therefore, if that remedy is available under law, we want to make sure it is available under our license as well." And then, even more peripherally related, none of the libre licenses I know have some variants for transcopyright, a licensing concept almost forgotten, and outlined by Ted Nelson, here: http://www.youtube.com/watch?v=x3l7CpnpyGw http://www.youtube.com/watch?v=x3l7CpnpyGw At this point, I really wish we'd have some sort of mathematically sound "mix and match" license generator, where you can pick what you want your license to do with extreme granularity, based on as detailed of a parameterization of what one might do with Software licenses in general, and get a standardised, reproducible license build. There does exist this: https://en.wikipedia.org/wiki/Rights_Expression_Language https://en.wikipedia.org/wiki/Rights_Expression_Language But it doesn't actually really do what you might expect it to do. For example, compare these two RDFs for the GPLv2, and the GPLv3: https://www.gnu.org/licenses/gpl-2.0.rdf https://www.gnu.org/licenses/gpl-2.0.rdf https://www.gnu.org/licenses/gpl-3.0.rdf https://www.gnu.org/licenses/gpl-3.0.rdf The GPL v3.0 RDF pulls in http://xmlns.com/foaf/0.1/ http://xmlns.com/foaf/0.1/ as an additional XML Namespace, and has a logo, but in terms of the actual ccREL encoding, they seem completely identical, both just contain this: <cc:requires rdf:resource="http://creativecommons.org/ns#Copyleft"/> <cc:requires rdf:resource="http://creativecommons.org/ns#SourceCode"/> <cc:requires rdf:resource="http://creativecommons.org/ns#Notice"/> <cc:permits rdf:resource="http://creativecommons.org/ns#Distribution"/> <cc:permits rdf:resource="http://creativecommons.org/ns#Reproduction"/> <cc:permits rdf:resource="http://creativecommons.org/ns#DerivativeWorks"/> For even more licensing shenanigans, compare all of the above to the Eclipse license as well as to the Mozilla Public License & the Apache Licenses.
0x0 7y ago
Didn't debian change to the AGPL version of ghostscript in a patch security update? If you use imagemagick or other pdf related libraries that maks use of ghostscript, this could happen easier than you think.
- klez 7y ago
  > Didn't debian change to the AGPL version of ghostscript in a patch security update? Mostly, yes[0]. Parts of the package are under BSD, others FreeType license, others GPL etc. I don't know which ones are used in imagemagick, so I can't say whether AGPL "infected" it. [0] https://metadata.ftp-master.debian.org/changelogs//main/g/ghostscript/ghostscript_9.26a~dfsg-0+deb9u3_copyright https://metadata.ftp-master.debian.org/changelogs//main/g/gh...

by mfer 7y ago

pas 7y ago

How does "linking" works in this regard? If I have an internal AGPL service do I have to open source that too? I mean my end users never interact with that service. They interact with a - let's say - proprietary one. And that service is the client to the AGPL service. Or anything AGPL touches turns into AGPL? What is considered touching? If I use an AGPL firewall do the packets turn into AGPL? If I use an AGPL log aggregator? Or an AGPL centralized identity management thing every other service that auths turns into AGPL?

megous 7y ago
https://www.gnu.org/licenses/agpl-3.0.html https://www.gnu.org/licenses/agpl-3.0.html 13
- pas 7y ago
  https://news.ycombinator.com/item?id=20122666 https://news.ycombinator.com/item?id=20122666 Furthermore the combining with other works is not clear in on GPL3 cases. When combining happens and when doesn't? What happens if I combine it with proprietary software?
jsty 7y ago
This is half the reason why many large companies have prohibitions on using AGPL code - no one is quite sure exactly what counts as 'interacting remotely', and thus what would be in scope for the source release requirements. In the absence of any case law to clarify the situation, many orgs just prefer not to bring in that uncertainty in the first place.
- bitL 7y ago
  Usually AGPL products are dual licensed, allowing development of sustainable free software businesses, so I suspect the real reason is that companies simply don't want to pay for commercial licenses.
  - mfer 7y ago
    Companies often pay for commercial licenses and to use SaaS. Just look at the number of companies paying for Oracle or support from a GNU/Linux vendor like Ubuntu or Red Hat. I wonder if it's about control. With a SaaS you can switch to a competitor. It's possible to switch between GNU/Linux distros and the companies that support them. Change is possible. This can protect you from a vendor tanking or who has bad behavior. Oracle is an outlier. They aren't going away. There's enough business to keep them around. And, many companies are trying to get away from them slowly. When you have an AGPL and commercial dual license it puts that vendor in control. Do big businesses like putting others in a position of power and control over them? If that business is small or a startup do they want to have that as a hard dependency? Is it a risk to the big business? This isn't about paying for commercial licenses. It's about risk mitigation. Something big businesses do a lot of.
- AnthonyMouse 7y ago
  This is the section about "interacting remotely": > Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph. So that's about who you have to give the source code to if you modify the program, right? But isn't the salient point there that it only matters if you make modifications? Why should anybody who is using the software unmodified care about that at all? And all the stuff about "what is linking" would be the same as it is for the ordinary GPL, would it not? The "Source Code" section of both licenses are word for word identical, anyway. It all seems like a lot of FUD from people who don't like the AGPL because it requires them to follow the spirit of the ordinary GPL when they actually do make modifications but then use them in a public-facing service instead of distributing them as a software product, i.e. when it does exactly what it's intended to do.
no_identd 7y ago
Unfortunately the FSF neglects to offer something like a "Lesser AGPL", see the discussion in this Github issue for some details on that: https://github.com/moll/node-pg-error/issues/1 https://github.com/moll/node-pg-error/issues/1 It also seems worthwhile to examine the differences between the APGL and the recently introduced (and much critiqued, albeit I find somewhat unfairly, in some aspects) SSPL: 1. https://news.ycombinator.com/item?id=18352171 https://news.ycombinator.com/item?id=18352171 2. https://news.ycombinator.com/item?id=18301116 https://news.ycombinator.com/item?id=18301116 The above should let you find the answers to your questions, but I'll use this comment to also point to some less on topic but still very much related to licensing granularity matters. Compare the various FSF licenses to the OSET license: http://www.osetfoundation.org/public-license http://www.osetfoundation.org/public-license Two specific things I find rather atrocious about all the FSF licenses seem easiest to highlight by pointing out what the OSET license does to explicit avoid these pitfalls: 1. "Sovereign Immunity. Contracting with governments brings up a special issue that doesn’t apply to anyone else: normally, if you grant a license to government, you may not be able to sue for a violation because governments can be immune from legal claims. We ask recipients to waive this restriction, so there is a remedy if the recipient does not abide by the terms of the license. See Section 9.2 of the OPL" 2. "The OSET Foundation (then the “OSDV Foundation”) attained its full tax-exempt status under 501(c)(3) of the Internal Revenue Code declaring us a public charity in the 3rd quarter of 2013. In the course of seeking this status, as part of a negotiation⁴, we agreed to make certain changes to the license to ensure that our source code is free for everyone to use. Section 5.3 of the 2.0 license now requires that a licensee who does not abide by the terms of the license must make the Covered Software available in Source Code Form on a publicly available computer network for a period of no less than three (3) years. This goes beyond the source code delivery requirements of standard open source licenses. Section 5.4 reserves the ability of a licensor under our license to seek injunctive relief for violation of the terms of the license. It is not clear at this point whether a court could, under applicable law, order a violator to release source code. But we cannot control the law, only our license. Therefore, if that remedy is available under law, we want to make sure it is available under our license as well." And then, even more peripherally related, none of the libre licenses I know have some variants for transcopyright, a licensing concept almost forgotten, and outlined by Ted Nelson, here: http://www.youtube.com/watch?v=x3l7CpnpyGw http://www.youtube.com/watch?v=x3l7CpnpyGw At this point, I really wish we'd have some sort of mathematically sound "mix and match" license generator, where you can pick what you want your license to do with extreme granularity, based on as detailed of a parameterization of what one might do with Software licenses in general, and get a standardised, reproducible license build. There does exist this: https://en.wikipedia.org/wiki/Rights_Expression_Language https://en.wikipedia.org/wiki/Rights_Expression_Language But it doesn't actually really do what you might expect it to do. For example, compare these two RDFs for the GPLv2, and the GPLv3: https://www.gnu.org/licenses/gpl-2.0.rdf https://www.gnu.org/licenses/gpl-2.0.rdf https://www.gnu.org/licenses/gpl-3.0.rdf https://www.gnu.org/licenses/gpl-3.0.rdf The GPL v3.0 RDF pulls in http://xmlns.com/foaf/0.1/ http://xmlns.com/foaf/0.1/ as an additional XML Namespace, and has a logo, but in terms of the actual ccREL encoding, they seem completely identical, both just contain this: <cc:requires rdf:resource="http://creativecommons.org/ns#Copyleft"/> <cc:requires rdf:resource="http://creativecommons.org/ns#SourceCode"/> <cc:requires rdf:resource="http://creativecommons.org/ns#Notice"/> <cc:permits rdf:resource="http://creativecommons.org/ns#Distribution"/> <cc:permits rdf:resource="http://creativecommons.org/ns#Reproduction"/> <cc:permits rdf:resource="http://creativecommons.org/ns#DerivativeWorks"/> For even more licensing shenanigans, compare all of the above to the Eclipse license as well as to the Mozilla Public License & the Apache Licenses.

0x0 7y ago

Didn't debian change to the AGPL version of ghostscript in a patch security update? If you use imagemagick or other pdf related libraries that maks use of ghostscript, this could happen easier than you think.

klez 7y ago
> Didn't debian change to the AGPL version of ghostscript in a patch security update? Mostly, yes[0]. Parts of the package are under BSD, others FreeType license, others GPL etc. I don't know which ones are used in imagemagick, so I can't say whether AGPL "infected" it. [0] https://metadata.ftp-master.debian.org/changelogs//main/g/ghostscript/ghostscript_9.26a~dfsg-0+deb9u3_copyright https://metadata.ftp-master.debian.org/changelogs//main/g/gh...