Google Open Source Blog

You continue to dance around this question on this post - did you or did you not follow Google's open source approval process[1]? Did you have an approved Ariane/Launcher2 entry? 1: https://opensource.google/documentation/reference/releasing/approval

I'm not a lawyer, or a licence/copyleft expert. Plenty of people who know lots more than I do about those subjects specifically recommend any reliance on AGPL projects/tools/libraries/what have you, because of the viral nature of *GPL licences that don't have the linking exception of lgpl. Google's lawyers have a pretty clear-cut take on it: https://opensource.google/documentation/reference/using/agpl-policy/

Also worth noting (as a sibling comment pointed out) that despite these assurances the untested legal risks of AGPL-licensed code may still cause difficulties for larger, risk-averse companies. Google notably has a blanket policy [1] banning all AGPL code entirely as "the risks outweigh the benefits", so large organizations are probably another area where the commercial license comes into play. [1] https://opensource.google/documentation/reference/using/agpl-policy

Is there a real reason not to use AGPL? The fact that it makes Google very uncomfortable[1] is a great selling point to me. [1]: https://opensource.google/documentation/reference/using/agpl-policy

Microsoft uses git for office development https://danielsada.tech/blog/carreer-part-7-how-office-moved-to-git-an… Google has android and chromium as well as Git+Gerrit-on-Borg https://opensource.google/documentation/reference/releasing/hosting/

Any license that prohibits selling a hosted version will necessarily fail to meet the Open Source Definition. Your best bet would instead be to pick a license that the companies that would do so are irrationally afraid of. The AGPLv3 is the usual choice for this. Even though, e.g., GCP would be legally allowed to, Google internally has an absolute policy against doing so: https://opensource.google/documentation/reference/using/agpl-policy

No, it's a true FOSS license and not one of the scammy ones in the news of late, but some organizations straight up ban AGPL[1] because it is network viral in a way that hasn't been tested in the courts, so best to just avoid the hassle I didn't mean my comment in a disparaging way, just trying to answer a FAQ on any such "Show HN" that uses the term "open source" but doesn't otherwise specify. Often that means it's a scam license, and I find that to be doubly true when the submitter craftily omits any mention of the license, but it is not the case here and I applaud the use of an actual FOSS license, even if that means I personally don't get to enjoy using this software 1: e.g. https://opensource.google/documentation/reference/using/agpl-policy (discussed: https://news.ycombinator.com/item?id=31176071 and likely a ton of others, too)

