5 ms·

> Many of these recent forks are being done because people won't want AWS/GCP/Azure to slap a UI on top of their free open-source product and resell it, making

> Many of these recent forks are being done because people won't want AWS/GCP/Azure to slap a UI on top of their free open-source product and resell it, making tens of millions of dollars per day in the process. I can't really blame them. I won't blame them for regretting their past actions, but I hope the lesson would be learned: if you want to put limitation on the use of your software, you shouldn't have licensed it in a way that doesn't allow such. You can't recall a gift because you don't like how the recipient is using it. Though you are more then welcome not to gift them ever again.

slashdev 2y ago
With the noise people make when you don't use an OSI open-source license, little wonder. But when Redis started I think we didn't yet boardly understand the limitations of OSI licenses in the era of big tech cloud computing. To people starting projects today, you have no excuse, we know better. Don't use OSI open-source unless it's entirely a labor of love that you're giving away free. OSI Open-source business models are dead. Don't make that mistake.
- lenerdenator 2y ago
  They're not dead, just mostly dead. You can probably set up a decent privately-funded venture to deal in OSI software. The problem comes (as it always does) when the founders think they're the reincarnation of Steve Jobs and deserve a nine-or-ten-figure net worth for making a few nice, but ultimately not earth-shattering, software tools. Then they have to enshittify to get ready for the IPO.
  - snotrockets 2y ago
    nit: s/founders/executives/ (sometimes they are the same, but not always)
  - deleted 2y ago
    [deleted]
