3 ms·

> 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 wou

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

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.