Hacker News Reader

Comment by mnahkies | Hacker News Reader

What are people's thoughts/experiences about dual licencing?

Eg: is there a clean way to dual license such that hobbyist, and exploratory work (eg: a proof of concept done in a commercial setting) are allowed, but using it in production requires a fee?

If you've done this, has it been successful? Obviously there's been many projects relicense over recent years (terraform, redis, etc) - but it's less clear to me if this is a viable path for new projects starting out, or if it just kills adoption from the beginning.

View on HN

I think it definitely hurts adoption. No hobbyist or experimenter wants to delve into legalities head first by first having to understand the licensing terms of software, whereas permissive licenses like MIT and Apache 2.0 are easily-understood and familiar.

The solution is probably to be more selective what you're open sourcing if you're planning to build a business. And what you open source, you do it under a permissive license so people don't feel limited should they wish to play around with it.

A more restrictive license might be more apt if you don't really want to open source, but you must for regulatory reasons.

Excuse me but as both a hobbyist and commercial software developer I say that the gpl (any version) is quite simple enough. There is no need to go all the way to bsd/mit just to get safety and clarity and freedom from encumberance.

The only people who avoid gpl and talk about mit as being the only safe option, are exactly the people no one should care about. They are the people for whom free isn't free enough, and they must steal even when it's already free.

That is not "adoption" anyone needs to care about.

right but the GPL explicitly allows commercial use, which isn't what the original comment was about ("use in production requires a fee"); i agree with the previous comment that such a license is hard to assess for a hobbyist, but the GPL is not such a license (hence yes it's simple enough)

Even though it's technically allowed, a lot of companies are afraid of it. Not GPL2 - that's used a lot, because tivoization lets them ignore the spirit of it. But they fear GPL3 and AGPL.

You can also just do a crayon license. "All rights reserved, noncommercial use allowed." Nobody's stopping you. If and when Debian wants to ship your package, ask them for proper legal advice about changing it, they have lawyers.

I'm not sure there's a lot of fear of GPLv3 out there. Linus just didn't want to adopt it for Linux.

AGPL is a different matter because companies are unsure of the boundaries between their own proprietary code and any AGPL code they're using.

Companies that make physical products are afraid of GPLv3 because of the anti-tivoization clause. Cloud companies aren't, but they're afraid of the AGPLv3, because of the anti-cloud-tivoization clause.

"The solution is probably to be more selective what you're open sourcing if you're planning to build a business."

Fully agree, FOSS maintainers are - in the grand economic scheme of things - beggars high on altruism. The whole model of FOSS from the position of a non-corporate sponsored developer was already broken and with the advent of AI is now most probably broken beyond-repair. Buy-me-a-coffee with a <0.01% hit rate compared to open feature requests/gh issues on some of the more popular projects out there, all while companies like atlassian - using FOSS to run their business on for free - can charge 50k EUR for a single 1h migration call. Time is the most valuable resource one can waste, something you get to realize once all the mental gymnastics wear off(either by itself or due to less fortunate life situations)

Will hobbyists and experimenters that has no interest in understanding licenses go out of their way to locate specific licensed code, or are they more likely to just ask the AI/agent to cobble together stuff without care of any licenses?

In practice AGPL might achieve that. It does allow commercial use, but a lot of big businesses, especially big tech, will not use it. On the other hand it is a clear, OSI approved, FOSS license.

Well, the language is clear enough. What's not clear are the implications of the language. And, honestly, the sensible default for a lot of companies is just not to go there. And big companies tend not to operate on hopes and prayers to avoid distracting and expensive lawsuits. Without going into details I have enough familiarity with the space to know that a lot of open source-friendly companies either avoid AGPL entirely or discourage its use.

Yes. The clean way is to use the strongest copyleft license you can find, probably AGPL. Even if corporations are technically allowed to use it, they don't want to risk touching it with a three-meter pole. Then you offer to sell them a different license. Hobbyists and OSS folks usually have no issue with AGPL.

Do you have data on that last bit, or just a guess? As a hobbyist and OSS developer I treat AGPL as a rabies infected animal. I may have uses for it, but I'll keep it EXTREMELY segregated from everything else.

But that's the whole point of dual AGPL + commercial licensing.

Sure, but for anything except large companies it has a bootstrapping problem. I'm absolutely not going to use AGPL software in a test one-person trying to sell a service kind of deal. So if it takes off, I'm already on a non-AGPL stack, so why reach out at that point to get a commercial license for software I don't even use?

And hell, even without money involved, I'm not going to make a hobby project with AGPL software either. Not only may I have small parts of the project I've not opensourced, but AGPL is untested in how far the virality goes. Are my backup cronjobs in scope? I certainly don't want to be the test case for this. Even if I win against an AGPL troll, I'll still lose.

