Hacker News new | ask | show | jobs
by betamaxthetape 2330 days ago
I've always wondered about whether the AGPL is a good fit for software that isn't accessed over the network. At first glance this would appear to offer the exact same rights as the GPL in this scenario, however you then have the protection of the AGPL if the software was ever incorporated into a networked program.

Does anyone have any experience with this? Are there pitfalls to using the AGPL for a regular program that I'm not thinking of?

4 comments

The thing about modern code is that anyone can take a project, turn it's function into a webpage, and charge money without revealing that you could run the program on your own machine.

If you license all of your code under the AGPLv3, you will at least see if someone is using it out in the wild and maybe even get some contributions to your project.

This is called "SaaSification" and there is a debate over to what extent it violates the spirit of open source and what if anything ought to be done about it.
How is it different in spirit from taking a product, adding a feature to it, and distributing? It's still removing freedom from the user. That's what the AGPL is for, for removing runtime host as an excuse to not let users control their use of software.
AGPLv3 is the only solution I see.
I recently used the iText Library for PDF parsing in java. Everything was alright until I discovered their AGPL license.

https://itextpdf.com/en/how-buy/agpl-license

Since our product was proprietary, we had to remove the library since our product would also come under the AGPL license or we would have to buy their commercial version, for which we can get a "quote"(https://itextpdf.com/en/how-buy)

I'm pretty sure that's the intended effect in this case: force you to either open source your product or buy a commercial license (or use the ancient version from before the license update).
There is an actively maintained fork of iText: https://github.com/LibrePDF/OpenPDF

From their background section: It is a fork of iText version 4, more specifically iText svn tag 4.2.0, which was hosted publicly on sourceforge with LGPL and MPL license headers in the source code, and lgpl and mpl license documents in the svn repository. Beginning with version 5.0 of iText, the developers have moved to the AGPL to improve their ability to sell commercial licenses.

What did you replace it with?

Why wouldn't iText deserve your money if you were using it in your commercial product?

> Why wouldn't iText deserve your money if you were using it in your commercial product?

Because they're not even saying how much money. "Call us for a quote" usually means "Let's start the sales dance in which we try to gauge how much we can fleece you for", which also means it's not going to be a quick answer.

For me it means the software is immediately categorized as "to be considered only once all other options have been exhausted".

I agree with your feelings on this last point. I wonder how it's working out for them as I imagine it's a turn off for corporate buyers as well as lone devs and small shops.
I doubt it's a turn-off for corporate buyers in the large, but it's absolutely a turn-off for dev teams within corporations. Especially nowadays in an increasingly Agile world where everything is due 2 weeks from when you start work on it.

A developer might be quite willing to go to their manager with, "Hey, can we buy X? It will cost $Y, and save us $Z worth of time." But "Call for a quote" is a quagmire: They can't (and don't want to) negotiate prices themselves, and they also don't want to annoy their boss by causing them to spend the next 3 months being hounded by sales people.

I imagine it's a turn off for corporate buyers as well as lone devs and small shops.

The request a quote style of pricing is almost exclusively for corporate buyers. It allows them to go out to lunch and get the purchasing department involved and make management feel like an important part of the process.

Hunting for a replacement seems more work than making a phone call.
It's not just a phone call, of course. If they had a concrete pricing model they could just tell you on the website.

"Call for a quote" means they expect to have their sales staff talk to your management or procurement department to negotiate a price, do a face-to-face meeting if possible, so they can see how much you're willing to pay.

We are awaiting a response from IText for the license, but for now Apache PDFBox got us the same results
you won't use itext, their quotes are hilarious.
nonetheless, I found their library pretty easy to use and faster compared to the competitors. Sadly due to the licensing issues, I think I won't be using it for sometime ( or ever incase quote is above and beyond expectations )
Probably yes, because seems their licensing policy is not very user-friendly or straightforward. On their How-To-Buy Page (https://itextpdf.com/en/how-buy) the licensing model is pretty convoluted
A potential pitfall is that only AGPLv3 and GPLv3 are directly compatible (in the sense of producing programs created from both AGPLv3 and GPLv3 code without violating either license). That's not possible with GPLv2 or AGPLv1 in any combination, and there's still some code-bases that will be GPLv2 forever.

But if that's not a concern then I would agree that AGPL is exactly how the GPL should look like in the age of SaaS, PaaS and all the other ?aaS.

That's not entirely true. GPLv3 and AGPLv3 have explicit clauses that allow the linking of GPLv3 and AGPLv3 code into a single work without violating either license: https://en.wikipedia.org/wiki/Affero_General_Public_License#...

You're right about GPLv2 though.

But GPLv2 is the one that allows for tivoization, and whether that violates the spirit of free code does not have a consensus.
Nothing has consensus, that's why there are so many licenses.
People seem to be doing this. ArgyllCMS (cms = color management system) uses this model. I am not sure what the practical implications of this are. 99.9% of people just ship their calibration software to the user's desktop, so probably don't care if they have to make the ArgyllCMS source code available.

To me, the biggest problem with the AGPL is that nobody really knows what the implications are. A lot of people say a lot of things, but that's all we have. I find it to be a greater burden to figure out what the license actually means than to just pick another software system that uses a permissive license. Large companies like Google seem to agree with me.