Hacker News Reader

Comment by CuriousCosmic | Hacker News Reader

I feel like fair source exists as a concept mainly because of fearmongering about free software and copyleft licenses. There is little reason projects can't dual license a copyleft license like the GPLv3 or AGPLv3 with a proprietary license.

The problem clearly isn't that the source is available but rather that companies don't feel like they can monetize their products in an open source ecosystem.

However frustratingly these same companies avoid copyleft licenses that would give them that exact ability to effectively monetize (via a dual license) without unduly limiting users rights to use the main version of the product.

View on HN

That’s what I think as well. They are beating around the bush, everyone inventing their own license types. If I see some unknown license, I will assume it’s a trap and stay away. I don’t have lawyers on retainer to interpret new license types for me.

GPL and AGPL are already there, I know what they are and the intention is clear. And like you said, if they want to dual license it, they still can.

AGPL or other copyleft licences don't stop amazon taking "your" product and hosting it for less than your own hosted offering as they don't have to pay the developers.

"Then it shouldn't be open source" - Yes, true and I agree. But source available, with a bit of a community in github/discord and opportunity to host the code yourself free for small use cases, read the code and raise PRs is WAY BETTER than a fully closed source product. How do we standardise that in a similar way we have done with open source licenses?

> AGPL or other copyleft licences don't stop amazon taking "your" product and hosting it for less than your own hosted offering as they don't have to pay the developers.

It doesn't but I don't think I've seen Amazon being cheaper than other hosting options, especially after IO costs.

What AGPL does stop is Amazon writing improvements, extensions, and integrations for your product and then refusing to make them public in a way they can be upstreamed. That's the bigger issue.

Competing on hosting price or on maintenance/support contracts against Amazon generally is going to favor the smaller party because of the AWS tax. Competing against a city's worth of engineers improving a closed source downstream of your product however is going to be a losing battle. AGPL fixes that.

> Competing on hosting price or on maintenance/support contracts against Amazon generally is going to favor the smaller party because of the AWS tax.

This is exactly backwards, because of how corporate procurement works.

Large companies--the ones with money--have a whole process around working with new vendors. It can take months to setup. A security review, audit, and legal are likely to be involved.

Or, they all already have a contract with amazon and can start using the Amazon service providing X immediately.

From CTO to audit, risk, accounting, and compliance, everyone's life is easier if they use one vendor for everything, rather than 10.

That may be true but that's a very different discussion than discussion on competing over cost.

Larger companies are willing to eat a higher cost for the sake of bureaucratic and logistic simplicity.

For the purposes of the point I was making and this discussion it doesn't really matter if it's market dominance or cost.

The point is big established vendor free-riding on the work a smaller company has done, potentially extinguishing or significantly damaging it and by extention the future of the project.

Of course that can be problematic still but I don't see how they can extinguish the founding company when you are working with a license like the AGPL (with proprietary dual licensing). They are still the upstream and "parasitic downstreams" have very limited opportunities to build trenches with such a strong copyleft in play.

The upstream can provide:

- Hosting (as mentioned before) or assisting in managing colocated infra.

- Proprietary Licensure for more permissive uses (as mentioned before).

- Support/Security contracts for LTS/Enterprise releases.

- Bug & Feature Bounties for priority changes (or a "hire our engineer" type system).

- Contracting and consulting services for companies building on top of their product.

That's just naming a few but there are plenty of ways to build out a reliable income base for a popular open source product as long as you pick the right licensing early on.

Why would you need

Hosting, Deployment help, LTS release

When you are buying a "one click" aws managed service?

Are feature or bug bounties even applicable if you have to wait an unknown amount of time for it to reach you via AWS?

I'm merely suggesting THAT copyleft doesn't provide you any protection here and WHY that is potentially problematic.

> Why would you need Hosting, Deployment help, LTS release When you are buying a "one click" aws managed service?

You wouldn't however I was listing them for completeness-sake because they are common strategies employed by FOSS maintainer companies and there's still a market for them outside of the AWS world.

> Are feature or bug bounties even applicable if you have to wait an unknown amount of time for it to reach you via AWS?

That can actually end up being a selling point for moving off the AWS version. If you can effectively "advertise" that and a company really needs a specific feature for their product, that might give them the justification to jump ship to the non-AWS version of the product.

> I'm merely suggesting THAT copyleft doesn't provide you any protection here and WHY that is potentially problematic.

Oh for sure. However I would maybe say that it offers limited protection here (mainly offering protection in other ways) rather than none at all. And that can definitely be problematic no doubt but nowadays I think companies are a lot more hesitant on blindly lumping everything onto AWS compared to 5 or 10 years ago so I'd like to believe that AWS' authority in deciding what is and isn't a viable product is declining in the space.

They are indeed beating around the bush.

What the end goal of these so-called opensource companies want is to have you use their "free" demo, but when you get slightly big and is somewhat locked in, or need some feature considered enterprise (coz you got bigger or have revenue), they extract a partial income stream off you.

This revenue model isn't bad per se, but why not just be upfront about it?

Look at unreal engine - their license explicitly states this. You give them some % of your revenue if it reaches $1 million or something like that. Why can't this be more normalized?

Couldn't agree more, I'd love to see a range of standard licences for this business model, in a similar way to what we have with MIT, GPL etc.

This business model is still massively preferable to fully closed source in my view.

It would be nice to see a standardised set of proprietary licenses that you can easily dual license a copyleft project with.

Given the way that SPDX is set up, I imagine the ideal way to do it would be to create some standard proprietary licenses and then add exceptions for "small" users that don't want to use the copyleft license and would eventually like to get big.

i.e.

- Commercial-Royalties-1pct

- Commercial-Royalties-5pct

- Commercial-Royalties-10pct

- Commercial-Royalties-Negotiable

- Commercial-Seats-Negotiable

with the following optional exceptions

- Under-100k-USD-Revenue

- Under-1M-USD-Revenue

- Under-5M-USD-Revenue

- Under-10M-USD-Revenue

There's a certain amount of inflexibility that comes from trying to standardise license terms in a way that's compatible with SPDX but maybe an extension to SPDX in the future might improve that and allow you to specify certain terms on licenses more than just basic exceptions.

Love the idea, but for unreal engine 1% royalty is fair, you've built your entire product on it.

But what about 1% of revenue for a UX libary or database product from uber?

I'd say that the old elastic licence is great to standardise and so is the 0.5%, 1%, 1.5% or 2%; over a Million, 5 Million or 10 Million.

Yeah you could definitely do smaller royalty rates or a step up fee schedule but I know SPDX isn't too keen on people dumping a thousand licenses at their feet to include and until you can easily plug in custom license parameters, I'm not sure if there is a better approach without absolutely blowing up the SBOM with custom licensure.

i mean, surely you can have tweak the license (i.e., have the wording be a "variable" which is set at the point of agreement).

It doesn't have to always be at 1%.

Ehh that's kind of the problem with using a SPDX license tag.

You could have a "negotiable" license as well but it becomes quickly non-trivial to document what the negotiated terms are in your SBOM.

Reply on news.ycombinator.com