If you don't want to give people downstream of you my source code, I'm happy to sell you a commercial license.

This means you have only solved the problem for large companies, and specifically those who have money and who have a functioning procurement system that's developer-driven. Which is a very narrow use case.

Also relevant comment: https://news.ycombinator.com/item?id=49596403

You can also just give people downstream of you my source code, supporting software freedom. Then you can use it for free.

Again, that only works for large companies, and for companies that can exists even if their service is downloadable.

Which fine, you can choose to take that political stance. But that's a stance of "I want to change the world to my liking", not "I want to help the world/people".

Up to you, of course, but I prefer to help not only large companies.

If you are trying to monetize your software, the biggest factor is whether or not your customer trusts you.

MIT and source out on GitHub is the easiest way to build trust. You will find that some people simply "steal" your work in this arrangement, but much like with movie piracy I don't think they ever intended to compensate you or anyone else.

So, we wind up alienating all potential customers because we are so worried about preventing ideological crime.

People will steal your ideas and they will get away with it. The more you react to this in first order terms, the more it will destroy you.

Most money in software is made with support contracts, not the initial sale.

How does MIT build any more trust than a copyleft licence like AGPL? At the very least AGPL stops people "stealing" your work without contributing back their changes?

AGPL does not do anything to force people to contribute their changes back. They have to make the changes available, however that's very different from actually contributing back. It is not hard to make a low quality contribution that the upstream would for very good reason refuse even though it 'works'.

The poster child for this is chromium which is GPL because it has clear and obvious roots in the old KHTML code of 20 some years ago. In theory you can contribute to Google movement and I suppose some people do but realistically Google controls it completely and they will do whatever they want. even though the source is available it is effectively not a contribution back.

By "contribute back" I was referring more generally to the commons.

The chrome example actually proves my point, the KDE project, or anyone for that matter, can take the changes Google made to their code. If KHTML was MIT it's likely that wouldn't be the case

Practically though, there is no difference. The KDE project has lost control over the web browser, even though they started it. It's an all or nothing. They can take all of chrome or they can take nothing. There is no in between. If KDE and Google disagree on the direction of the web browser, Google wins. There is no control. There's no advantage to open source, other than it's free. It may as well be a closed source project for all the good it does.

You can't be stealing what is given away for free. Developers that choose copileft license want to see al changes shared under the same license. Developers that choose permissive want their code to be of use to as many developers as possible for whatever they want to use it for.

Almost no business relationships builds trust based on source code. It's based on whether you deliver what the other side wants.

>MIT and source out on GitHub is the easiest way to build trust. You will find that some people simply "steal" your work in this arrangement, but much like with movie piracy I don't think they ever intended to compensate you or anyone else.

You've chosen the license which allows "stealing", why did you do that if you don't like that? Nobody forced you to do that, I hope.

How can I trust the person who published their code with the strict legal terms, but becomes sad when other people use their code exactly as the author said it could be used?

Every once in a while I read discussions about licenses, and puzzled every time why the author of the software chooses free license when the freedom of copying and distribution is seem to them as pirating. If the license is not suitable for you, why choose it?!

Licenses are about legal possibilities. You're looking for social/moral terms instead if I understood you correctly (something like CoC).

After many years of thinking about this, I have arrived in the exact same place. I think the SQLite team learned this in the early days, and have done very well for themselves, giving away all of their source code for the product itself, free of charge, and then having folks pay for consulting and enhancements, which they remain particularly strong at because of their closed, comprehensive regression test suite.

The usual way I've seen it work is using the AGPL.

AGPL doesn't bar use in commercial production, but the requirements usually scare off any corporate from using it in production.

I like the AGPL but don’t often use it. (I did recently license two coding harnesses I wrote as AGPL.)

A long time ago, I didn’t mind huge tech companies getting rich partially via open source, now I do. In the USA the collusion between government and big tech is starting to smell a little bit like fascism. Sorry, I have only complaints, not any good answers.

>A long time ago, I didn’t mind huge tech companies getting rich partially via open source, now I do.

Is the concern that anybody will be earning money on your software (just that), or that you won't get any money, or that they will earn money and don't give back the code?

If the company earns money and opens the code, is that OK for you?

Just for you and for everyone information, Richard Stallman himself told people not only to sell their own software, but the software written by others as well!

> Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license. If this seems surprising to you, please read on.

https://www.gnu.org/philosophy/selling.html

