Hacker News new | past | comments | ask | show | jobs | submit login

Doesn't Affero turn people off?

Affero means you really can't work with the code in any effective way cause anything it touches becomes Affero.

Personally I found Affero repellent when considering which open source software to download and install.

I am not a lawyer, but as long as someone uses a AGPL-licensed software stand-alone, I don't see a reason for that Someone to be turned off. Many AGPL-licensed components/applications run standalone and don't have caused trouble for their users, e.g. MongoDB users (also see https://en.wikipedia.org/wiki/List_of_AGPL_web_applications ).

At the moment someone starts editing/working on the code, he/she does so with a reason, either commercial or non-commercial in nature.

So you, as the copyright holder, could license your software under the following conditions:

"If you use our software commercially, then you have to pay for it by purchasing a commercial license.

If you use our software non-commercially, then you may use it under the terms of AGPL.

For private, evaluation, and research purposes possibly leading to a commercial use, you can evaluate, use, and modify our software up until the point where you decide to publicly use it in a commercial or non-commercial way. At that point you will have to decide on either of the two aforementioned licensing options."

MongoDB made an explicit exception to AGPL. Normally a driver wrapping an AGPL database would have to be AGPL too. In turn every app using the driver would be AGPL. But Mongo, as owners of the driver and DB, made an exception for users.

The only situation where AGPL wouldn't affect other components is where you're using industry wide standard APIs. E.g., I can use Firefox to connect to an AGPL website, but that doesn't make Firefox AGPL. This is what Stallman is getting at when he talks about intimacy of API communication. He points to a simple call to main as an example that's not intimate communication and thus has no licensing consequences.

Also you can't say "we license this as AGPL for non-commercial use". That violates the rights of the user to not have additional restrictions placed on the AGPL. And if you think through the practicalities of how that would work, it's not feasible anyhow.

Edit to add: AGPL does not prevent private modification of code. Your are required to license the code as AGPL and distribute the AGPL licensed project to users, but if the user is just you, there's no practical effect. However, once you start sharing it internally in a company, it's a giant grey area especially if you have contractors or any non-employee ever access your infrastructure. Employees might also be able to claim they are entitled to an AGPL copy of it. The only thing that's allowed internally is having someone "make modifications exclusively for you, or provide you with facilities for running those works", which would be effective for a trial or POC. Essentially you should either plan to abide by the AGPL or plan on buying the dual license at some point (the license allows violations to be fixed within 30 days).

(This post is for entertainment purposes. I am not a lawayer, and this is not advice.)

> Also you can't say "we license this as AGPL for non-commercial use". That violates the rights of the user to not have additional restrictions placed on the AGPL. And if you think through the practicalities of how that would work, it's not feasible anyhow.

Are you referencing "further restrictions" in AGPLv3's "additional terms"? http://www.gnu.org/licenses/agpl-3.0.html#section7

Good point! (Maybe) to fix this problems, for dual licensing with a non-commercial AGPLv3-like tier and a commercial tier, we would require a "modified AGPLv3" on the non-commercial tier. That "modified AGPLv3" would explicitly prohibit commercial use.

There is a Stack Overflow question asking on how to prohibit commercial use: http://stackoverflow.com/q/3485750/923560

Yes, I was referring to that section. Eventually restrictions on commercial use completely nullifies the AGPL... no one ends up with anything that's AGPL in the end.

Your alternative approach here would work. Maybe specifically a tri-license: non-commercial, commercial, and plain AGPL. For non-commercial licenses, this list mentions some: https://www.gnu.org/licenses/license-list.html

Also consider that the AGPL strongly discourages modifications directly to it. The proper way to "modify" it is by adding extra permissions. Those permissions can come with strings attached (from the original developer only), but any user should be able to discard those terms and choose the original AGPL instead. So instead of dual or tri-licensing you could add permissions that say, you can bypass requirements X, Y, and Z of the AGPL but only if either: (1) you use this non-commercially or (2) you buy a license. But in that event you basically can't have either one of those people sharing their code or it pollutes everything and might destroy the original project. Meaning, not only could a project be forked, but forked as many wildly different and incompatible licenses with the original author having no control of it.

In some situations, that's exactly the point. When I want a license that everyone can use without thinking twice, including you, I take MIT/BSD. When I want people to consider their position on software freedom before they use my software, I use AGPL.

Perhaps other people don't use it that way, but for me: yes, Affero turns some people off. That's why I use it. To remind people: Hey, there is a world of aggressively free(dom) software where many people are happy. Why not join us?

No hard feelings, of course. I love MIT/BSD and use it in almost all my projects.

Well, isn't the point to turn competitors off? If one is a die-hard Free Software advocate, you have no problem with Affero. If you want to set up a fork, then you might have a problem.

If you refuses to download and install software because of personal believes in license, I wish you good luck. Its hard to do on a personal level, and RMS has got a lot of heat for documenting about it.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact