Ask HN: Adding non-commercial clause to open source license? | Hacker News Reader

Ask HN: Adding non-commercial clause to open source license?

38 pointsfreeloaderz78 comments

Has anyone has released software with an open source license (eg MIT) with an additional "The software is for non-commercial use unless you have purchased a license, sponsor development, contribute something, etc....." clause?

I imagine people will either find something else or just ignore/violate the clause.

Have you tried? How was it taken?

View on HN

Yes, it's been done. No, it's not a good idea. And the result is no longer open-source. I'd strongly advocate not doing that. If you want to make something "shared source" or "source available" (as opposed to open source) it would be better to use an existing, well-known license for that. Microsoft put out a few such licenses years ago[1], maybe consider one of those.

[1]: https://en.wikipedia.org/wiki/Shared_Source_Initiative

"good idea" depends on the goal.

It's a good short-term cash grab, especially if your project has good vanity metrics (they don't magically go away when you relicense) and many users. https://www.indiehackers.com/post/how-to-earn-1-5m-in-revenu... is a case study where an open source project switched to a proprietary license and managed to extract $1.5M

But it definitely burns bridges and arguably gives the project the downsides of proprietary software (fewer contributions, people switching to open source projects) and the downsides of open source software.

It has already been tried - see e.g. the duo of https://paritylicense.com/ + https://prosperitylicense.com/

Just don't call it open source or free software. It's source-available at this point.

That was an interesting rabbit hole, their github owner is https://github.com/licensezero/. I don't think I've seen licensing as a service before (https://fastpathlicense.com/) or connecting a license to a Patron reward tier.

Thanks for sharing, I haven't seen these before. I'm curious what the viewpoint is from other devs are on sw with a license like this? Would you use sw under either of those licenses? (They seem reasonable to me).

I don't really understand what goal you're trying to achieve that the GPL or LGPL couldn't. As a dev, if I see a project using a license I'm unfamiliar with, I'll probably first look elsewhere as I already understand the ins & outs of GPL- and MIT-style licenses, but not whatever this new thing is.

These two licenses in particular are pretty crummy. Define "commercial." When does the 30-day period start? How would my usage be proven one way or the other in court?

No, I wouldn't. Most of what I do requires Free Software licenses or sometimes even GPL compatibility, and such licenses are neither free, open nor GPL compatible. For me, such software wouldn't be much different from proprietary freeware.

So you wouldn't add a test case, new example, or fix a typo in the docs to gain access to an MIT equivalent license?

It's not MIT equivalent. It it was, it could be relicensed.

In many cases it's not even relevant what I would do or not, because such licenses make it not possible to integrate such code in a project under GPL, or to include it in a free distribution.

Looking at these licenses closer, I wonder if Parity could actually be considered free. Seems to my eye like it could be, but IANAL. For practical purposes, I'd probably consider it same as non-free until it's said to be DFSG-compliant. Prosperity sure isn't free though.

Prosperity license seems to be exactly what OP is looking for. Looks like it's had a few big projects use it too, which is promising.

I wish someone would write a software compatible equivalent of Creative Commons CC BY-NC-SA however: https://creativecommons.org/licenses/by-nc-sa/4.0/

Some people have tried, for example https://commonsclause.com/ but it breaks the definition of "open source". With that additional clause it's just "source available". (Some people disagree and call it "open source" anyway.)

"Open source" is an established term, so CC rider in fact breaks it.

Under CC-like conditions the source is accessible, as it is hackable, derivatives are permitted and they are usable. So it is technically "open" in a conventional sense of the word. There are however strings attached, so it's not free or libre. You can't do whatever you want with it, your freedoms are restricted.

On the other hand, it is still more permissive than what's described as "shared source", because the latter doesn't usually allow for changes or even usage.

So there's basically a distinct license category that lies between the "open source" and "shared source". There's no established name for it, but clumping it with "shared source" is not just.

"open source" has largely been transformed by large corporations to mean "dev friendly" but user hostile. This is why Libre or "Free" Software continues to further seperate itself from "Open Source"

The Googles, and Microsoft of the world want developer tools, libraries, frameworks etc to be open but not end user software for which they commercialize.