I once saw a presentation once given by a lawyer where the GPL meant different things to different communities (again I'm talking about the GPL here). I believe it was Van Lindberg that gave that talk. https://www.linkedin.com/in/vanlindberg/ Basically the license was read differently based upon the community -- particularly in subtle ways. You can say, "Well... it's the GPL it means this and exactly this." But that presentation convinced me that different licenses can have different readings -- particularly depending upon the community. It's worth noting this is google's take on it AGPL is here: https://opensource.google/documentation/reference/using/agpl-policy?re… "...we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner."

(googler, opinions are my own). Google actually publishes most of the docs that Googler's have to follow when open sourcing software. See: https://opensource.google/documentation/reference/releasing This specific line you're asking about is talked about here: https://opensource.google/documentation/reference/releasing/publishing…

Name one. Google won’t: https://opensource.google/documentation/reference/using/agpl-policy/ Unless things have changed recently I know Amazon won’t, and I’m fairly sure Facebook still won’t. For most corporations it’s simply not worth the risk

First, I work at Google and its onboard training explicitly mentions Stack Overflow as a forbidden example due to CC-BY-SA license (SA is the problematic part). The following link is the official reference. https://opensource.google/docs/thirdparty/licenses/#restricted

I like to learn new stuff by doing personal projects, but since there are so many things to learn, I select those that, one day, might benefit me professionally as well: as a consultant, to help me with perform some task at work more efficiently, etc. Most new languages that gather some kind of following get their start outside a commercial environment. If a tool has a license so toxic that many companies (1) simply rule out their installation on company servers or company laptops out of principle, I move on and select something else to learn. > the thing you need The license makes it so that I'll never know whether I need it or not. (1) Google is one of them: https://opensource.google/docs/using/agpl-policy/

This is also what Google suggests: > Please associate your commit with your google.com email unless: - You have a history of contributing to the repo under a different email before your employment at Google Source: https://opensource.google/docs/patching/ > The release process applies to all types of projects: personal (at home), 20%, and new Google open source releases that aren’t part of and following the release process of an already-established Google open source project (like Chromium or Android). Source: https://opensource.google/docs/releasing/#patching It’s a bit less strict, but signing work that I’m doing after job with my job e-mail doesn’t sound fair.

Why's that? I thought megacorps would love software with no strings attached: at least, they seem to love MIT- and BSD-licensed codebases, which give up pretty much everything but attribution, if I understand correctly. Is it because it's unclear whether such a statement would really waive all copyright? Edit: that seems to be it; here are Google's views on the matter: https://opensource.google/docs/thirdparty/licenses/#unencumbered

Ad supported search engines comes to mind, as one example: https://opensource.google/ /me dodges tomatoes But maybe you meant something about software under the GNU license specifically?

Since it's AGPL it will probably never end up in the same commercial use cases as Confluence does. Google has some motivations written down from their lawyer department: https://opensource.google/docs/using/agpl-policy/ It boils down to 'not worth the risk, do not use'.

Google’s internal OpenSource releasing policy is actually public: https://opensource.google/ It’s written from a more process/legal viewpoint but you might be able to pick up some ideas in there.

sidebar question - Anyone know how they've made the interaction/animation on this page [1] ? Feel like it is a great way to show lot of info in a concise way. [1] - https://opensource.google/projects/explore/featured

Maybe you saw it but no need to sigh anymore: https://news.ycombinator.com/item?id=22551856 https://opensource.google

> Nothing in the article suggests it did not autonomously do the work. I don’t know how to respond to that other than to ask you to quote the part of the blog post where the author described the language model running into a problem that it could not fix and then described the details of how he manually intervened to fix the problem that the language model could not fix when you elaborate on your definition of “nothing” in that sentence. >Every agent would hit the same bug, fix that bug, and then overwrite each other's changes. Having 16 agents running didn't help because each was stuck solving the same task. >The fix was to use GCC as an online known-good compiler oracle to compare against. I wrote a new test harness that randomly compiled most of the kernel using GCC As for: > Because a lot of naysayers here pretend as if this is somehow trivial. This is an answer to “why do you want someone to do that?” You have already established that you would like that to happen. It doesn’t answer “why would a real human being (who is not you) that isn’t impressed by the compiler that doesn’t work put their time into making Anthropic look good?” For example “I will pay a naysayer $20,000 to try” or “I know a guy that will pay a naysayer to try this, succeed or fail” or “I will give a naysayer a bunch of hardware to play with in exchange for attempting this” would be motivation to work for Anthropic and not get paid by Anthropic. Saying “I want you to do that because I think…

I would love to begin using this system, but the licensing is giving me serious pause. While most of the software is under the AGPLv3, the Commercial License section of the README [0] implies that the company takes on a fairly broad interpretation of the AGPL. In particular, the line "[...] to build a feature on top of Windmill, to comply with AGPLv3 your product must be AGPLv3 [...]" seems to imply the company aligns with the stance taken by Google and other companies: that even calling the application via API is enough to trigger copyleft [1]. This implies that if I were to build a sign-up form that triggers a Windmill workflow in the backend, my entire application would either need to be AGPLv3 or I would need a commercial license. That's perfectly reasonable, as it means any non-AGPL use will have to contribute back to Windmill via a commercial license. However, it does mean positioning this as an "Fully Open-source" alternative to Airflow is only technically correct. This is much closer in practice to "source available" than how most developers would think as "open source". If this isn't how Windmill wants their license interpreted, I highly encourage clarifying things. [0] https://github.com/windmill-labs/windmill#commercial-license [1] https://opensource.google/documentation/reference/using/agpl-policy

Drew misses a huge cause of misunderstandings about the AGPL, which is that some of the companies that use AGPL would love for AGPL to be more complicated than Drew's simple version. For example, iText PDF's entire business relies on interpreting the AGPL as being as viral as possible [0]: > You may not deploy it on a network without disclosing the full source code of your own applications under the AGPL license. You must distribute all source code, including your own product and web-based applications. > It’s a legal violation to use iText Core/Community and our open source add-ons in a non-AGPL environment. Rather than interpret Google's page[1] as some sort of psy-op, a simpler explanation is that there are many companies who use the AGPL license and want it to be totally viral even over network calls, and since the license has yet to be tested in court it's safest to just assume it has the strongest virality possible. [0] https://itextpdf.com/how-buy/AGPLv3-license [1] https://opensource.google/documentation/reference/using/agpl-policy

No it's not, and yes it does. This trend on HN that has consisted in wanting to kill the meaning of "open source" as most people understand it is very weird and surprising. I don't understand what is at stake. I have noticed this since one month or so. The vast majority of projects that call themselves open source mean the open source definition as defined by the open source initiative, or something equivalent. You might not like or recognize the OSI and that's fine, but you can't decide what people mean when they say open source. You are the one starting the battle and I don't understand your motives. I just searched for "open source" in a search engine, I'm getting [1,2,3] and lists of "the best open source software". And they are all using the OSD. You are at odds with Wikipedia, IBM, RedHat and with Microsoft, Google, Amazon, Facebook, Apple [4,5,6,7,8], and with everyone else, really. [1] https://en.wikipedia.org/wiki/Open_source [2] https://www.redhat.com/en/topics/open-source/what-is-open-source [3] https://www.ibm.com/en-en/topics/open-source [4] https://opensource.microsoft.com/ [5] https://opensource.google/ [6] https://aws.amazon.com/fr/opensource/ [7] https://opensource.fb.com/ [8] https://opensource.apple.com/

Here's Google's stance on why they ban AGPL software: https://opensource.google/documentation/reference/using/agpl-policy > The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license. > This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed. > Because Google's core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube), the consequences of an engineer accidentally depending on AGPL for one of these services are so great that we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner. FWIW, every company I've ever worked at bans AGPL products / code.

As far as blessing certain licenses, I believe that we currently recognize all the OSI and SPDX licenses and display documentation for code with any license that permits commercial use. The full list is at https://pkg.go.dev/license-policy. Analyzing public data is different from reproducing and distributing significant portions. The problem here is reproduction and distribution. Legally, Google's short search result snippets, which quote just a few fragments of a page, are quite different from reproducing and distributing a package's docs in their entirety. https://opensource.google/docs/using/license/ is a good overview of what a license needs to do and why. I don't know what to say about the "have some trouble believing" part other than to attest that I have personally spent many hours working with (excellent, wonderful) lawyers on these issues. Google really does care about making sure we are respecting the limitations set out in people's licenses.

This sort of mixes up a number of issues: The whole git/mercurial thing is, as I understand it, related to the extensibility of the systems. Mercurial is hackable and extensible in ways that matter, git isn't (or at least wasn't) The one version policy only really matters for third party dependencies. If you're making a change to a library that is entirely within the monorepo, you can do a three phase migration (add the new functionality, migrate users, deprecate the old functionality). Google is exceedingly efficient at this, and the vast majority of the time these migrations can be done without any effort by local owners. For third party deps, you can't usually do that, but there's a workaround[2]. I also think that this post and the one here[1] are amusingly both on the front page at the same time. This one decrying the exact sort of mandate based approaches that "make SRE scale". Also worth mentioning that > The person making the new API is expected to change client code to match, but is not responsible for ensuring the change does not break the client. Is just explicitly untrue. There are policies that are clear about this (this generally comes down to "we cannot break your tests, but if it isn't tested, we can't know we broke it") [1]: https://news.ycombinator.com/item?id=28825352 [2]: https://opensource.google/docs/thirdparty/oneversion/#temporary-month

