We ported it by using Google Web Toolkit Java->JS compiler, and replaced OpenGL with WebGL, and all of the other bits with Web APIs (websocket, pointer-events, fullscreen-api, filesystem api, etc)
The assets (proprietary artwork, levels, etc) were not hosted on AWS, it simply downloaded the EXE file from ID servers and extracted it in the browser.
That sounds like you wrote code, code on which Google holds copyright, and you really need to read up on the Google company policy on that. I'm not sure you understand fully what distinct things copyright and software licenses are, and how Google policies apply to them.
There's a reason people who join Google have historically "disappeared" from open source: It's because they can't just contribute.
Back when you did this it definitely was explicitly and strongly violating policy. Nowadays maybe it could get away without opensource review by counting it as a "patch".
My first few years at Google, I worked almost exclusively on official OSS projects (no google3 commits).
Edit: looking at the trailer, I forgot we released this on April 1, as an April Fools joke. LOL
I'd hate to see people get in trouble after reading what you wrote and reason their way to thinking because it's opensource and their own time they can do what they want.
For the most part, I think most Googlers are thoughtful about the rules, god knows we go through enough training decks, but also as a xoogler? you know Googley behavior means people are pretty reasonable about obeying license restrictions and adhering to desires of OSS authors.
Although as the number of employees at Google skyrocket, the probability of bad actors increases and company culture was probably much different than when there were only 5-10k employees vs >100k
> As a Googler, it's often easier for me to setup a GCP consumer account, AWS, or Heroku account to demo something, compared to using anything internal.
I get you're trying to make a point of saying you can do something easier elsewhere, but then why even through in the "as a Googler bit" without clarifying that you're not really working on anything of consequence where you'd be actually asked to host things internally.
You're basically hosting open source projects on AWS.
A bigger reason AWS was chosen was because AppEngine, IIRC, back in those days could not support WebSockets (among other things), as Google's frontend Load Balancers that the predecessor to GCP used didn't know how to deal with it. The Chrome team was pushing heavily on new Web APIs like WebSockets, but by the time they were ready to ship to market, our own cloud infrastructure didn't support it yet.
I'd go further and say that, using internal infra to host employee 20% projects that are not really for production, is the kind of dogfooding that would have generated the pain points necessary to make a product like AWS, because those hobby workloads are far more similar to the workloads the average GCP customers deploy. Because we didn't really prioritize that, we kind of missed the boat on Cloud and was a late entrant, even though most of the foundational technology (eg Containers) we already had a long time ago.
These things typically ride on a pendulum over the course of 10 years or so, swinging from high speed to high friction. As the costs associated with approaching one extreme stack up, someone eventually says enough and the direction reverses.
In recent years, there actually is an internal framework for standing up servers quickly along with end-to-end everything else a Google production service usually gets. The frontend uses Wiz. It's still not as easy as say, NextJS/Vercel, or Heroku, or even throwing together a Kube deployment, but it does provide a lot more than any of those, so the medium learning curve pays back quickly.
I was just saying there is a line you can easily cross and you need to be careful when you take something and put it on other platforms. I've seen people get in trouble for enabling a Slack / GitHub integration, which actually made sense when I thought about why it was an issue.