They also do not want to limit their ability to take an "open source" software and make it a SaaS or PaaS on their cloud.

At this point, "open source" is openly hostile to Free Software

A lot of organizations may behave that way, but open source itself is not hostile to free software. Keep in mind that basically everything that qualifies as free software also qualifies as open source.

Open Source is made up by the organizations that represent Open Source. As such if the Organizations are hostile to Free Software, then Open Source is hostile, you can not separate the 2 like you are attempting

Sure under a technical definition Open Source all Free Software is open source, however not all Open Source software is Free Software.

That is the core of the problem, as we move forward in time, the amount of software that is "Open Source" while not being Free expands, not contracts.

> Open Source is made up by the organizations that represent Open Source. As such if the Organizations are hostile to Free Software, then Open Source is hostile, you can not separate the 2 like you are attempting

In my mind, it's only licenses and the software they're applied to, not organizations, that can be open source or not.

> Sure under a technical definition Open Source all Free Software is open source, however not all Open Source software is Free Software.

Neither category is a subset of the other. For example, SQLite is free software but not open source, because the Free Software Definition includes public domain software, but the Open Source Definition explicitly excludes it. And prior to Perl's adoption of the GPL, it was open source but not free software due to the Artistic License 1.0. Anyway, keep in mind that these examples are really rare, and that the vast majority of programs are either both or neither.

> That is the core of the problem, as we move forward in time, the amount of software that is "Open Source" while not being Free expands, not contracts.

I can't think of any programs in recent times that are open source but not free software. Do you know of any?

> Open Source Definition explicitly excludes [public domain]