I won't try to be exhaustive here, but I think it's worth mentioning a few things: One con is that most open source (as well as publicly available but proprietary) tooling is geared towards the non-monorepo approach. So if you want to use a monorepo, you're going to have to fight a bit of an uphill battle because most tools and processes assume you have lots of little repos. For example, build triggers in a lot of CI/CD tools operate on a per-repo basis. There are some random benefits - it's easier to make everything public-by-default, which encourages people to look at source code written by other teams, and creates a culture of transparency and internal openness. But the big thing in my opinion isn't directly the monorepo itself, but what's known inside Google as the "One Version Rule"[1]. Basically this means that only a single version of any package should be in the repo at a time. There are exceptions, but that requires going to extra effort to exempt your package from this rule. I guess Chrome and Android are examples of this - they are made up of lots of little Git repos that are stitched together, but they generally follow the One Version Rule. On the other hand, if you just stick a lot of npm modules in there and every single one has a separate package.json file, then it's technically a "monorepo" but it's not following the One Version Rule. You also need good test coverage. Not just in terms of line coverage or some other artificial metric, but to the point…

I haven't commented on HN in a while, but this article actually pretty much complains about me, since I wrote the text in question and enabled the policy to be released. So i'm just going to say: 1. The author claims the Google states something, then doesn't actually quote anything google stated, but instead writes their own interpretation of the words and a made up example. That's not a good start. 2. Having set up their own example, the author then proceeds to say it's wrong because of an appeal to authority, asserting no reasonable disagreement is possible - when not only is it possible, but large numbers of IP lawyers disagree on what the AGPL requires. It's true that someone wrote it, and there are FAQ's, but depending when and where, their opinion on what it means is not as relevant as one might think. In truth, lots of people disagree over interpretation of the AGPL - many more than disagree about GPL interpretation or LGPL interpretation (which are fairly settled at this point). Searches over any legal licensing list in existence will you this. When I wrote the interpretation you see here, it was the best available info at the time, guided not just by own views, but by listening to a lot of smart lawyers, counterparts at other companies, etc. Even if you ignore all the lawyers and whatever as useless, the author has the huge problem that There are people who make AGPL software that take the view listed in the google policy So it's not just Google or…

