3 ms·

I don’t think it’s reasonable to call it a “two-year exclusivity period”—it’s more like a two-year dead man’s switch. As long as the original SaaS is relevant y

I don’t think it’s reasonable to call it a “two-year exclusivity period”—it’s more like a two-year dead man’s switch. As long as the original SaaS is relevant you are never competing with it, because you won’t be able to reuse any security fixes that the original developer made. Unless, of course, you are Amazon or Oracle, and can afford an independent security team. I don’t know how I feel about this. Or, okay, right now I feel that I’ll believe it when I see the old versions actually go open source for, say, several times the declared period. (The first BUSL versions of Sentry, from 2019, only started running out their timers a year ago.) Otherwise, I ... don’t think that, say, Stallman would call it evil? It’s certainly better than the other non-FOSS possibilities. And yet I feel absolutely no desire to contribute (to the non-FOSS versions) under such conditions, and I wouldn’t suggest others do so, either. So I don’t know if there’s a “bazaar” to have here, or if the “bazaar” should spend its efforts on such cases instead of going elsewhere.

the_mitsuhiko 3y ago
> because you won’t be able to reuse any security fixes that the original developer made You are, just not in a competing commercial service. For that you would have to wait for two years. Which is precisely the point. In a non commercial, self hosted setting you're free to incorporate these patches.
- mananaysiempre 3y ago
  That’s why I said “competing” and not “using”, yes. It’s just that for me the phrase “exclusivity period” would imply that you could compete as a provider of sufficiently-old versions. And technically you can, except the script kiddies will take you down in a heartbeat, and in that respect you’re in a very different world from the one the original developer was at that point in the past even if alternative offerings are ignored. (Consequently, the original developer is not competing against old versions of their own software the same way as Microsoft used to be competing against old versions of Office or Apple is now competing against older Macbooks.)
  - the_mitsuhiko 3y ago
    > It’s just that for me the phrase “exclusivity period” would imply that you could compete as a provider of sufficiently-old versions. And technically you can, except the script kiddies will take you down in a heartbeat, and in that respect you’re in a very different world from the one the original developer was at that point in the past even if alternative offerings are ignored. I give you an analogy from the real world: MySQL was bought by Sun and then merged into Oracle. The original developers didn’t even like that direction and forked the project and build MariaDB. Some of the code they took was even older than the latest release. There can always be situations where a project withers for years and you get stuck with a license that impedes commercial revitalization. The FSL doesn’t come with that risk.
- bonzini 3y ago
  You can always clean-room reverse engineer it. Or you can look yourself for 0-days in the released version, and develop simultaneously the fix for the closed and the open source version. You just have to be creative.

the_mitsuhiko 3y ago

> because you won’t be able to reuse any security fixes that the original developer made You are, just not in a competing commercial service. For that you would have to wait for two years. Which is precisely the point. In a non commercial, self hosted setting you're free to incorporate these patches.

mananaysiempre 3y ago
That’s why I said “competing” and not “using”, yes. It’s just that for me the phrase “exclusivity period” would imply that you could compete as a provider of sufficiently-old versions. And technically you can, except the script kiddies will take you down in a heartbeat, and in that respect you’re in a very different world from the one the original developer was at that point in the past even if alternative offerings are ignored. (Consequently, the original developer is not competing against old versions of their own software the same way as Microsoft used to be competing against old versions of Office or Apple is now competing against older Macbooks.)
- the_mitsuhiko 3y ago
  > It’s just that for me the phrase “exclusivity period” would imply that you could compete as a provider of sufficiently-old versions. And technically you can, except the script kiddies will take you down in a heartbeat, and in that respect you’re in a very different world from the one the original developer was at that point in the past even if alternative offerings are ignored. I give you an analogy from the real world: MySQL was bought by Sun and then merged into Oracle. The original developers didn’t even like that direction and forked the project and build MariaDB. Some of the code they took was even older than the latest release. There can always be situations where a project withers for years and you get stuck with a license that impedes commercial revitalization. The FSL doesn’t come with that risk.
bonzini 3y ago
You can always clean-room reverse engineer it. Or you can look yourself for 0-days in the released version, and develop simultaneously the fix for the closed and the open source version. You just have to be creative.