Mis-information. The Open Source Definition (https://opensource.org/osd) has no such exclusion. Read it for yourself.

Sorry, I indeed should have said "deliberately" or "intentionally" instead of "explicitly". What I meant was that it's not included, and that not including it was a conscious choice rather than an oversight:

https://opensource.org/node/878 https://opensource.org/faq/#public-domain

Microsoft was fond of this concept before embracing open source. Depending on how one feels about whether Microsoft has abandoned the other two Es, that could be a bad sign, or a ringing endorsement of the "official" definition because even Microsoft lets people use their code under it.

There's a reason that you haven't found any open source licenses that already have such a clause: any license that did would violate the Open Source Definition. The best way to accomplish your goal is to license your code freely to everyone under the AGPLv3, and then sell exceptions to companies that refuse to use that license.

This is the way to go, I feel, unless you have some other way of "guaranteeing" that the source becomes unencumbered when abandoned/the company fails.

Either way you're going to be better served by using existing licenses than trying to roll your own.

You can accomplish this with dual licensing (e.g. GPL and commercial), where the user decides which license to fulfill.

Once upon a time I built a platform to simplify this [1], but it didn’t take off—between the extra mental effort, the impact to growth, and the inability to call it “open source”, I think most authors just prefer the simplicity of MIT.

[1]: https://license.land/

> You can accomplish this with dual licensing (e.g. GPL and commercial), where the user decides which license to fulfill.

This is a good solution, but you have to make ultra-certain that all of your contributors, who may have chosen the GPL, understand that their contributions will be dual-licensed, too. It introduces a barrier to contribution that may be more harmful than good.

I think in these cases to receive contributions you must ask people to sign a CLA that transfers the copyright to the you/project. Otherwise it's not possible to relicense the contributed parts.

> I think in these cases to receive contributions you must ask people to sign a CLA that transfers the copyright to the you/project. Otherwise it's not possible to relicense the contributed parts.

This is a common misunderstanding. A CLA allows relicensing of a contribution, but doesn't require transferring of copyright.

Transferring copyright is only needed if you want to allow changing the terms of licensing unilaterally in the future (for example, you contribute under GPL/proprietary terms today, but the company decides to change the license of your contribution to proprietary-only in the future), and makes suing for license violations a bit simpler (since one entity obviously holds the entire copyright). Technically a copyright assignment could even allow the assignee to sue the assigner for a licensing violation.

In other words, copyright assignment really isn't needed for anything reasonable a company might want to do. Only for things (like reselling the copyright to some other company or making the code proprietary only), that you wouldn't agree to if it was spelled out in a CLA.

I stumbled on multiple initiatives (licensed).

N8n seems to work as a "fair licensed" project, see https://github.com/n8n-io/n8n and their corresponding license initiative https://faircode.io/ .

https://polyformproject.org is another initiative with multiple different (easy to understand) licenses.

You might as well just make it closed source or "source available." Almost all uses are "commercial" in some sense, and including that clause adds too much risk for most reasonable uses (including many uses that you would probably be fine with) and potentially pollutes the pool if your source is then used in another project that is offered with a less restrictive license.

> pollutes the pool if your source is then used in another project that is offered with a less restrictive license

Did not think about that... interesting (unintended) side effect.

Organizations with any kind of license review will immediately decide that this tool is unusable and move on.

Your only options for making a tool that you expect people to use and respect the license are the big FOSS licenses, or have it be unlicensed and sell licenses.

> Organizations with any kind of license review

This is what I expected, I imagine it's unlikely they'd buy a license anyways even if it's cheaper than paying their own devs.

I don't mind commercial use of my software. I do mind having to spend time and effort to answer support questions, feature requests, and incorrect bug reports from commercial companies. Of course, I usually don't know they are from commercial companies (but occasionally I find out at the end after spending several hours). How do other people deal with this?

> How do other people deal with this?

"Thanks for your inquiry/PR/bug report. You can see the current development roadmap/backlog/issue tracker board here (link). If you would like me to prioritize your issue, please consider becoming a sponsor. If you want custom work, I can also offer consulting at the €X/day rate and I can provide a substantial discount if the product of the work is also released under a FOSS-license."

I'm CEO of an open source based startup (robusta.dev for Kubernetes monitoring and troubleshooting) and IMO those limitations are usually a bad idea.

In my experience, most contributors start by playing around with software, then properly using it (often in a commercial setting), and only later on contribute.

What are you trying to accomplish by restricting commercial usage? If you'd like to monetize there are a number of alternative options for that. If you're bitter because people are using your software without contributing, I would suggest just not making it open source then. The ability for anyone to take it and use it is fundamental to FOSS.

It's a mix of all the above, I've written several OSS projects over the past 10 or so years. Recollecting on it, I typically get little value back by releasing it as OSS and license(s) pretty much guarantees this will happen.

If it's not shared at all few can benefit at all. So the goal is to strike a balance.

Are you looking for strategies to monetize on a massive scale (e.g. VC funded, whole company) or a way to monetize small personal projects while keeping them small?

I use Commons Clause [1] tacked onto BSD/MIT licenses for the code that I don't mind sharing, but that I may also turn into commercial projects later on. To date this has never surfaced as an issue. This combo is technically not Open Source as per OSI definition, but it achieves exactly what I am after, which is to let others to see, tinker, hack and adapt the code to their needs, but without making money off the derivatives.

[1] https://commonsclause.com/

Anyone have experience with this? How did it go?

If that can be of any help, we've recently updated the Joplin Server license to a "Personal Use License" which disallows commercial use. It is not open source of course, but allows sharing your work while putting some restrictions.

This license was crowdfunded and anybody is free to reuse its text as a base template:

https://github.com/laurent22/joplin/blob/dev/packages/server...

Also one thing you need to keep in mind, is that if you have such license you'll also need to make sure that anybody who contributes signs a CLA such as this one, otherwise the ownership of the code is not going to be clear:

https://github.com/laurent22/joplin/blob/dev/packages/server...

Thanks for sharing Laurent.

I've been searching for information about this subject for the last few days, as my co-founder and I ponder whether open-source can be a viable option to build our product. As two indie hackers bootstrapping, our goal is to create and monetize a SaaS, but we would like to create an open and future-proof solution.

Use the license to protect your IP, but don't try to accomplish everything with your license.

Use terms of service and marketing to get paid.

Compelling reasons customers pay:

1. To receive a license key that unlocks paid features

2. To receive support and better documentation

3. To take advantage of cloud features

4. To support future development efforts

5. Access to beta branch (early release)

6. To use a hosted version of the software

Wordpress ecosystem is worth looking at. Everything must be GPL and their is a ton of business going on there. Example terms of service [1]

(I am not a lawyer and probably used the wrong terms)

[1] https://theeventscalendar.com/terms/

What's your goal? If you want to prevent people from profiting off your work, then adding non-commercial language is the appropriate thing to do. "Open Source" isn't a trademarked term. You can legally use it to describe your non-commercial software, but you will face criticism from those who strictly go by the OSI definition. Alternately, if being OSI approved matters to you, then consider releasing your software under a viral, copyleft license like the AGPL and then sell closed source licenses.

The goal is to get some form of value back for sharing it... from those who otherwise wouldn't contribute (as a few do already). Even if seemingly small, it's better than nothing.

I'd recommend you explore what other projects are doing for creative solutions. For instance consider Slint, a UI toolkit, offers their software under a viral copyleft license, a paid-for closed source license, and an "ambassador" license [1] which allows the code to be used in closed source software for free, but with the requirement that the Slint developers can use the derived product and its logo in marketing material for free.

[1] https://slint-ui.com/ambassador-program.html

As others have said "non-commercial use only" means "not open source". But ignoring that for the moment, what does "non-commercial" even mean? Is the license violated if the software is used on a website that has ads? Can a for-profit company use it for any purpose? Can a self-employed consultant use it to assist with their work?

In academia there's a lot of "for research purposes only, get a license otherwise" software releases. Again, the line for what is allowed and what isn't is very vague.

It means if you're scared enough by the intentional vagueness of the term, either somehow contribute to fulfill the clause or don't use the software. Perhaps that's not how it would be interpreted, IDK, I'm not a lawyer.

Is fixing a typo in the docs enough? What about bugs reports? These are useful tasks for a open source project.

You may get contribution-spam fixing inexistent errors, just to fulfill the clause.

If developer X is working in company Y and a year later X changes to company Z, who can use the software Y or Z? What happens if X dies? What happens if Y goes bankrupt and W buys all the assets?

I agree it's vague... you could say for whatever the contributor(s) decide to merge but in any event it seems easy to fulfill the cause, especially since projects need continual maintainence.

At least it leaves some leverage in the hands of the authors/contributors against flat out freeloading. Normal MIT is essentially no strings attached.

If you don't want freeloading from big companies, why not simply using GPL or AGPL, and offer the possibility of dual-licensing?

It's likely I misunderstand but using the GPL essentially prevents contributing or you lose the ability to dual license (without a CLA)?

The intent of the clause is to encourage both, if you contribute, you can do whatever but maybe it doesn't work that way.

I think your understanding is correct, but I don't see how asking for a CLA is too much of a problem. It's at least more straightforward than whatever legal spaghetti you'd be getting into just to find something that fits your definition of "fair".

I'm not an expert or anything, but you could consider making the "community edition" open source but then all the components used to better integrate with large organizations closed source (e.g., SSO, team/group management, white labeling, high availability deployment tooling, or any other features that are only relevant to companies doing large scale projects).

You could also make support contracts and uptime guarantees part of a paid package.

Of course, if you're just making a little utility, none of this applies.

Aside; Cardinal, a VCV Rack wrapper, compiles in a bunch of modules, and a lot of care has being taken to avoid certain software and asset licences, partly so there are no problems with distros creating a binary package https://github.com/DISTRHO/Cardinal/blob/main/docs/LICENSES....

maybe take a look at Business Source License?

faq: https://mariadb.com/bsl-faq-adopting/

the license: https://spdx.org/licenses/BUSL-1.1.html

but keep in mind no license can protect you from misbehaviour. A license is worth nothing if you don't have the resources to fight in court

> but keep in mind no license can protect you from misbehaviour

Agree. I've had this happen with my GPL sw. On a side note, I think github's copilot is a disservice to all developers in this regard as it effectively throws developers under the bus.

You also get the situation where you're not protected from dishonest people, but honest people get discouraged from doing anything with your software because of the same clauses that the dishonest people just ignore anyway.

i've had possibly hundreds of GPL violations done to my repositories

most of them weren't deliberate

as a software developer i know what MIT, GNU and BSL are but most people from the internet don't and they don't bother to look up

i'm pretty sure large companies wouldn't even touch copilot with a 10-foot pole

And what's your end goal? Why not just make commercial software? Or just make open-source software and sell a service or extra features?

> contribute something

Sure, let me fix that typo in your readme. Thanks for the perpetual commercial use license!

But the typo gets fixed... which is better than the normal MIT license where it doesnt.

How much FOSS software do you rely on that has similar terms?

IME the GPL is extremely effective against commercial abuse of FOSS. I don't know what advantage this license would have since you'd need to prevent the people you're granting the license to from changing it in derivative works (otherwise they could just re license it as MIT again.)

You're getting downvoted but this really is a great point. People tend to avoid GPL in commercial settings. What blocks other people from using GPL on the commercial side is the "share alike" aspects of it, but it's still open source because commercial use is still allowed.

> you'd need to prevent the people you're granting the license to from changing it in derivative works

No you don't need to. People cannot change the license of code they don't own nilly-willy, only the owner(s) of code can (which can get hairy when a codebase has multiple owners).

However a license can allow sublicensing, aka sharing the code or software under a different license, but this right must be explicitly granted by the license (or by the code owner directly), and they may be conditions attached (such as attribution)

MIT:

"[...] Permission is hereby granted,[...] to use, copy, modify, merge, publish, distribute, sublicense, [...] subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

GPL:

"[...] You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License."

So the MIT license grants you the right to redistribute the code under GPL (under attribution condition), but GPL does not grant you the right to redistribute the code under MIT.

(Note that all of this applies to redistributing the code or the software, not about your own internal use of the code or the software)

> IME the GPL is extremely effective against commercial abuse of FOSS.

There do exist people who consider the usage of open source software for cloud services without providing the derived source code also to be commercial abuse. To prevent this usage scenario is what the AGPL license was made for.

The GPL doesn’t prevent anyone from using software for commercial purposes.

The OP is trying to prohibit commercial use, which isn’t a feature nor even a goal of the GPL.

The GPL doesn't explicitly forbid commercial use, but as /u/tedivm points out, it often has the effect of at least strongly discouraging commercial use. That may actually be enough for what the parent poster wants. Or not... but it's worth talking about.

I don't think that's remotely true anymore, especially in a SaaS world. Some fairly big companies use a lot of Linux, for instance...

Yeah, AGPL is the thing you want now to dissuade commercial use in SaaS.

> Yeah, AGPL is the thing you want now to dissuade commercial use in SaaS.

The thing is, AGPL allows commercial use just fine, it only disallows proprietary use.

The fact that companies are dissuaded from making commercial use by being prevented from putting a proprietary moat around the software is really an indictment of those companies.

Heck, you can even make AGPL software a bit more friendly for commercial enhancements if you want by granting an exception for plugins the way some GPL software does, but those same companies would probably still be dissuaded.

Linux was sort of always the one big exception to that though. But you have a fair point that the SaaS world has changed the dynamic somewhat. That said, I don't think it's changed it that much.

> otherwise they could just re license it as MIT again

Doesn't the first clause of the MIT license prevent this?

The GPL prevents it actually (I made a sibling comment with some details)

i would suggest going through "open source vs foss" licensing philosphy. that said, i suppose SSPL does what you want. its not "open source" by definition because its not in the list but foss people would agree its the evolution of AGPL.

I don't think FOSS people would agree on that at all.

why? on the evolution of agpl or open source vs foss?

how is SSPL different from AGPL?

The AGPL requires that you make the program's source code available to anyone who uses it, even if they use it by accessing it remotely rather than by you giving them a copy of the binaries. The SSPL extends that requirement to include the source code of every other program at all involved with the system hosting the software. For example, if you use a closed-source program to back up the data on a server, you may not use that server to host any SSPL software for third parties.

in your answer, where do you think i made a mistake?

the user says >I don't think FOSS people would agree on that at all.

what did i say wrong?

I don't think you made any mistake or said anything wrong in that post. I was answering your question "how is SSPL different from AGPL?".

Reply on news.ycombinator.com