I don't really want to debate with you here, and if anything I feel like the points you are hammering on just fortify my stance that this topic is a waste of breath. > The OSI is merely pointing out that it will make everyone's lives easier if developers try their best to use one of the licenses that already exists Maybe, maybe not! Perhaps existing licenses are not sufficient. I doubt we'll be using the same licenses in 100 years. I bet there are better licenses waiting to be authored -- maybe TFA's license is the future? > > The OSI includes GPLv3, which is certainly not "free" for a ton of commercial uses. > > Incorrect. Commercial customers are free to use, modify, and redistribute just like everyone else. They can even sell a product based on it - they just can't keep any changes they might make closed source if they do so. Look, I live in the real world. If I link to a GPLv3 library in my product, I have to release all of my source code. This is potentially a pretty big burden on a lot of folks. Sure, there's a lot of legal FUD, but unfortunately, while FUD, has a very real impact. Lawyers won't sign off on a lot of this stuff. > Take a look at some of the approved licenses - for example AGPL, GPL, MPL, and MIT. In _all_ cases I'm free to modify and redistribute. In some cases I might be required to make my changes available, but never am I barred from making use as I see fit. Source available is simply not the same thing. AGPL is defacto banned at most…

Xoogler here who also published things within Google repositories. This is a standard phrase that you should have in the README to get an approval to publish your repository to GitHub, even if it is totally related to the Google business (as mine were). My guess is that it's similar to the regular "no warranty" clause in the licenses, just explicitly opting out this code from any possible agreements Google might have with its customers. Google's process to publish to open source is well documented and this documentation is public. [1] is the document that requires this disclaimer. [1]: https://opensource.google/documentation/reference/releasing/publishing