Avoid if possible

Posted Aug 6, 2024 9:34 UTC (Tue) by spacefrogg (subscriber, #119608)
Parent article: The complexity of BUSL transformation

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.)

Avoid if possible

Posted Aug 6, 2024 15:25 UTC (Tue) by Wol (subscriber, #4433) [Link]

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