5

I have written from scratch some SW that I want to publish as open-source in Github while being the only contributor.

I want to publish it under AGPL license.

At the same time I want to use the very same software in my other private projects which supposed to be commercial. The projects should not disclose the source code.

In this case should I include the licensed SW as-is (i.e. under AGPL license with proper textual declarations) or should I include it under more permissive license (e.g. MIT) or should I remove any licensing reference?

Improve this question
4
  • 2
    If the code is 100% yours you can use it as you like and release it how you like. AGPL for others, proprietary for you works. You can even sell closed-source licenses to others.
    – ivanivan
    Apr 27, 2019 at 13:34
  • What happens if later I decide to sell the proprietary code? Wouldnt the buyer say that the code portion published under AGPL therefore it is not proprietary anymore?
    – BorisV
    Apr 27, 2019 at 14:49
  • 3
    Look at the Qt stuff - dual licenses are available, open or commercial. Same with quite a few other offerings.
    – ivanivan
    Apr 27, 2019 at 17:02
  • 1
    @user14862 it depends on what you purport to be selling. As amon says in his/her excellent answer, as long as you're clear with the buyer that copies have already been released under AGPL, you can sell them the remaining rights. The buyer may find them less valuable than if this had not been so, but less valuable isn't valueless.
    – MadHatter ♦
    Apr 28, 2019 at 6:54

2 Answers 2

Reset to default
7

If you are the sole copyright holder you can do with it as you wish, and issue multiple non-exclusive licenses at the same time. For example, you can license it to the public under the AGPL and license it to some client under a commercial license.

  • When issuing a commercial license I would remove all AGPL license headers.
  • There is no need to disclose to the client that you have licensed the software to the public as well: the client's license stands on its own. But it might be helpful to link to the public version anyway.
  • There is no need for a workaround like licensing the software to yourself or to the client under the MIT.

This stops being simple if you are not the sole copyright holder, or if you want to issue an exclusive license or transfer your copyright.

If you received outside contributions under the AGPL you are bound by that license as well, and would not be able to provide commercial licenses for versions including the third party contribution. The solution is to not take outside contributions, or to only accept contributions under a Contributor Licensing Agreement that gives you the necessary rights. CLAs and Cathedral-style development are frowned upon by the open source community because it gives you all the power over the project.

If you have licensed the software to the public under the AGPL you can no longer issue exclusive licenses (“sell” the software). However, you can still sell your right to issue more licenses in the future. So people who received the software under the AGPL will continue to enjoy their license. If you want to transfer your copyright, the same problem arises: this won't cancel existing licenses. The new copyright holder must be made aware of existing licenses.

Improve this answer
3
  • +1 from me, except "If you have licensed the software to the public under the AGPL you can no longer issue exclusive licenses (“sell” the software)". Why not?
    – MadHatter ♦
    Apr 27, 2019 at 16:34
  • 2
    @MadHatter You can't issue exclusive and non-exclusive licenses in parallel for the same rights, for example the right to make copies. Perhaps I should clarify that I don't mean selling licenses, but selling the entire project with all associated rights.
    – amon
    Apr 27, 2019 at 17:39
  • 1
    Clarification would certainly help. I'm beginning to suspect that we agree, but I'm getting hung up on the purported equivalence of the terms exclusive licence and sell the software, the second of which isn't a very precise term.
    – MadHatter ♦
    Apr 28, 2019 at 6:51
3

Beside the good legality-oriented answer above, there is also another facet to the issue: why does someone want to buy your software, especially if a FOSS equivalent exists? This is not a simple question, and history shows that many projects that wanted to attract community by being open and having a value-added version that is closed and for sale, brought upon themselves frown from the community ("are we your free lab rats?") quite vocally, not sure about the commercial side (they are usually under NDA and quiet, or otherwise not as socially active).

I am not really aware of projects that would provide as a FOSS or sold "closed-source" variant the exact same codebase, but this is logically just a first-step subset of having a closed commercial value-added product, or many such in case of customizations per customer's needs. Note that "closed" is not a requirement for "commercial" - based on your written agreement, the customer can effectively sponsor a feature they need and you still have it in the open. On the up-side, if their feature is exposed to the public and eventually someone improves it or fixes bugs, the original "sponsors" also benefit like anyone else in the community. Conversely, even if someone pays for development of their new tool, or buy/license the use of one you made earlier, they may have or not have access to its sources - it is all discussed in the contract you would have.

This brings to the "why buy?" question. From what I've seen over the years, major reasons include:

  • indemnification - someone to blame in case of errors, others' copyrights and license violation claims, etc.

  • support the author - hoping for more goodies to come out of this source :)

  • support the client - a customer can not/does not want to burden themselves with builds and modifications of your open source codebase, it is just not their business. If something does not work or something they need is missing, it is your job (as a proven expert in the area) to make it happen. Often for an added premium, depending on the agreement, though some things can be part of the original sale (e.g. N-year warranty coming with the license, or right to upgrade to any release of same X major version while you iterate X.Y.Z, etc.)

  • really private "forks" with customizations and features needed by this customer, and unknown to their competitors. Even if they did not actually change anything, with your or others' help, nobody really knows, adding to the "muddiness in the water" as a protective scheme from peering eyes (what do they use? where are they heading? is this a really used building block or something just bought to mislead "spies"?)...

In fact, there are quite a few projects out there licensed very permissively (e.g. with a MIT License, or BSD, or indeed one of Apache ones) so effectively anyone can do anything with the sources with few constraints (e.g. embed into their proprietary codebase and just mention that your work was used). Sometimes they are "one-man shows", sometimes large industries like the Jenkins core and plugin community, or the *BSD and illumos OS ecosystems, which actively intend and help to give the code away for any use (or some extent thereof), and the people in community make money by consulting, maintaining, customizing, etc. for the willingly paying users. Or they are employed by such users. Or they make it for the fun of it in the afterhours and just want to see their work spread and be used (well... TBH "seeing" is not that easy when people don't even have to tell you).

While "forks" of such projects are not required by license (like in GPL-licensed projects) to open the sources or commit back to upstream, this still happens actively in practice if only as a way to easily synchronize your fork from the upstreams eventually, have your changes revised by more experts, and maintained by someone else in the long run (non-regression as new features are added in upstream).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.