0

So I am making this library and I wish to monetize it, I got my first client for it and I am already rolling a product made with it, yet I don't have a license yet.

The thing more than just a library is an entire toolbox, includes a lot of server code, client code, and toolkits to build and deploy the application, and interaction with other libraries (mainly MIT), but also proprietary APIs (this is allowed in their licenses, API keys needed, so that's a non-issue).

My purpose is:

  1. If you make something with it and (both client and server) are opensource I don't care.
  2. If you modify the source library it must be on the same opensource terms.
  3. Assuming business with competition aren't interested in making their own code opensource and GPL (as anyone else can then copy them) these will need to buy a proprietary enabled license from me (the copyright holder).
  4. If you are a small business/startup and have 0 money but also don't wish to make your code opensource then you can get a free proprietary license for a limited number of users.
  5. If you are a business that wants to use the library to develop products for others, you can do so freely, however to make a closed source product for another person requires either the free proprietary enabled license (same terms as #4) or the paid proprietary enabled license (same terms as #3)

I am trying to achieve some balance here.

What about GPLv3 GPLv2 and AGPLv2 would they work too?... I prefer less restrictive as long as they give advantages to the purpose, I want to create value, make something useful, but I have to eat too.

1 Answer 1

2

This looks like the well-known and perfectly respectable dual-licensing model, with the small wrinkle that there are two proprietary licences: one zero-cost but usage-limited, and one paid-for and usage-unlimited. Dual-licensing models are well-known and well-understood in the free and proprietary software worlds; IANAL/IANYL, but I can't see any problems with offering your software like this.

For the free licence, GPLv2, GPLv3, and AGPLv2 are all suitable; all will give freedom to users who get copies of derived works based on your software, and AGPL will in addition give freedom to users who interact with such software over a network. I'd be inclined to go AGPLv3 in that case, but it's your software, so it's your call.

The major wrinkle of all dual-licensing schemes is that you can't accept contributions unless you get clear permission from the contributor(s) to relicense their code on the same terms. So if you're going to accept contributions from the community, you'll need a clear and unambiguous CLA in place from each contributor before you merge (and preferably before you even examine) his/her contribution.

3
  • I imagined that, what advantages do I get for agpl over gpl?... my library does not produce output on its own, it has to be bundled to be useful; it's more akin to something like nginx, where you need to put stuff in it.
    – Onza
    Oct 16, 2020 at 16:50
  • 1
    If other applications such as web servers are linked to your GPL/AGPL library, they, too, would need to be under the same licence. AGPL would give an advantage to users of network-accessible applications like web servers, as those users, too, would be entitled to request, modify, and redistribute source code.
    – MadHatter
    Oct 16, 2020 at 20:32
  • Alright got it. Thanks
    – Onza
    Oct 17, 2020 at 0:52

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.