Seeking community suggestion for licensing

I have been making a storage library, rdms, written purely in Rust.

After 2 years of prototyping and development, it is now maturing into usable state. And I want to open-source the project, which is where I seek community suggestion. I will state my intentions here:

  • The project shall be distributed as library, not as application.
  • I want the source code for this project to be available to anyone for inspection, review without any constraint or conditions.
  • I have no intention of monetisation when the project is used for non-commercial purpose.

Pretty sure I am not the first person to reach here. Would love to here your thoughts.

It sounds like you currently have the AGPL license. This certainly allows inspection and such. As for commercial use, the license allows it as long as they tell users about it and publish any changes they've made in the version they use.

I'm not quite familiar with how infectious the license is wrt. code that uses the library.

1 Like

That means, you must exclude licenses that allow commercial use. If someone wants to use the library in a commercial way, they'll have to contact you and get another license from you, that allows commercial use.

While not specifically made for source code, this is the closest to what you want, I could think of:

That said, I am by no means a copyright expert, so make sure you read the license carefully and double-check, if it applies to your needs.

1 Like

Might be off topic, but why not be commercial friendly?
if you are limiting yourself to free apps, you are limiting the exposure and adoption of your library.
So ask yourself, what is your goal? what are you trying to do with the library? help open source only? monetize for commercial (that would require support from your end)? or are you trying to make an impact which is much broader.
Even open source foundations like apache will not use open source libraries that are not commercial friendly (those with viral licenses like GPL, LGPL, ....).

If you want to retain some rights, i think apache 2 license is the most common.
but it does give away free usage for commercial use which doesn't seem like what you want.

1 Like

In case you aren't familiar with it, the API Guidelines have some notes on licensing that might be good to look at.


I would definitely like maximum-compatibility and maximum-reach.

Well, if let us say I am picking Apache-2.0/MIT license which gives maximum compatibility and commercial friendly, is there a way to monetize the project ?

Note that the source base is already > 25K lines of code and I expect it to grow to the tune of 50K-100K lines of code. Developing/maintaining/improving a large source base is obviuosly not sustainable without generating revenue.

Any ideas ?

1 Like

The typical way of monetizing fully Open Source Software is offering paid support contracts, though the exact method of doing such varies.

It's understood that free software is provided AS-IS. Issues can be created on the tracker, if enabled, but will be gotten to on the maintainers' time and schedule, and prioritized based on the maintainers' interest.

A simple way monetizing that relationship is to accept some form of payment to prioritize issues and support, though you do need to be careful not to let it appear as "give me money to control the project's direction."

That, plus companies actually can be quite easily talked into buying support contracts, because paying for guaranteed support makes the use of a product feel more secure. You just have to make it simple for the company to do so.

The people who use your work probably would love to support it with company funds, you just mainly have to make it easy and obvious to appeal to those who have power over the budget to give you that contract.

It's a lot easier for a company to expense a $10K support contact than to send of a $20 donation to an OSS dev.

Side note: if you're interested in OSS monetization, you should probably seek out some of the projects where that's the whole idea, such as TideLift or OpenCollective. There's one that brands itself as a "license vending machine" but I can't find the name right now.


Dual-licensing as AGPL + commercial licensing should work well. Be careful about taking contributions — you'll have to clarify that contributors either assign copyright to you or license contributions to you under a compatible license, which might be one of the common permissive licenses, so your product will be (AGPL + permissive) or (commercial + permissive).

1 Like

There's been a few cases where software authors licensed their work under a permissive licenses to get reach, and later regretted it when a faceless corporation made a million bucks on it simply by calling it an Enterprise product, giving $0 back — exactly as permitted by the permissive license.

With permissive software there's unwritten expectation to get something back, but the reality is that all you get back may be just endless support requests, and you'll be de-facto working for free for a for-profit corporation.


@kornel, like i wrote, the question at the end is what is your goal.
if its to make money, ok. nothing wrong with that at all. we gotta get paid :slight_smile:
If its to make a broader impact, that would require permissive license.

I'm sure there are, but I'm not personally, familiar with an open source project, developed by a single individual without funding that some company just took and made millions from it and gave 0 back.
its possible, but....

bottom line, what is your goal with the project and not how much you invested in it.

my goal with my open source projects is simple: fun.
i love coding and love learning.
if people use it, its very rewarding but that's just a bonus.

1 Like

There seem to be one or two cases, like

Looks like following options might be suitable.

a. CC-BY-ND, reflects my true intention. But I don't see many serious open-source project using this license. May be it does limit user adoption.

b. MIT/Apache2.0, though recommended by Rust ecosystem, like @kornel hints, I might end up changing to protective license or abandon the project if not sustainable.

c. AGPL + commercial, looks like a safe bet, for all parties - myself, contributors and users. At least there won't be any surprises for users.

Most likely it is going to be (c).

Derived work

Btw, while reading up on licenses. I came across something called "derived work". In rdms I am implementing algorithms described in research papers. Will this be treated as derived work ?

Most likely it is going to be (c).

Just be aware that open source projects using your project will have to be GPL as well.
Most open source projects are not.
Good/Bad/Whatever is not the point, just that you are aware of this.

Will this be treated as derived work ?

ya, but if i'm not wrong the GPL license talks about derived work from the licensed work. meaning derived work from your project. if you are using some algo in some paper, i'm guessing that its not licensed and its free to use.

by the way, no advice in this forum can be considered legal advice you know. its from personal knowledge and experience and not law studies :slight_smile:

1 Like

If you're planing to monetize on it, why aren't you consulting a lawyer? I understand there are those that have specialized in those kind of questions, and you'd probably be off much better than soliciting advice in an internet forum (with all due respect :slight_smile: ). I'm have no idea about the fees involved, but I'd consider that an investment of the future of your product.


That's License Zero, I think. They have two licenses:

  • Parity, which only allows for-profit derivatives if they're shared under a compatible license (share-alike).
  • Prosperity, which only allows non-commercial derivatives.

The 'vending machine' part is that if you want to use a Parity-licensed project without sharing source, or if you want to use a Prosperity-licensed project in a commercial project, you can buy a private license to do so through the License Zero website or CLI, with most of the proceeds going to the developer. It's an interesting model, and I've seen a few Rust projects using it already :slight_smile:


These licenses are all about copyright, and copyright applies to actual work, not concepts. It's very different from patents.

So implementing an algorithm from a paper is your original work, unless you literally copy'n'pasted code from the paper.

Copyright also applies only to copyrightable work, which must be non-trivial. For example, someone contributing a typo fix to your project doesn't get to claim copyright, because fixing a typo is not a creative work.


You really have to ask yourself what you want to do. Do you want to make money out of your project? Do you want to provide useful software for the benefit of mankind and make it available to the maximum audience?

I suspect that monetizing this will be all but impossible. Unless it has some spectacularly compelling functionality. There are many "storage" solutions out there already, commercial and otherwise.

I also suspect that the AGPL will make it unusable by most of the Rust community that expect open source software to build into their projects.

In short option c) ensures the least take up of your project.

You might want to take inspiration from those whose projects do provide code as open source but also commercialize them. For example:

CockroachDB :


MariaDB :


exactly my point!

1 Like

And a very good point it is.

Looking into Qt, it is GPL style (viral!) + talk-to-me for non GPL cases.
This will be the least uptake by those who don't respect developer's work, of course.

Non-GPL, like MIT, signals all recruiters that you are not going to bargain for a better pay.

@sagiegurari and @ZiCog , can you guys tell your own internal experience and motives for pushing MIT style licenses. May be you are paid by employer for writing open source, and you are golden? Seriosly.