Comment by Eduard | Hacker News Reader

Comment by Eduard | Hacker News Reader

I'm as well currently thinking about open-sourcing components of my web application. "Open sourcing" comes in many flavors, and the one I'm mostly favoring right now (for one of my particular components) is a dual license, "GNU AGPLv3 / commercial" combination.

https://en.wikipedia.org/wiki/Affero_General_Public_License

Metafizzy's Isotope goes a very similar dual-licensing way: http://isotope.metafizzy.co/license.html

Isotope's author has written about how commercial support has worked for him in his particular context, search for "support" on his blog archive: http://metafizzy.co/blog/archive.html

While an MIT and BSD license is (among other things) good for monetizing on consultancy (... not easy for a one-person project), a GPL-including multi-license may additionally allow to monetize on third party modifications of a software component (... that's way easier for a one-person project).

If someone sees a fallacy or gotcha in my monetization reasoning, please comment.

One problem with dual-licensing though is that open source contribution becomes unnecessarily hard. Every contributor will have to sign a Contributor License Agreement, that at the very least allows you to dual-license their code. Many CLAs even have the contributor sign over her copyright to you.

Not everyone will be happy to sign something like that. And integrating a pull request on github suddenly becomes a tedious excercise in international copyright law :)

So dual-licensing gives you all the publicity-related and try-before-you-buy advantages of open source. But you will probably miss out on other great aspects, especially community-wise.

Could that be fixed by having a technical architecture that supported additional functionality by plugins? So the core product is dual licensed and contributions are done as plugins that can be licensed separately?

It's prudent to have a CLA anyhow. Even if a whole project were AGPL, an employer of some contributor could claim ownership and IP theft.

And the right to fork a project also means the right to put conditions on accepting contributions.

And there are more advantages than publicity and free demo, namely that users have freedom to run the app themselves, find another service provider, find another project maintainer, etc. I'd see it as a far less risky situation than anything proprietary. Compared to Apache/BSD/MIT it's less risky in the sense that people aren't going to be introducing proprietary forks.

Another approach is to dispense with CLAs and copyright assignment, and let the community edition diverge from what you run for your paid service.

If you do that, you can't incorporate improvements from the community edition back into your code by simply copying them, but you can use them for inspiration to guide your parallel development for the paid version. That's more work than simple copying, but less work than developing new features from scratch.

This is a problem for all those 0.1% of FLOSS projects which actually get contributions. If yours are one of those, then donations or grants is something to look into in favor of dual-licenses.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com