[Barrin92]

>If they don't like it, they shouldn't have licensed their software under a free software license

They or anyone else are also free to relicense their project, there's nothing wrong with it at all and anything under the old license is still what it was before.

It seems kinda strange to demand that someone operate under some license in perpetuity, there is no such rule. Licensing questions don't stop after the inception of a project.

[AmericanChopper]

The lessons that some contributors (myself included) will learn from this, is that it’s now a common bait and switch to build your product with open source contributions, and then relicense it when it’s time to monetise. I used to talk most of my employers into letting me bug fix open source projects that they were having issues with, now I just talk them into maintaining their own forks. The open source “freemium” business model is very clearly a scam at this point.

I also personally can’t stand Elastic, because they charge enterprise rates for support, and then offer open source level support. You’ll come across a show stopping issue, and the support you’ll get is most commonly “why are even trying to do this?”, or “please refer to this issue that’s been stale since 2016”.

[pabs3]

There are lots of open source projects that aren't bait and switch, like the Linux kernel, or Python. So I would encourage you to reconsider a blanket fork-everything policy and at least contribute to the projects that aren't backed by VC-funded companies and instead have a diverse community of contributors with multiple copyright holders.

[AmericanChopper]

Yeah I should have been more specific. I’m just whining about the open source as a business model type of projects.

My general approach has been, when I’m capable and have the time to, to fix any issues or obvious feature deficiencies that I come across in open source projects that I use. I still do that, but I now only contribute my changes back to projects that seem more trustworthy.

[pabs3]

I wonder what criteria you apply to determine the trustworthiness of a project. For me, signing a CLA or otherwise not using inbound=outbound licensing is a major one, as well as any project backed by a company with VC funding. Any project backed by a single organisation instead of a group of people from lots of different organisations is a red flag, with some exceptions for long-term known-trustworthy non-profits.

None of that helps with a situation like Audacity/MuseCore though, if developers are willing to sell out their project copyrights, that isn't something that you can really protect against, except maybe discussing people's opinions on that openly.

The other issue with withholding changes from upstream is the potentially infinite cost of updating your changes as the project evolves, things like git-imerge, mergify or git-mergify-rebase can reduce that burden by letting you do incremental rebases/merges though. Normally I don't contribute to projects with a CLA assigning extra rights to corporations over the license, but I've been considering signing one just to drop the maintenance burden.

https://github.com/mhagger/git-imerge https://github.com/brooksdavis/mergify https://github.com/CTSRD-CHERI/git-mergify-rebase

[AmericanChopper]

That’s pretty much the criteria I use. At my most recent job I left behind a Telegraf fork after running in to the Influx CLA.

But the more important criteria is deciding what changes are feasible to support with a fork. The projects that I find to be most suspect typically come with an enterprise support license, and if you’re struggling to get your issues fixed with one of them, then the best long term solution is usually to abandon the product. Forking for a bug fix would typically be a temporary solution, and hopefully the first merge conflict you run into is the vendor actually fixing the issue, otherwise you can take your time to find a product that offers better value for money.

There’s lots of things I don’t especially like about the large enterprise workplace, but I really detest vendors that fleece them with high price, low quality products/services.

[ixs]

I fear you might underestimate the maintenance costs of forking.

A nice anecdote I heard a long time ago was comparing the approach to custom engineering between SuSE and Red Hat.

SuSE was always very happy to do custom engineering for paying customers and developed and shipped these features in their Linux Distribution. Specifically I am thinking of some interesting features done in the Kernel. At that point, SuSE received money for the engineering work but now had the burden of supporting their fork. The functionality code itself was not a problem, but the interfaces to the remaining kernel were a source of churn and pain.

Red Hat did the opposite. They told their customers that they can have whatever is in the upstream Kernel and they will help them upstream the necessary changes. That took markedly longer but the long term maintenance was much less effort because the in-tree code would be updated whenever an API/interface changed.

Canonical also had a tendency to happily fork of whatever project they needed to ship a fancy thing on time (think Netbook UI, think Unity etc.) and then get hit by the long term maintenance burden once upstream diverged.

Both SuSE and Canonical always found themselves in the unenviable position of having to constantly update their code and potentially seeing a competing but conflicting solution being merged upstream.

Carrying a few bugfixes or feature improvements in a local branch of a library is easy at first. But you're essentially creating technical debt which you'll need to pay off on every upstream change, every security fix etc. Most companies see value in developing features for their main application, not in maintaining internal forks of open source libraries.

[manojlds]

Good point on contributors, didn't think of it this way.

[pjmlp]

It is the return of shareware, as developers realised their parents wouldn't pay forever their housing needs.

[reacharavindh]

That is not quite fair is it?

Publicise your work as open source and make hay with the work of open source contributors who thought they were contributing to a truly free and open source project only to find out a couple of years later that their contributions are now locked into a project that locked itself up with a changed license... (I know that their contributions may stay with the license it originally was, but if the total product changes license, who is going to continue an unmaintained fork? )

IMO, it is fair criticism when someone starts off with a liberal license and then changes it when it is time to monetise, or someone else figures out how to monetise it better than the creators. Either be okay with it or not, you can't have it both ways.

[tybit]

No ones demanding they don’t change, they’re just stating that as users they’ll react accordingly.

[erezsh]

You write "accordingly" as if it's obvious what's the correct course of action for a company that's in direct competition with a titan, and any other course of action must disappoint their users.

What would you have them do? Would only their demise appease you?