Live data from Hacker News

Square’s terms of service forbid use of AGPL-licensed software in online stores

squareup.com

61–70 of 145 posts

Re: Square’s terms of service forbid use of AGPL-licensed software in online stores

#61
post #37
post #28

Earlier quoted context omitted.

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

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 ag…

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

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

2. 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

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

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

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-3.0.rdf

The GPL v3.0 RDF pulls in 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:

    
    
    
    
    
    

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.

Re: Square’s terms of service forbid use of AGPL-licensed software in online stores

#62
post #38

Earlier quoted context omitted.

That's not true although it is easy to misunderstand AGPL in this way. You only have to provide the source of derivative work, and only to users of your service. So only the micro service using AGPL code. If you use an AGPL database for example, you don't have to provide any source code unless you change the source code of the database. This idea was behind the business models of Rethink DB and Mongo DB.

Except AGPL doesn't have the linking exception from LGPL, so your entire application is covered. A microservice doesn't get around it if it's tightly coupled. It would only be enough if your main application was not dependent on the AGPL microservice (e.g. you have another image processing microservice that provides perfect parity).

Yepp, see here for more details:

https://news.ycombinator.com/item?id=20113021

Re: Square’s terms of service forbid use of AGPL-licensed software in online stores

#63
post #59
post #22

This makes absolutely no sense. I'm almost certain that Square lawyers fucked up big time. They looked at the AGPL and completely misunderstood the context. There is no way in hell anyone can interpret AGPL in a way that makes Square responsible for any license violations their customers make selling software.

I see that aswell. else, google would need to provide the source code for gcloud, since I can run agpl software on top of their compute nodes... like wtf?

BTW, isn't this the exact purpose of the new MongoDB license?

Re: Square’s terms of service forbid use of AGPL-licensed software in online stores

#64
post #5

Earlier quoted context omitted.

How's that even legal or verifiable?

Why would it not be legal? Verifiable does not play a role. You sign a contract that you won’t do it.

Not all contracts are valid.

Re: Square’s terms of service forbid use of AGPL-licensed software in online stores

#65
post #58
post #50

Earlier quoted context omitted.

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.

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.

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.

Re: Square’s terms of service forbid use of AGPL-licensed software in online stores

#66
post #22

This makes absolutely no sense. I'm almost certain that Square lawyers fucked up big time. They looked at the AGPL and completely misunderstood the context. There is no way in hell anyone can interpret AGPL in a way that makes Square responsible for any license violations their customers make selling software.

I mean I never understood AGPL for client-side code to be honest. Would the GPL not cover this use case? My understanding of the license is that the GPL would of been enough, unless the AGPL has some terms I'm not aware of that aren't server specific like ensuring access to code in unobsfucated form or something.

Re: Square’s terms of service forbid use of AGPL-licensed software in online stores

#67
post #27

Earlier quoted context omitted.

I looked it up. Agpl is meant to close the loophole whereby, you know Google can use GPL tools while they index the web but I can't demand a copy of their private repos source code, since I just get to use the result (over the web). Agpl closes this loophole. I think gpl is enough for web apps. I don't think I should have the right to demand all of gmail's or google search's server-side code if they use but don't dis…

>But all companies need to steer really clear of agpl code. Even editing an image using an agpl image editor could taint the image, even though you're not exporting any code. This is an outrageous claim. Citation needed.

Dude, I literally didn't know what agpl is. I found:

>Just my impression after 5 minutes of research. If someone has more detailed legal position please do correct whatever I got wrong.

after 5 minutes of Googling. downvoting my personal research results after 5 minutes of Googling won't get anyone to answer with the corrected version. I had never heard of agpl until I googled it and summarized what I saw.

It's a summary. if you put up a web app where you modify open source software as part of your stack, you have to publish those changes if people ask for them. Even if you are not distributing those changes. (This is my impression.)

I look forward to a correction from an expert - it's why I posted what I found. (Yes, what I found was outrageous.)

Re: Square’s terms of service forbid use of AGPL-licensed software in online stores

#69

Earlier quoted context omitted.

Why would it not be legal? Verifiable does not play a role. You sign a contract that you won’t do it.

Not all contracts are valid.

This is not an answer. Invalid contracts are usually invalid for a specific reason.

Re: Square’s terms of service forbid use of AGPL-licensed software in online stores

#70

Relevant quoted text from the article: > B. Content Restrictions. In addition to the restrictions set forth in these Additional Product Terms, the General Terms and Payment Terms, you will not: [...] > 15. use, under any circumstance, any open source software subject to the GNU Affero General Public License v.3, or greater;

I don't use square so I haven't read the full terms, but I think it's important that B 15 is under 3. Online Store I. eCommerce Terms

So I think these restrictions only apply to websites they designed or host. I think it would be fine to distribute software under the AGPL and use square for the payment. Or run AGPL software on your own ecom site and use them as the payment provider.

Does this sound right? And if so, I guess they wouldn't want to have to redistribute the modified versions of software?

Post reply on HN