- Pet_Ant 2y ago
  > Don't use OSI open-source unless it's entirely a labor of love that you're giving away free. Well, know what your secret sauce is. I think performance is really the best differentiator. Make a fully behaviourally compatible (maybe not bug for bug) version available and then sell a proprietary faster version. Think an compiler that doesn't due any optimisation and outputs naive code. You know have a useful OSI project, and a clear value add, and a clear boundary between the two. This is really applicable for databases, and it still leaves you with something useful for learning small projects, and for developers to run locally on their own machines.
  - snotrockets 2y ago
    It ain't performance, it's cost (which increased performance can improve, but it's far from the only factor).
  - wing-_-nuts 2y ago
    >I think performance is really the best differentiator. I don't understand this at all. Most open source projects start out equally as a means to give back to and collaborate with the community as well as showcase one's skills. You're asking me to purposefully publish badly optimized software? I don't have it in me. That offends my sensibilities of craftsmanship. A 'slow' open source project will never get traction. Even if it did, I also don't know how an open source project wouldn't immediately have it's obvious performance bottlenecks fixed. Far better to go the VSCode route. Release a useful project, then release paid extensions for it.
  - pas 2y ago
    this is the open core model, it works well for things like GitLab (as far as I know) and in effect GitLab is doing a BSL-like thing by after a few years they release features to the free tier but it rarely works if you need to decline contribution from people who would eat into your profit margins. I think ElasticSearch had this problem (and the community basically ended up with a few forks, because people sent the patches for security features that were in the enterprise version, and to no one's surprise they did not get merged ...) so, I guess it works if there's a huuuge scope with plenty of things to contribute, to shoot for the moon together, without hurting the business side too much.
- snotrockets 2y ago
  > But when Redis started I think we didn't yet boardly understand the limitations of OSI licenses in the era of big tech cloud computing. According to antirez, he understood the implications of licensing Redis as BSD: https://news.ycombinator.com/item?id=39863371 https://news.ycombinator.com/item?id=39863371
  - bornfreddy 2y ago
    But not in "the era of big tech cloud computing": > That is, if I was still in charge, would I change license? But that's an impossible game to play, I'm away from the company for four years and I'm not facing the current issues with AWS impossible-to-compete-with scenario. Not saying he would have decided any differently, just that cloud computing has changed open source situation for the worse.
- jrochkind1 2y ago
  It looks to me like people start with open source licenses because that's helpful to get them market-share (and in some cases community contributors and maintainers), and then they switch to a non-open-source license reserving certain rights to profit to them hoping to maintain the users that they wouldn't have gotten if they started with that license. I am curious for examples of any projects now *starting( with one of these non-open-source rights-to-profit-reserved licenses, now that is clearly "understood". Are there any examples? Are they successfully attracting users? Contributors?
  - growse 2y ago
    Cockroachdb started with BSL I think.
    - jrochkind1 2y ago
      Wikipedia suggests it was initially apache, changed to BSL in 2019. https://en.wikipedia.org/wiki/CockroachDB https://en.wikipedia.org/wiki/CockroachDB. But still perhaps an example of fairly quick switch to BSL before it had gotten wide market/mind share? I don't know the history.
      - orangechairs 2y ago
        That's correct - CockroachDB's license changed in 2019, from Apache 2.0 to a permissive version of the BSL: https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/ https://www.cockroachlabs.com/blog/oss-relicensing-cockroach... "We’re adopting an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license."
sanderjd 2y ago
First of all, you can "recall a gift", if it is legal. I don't think I've seen people arguing that these re-licensing actions are not legal. But if you mean that you can't recall a gift without making people mad, then yep, that's true! But keeping people from being mad is not the only thing that matters. But the real problem I have with, "I hope the lesson will be learned" is that the lesson people are learning is "don't try to build ambitious software requiring a lot of work from a dedicated core team using an open source license; you're going to find yourself damned if you do and damned if you don't". And I think that really sucks! And sadly the ship has already sailed here. I'm certain we're going to see way fewer products with open source licenses because of all of this. And I think it's unlikely we'll even see as many products with "source available" licenses because, how is it worth the hassle to release source when the community has shown more good will to projects that are entirely proprietary? I really think I'm going to look back at the last 15 years or so in awe at how often I had the luxury of digging into the behavior of software I rely on, by reading the code.
- snotrockets 2y ago
  We're living in a society, with certain systems baked into it. Fighting to change those systems and norms is a Good Thing™, but I'm too pessimistic to act today as if the change is coming tomorrow. I'll both work to change those systems, AND act as if they're here to stay.
  - sanderjd 2y ago
    I'm not sure if this was a purposeful allusion or not, but I entirely agree that you "can't recall a gift" in exactly the same sense that you can't keep talking on a payphone for a long time when someone is clearly waiting; because, you know, we're living in a society!!
    - snotrockets 2y ago
      Unlike the payphone analogy, where there is metering rules, and as long as you abide by them, you can keep talking, even if it's impolite, there is a legal definition for gifts (it is, after all, a transfer of ownership, and such things are regulated), which, as far as I know, matches the social norm of not being able to claw those back.
bloppe 2y ago
> Though you are more then welcome not to gift them ever again That's actually an accurate description of what's happening with these re-licensing dramas. Redis versions from before the split are still BSD-licensed. They can't recall those gifts. The re-licensing only applies to newer versions. Of course, it wasn't just people employed by Redis, Inc. who were providing the gifts. My (vague) understanding is that a lot of contributions came from people at AWS, etc. Technically, AWS was providing those "gift" contributions to Redis -- because Redis, Inc. maintains the copyright for community contributions -- and Redis was then re-gifting those contributions to the world, via the BSD license. That's all fine and dandy until the big contributors realized they're actually fiercely competing with each other for cloud customers, and it's not realistic for Redis, Inc. to compete with the largest cloud provider on Earth without any technical moat whatsoever. Hence the re-licensing. I think the breakdown in trust for Redis, Inc. is overblown. By far the biggest contributor to valkey (madolson) is employed by AWS. Does the OSS community really think that's a better organization to back in the long term?

slashdev 2y ago

With the noise people make when you don't use an OSI open-source license, little wonder. But when Redis started I think we didn't yet boardly understand the limitations of OSI licenses in the era of big tech cloud computing. To people starting projects today, you have no excuse, we know better. Don't use OSI open-source unless it's entirely a labor of love that you're giving away free. OSI Open-source business models are dead. Don't make that mistake.

lenerdenator 2y ago
They're not dead, just mostly dead. You can probably set up a decent privately-funded venture to deal in OSI software. The problem comes (as it always does) when the founders think they're the reincarnation of Steve Jobs and deserve a nine-or-ten-figure net worth for making a few nice, but ultimately not earth-shattering, software tools. Then they have to enshittify to get ready for the IPO.
- snotrockets 2y ago
  nit: s/founders/executives/ (sometimes they are the same, but not always)
- deleted 2y ago
  [deleted]
Pet_Ant 2y ago
> Don't use OSI open-source unless it's entirely a labor of love that you're giving away free. Well, know what your secret sauce is. I think performance is really the best differentiator. Make a fully behaviourally compatible (maybe not bug for bug) version available and then sell a proprietary faster version. Think an compiler that doesn't due any optimisation and outputs naive code. You know have a useful OSI project, and a clear value add, and a clear boundary between the two. This is really applicable for databases, and it still leaves you with something useful for learning small projects, and for developers to run locally on their own machines.
- snotrockets 2y ago
  It ain't performance, it's cost (which increased performance can improve, but it's far from the only factor).
- wing-_-nuts 2y ago
  >I think performance is really the best differentiator. I don't understand this at all. Most open source projects start out equally as a means to give back to and collaborate with the community as well as showcase one's skills. You're asking me to purposefully publish badly optimized software? I don't have it in me. That offends my sensibilities of craftsmanship. A 'slow' open source project will never get traction. Even if it did, I also don't know how an open source project wouldn't immediately have it's obvious performance bottlenecks fixed. Far better to go the VSCode route. Release a useful project, then release paid extensions for it.
- pas 2y ago
  this is the open core model, it works well for things like GitLab (as far as I know) and in effect GitLab is doing a BSL-like thing by after a few years they release features to the free tier but it rarely works if you need to decline contribution from people who would eat into your profit margins. I think ElasticSearch had this problem (and the community basically ended up with a few forks, because people sent the patches for security features that were in the enterprise version, and to no one's surprise they did not get merged ...) so, I guess it works if there's a huuuge scope with plenty of things to contribute, to shoot for the moon together, without hurting the business side too much.
snotrockets 2y ago
> But when Redis started I think we didn't yet boardly understand the limitations of OSI licenses in the era of big tech cloud computing. According to antirez, he understood the implications of licensing Redis as BSD: https://news.ycombinator.com/item?id=39863371 https://news.ycombinator.com/item?id=39863371
- bornfreddy 2y ago
  But not in "the era of big tech cloud computing": > That is, if I was still in charge, would I change license? But that's an impossible game to play, I'm away from the company for four years and I'm not facing the current issues with AWS impossible-to-compete-with scenario. Not saying he would have decided any differently, just that cloud computing has changed open source situation for the worse.
jrochkind1 2y ago
It looks to me like people start with open source licenses because that's helpful to get them market-share (and in some cases community contributors and maintainers), and then they switch to a non-open-source license reserving certain rights to profit to them hoping to maintain the users that they wouldn't have gotten if they started with that license. I am curious for examples of any projects now *starting( with one of these non-open-source rights-to-profit-reserved licenses, now that is clearly "understood". Are there any examples? Are they successfully attracting users? Contributors?
- growse 2y ago
  Cockroachdb started with BSL I think.
  - jrochkind1 2y ago
    Wikipedia suggests it was initially apache, changed to BSL in 2019. https://en.wikipedia.org/wiki/CockroachDB https://en.wikipedia.org/wiki/CockroachDB. But still perhaps an example of fairly quick switch to BSL before it had gotten wide market/mind share? I don't know the history.
    - orangechairs 2y ago
      That's correct - CockroachDB's license changed in 2019, from Apache 2.0 to a permissive version of the BSL: https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/ https://www.cockroachlabs.com/blog/oss-relicensing-cockroach... "We’re adopting an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license."

sanderjd 2y ago

First of all, you can "recall a gift", if it is legal. I don't think I've seen people arguing that these re-licensing actions are not legal. But if you mean that you can't recall a gift without making people mad, then yep, that's true! But keeping people from being mad is not the only thing that matters. But the real problem I have with, "I hope the lesson will be learned" is that the lesson people are learning is "don't try to build ambitious software requiring a lot of work from a dedicated core team using an open source license; you're going to find yourself damned if you do and damned if you don't". And I think that really sucks! And sadly the ship has already sailed here. I'm certain we're going to see way fewer products with open source licenses because of all of this. And I think it's unlikely we'll even see as many products with "source available" licenses because, how is it worth the hassle to release source when the community has shown more good will to projects that are entirely proprietary? I really think I'm going to look back at the last 15 years or so in awe at how often I had the luxury of digging into the behavior of software I rely on, by reading the code.

snotrockets 2y ago
We're living in a society, with certain systems baked into it. Fighting to change those systems and norms is a Good Thing™, but I'm too pessimistic to act today as if the change is coming tomorrow. I'll both work to change those systems, AND act as if they're here to stay.
- sanderjd 2y ago
  I'm not sure if this was a purposeful allusion or not, but I entirely agree that you "can't recall a gift" in exactly the same sense that you can't keep talking on a payphone for a long time when someone is clearly waiting; because, you know, we're living in a society!!
  - snotrockets 2y ago
    Unlike the payphone analogy, where there is metering rules, and as long as you abide by them, you can keep talking, even if it's impolite, there is a legal definition for gifts (it is, after all, a transfer of ownership, and such things are regulated), which, as far as I know, matches the social norm of not being able to claw those back.

bloppe 2y ago

> Though you are more then welcome not to gift them ever again That's actually an accurate description of what's happening with these re-licensing dramas. Redis versions from before the split are still BSD-licensed. They can't recall those gifts. The re-licensing only applies to newer versions. Of course, it wasn't just people employed by Redis, Inc. who were providing the gifts. My (vague) understanding is that a lot of contributions came from people at AWS, etc. Technically, AWS was providing those "gift" contributions to Redis -- because Redis, Inc. maintains the copyright for community contributions -- and Redis was then re-gifting those contributions to the world, via the BSD license. That's all fine and dandy until the big contributors realized they're actually fiercely competing with each other for cloud customers, and it's not realistic for Redis, Inc. to compete with the largest cloud provider on Earth without any technical moat whatsoever. Hence the re-licensing. I think the breakdown in trust for Redis, Inc. is overblown. By far the biggest contributor to valkey (madolson) is employed by AWS. Does the OSS community really think that's a better organization to back in the long term?