5 ms·

The author calls it a 'joke' that Heroes are just unpaid Amazon employees, but reality doesn't become a joke just because it's funny. The asymmetry here is stag

The author calls it a 'joke' that Heroes are just unpaid Amazon employees, but reality doesn't become a joke just because it's funny. The asymmetry here is staggering. I find myself holding back private research because I don't want to provide free R&D for a value-extraction machine that is already efficient enough. The author was at least dependency-driven in their contribution, but outside that kind of dependency, it's hard to justify contributing even 'in the open' when the relationship is this one-sided. Amazon in particular has done enormous damage to the economic assumptions that permissive open source once relied on. There's increasingly more projects adopting 'Business Source Licenses', precisely to prevent open work from becoming a free input into hyperscaler monetization. These devs know Amazon is grabby and, at some point, the only dominant outcome their community contribution is upstream of is unpaid labor for a trillion-dollar entity that also diverts support and community engagement away from the original projects by funneling users into managed versions of the same software.

deleted 6mo ago
[deleted]
queenkjuul 6mo ago
I'm "lucky" to not be smart enough or important enough to think about this. Regardless, i wholeheartedly agree -- at this point, anything i personally could release publicly, will either be fully open source, or completely private. And I'm only choosing open source if I'm relatively sure it's not gonna make some asshole tons of money.
- gobdovan 6mo ago
  That's in the ballpark how big corps use open source strategically. They try to kill everyone value extraction moat at any other layer than the ones they dominate. So they commoditize their complement [0]. They don't care if you make money based on their OSS, as long as you race to the bottom against anyone else who also has access to it and turn anything but the corp's profit center into a ubiquitous commodity. So they make the "asshole"'s incentives line up with their own. [0] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
  - growrow 6mo ago
    That link was a great read and makes a strong point! Another reason corps invest in OSS is to develop something they rely on - special driver, etc - and capitalizing on that in the form of OSS maintainers charging consulting fees has been successful. Exactly in agreement with making the incentives line up with their own.
surgical_fire 6mo ago
> There's increasingly more projects adopting 'Business Source Licenses', precisely to prevent open work from becoming a free input into hyperscaler monetization. They could use AGPL or GPL3, typically those licenses are verboten in hyperscalers. The truth is that the sort of company opting for BSL never really wanted to do OSS, and in truth only did so for the optics of it, for the goodwill it buys among developers, etc.
- direwolf20 6mo ago
  Or SSPL, which extends AGPL with even more sharing requirements.
  - aleph_minus_one 6mo ago
    The SSPL is not an open-source license.
    - cxr 6mo ago
      > It's deception, plain and simple, to claim that the software has all the benefits and promises of open source when it does not. From "The SSPL is Not an Open Source License" <https://opensource.org/blog/the-sspl-is-not-an-open-source-license https://opensource.org/blog/the-sspl-is-not-an-open-source-l...>
    - direwolf20 6mo ago
      Yes it is. It plainly meets all the criteria in the definition iff AGPL meets them too.
      - aleph_minus_one 6mo ago
        The central difference is that SSPL discriminates against specific fields of endeavor, while the AGPL doesn't; see * https://web.archive.org/web/20230411163802/https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003977.html https://web.archive.org/web/20230411163802/https://lists.ope... * https://opensource.org/blog/the-sspl-is-not-an-open-source-license https://opensource.org/blog/the-sspl-is-not-an-open-source-l... * https://en.wikipedia.org/w/index.php?title=Server_Side_Public_License&oldid=1335206483#Certification_with_OSI https://en.wikipedia.org/w/index.php?title=Server_Side_Publi...
djoldman 6mo ago
If someone doesn't like Amazon using software they write, they can just outright disallow Amazon from using it in the copywrite license. It's perfectly legal to say: "except for Amazon [and whoever], anyone can use this for any purpose, provided..." Amazon won't intentionally use that software. It's not worth the potential legal liability. That doesn't mean Amazon won't write their own version though if they think they need to at some point.
- gobdovan 6mo ago
  I am saying this is exactly what's happening, but with more robust language. If you disallow Amazon, maybe there is a third party that offers our services to Amazon. So Amazon-the-string is not the bogeyman; the concern is the resale or hosted-service arrangement they can access. So you see formulations that target infrastructure resale rather than specific entities, such as: "For the avoidance of doubt, the following scenarios are not permitted under the license: * A managed service that lets third party developers ... register their own [SERVICE] service endpoints and invoke them through that managed service." "You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software." "If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License [...] where 'Service Source Code' is defined broadly to include the entire hosting stack (monitoring, backups, etc.) to ensure a level playing field"
  - Cpoll 6mo ago
    > If you disallow Amazon, maybe there is a third party that offers our services to Amazon. So Amazon-the-string is not the bogeyman; the concern is the resale or hosted-service arrangement they can access That's some acrobatics I suspect Amazon won't engage in, because communicating to the customer that your FooBarDB is managed in AWS but hosted by a third party is awkward. Amazon will happily reimplement your API with their backend, as they've done before.
  - djoldman 6mo ago
