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.
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.
Only the AGPL is remotely close to forcing hyper-scalars to release the source code of what they provide.
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.
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.
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.
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.
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"
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.
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.
[0] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
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.
I personally believe it should not and that AI code should NOT be considered a "clean room" method. That said, IANAL.
Back in 2006/7 I had an idea for a project for which, in all enthusiasm, I setup a mailing list, but ended up never pursuing it. It's a very unique name.
In 2012, another developer landed on the same name for their project, but saw that the mailing list was taken up and reach out inquiring if he could take over, and I obliged because here's another person doing something in cryptography and open source, 2 of my favorite things then (and now).
The project was "scrypt" and the developer was Colin! :) I knew nothing about Colin or tarsnap then, IIRC.
Sometimes you just do kindnesses of which you're able, with people who you feel a sense of community with, without expectation of anything commercial. Karma adds up, and it's benefits are large, though hard to always articulate.
There's so much about that phrase that makes me smile. Easy to forget that Second Life was also one of the earliest users of AWS, S3 first. Jeff Bezos had personally invested in our 2005 round (a round that made Linden Lab a unicorn before that was a thing) and pointed us at Jeff Barr and the work coming from AWS.
In return, Jeff Barr started hosting AWS meetups in Second Life -- this was the era of lots of groups setting up Second Life outposts, from Jonathan Coulton to Reuters.
We were with Evolution Robotics and were showing off the ER1, a new hobbyist robot.
Good memories for sure!
>I received sponsorship from Amazon via GitHub Sponsors for 10 hours per week for a year
For whatever reason, I remember being shocked that you were only charging $300/hr [1] which was what a mere L6 google engineer would make salaried. I hope they are paying you more nowadays
No disrespect to German-speaking engs, but Colin isn't merely "top-notch", he's "the top".
Huge salaries (like those paid to "top" athletes in "top" professional team sports) aren't unheard of in Tech anymore. For instance, Google paid $2b+ to acquihire Noam Shazeer of c.ai back. Meta was rumoured to be paying $20m+ salaries to poach OpenAI researchers based in Zurich.
100-200k, is what you'd expect elsewhere. Which is still pretty good, just not astronomical.
> a useful improvement (especially given the urgency after the Capital One breach) but in my view just a mitigation of one particular exploit path rather than addressing the fundamental problem that credentials were being exposed via an interface which was entirely unsuitable for that purpose.
What alternative interface does the author propose we use to securely exchange credentials? The only other approaches I can come up with involve allowing monkey hands to come into direct contact with secret materials. Outlook, slack and teams cannot possibly be more secure than IMDSv2. I think if you are manually passing around things like PFX files you've already lost the game.
The entire point of the IAM roles is to make everything a matter of policy rather than procedure. The difference here is insane when you play through all of the edges. IAM policy management is significantly easier to lock down than the alternative paths. I can prove to an auditor in 5 minutes that it is mathematically impossible for a member of my team to even see the signing keys we use for certain vendors without triggering alerts to other administrators. I've got KMS signing keys that I cannot delete with my root account because I applied inappropriate policies at creation time. This stuff can be very powerful when used well. Azure has a similar idea that makes accessing things like mssql servers way less messy.
If you read the linked post you'll see that at the time I suggested using XenStore to pass credentials to the OS kernel. Obviously a different approach would be needed with Nitro but if anything it would be easier now.
Once the kernel had them they could be exposed to applications via a synthetic filesystem which, crucially, can have ownership and permissions set on it.
I'm absolutely not arguing against IAM Roles for EC2. I'm arguing that they picked the worst possible interface over which to transmit those role credentials.
[0] 86a7b126fea03dd57e6a3c9c9b7951b5318d33029cef0547ff441862174682f5 is the sha256 of the shelved project’s name
You can do similar with vsock(7) sockets. This also has the advantage that it's harder to trick an application into making a connection to a vsock socket.
Both of these have the weakness that it is not entirely atypical to give processes CAP_NET_BIND_SERVICE so they can listen on "privileged" sockets, but they work against anything without that.
Even better, you could put bootstrap credentials in DMI data or similar, where it'll end up (on Linux) inside a sysfs directory which can only be read by root.
Nothing useful to add except that I Like these blog posts from someone who actually did a bunch of things. Nice round-up of the past.
The next service I signed up for was "Alexa Web Information Service". Web search as a service, back when "Alexa" was the search company they had acquired, not a voice assistant. By mid-2007 I was (finally) accepted into the EC2 beta. The rest, as they say, is history.
Why on earth would you give this monstrosity of a company so much free labour?
I get that volunteering is fun, but donating your time and competence to a hyper capitalist company is short sighted. I hope there was appropriate compensation, and I'm not including "early access".
In mid 2000s these companies were already operating in the billions and their engineers were already well compensated, and it was known.
Hell, "Cracking the Coding Interview" came out in 2008. Getting a job at those companies at the time was already something coveted because of how well they paid.
Perhaps in the USA, but in many other countries this does for sure not hold.
I'm sure I could get away with it and nobody at Amazon would even notice, but it's the principle of the thing.
So... I'd have to check my notes to be sure but I think fall 2011?
At some stage I realised AWS is extremely expensive, extremely slow, extremely ridiculously complex and also a parasitic attitude to open source.
I realised I should instead go all in on Linux on virtual machines on other platforms.
AWS I’m done.
Netflix uses FreeBSD specifically for their custom-built CDN/streaming servers, which are hosted directly with ISPs … not on AWS. Their user-facing catalog app, however, runs on Ubuntu servers hosted on AWS.
At least that’s what I recall reading here on HN.
It knew how to be the market leader and first to market with big launches. It’s now struggling to navigate a world where in more and more areas it’s falling behind. The big early misses on GenAI seem to have accelerated that.
A ton of momentum from earlier years keeps it moving, but that playbook only lasts so long.
2 companies have functionally similar products, but behaves completely different. One company makes technical decisions with security as the fundamental principal, while for the other company, security is not a consideration.
Azure engineers absolutely considered security.
They just chose other priorities: growth at any cost to catch up with AWS.
