Hacker News new | ask | show | jobs
by behnamoh 385 days ago
This is why I don't like open sourcing my projects anymore. Someone else with more resources just forks it and makes profits, thinking that merely acknowledging me pays my bills.

For years, ollama didn't acknowledge llama.cpp and r/localllama found it weird until they finally mentioned llama.cpp on their page, but the damage is done: most apps that support local LLMs only support ollama or LM Studio API, not the original llama.cpp.

5 comments

Choose your license well. If you are using a permissive licence (MIT, Apache, BSD, etc...) you are begging for it. If that's what you want (and it may be what you want), go for it, but don't expect it to pay the bills.

If you are using a copyleft license, especially AGPL, you may not get paid either, but you may get valuable contributions in return. It is also a good way to avoid having big companies profit from your work, if that's what you want.

If you want to make money but still want to open source, use a non-free "source available" licence (ex: "non-commercial"). They tend to be unpopular in the open source community and it is probably not the best way to get known.

And then you can have dual-licences, like GPL + commercial. Qt is probably the most popular software using that scheme.

But I don't really understand the people who publish software under a permissive licences and get forked by some tech giant and complain. That's what permissive licenses are for!

From the POV of an indie dev selling closed-source binaries, would a source-available license gain any goodwill in this space? And how would you tackle pricing?
I don't really have a say since I don't buy nor sell software. As a technical guy, I may have an influence, but usually, finance decides and not always the way I'd like.

That being said, I highly value having access to the source code, even under a restrictive license. The source code is the best documentation, it doesn't lie. Also being able to make small changes, recompile with different libraries, etc... but for me, the "documentation" aspect is the most important. I don't do security, but I guess being able to audit the code is a good thing too.

For me, open source goes beyond the "freedom" aspect. Also, AFAIK, most commercial game engines are "source available" too.

I would prefer the BSL with some sort of trial period grant and source available to closed source.

Other nice thing about BSL is it converts to an Open Source license after 3-4 years which addresses the concern “what if the software vendor goes out of business”. You can support it yourself or another vendor can pick it up and support it after that time period.

> But I don't really understand the people who publish software under a permissive licences and get forked by some tech giant and complain

They want to have their cake and eat it.

Licenses only work if it's copyrightable and weights, almost certainly, aren't.

The code would be, but I'm not sure that's much of a barrier.

Even the copyleft licenses need lengthy costly lawsuits to enforce them, so they aren't that useful for many developers who can't afford to pay lawyers for ages.
> This is why I don't like open sourcing my projects anymore. Someone else with more resources just forks it and makes profits, thinking that merely acknowledging me pays my bills.

Then I would submit that you are picking the wrong license. The whole point of the GPL/AGPL family of licenses is to ensure that they can't just do this. They will be required to publish their changes, which benefits the original project (you). It's not a perfect solution, but it helps a great deal. The answer to this problem is not to close up and/or go proprietary.

The GPL family of licenses doesn't say anything about profits, competition, giving back or publishing changes at all, just that downstream users (not the original project) have to get access to the source code. Those users probably won't bother to do that though.
then don't. the point of open source is not to earn money or profit. it's to have the software open so people can inspect it, be inspired by it, trust it, modify it without contacting you and possibly copy it. imagine sharing your idea with the world but not wanting anyone to implement or capitalize on it. it's an impossible ask.

i'm a bald head grey beard, at least in the 90's when we shared software it was for the reasons we outlined, there was no github stars, there was no trying to line a job. it was a true gift and pay it forward sort of thing to the world. it's been almost lost due to money, if you need to earn a living, start a business, get a job and make your open source project a hobby. don't mix them together.

> at least in the 90's when we shared software it was for the reasons we outlined...

With all due respect, that's not how most open source software is today [1]. A lot of CS students on the job market need Github stars or green tiles in case the employers check their page. So many open source projects are done only to boost resumes, not for the reasons you mentioned. Not to mention a lot of projects start as open source to lure users, only to become closed at some point (the notorious langchain is one example).

[1]: with the exception of some huge projects like ffmpeg, llama.cpp, etc.

The MPL 2.0 is a great compromise. it's basically as permissive as the MIT, but the source code must be made available.

https://www.tldrlegal.com/license/mozilla-public-license-2-0...

IIRC, only modifications to the existing code, not all of the source code, for example if you added a proprietary dependency, or a new source code file, that doesn't need publishing.
This is completely within your control:

- If your primary goal is to release open software that stays open, then release under a copyleft license (GPL)

- If your primary goal is to release software for no-strings-attached use (including incorporation into commercial services) then use a permissive license (MIT, BSD, etc.)