AGPL, just as all other GPL, does not prohibit selling the software. If you goal is to make your software unsellable, please use your own licensing terms (there's nothing wrong with that!!!)

> Eg: is there a clean way to dual license such that hobbyist, and exploratory work (eg: a proof of concept done in a commercial setting) are allowed, but using it in production requires a fee?

Yes, it's called language. Contracts are nothing but text, so why don't you just write down what you think should be the rules around using your software by other people?

I get the urge of a lot of developers to pick an existing third party license from the shelf, but just as you can write your own code - and are not required to use ready-made libraries/frameworks - you can write your own open source license for your software.

No success yet, but I recently found BUSL - used by Terraform: https://en.wikipedia.org/wiki/Business_Source_License

It stops companies from building high-revenue products for free, while not being as scary as AGPL/LGPL from the business perspective, and completely unrestricted for everyone else (despite not being technically an open-source license).

You might also be interested in the O'Saasy license (https://osaasy.dev/) which is in the similar vein, but simpler.

HashiCorp switched to BUSL license for their products/tools when they already had substantial market share, and they still faced MPL-licensed forks (Terraform -> OpenTofu, Vault -> OpenBao). It will be interesting to see in a few years if those tools notably cut into their share.

I'm not sure a new tool with a BUSL license will get adoption as easily.

Looks nice. Two main differences:

- BUSL is OSI-approved and listed in SPDX, so corporate lawyers won't be scared away by it: https://spdx.org/licenses/BUSL-1.1.html

- With BUSL the restriction is revenue-based. You can still create competing products, but would have to pay a licensing fee.

Good points, the second is very "dual-licensing" in nature. BUSL is certainly the more "mature" option and there's a higher likelihood people came across it in the wild.

> BUSL is OSI-approved

Of course it isn‘t.

I was a bit surprised to read that there was an OSI-approved license with usage restrictions and wondered if I had missed the memo. But you seem to be correct and it's not OSI-approved and therefore is not generally considered to be an open source license.

https://en.wikipedia.org/wiki/Business_Source_License:

  Debian FSG compatible No
  FSF approved          No
  OSI approved          No
  GPL compatible        No
  Copyleft              No

I'm sorry - what I meant to say is that it is listed in the SPDX (https://spdx.org/licenses/BUSL-1.1.html) as a recognized license. The revenue gate means it will never be considered an open-source license by the OSI.

The heat around this particular issue has cooled down a bit and I'm not sure anyone is especially happy with the state of affairs. But questions around AI have sucked a lot of the oxygen from the room for now.

Once you decide on a non-free license, in the FSF sense, in the DFSG sense, and in the open source sense, does the details of the license matter much? You want as many people to pay as possible, and you do not wish for others to compete with you providing this software.

It's pretty much a standard non-free commercial license, which exact wording will matter only to purchasing department of your customers. It will be inconsequential to the broader open source community. Literally thousands of those exist and the specific wording matters very little.

It doesn’t have to be binary. A license like this allows for 99% of the personal and commercial use that a project will ever see, while giving the author leverage over large corporations - which is the main gripe people have. It is not ideal for libraries or things that would be redistributed, but then you have other options.

Some things in life are binary. You either allow people to build new products and businesses on your work or you don't. Would you allow me to extend the product with new features? "It depends" is a form of "no". It is not a position to sustainably work from.

If you frame the licensing space as for either personal or commercial use, perhaps your point of view makes sense, but this is not a useful framing for most people, and it is specifically not something the open source community cares about.

If you wish to keep leverage over others then you do not wish to have them compete with you on the same product. That is a valid position to have, but it is squarely on the non-free part of the licensing spectrum. You don't want to play within the open source community and they don't want to play with you. All anyone owe others is to make that clear.

This is why open source is rapidly becoming obsolete ;) There have been source-available/fair source/whatever-you-name-it approaches before.

They were attacked by OSI zealots every time because it's not real open source. Which is true, but the unsaid - or well, only sometimes mentioned - other half is that these open source enthusiasts would you rather have a bog standard all-rights-reserved commercial licence than a relatively open licence without the four freedoms!

I can't claim to read other people's thoughts, but my hunch is that this happens because it's too "close" to an open source licence so they view it as competition, while they view commercial software as either a straightforward enemy or they don't care about it whatsoever.

The history aside, this approach just makes the open source community more and more irrelevant each day, especially with the advent of "vibecode your own dependencies up". The 4 freedoms come from a place where they were about users, but gigantic corporations have shoehorned themselves into being users, and instead of the community defending against it, they think the freedom to exploit the maintainers' work while contributing nothing back is more important than keeping the commons free and shared. :P

Only siths think in absolutes.

The freedom to host open-source software is more important than contributing back to the original project: it's where the actual value of open source comes from. Would you host your website behind Apache or Nginx if you couldn't just switch providers and keep the same web server? Would you ever pick up Postgres or MySQL if you couldn't actually pay a company to host that for you, knowing that if they screwed up, you could switch to a provider that did it better?

