OT, as the sole copyright owner of a web application I wrote, can I license it under the AGPL for the general public, and license it under different terms for clients who would prefer not to use AGPL software (and possibly pay for it) ? is dual licensing allowed by the AGPL ?
Yes. But keep in mind that the copyright of any contributions you might get will be held by the author of that contribution, not by you. The contributor might license that contribution under the AGPL only, and thereby put a stop to your little scheme. You would have to either get a license from the contributor to your dual licensing scheme, or simply require all contributors to sign the copyright over to you, which is most commonly done in a so-called Contributor Licensing Agreement (CLA). However, CLAs are rightly disparaged for being unfair, in that it lets you, and only you, profit and monopolize what might become a community effort. A requirement of a CLA will most certainly discourage many, if not most, potential contributors from contributing.
I knew about this, that's why I said "sole copyright owner". The goal is to put the code out there and restrict other from modifying it without publishing their changes to their users.
But I want to keep the option of licensing it differently for specific (b2b) clients. It's a not a true open source / free software in spirit as I don't plan to accept outside contributions.
You seem to be assuming that you are the only person who will ever contribute meaningfully to the software. But if, as you probably also hope, the software is widespead and successful, there will most probably arise at least one popular third-party extension/modification. And you will not be able to incorporate this addition into the product which you distribute to your b2b customers; this will make your version of the software inferior to the free version.
The other option is that could simply pay community members some fair portion of the b2b revenue in exchange for signing the CLA. If you're the primary contributor, it's fair to take most of the revenue for yourself, but revenue sharing with major contributors from the community is also fair. Could be difficult tax-wise though? IDK.
Don't let the other commenter dissuade you. There are many successful open source AGPL projects that have CLAs which are not widely disparaged. There's no shame in owning your creation, nor is it immoral to ask contributors to assign their copyright to you. To each their own. Good luck!
That's not how licensing works. If you write the software, you can release it under any license(s) you want. The license states the terms under which you'll let others use the software.
Yes, you can licence it however you want because you are the copyright holder. See mongodb. IANAL. Licences are to restrict those who do not hold copyright.
> Licences are to restrict those who do not hold copyright.
On the contrary, licenses gives permission to those who do not hold copyright. Without any license, only the copyright holder has any rights to copy or modify the work in any way (except for fair use). A license gives permissions to non-copyright holders to do things which would otherwise be illegal under copyright law. A license can never restrict what anyone would otherwise be allowed to do, since it is not a contract.
Is the suggestion here that, say I was in the business of selling proprietary software, by running Wiki.js and making it accessible to the public that the copyleft license would then apply to my proprietary software?
If you package it with your software, then that might be the case unless you had negotiated other licencing terms first.
Simply hosting it with your information in would not have any such effect, but many commercial entities avoid anything xGPL just-in-case. In this case perhaps because they see a time that they might later want to package and distribute documentation that is in the wiki without converting it to something else first.
There is an extra concern with AGPL that does not exist with GPL specifically because of its key difference. AGPL applies to hosting the software and making it available not just distributing a compiled form. Some interpret this as meaning that if it is hosted on the same server, or in the same site, as other software then that other software becomes AGPL licensed too. I doubt anyone would enforce this interpretation but the possibility is enough to put off those who create proprietary software.
> making it accessible to the public that the copyleft license would then apply to my proprietary software?
Not just the public. Anyone you give access to, so for non-public hosted proprietary software you could be beholden to giving them access to the code under the AGPL in situations where AGPL applies. This will be a complete blocked for many creators of proprietary, or other non-*GPL licensed, software.
[if the above makes me sound against AGPL rest assured that I am not - I in fact might end up using it at least initially (at least until I decide upon which of the more proprietary-friendly options to use) for some near-future projects]
If I hosted a wiki.js, say on a subdomain, unrelated to a commercial application's code at all, but lined to it (e.g. the "docs" section of navigation) would I need to disclose
a) the source code of the wiki.js subdomain only, and any modifications we make to it
b) the source code of wiki.js and the other proprietary app BOTH
?
A, unless you package and distribute the code of wiki.js in some way with the application - but it sounds like you are talking about a hosted only solution so that won't be an issue.
If you allow self-hosting of your proprietary code by your users and the refers to your documentation server than this would still not trigger AGPL for the other code - you are not distributing wiki.js or parts of it. If you allow self hosting of the other code and include wiki.js for a local copy of your documentation then APGL might trigger.
Linking is meaning software linking, not referencing your own content displayed by the software. Think of it as the same difference between including using chunks of a paper in your own paper, or saying "as discussed in This Paper About This Thing (Him, Her, et. al, 2013)...". Or, as in this case the content is your's, referencing your own paper.
This potential confusion with the word "linking" (as natural languages are fairly dynamic beasts) is why people are sometimes overly fearful of AGPL and GPL (and often even LGPL) software.
Linking as in binary linking: yes (option b).
Linking as in HTML A href link: no, only option a.
Problem is that unless you are installing your servers by hand you end up re-packaging wiki.js and then your own packaging code and the modification on wiki.js as a build artefact are now supposed to be public as well.
I don't understand what you mean about packaging code.
Do you mean to distinguish between setting up an EC2 instance or digitalocean droplet type of thing versus using ansible/chef/etc orchestration among the servers? Implying you would have to publish the configs for all your servers?
That would make no sense, both from a practical perspective (publicly disclose server configs? those can include sensitive information), and a theoretical perspective (what does that have to do with the source code at all?).
Interestingly Amazon just finished a multi-year effort to migrate off MediaWiki internally to comply with an infosec mandate that PHP is banned company wide.
If its your own password you can change from the web interface. If it is someone else's password you can send a password reset email from the web interface.
To actually set someone else's password to a specific value does require running a command line script (not the same as going into db). In my view that is a reasonable security-convinence trade off.
In any case, i would assume a large org would use a single-sign-on extension and not mediawiki's native user management, which would make MW's password management moot.
Google has some motivations written down from their lawyer department: https://opensource.google/docs/using/agpl-policy/
It boils down to 'not worth the risk, do not use'.