LWN: Comments on "The complexity of BUSL transformation"

Free LIBRE includes right to make changes & pass them on

jjs — Fri, 16 Aug 2024 13:48:42 +0000

If someone controls who makes changes to the code, it's not free (libre). I could, theoretically, take MariaDB and fork my own version. I could even do that with Linux (note: in neither case would I recommend ANYONE use my fork - but I could). With BUSL, only the original vendor can do patches. I can't even use the code in production without a license.

IFF patches to the older versions fall under the OLD (GPL at a set date license) does the software become LIBRE. The vendor is free to continue patching, but only if they keep the license GPL does it remain LIBRE. That's the issue here - when exactly does that transformation from BUSL to GPL occur? If the vendor puts in one patch into the old code, does that reset the clock? Or are those patches GPL? And who decides / how is the decision made? From a legal/liability standpoint, it matters.

Note that, for any patches not from the vendor to the GPL version, those patches CANNOT legally be pulled into the latest BUSL version of the code - BUSL does NOT grant the same rights as GPL, and is thus incompatible with it.

The answer to support for FOSS for companies willing to pay is for them to pay for developers of the open source software. There may be foundations (such as The Document Foundation and the Linux Foundation), companies (Canonical, Red Hat, Collabra among others), or pay to individuals. Budget 1/2 what licensing of the proprietary software would cost (heck, even 100%). You get your needs prioritized, you get the software fixes, and you always retain the option to change support vendors.

Forking because upstream refuses to support something the distro cares about

farnz — Thu, 08 Aug 2024 08:29:36 +0000

You also, as alluded to by Berrangé's quote in the article get into a sticky situation if upstream doesn't want to support something downstream supports, and then later upstream decides to make downstream's decision untenable.

Fundamentally, any packaging work you do entails (hopefully temporary) forks to keep the package in line with distro policies; most of these forks are relatively minor (e.g. "fix build on AArch64" when upstream only supports x86-64), but there's always the risk of a major fork (e.g. "port to libfoo 2.0", when upstream vendors libfoo 1.0) that changes the feature set of the package. If upstream then chooses to go a different direction, you're at risk of pain.

For example, if libfoo is a structured data importer, supporting CSV, TSV, JSON, XML, and YAML, and libfoo 2.0 refactors the API and then adds XLSX support, downstream has a problem if upstream decides to port away from libfoo completely to libquux that only supports CSV, TSV, JSON, XML and YAML - you used to introduce XLSX support, and now you've got to take it away.

This is why it's generally frowned upon to package things where upstream isn't willing to work with you to make the forks temporary; if you'd stuck to upstream, you'd have had no change in functionality. If you'd persuaded upstream to accept your port to libfoo 2.0, they'd have planned their move to libquux knowing that they be losing XLSX support; by doing it yourself, you end up in a position where they can legitimately say "we never supported XLSX; you'd have to ask your distro why they added and then removed XLSX support".

unsupported by upstream.

Wol — Wed, 07 Aug 2024 18:40:58 +0000

Unfortunately, I've been dropped into exactly that position by my employer. I wanted to use the Free ScarletDME - my employer has said "no, but we have no problem paying for OpenQM".

And at the end of the day, what customer, *provided they are not surprised*, would object to a major upgrade?

My worry - speaking for myself - is I don't like nasty surprises. If I know support is going to cost me - it is what it is.

Cheers,
Wol

unsupported by upstream.

ballombe — Wed, 07 Aug 2024 11:43:32 +0000

> Or package it as "if you want support you'll have to pay the vendor"?

Not going to work, since the vendor is only going to support the proprietary version which is 4 year ahead.

unsupported by upstream.

spacefrogg — Wed, 07 Aug 2024 11:09:09 +0000

That is all good, but where does that connect to the people having to make the decision to package a program or not? There is an implicit expectation to a distribution that packages software is supported. If you make RH customers pay for the update, do the Fedora users see that, too? It just creates more grounds for a divide amongst users and for coercion. You are actually delivering the examples to make my earlier point.