From a pure engineering reliability perspective, coupling your technology choice to your vendor gives that vendor too much leverage (as we've seen with, for example, VMware).

This isn't about defending the big companies at all. It's about defending the right of hosting providers to compete on hosting a variety of software. In the alternative world of entirely commercial licenses, or entirely BUSL-styled licenses, you would be shackled to the specific vendors that happened to create the technology that you wanted to leverage. This is a scenario where the customer invariably loses.

At its core it's a question of control. If I use this library or app, will I be safe? Will I be able to repair it, use it in the future, pay someone to fix it? Will it still be developed in a few years?

FOSS is a great answer to the first few questions, but it fails at the last one. As a user, yes, I would prefer a cloud-protection license, if it means that software will still be developed in a few years time. It's not like I want to use this software to compete with the author, I'm happy not to be allowed to do that.

Well, there's no guarantee that there will be sufficient market in a few years for that software development to continue unless you fork it and do so (or pay to have done) yourself.

> or entirely BUSL-styled licenses

Let's not get everything mixed up here - I singled out BUSL exactly because it does not prevent competing services, especially at small scale. In fact it would encourage small business and individual usage vs big cloud providers. It also has a conversion clause, so worst case scenario you have a slightly outdated MIT-licensed release to pick up from.

The EUPL the author mentions, the AGPL and others are the ones that directly prevent competing services.

That said, indeed it might not be an ideal choice for that kind of cloud-hosted software if you want to maximize adoption.

The AGPL doesn't prevent competing services.

> The EUPL the author mentions, the AGPL and others are the ones that directly prevent competing services.

To support sibling comment: no it doesn't?

But your point about the revenue cut off in the BUSL is worthwhile (assuming we're talking about a licensor that is leveraging the additional use grant). I just disagree that it's a remedy because it basically punishes a business for being successful, by changing the rules upon which it was built. I'd be very curious to hear of anybody who has licensed software under the BUSL and has ended up getting a license from companies that meet those revenue thresholds.

It's worth noting that the BUSL, by default, with no additional use grant, prohibits the use of the software in production. So I actually think you have the two licenses reversed. The BUSL prohibits production use and competing services by default unless an additional use grant is specified and then it is only allowed under the revenue threshold specified in the additional use grant.

The AGPL has no prohibition whatsoever on the deployment of competing services.

It is expected that you use the license with an Additional Use Grant. For example, Hashicorp says:

> You may make production use of the Licensed Work, provided Your use does not include offering the Licensed Work to third parties on a hosted or embedded basis in order to compete with HashiCorp’s paid version(s) of the Licensed Work.

Or, for a revenue threshold:

> You may make production use of the Licensed Work, provided that your use is solely for an application or system developed or operated by an entity (including its affiliates) with total annual gross revenues of less than $10,000,000 USD.

That is the whole point - you can define your own limits for commercial usage, while keeping the rest of the license text unchanged.

The AGPL's "viral" property inhibits competition without prohibiting it - companies are just scared of accidentally becoming liable to publish private software sources. As far as I know, that's the reason it is banned at Google, Apple and other major companies [1].

That didn't stop AWS though, which is why we now have SSPL and the BSL.

[1] https://opensource.google/documentation/reference/using/agpl...

I think we're agreeing, but you seem to be spinning things:

1. BUSL does not allow production use. Additional Use Grant (optional) is necessary to allow this, and is typcially accompanied by a revenue limit, setting a trap for any business that attempts to use it by changing the rules as they become more successful.

2. The AGPL does allow production use, by default, forever, but requires you publish associated source code when providing the service.

Only one of these licenses bans production use, and that's the BUSL. It can be modified to allow it under certain circumstances, but your original statement, that BUSL allows production use and AGPL prohibits it, is exactly reversed.

Yes, you would be allowed to extend the product. There is no 'it depends', the license is quite short and clear. You have to acquire a commercial license once you go over the revenue threshold, that is all.

I find this much simpler to understand than AGPL/LGPL or the linked EUPL.

This framing ignores the fact that many people pick up technologies because they want to be able to switch the vendor that is hosting it for them. If I'm hosting a LAMP stack from some shared hosting provider, it's easy for me to just move to a different hosting provider because all the software is open source and anybody can host it. This falls apart when companies choose the BUSL, which is why it's not considered OSI open source.

Isn't that what Epic, MiniMax, Z.ai, and others are doing, where a license is free for personal use / low revenue projects, but cost a (steep) fee for commercial use? They don't use dual licenses, but rather a tiered license.

You're basically describing open core. It's hard to get the balance right. Give too much away for free and people won't buy your full product. Give too little away and they can't really properly evaluate it.

maybe?

CC-BY-NC-SA-4.0 Creative Commons Attribution Non Commercial Share Alike 4.0 International

Reply on news.ycombinator.com