Google Open Source Blog
opensource.google.com · Company blog · on HN since 2017
Google's open source team posts about its open source programs, policies such as AGPL restrictions, and featured projects.
What HN saysCommenters link it to show Google's open source output and its AGPL policy, with some praising the default Apache licensing and review process.
86HN people shared it
70linked it in comments
16stories submitted
436story points
2 years agolast shared
2017people per year2026
Most-shared posts
- 1Invention Assignment Review Committee for Personal Projects19 people · 1 points · first shared 2017 · 2 comments on HN
- 2Some software cannot be used at Google11 people · 149 points · first shared 2017 · 186 comments on HN
- 3Agpl policy11 people · first shared 2017
- 4A new home for Google Open Source8 people · 257 points · first shared 2017 · 63 comments on HN
- 5Releasing5 people · first shared 2018
- 6Google Opensource Featured Projects4 people · 5 points · first shared 2017 · discussion on HN
- 7Patching4 people · first shared 2018
- 8Docs4 people · first shared 2017
- 9Creating3 people · 2 points · first shared 2018 · discussion on HN
- 10Featured3 people · first shared 2018
- 11Thirdparty3 people · first shared 2017
- 12Pdfium2 people · first shared 2019
- 13Publishing2 people · first shared 2018
- 14Oneversion2 people · first shared 2019
- 15Blueprint2 people · first shared 2019
What HN people wrote when they linked it
afpx · 2019-09-06
But, we should also mention that Google also has some of the best software designers and architects in the world. You can't get a well-engineered library without someone experienced at design leading it. All of Google's open source projects have significant design. And, if you look at the commit logs, you can see that their designs didn't emerge from thousands of little pushes. Someone led those projects and enforced design criteria from the beginning.
[1]: https://opensource.google.com/
zamadatix · 2019-09-05
Here I am just wishing my company would even allow me to post the source of a project I've worked on with any license and apparently Google isn't worth praise for hosting all such projects with an Apache license by default and a review process if you'd like to try to keep copyright.
https://opensource.google.com/docs/iarc/
Mathnerd314 · 2019-08-31
AFAICT the relationship for Scratch is that Google wrote a new VPL (Blockly) and the MIT Media Lab released it as Scratch 3.0.
I guess the "thousands" is from https://opensource.google.com/? In a few minutes of browsing, I couldn't find anything besides Bullet that wasn't just Google releasing something as open source.
steren · 2019-07-02
Google does not contribute to OSS? https://opensource.google.com/
rmc · 2019-06-07
Google has a similar policy: https://opensource.google.com/docs/using/agpl-policy/
This is a great advantage of the AGPL IMO. You can release your free software/open source code, and big tech companies won't use your code and make lots of money.
Some companies tried to relicence their code to some 'source available'/'non commerical' licence because they didn't like the MIT's lack of conditions. AGPL could have helped.
SigmundA · 2019-05-03
I very rarely run into this in Chrome, they licensed Foxit and made it open source https://opensource.google.com/projects/pdfium its native and fast.
Firefox I think still uses https://github.com/mozilla/pdf.js which was not bad last time I used it, but it all javascript so performance isn't up to par with native. Also printing is not great and I don't think they have implemented a SVG backend yet for better printing. On the plus side you can embed it in your web app if you want and have more control over the viewer.
DannyBee · 2018-10-16
So i'm the one who forbid WTFPL at Google, and we forbid it mainly because it's bad for developers, believe it or not.
We go over it in new googler training (and our reasoning is on the Google open source policy site we publish: https://opensource.google.com/docs/thirdparty/licenses/#wtfpl-not-allo…
You are welcome to not (but if you go and look, it's completely consistent with my viewpoints and history in OSS so ...).
I would love to live in a world where WTFPL is a good license, but we don't live in that world, and wanting it to be so will not change that.
I can also tell you stories of companies we've acquired who had bad experiences, FWIW.
So the "small companies" you think are being served, aren't.
delroth · 2018-10-11
It's also pretty easy to contribute to FOSS projects on your own time, as long as you're OK with Google being the owner of your contributions (I personally don't care since it's open source licensed anyway). https://opensource.google.com/docs/patching/ is an almost fully public version of the process Googlers have to follow to contribute stuff to open source projects.
Disclaimer: works at Google, maintains some FOSS code in my own time, both under my own copyright for some projects and under Google's copyright for others.
kregasaurusrex · 2018-08-05
Referencing the companies in the original tweet, each one has a landing page (internal or on Github) for how they contribute to OSS. Making open standards which are cross-compatible between programs doesn't happen overnight, where often community-driven users are a force under which further awareness and adoption are spread.
[0] https://opensource.microsoft.com/
[1] https://aws.github.io/ and https://aws.amazon.com/mp/oss/
[2] https://opensource.google.com/
edmondlau · 2017-12-28
If there are engineers you highly respect on your team, their code is a great place to start.
Otherwise, many top tech companies now open source software that they've written internally, oftentimes with their own websites. And there is also a growing trend for them to actually maintain the software they open source as opposed to just throwing it over the fence.
Think of companies that have a strong engineering brand, and then just search for what open source software they're released. Pick whatever seems most aligned with your interests.
Some examples:
Google: https://opensource.google.com/projects/list/featured?language=python
Facebook: https://code.facebook.com/projects/#backend
Stripe: https://stripe.com/open-source
Airbnb: http://airbnb.io/projects/
KB · 2017-10-20
Having gone through a few acquisitions where MongoDB was used, I would never recommend using it from a legal/compliance perspective. You either have to pay for a very expensive commercial license OR adhere to their AGPL license (which is very difficult).
https://opensource.google.com/docs/using/agpl-policy/
https://github.com/mongodb/mongo/blob/master/GNU-AGPL-3.0.txt
bitmapbrother · 2018-06-07
renegat0x0 · 2024-07-01
Oh google has many pages:
- https://arvr.google.com/
- https://bughunters.google.com/
- https://design.google.com/
- https://opensource.google.com/
- https://code.google.com/
- https://ai.google.com/
- https://mapsplatform.google.com/
- https://programmablesearchengine.google.com/
- https://privacy.google.com/
- https://lens.google.com/
- http://labs.google.com/
- https://jigsaw.google.com/
- https://datastudio.google.com/
- https://tagmanager.google.com/
- https://script.google.com/
There are some more scraped by me https://github.com/rumca-js/Internet-Places-Database
rvz · 2020-08-13
Other companies using the same subdomain for their open-source projects:
[0] https://opensource.apple.com
[1] https://opensource.google.com
[2] https://opensource.amazon.com
[3] https://opensource.facebook.com
[4] https://opensource.twitter.com
[5] https://opensource.uber.com
kyrra · 2019-09-09
Another interesting bit with the monorepo is the one-version-policy:
https://opensource.google.com/docs/thirdparty/oneversion/
That's why the typescript upgrade was so hard for them. We (attempt) to enforce a single version of a library/toolchain to be checked into the codebase at any given time. You can have multiple in during an upgrade, but it's highly discouraged.
jagthebeetle · 2019-09-09
The lingua franca for Google's building needs is (more or less) bazel, where you say target /a/b/c depends on /dep/v1_1, /dep/xyz, /common/foo, etc.). (There is a filesystem-like hierarchy parallel to, but not necessarily the same as the corresponding repository's directory layout.)
Bazel is extensible via rules [1], so if you really wanted to use NodeJS on your team, you might create a `nodejs_binary` rule that put everything in the right directory and ran some NodeJS packager on it. You'd probably not put it into production.
Also, third-party code lives in a single third-party directory, so yes, internal users could pull down code they wanted (and for which there wasn't a satisfactory internal version already) into that directory: https://opensource.google.com/docs/thirdparty/
[1]: https://docs.bazel.build/versions/0.29.0/skylark/rules.html
sebe · 2019-08-29
I think V8 belongs in the google camp.
"V8 is an open-source JavaScript engine developed by The Chromium Project for Google Chrome and Chromium web browsers."
https://en.wikipedia.org/wiki/V8_(JavaScript_engine)
Seems google does a lot of opensource stuff as well.
https://opensource.google.com/projects/explore/featured
MartinMond · 2019-07-29
Google's PDFium which is used in Android and ChromeOS is fast becoming the reference implementation to target: https://opensource.google.com/projects/pdfium
noahster11 · 2019-07-18
Google is behind tesseract[0], not sure if they use this for Google Cloud Vision OCR
[0]: https://opensource.google.com/projects/tesseract
jsolson · 2019-07-05
That's common to most projects released by Googlers. Options are either a getting the IP officially assigned over to yourself or releasing it under a Google copyright with a CLA: https://opensource.google.com/docs/creating/
The latter is lower friction, in my opinion.
This is especially common for "personal" projects that people end up working on or using on the clock.
I don't know if this was the case with Cue specifically (this is the first I've heard of the project, but less boilerplate in my JSON has some appeal).
mariocesar · 2019-06-09
Search for "Blueprint build tool"
https://opensource.google.com/projects/blueprint
https://github.com/google/blueprint
mkl · 2019-06-09
Duckduckgo for [blueprint build system] returns https://github.com/google/blueprint as the first hit, so I think it's that.
Edit: Google, for me, doesn't return that on the first page, but the first result is https://opensource.google.com/projects/blueprint which links to it.
DenseComet · 2019-05-12
There is no change in licensing that could achieve those changes. Companies will just use other software/rewrite the libraries, and blacklist the license.
https://opensource.google.com/docs/using/agpl-policy/
jacobparker · 2019-03-27
There's some public documentation on the "one version" policy here: https://opensource.google.com/docs/thirdparty/oneversion/
geofft · 2019-03-15
I am neither a Googler nor a laywer, but I think yes and yes - if you don't care about copyright ownership and only licensing (which most of the time is fine - you usually only care if you either want to commercialize it later or you want to make sure either you have standing to sue infringers or Google doesn't), there's an easy process for open-sourcing something and letting Google retain ownership, and a much more involved process for confirming that Google doesn't own it. So it's easier to let Google claim copyright and not argue about whether they really have had ownership.
Some relevant links are https://opensource.google.com/docs/releasing/ for the personal-project-with-Google-copyright flow and https://opensource.google.com/docs/iarc/ for the personal-copyright flow.
jchw · 2019-03-14
No, we use our @google.com address for anything that might fall under the copyright assignment rules of our employment agreement. I won't debate whether those rules are actually enforceable - I have no idea - but if you're actually curious, the documentation is mostly public.
https://opensource.google.com/docs/releasing/
raphlinus · 2019-03-14
No, the policy is to use your google.com address, with some exceptions[1]. This confuses a lot of people, as things done for fun by one person on weekends (maybe not even official 20% time) are mixed in with official projects.
[1]: https://opensource.google.com/docs/patching/
_msw_ · 2019-03-12
Disclosure: I work at Amazon, and from time to time I help out with open source policy.
There have been a number of changes to Amazon's policies over the years, and personal participation ("outside activity") is really straightforward now. For the vast majority of cases you just need to submit a ticket with details, and then it is auto-approved.
For comparison, you can have a look at Google's open source policy on personal projects here: https://opensource.google.com/docs/iarc/
If you are an employee and have questions, drop me a line at msw at amazon.com
sanxiyn · 2019-03-08
AGPL is especially attractive because you are guaranteed that you won't be exploited by Google. See https://opensource.google.com/docs/using/agpl-policy/
Datenstrom · 2019-02-21
Don't have one on hand but I have seen quite a few. I have heard that they are mostly 20% time projects though I'm not sure if they try to take code written on your own time but it looks like they do (and anything else you have written before working there) from this:
https://opensource.google.com/docs/iarc/