drzaiusx11 6mo ago
AFAICT, large saas players can simply implement the software interfaces regardless of business source licenses like what happened to redis, no? Or is there some specific protections for API surfaces that I'm not aware of. I vaguely recall Google v Oracle almost established some protections but then got deferred in later ruling. My memory is hazy on that though...
- ryandvm 6mo ago
  Indeed. And with the frontier AI models it's worse than that. You can literally just have them write test cases for the product you want to clone, then set it loose reverse engineering the code base. That said, all these models are trained on the open source code bases presumably, so it would be interesting to see if AI-blackbox reverse engineering actually holds up in court.
  - drzaiusx11 6mo ago
    My gut says it would infact hold up in current US courts, but only because the lionshare of corporations want it to and the courts have been stacked in their favor. I personally believe it should not and that AI code should NOT be considered a "clean room" method. That said, IANAL.

deleted 6mo ago

[deleted]

queenkjuul 6mo ago

I'm "lucky" to not be smart enough or important enough to think about this. Regardless, i wholeheartedly agree -- at this point, anything i personally could release publicly, will either be fully open source, or completely private. And I'm only choosing open source if I'm relatively sure it's not gonna make some asshole tons of money.

gobdovan 6mo ago
That's in the ballpark how big corps use open source strategically. They try to kill everyone value extraction moat at any other layer than the ones they dominate. So they commoditize their complement [0]. They don't care if you make money based on their OSS, as long as you race to the bottom against anyone else who also has access to it and turn anything but the corp's profit center into a ubiquitous commodity. So they make the "asshole"'s incentives line up with their own. [0] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
- growrow 6mo ago
  That link was a great read and makes a strong point! Another reason corps invest in OSS is to develop something they rely on - special driver, etc - and capitalizing on that in the form of OSS maintainers charging consulting fees has been successful. Exactly in agreement with making the incentives line up with their own.

surgical_fire 6mo ago

> There's increasingly more projects adopting 'Business Source Licenses', precisely to prevent open work from becoming a free input into hyperscaler monetization. They could use AGPL or GPL3, typically those licenses are verboten in hyperscalers. The truth is that the sort of company opting for BSL never really wanted to do OSS, and in truth only did so for the optics of it, for the goodwill it buys among developers, etc.

direwolf20 6mo ago
Or SSPL, which extends AGPL with even more sharing requirements.
- aleph_minus_one 6mo ago
  The SSPL is not an open-source license.
  - cxr 6mo ago
    > It's deception, plain and simple, to claim that the software has all the benefits and promises of open source when it does not. From "The SSPL is Not an Open Source License" <https://opensource.org/blog/the-sspl-is-not-an-open-source-license https://opensource.org/blog/the-sspl-is-not-an-open-source-l...>
  - direwolf20 6mo ago
    Yes it is. It plainly meets all the criteria in the definition iff AGPL meets them too.
    - aleph_minus_one 6mo ago
      The central difference is that SSPL discriminates against specific fields of endeavor, while the AGPL doesn't; see * https://web.archive.org/web/20230411163802/https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003977.html https://web.archive.org/web/20230411163802/https://lists.ope... * https://opensource.org/blog/the-sspl-is-not-an-open-source-license https://opensource.org/blog/the-sspl-is-not-an-open-source-l... * https://en.wikipedia.org/w/index.php?title=Server_Side_Public_License&oldid=1335206483#Certification_with_OSI https://en.wikipedia.org/w/index.php?title=Server_Side_Publi...

djoldman 6mo ago

If someone doesn't like Amazon using software they write, they can just outright disallow Amazon from using it in the copywrite license. It's perfectly legal to say: "except for Amazon [and whoever], anyone can use this for any purpose, provided..." Amazon won't intentionally use that software. It's not worth the potential legal liability. That doesn't mean Amazon won't write their own version though if they think they need to at some point.

gobdovan 6mo ago
I am saying this is exactly what's happening, but with more robust language. If you disallow Amazon, maybe there is a third party that offers our services to Amazon. So Amazon-the-string is not the bogeyman; the concern is the resale or hosted-service arrangement they can access. So you see formulations that target infrastructure resale rather than specific entities, such as: "For the avoidance of doubt, the following scenarios are not permitted under the license: * A managed service that lets third party developers ... register their own [SERVICE] service endpoints and invoke them through that managed service." "You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software." "If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License [...] where 'Service Source Code' is defined broadly to include the entire hosting stack (monitoring, backups, etc.) to ensure a level playing field"
- Cpoll 6mo ago
  > If you disallow Amazon, maybe there is a third party that offers our services to Amazon. So Amazon-the-string is not the bogeyman; the concern is the resale or hosted-service arrangement they can access That's some acrobatics I suspect Amazon won't engage in, because communicating to the customer that your FooBarDB is managed in AWS but hosted by a third party is awkward. Amazon will happily reimplement your API with their backend, as they've done before.
- djoldman 6mo ago

drzaiusx11 6mo ago

AFAICT, large saas players can simply implement the software interfaces regardless of business source licenses like what happened to redis, no? Or is there some specific protections for API surfaces that I'm not aware of. I vaguely recall Google v Oracle almost established some protections but then got deferred in later ruling. My memory is hazy on that though...

ryandvm 6mo ago
Indeed. And with the frontier AI models it's worse than that. You can literally just have them write test cases for the product you want to clone, then set it loose reverse engineering the code base. That said, all these models are trained on the open source code bases presumably, so it would be interesting to see if AI-blackbox reverse engineering actually holds up in court.
- drzaiusx11 6mo ago
  My gut says it would infact hold up in current US courts, but only because the lionshare of corporations want it to and the courts have been stacked in their favor. I personally believe it should not and that AI code should NOT be considered a "clean room" method. That said, IANAL.