Open Source

dskoll — Tue, 06 Aug 2024 15:35:27 +0000

Open Source / Free Software is not a business model. It's a philosophy. While a (very) few companies have made a successful business out of pure Open Source software, it's not a good idea to create a license that's a muddled mix of proprietary and free.

Make your licenses proprietary or free. But don't try to mix the two; it won't work. If I were a distro maintainer, I would not touch BUSL-licensed software. The risks are too high.

unsupported by upstream.

Wol — Tue, 06 Aug 2024 15:29:03 +0000

> The alternative is to either fork the open-source version or ignore it altogether.

Or package it as "if you want support you'll have to pay the vendor"?

Given that FLOSS is all about Free *LIBRE*, why does there seem to be so much emphasis in the community on Free *GRATIS*?

Cheers,
Wol

Avoid if possible

Wol — Tue, 06 Aug 2024 15:25:15 +0000

Much as I think this is horribly convoluted, imho the licence should say once a git tag is branched off as an official release, the date of the branch is the "flag day" for going Open Source, and any bug fixes, security fixes, whatever applied to the branch afterwards don't reset that date.

If the promise was "when we release the branch, that sets the date in stone, and we promise to cherry-pick bugfixes and security fixes into that branch from master", I'd be happy with that.

But then, I'm very pragmatic. I'd also be happy with the licence saying "if you upload features / fixes / et al to an Open Source branch, that is implicit permission to pull them into the next BUSL release, I'd be happy with that too. Why not - the company developers have to eat, too ...

Cheers,
Wol

unsupported by upstream.

ballombe — Tue, 06 Aug 2024 13:58:01 +0000

The short version is that the open-source version is not supported by upstream
Do you want to package such software ? How will you support it ?
The alternative is to either fork the open-source version or ignore it altogether.

Avoid if possible

spacefrogg — Tue, 06 Aug 2024 09:34:18 +0000

I would avoid these types of licenses as much as possible. By being able to shift the conversion date at any later point by modifying content, it effectively becomes what I want to call: susceptible to "license poisoning". Nobody should have that power. It is even worse than CS licenses, because it might create factual dependencies during its "open state" just to close again later and establish grounds for coercion.

The only acceptible form of these licenses would be to have a transition date that remains fixed to initial software release. You don't want to spoil your business? Don't put out updates on an already open branch. Your choice. But taking people's freedom away after the fact? Not your choice. (At least should not be deemed acceptable.)

Security updates

chris_se — Tue, 06 Aug 2024 08:11:16 +0000

> Vít Ondruch asked about security fixes. If a security vulnerability is discovered and fixed in a later version of the software, should that patch be reimplemented? Fontana said that might be an option, but Berrangé cautioned that it could be tricky if ""the 'reimplemented' patch ends up being effectively (or actually) identical to the official patch"".

"We'd really like to provide a fix for this 0-day unauthenticated remote code execution vulnerability, but we're not completely sure if we can legally do so."

Personally I think that security fixes that could end up looking identical are those where the fix is so trivial that it probably isn't copyrightable. And the more complicated fixes will not be that similar if developed in a clean environment (think what people who do reverse engineering do). So legally I believe that this should be completely fine. But would want I bet my own livelihood on this? When it comes MariaDB as a company as it stands now, sure, I think they've earned a lot of community trust to think they'd be very reasonable about this. But what if they are bought by some really litigious actor at some point in the future?

Maybe someone can convince MariaDB to update their BUSL to explicitly carve out an exception for security fixes for bugs that are present in code whose license has already been "transformed"? That those fixes can immediately be used under the GPL?

LWN: Comments on "The complexity of BUSL transformation"

Free *LIBRE* includes right to make changes & pass them on

Forking because upstream refuses to support something the distro cares about

unsupported by upstream.

unsupported by upstream.

unsupported by upstream.

Open Source

unsupported by upstream.

Avoid if possible

unsupported by upstream.

Avoid if possible

Security updates

Free LIBRE includes right to make changes & pass them on