| ▲ | gobdovan 10 hours ago |
| 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. |
|
| ▲ | djoldman 4 hours ago | parent | next [-] |
| 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 4 hours ago | parent | next [-] | | 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" | | |
| ▲ | djoldman 2 hours ago | parent | next [-] | | > 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. If someone wants to release technology in a way that makes it publicly viewable but restricts its use, they can do that. If they don't want to release it, they don't have to. Additionally, publicly released technology destroys patentability, if that's the objective. I don't understand what one would want to achieve that can't be achieved here. | |
| ▲ | Cpoll 3 hours ago | parent | prev [-] | | > 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. |
| |
| ▲ | 8 minutes ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | 9 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | surgical_fire 8 hours ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | noosphr 6 hours ago | parent | next [-] | | The GPL3 can be put behind a server and no one will ever see the source code because there is never any distribution. Only the AGPL is remotely close to forcing hyper-scalars to release the source code of what they provide. | |
| ▲ | graemep 7 hours ago | parent | prev | next [-] | | I know this is true of AGPL, but GPL3? I thought the people who objected to GPL3 were those distributing software to their users (e.g. was a reason Apple switched from bash to zsh). I cannot think of aything in GPL3 that would be a problem for hyper-scalers. | |
| ▲ | wasmainiac 7 hours ago | parent | prev | next [-] | | > They could use AGPL or GPL3, typically those licenses are verboten in hyperscalers. Laws are only as good as their enforcement, in business at least. Unfortunately I have seen first hand that no one cares about licensing if they can’t get caught. Businesses licenses are good because you can offer support and other benefits to encourage payment. | | |
| ▲ | cxr 4 hours ago | parent | next [-] | | > Laws are only as good as their enforcement The claim is that those licenses are deemed no-touch within those companies—it's the companies themselves that insist on the software and their business not mixing, e.g. Apple continuing to ship old versions of GNU programs like Bash and then eventually moving to zsh rather than provide updated versions that are GPLv3. Neither GPLv3 nor AGPLv3 say anything about businesses not being able to use the software. | |
| ▲ | surgical_fire 5 hours ago | parent | prev [-] | | Hey, nothing wrong with closed source, BSL, etc. I am fine with it. I am the last person that will say someone should give out their work for free. What I object to is companies releasing software with permissive licenses, and then getting butthurt that others profit from it, or trying to rug pull the permissive licenses after a community adopted and contributed to it. If you want to play the OSS game, then play it right. |
| |
| ▲ | direwolf20 8 hours ago | parent | prev [-] | | Or SSPL, which extends AGPL with even more sharing requirements. | | |
|
|
| ▲ | queenkjuul 9 hours ago | parent | prev [-] |
| 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 4 hours ago | parent [-] | | 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/ | | |
| ▲ | growrow 3 hours ago | parent [-] | | 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. |
|
|
