Hacker News new | past | comments | ask | show | jobs | submit login

This is a remarkably flamey summary. I would have expected something more balanced from you.

To be very clear, Google did not buy godoc.org at all. The maintainer of godoc.org tired of taking care of it and approached us about taking it over. We agreed, to ensure that this important community resource remained available. We put in significant operational time keeping it running - it was not a zero-maintenance server.

When the time came to update godoc.org to support Go modules, it was clear that a lot would need to change - the old godoc code just didn't expect any of the concepts that modules added. So we wrote a new one instead of trying to evolve the old one in place, and when it was ready, we turned down the old one with appropriate redirects to keep links working.

The idea that we "bought" godoc.org "just to cancel and replace" it is incredibly incendiary and not even remotely close to true. I'm stunned to see you spreading misinformation like this.

As for licenses, Google has deep pockets and does not want to be sued for non-permitted use of other people's source code. Our lawyers have decided that displaying a derived work (the docs) on a commercial site (anything Google runs) is something we need an clear license for. It is not hard to make a clear statement that code is licensed to allow the specific uses that are otherwise reserved to the author in copyright law. The 0BSD and MIT-0 licenses are good examples of clear statements granting the necessary rights, with no actual restrictions on use. WTFPL is very much not that kind of clear statement: it does not explicitly grant the copyright-reserved rights. Google's lawyers do not have any interest in one day having to stand up in court and defend having made commercial use of some software by debating the exact legal meaning of 'what the fuck you want to'.

It also turns out to be fairly difficult, legally, to put something in the public domain. If just saying "I put this in the public domain" were enough, the CC0 license would not be so incredibly long [1]. pkg.go.dev does recognize and display CC0-licensed code.

Yes, godoc.org used to display docs for code using any license at all. That was almost certainly a mistake, one that went unnoticed during the transfer of godoc.org to Google. I'm glad that the copyright violations on that site never led to any legal action.

[1] https://creativecommons.org/publicdomain/zero/1.0/legalcode.

I'm not who you are replying to, but am a contributor since the v1 ish days and will try to remain respectful, as I feel you usually are.

It feels the main inflammatory issue pointed out is 'bought' vs 'agreed to take over.' It is an important distinction, but to the end user the result is the same. Many have lamented a noticeably degraded experience. I'm curious if the original maintainer would have agreed to such action(in fairness, it doesn't matter, just wondering).

Further, many have expressed their distaste with the banner. I don't want to rehash or argue that here, and probably you don't either. FWIW, I'm just a passive observer and never argued one way or another. However, I'm not sure just ignoring folks is the right answer either.

One can see how both changes could lead to a lot of dissatisfaction, I think.

All of that aside, the legal issue described is a real double edged sword. It feels like G only blesses certain licenses to an end user. I have some trouble believing a company of Google's size worries about the implication of what boils down to analyzing publicly available data. Does Google check for and bless licenses in their web crawler?

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.

The new website is garbage, the old one was light and fast. So thanks for making my Go experience that much worse. Oh, and please remove the damn banner already.

You're making a big deal about "bought" but it doesn't really matter whether money changed hands. godoc.org existed, Google showed up, and now it does not. The thing that replaced it is not functionally equivalent, full stop. Whether or not someone got paid is not of interest. When Google shows up to a project, money tends to follow, so it's not really surprising that OP should make this assumption.

I'll not address any of this bizarre hypothetical law interpretation, except to say that SQLite, a software package which Google ships globally, is in the public domain, always has been, and none of the things you bring up seem to matter at all anywhere except web forums, which are consistently the only place anyone sees this kind of handwaving.

> You're making a big deal about "bought" but it doesn't really matter whether money changed hands. godoc.org existed, Google showed up, and now it does not.

This is just as untrue as "Google bought just to cancel and replace with proprietary bloat...". We did not ask for godoc.org at all. The maintainer approached us to take it over, which we did, to keep an important service available to the Go community. Eventually we replaced it with a newer version of the service. The service still exists, it's just pkg.go.dev instead of godoc.org.

The "proprietary" part is not true either, at least not anymore: the source code for pkg.go.dev is at golang.org/x/pkgsite. (It took us a couple months to get all the permissions lined up for the open source release, and that was a misstep on our part. There is a long story behind that, which I won't go into.)

> The thing that replaced it is not functionally equivalent, full stop.

I don't understand this comment.

I see functionality on pkg.go.dev that is not available on godocs.io, like being able to see the version history of a package and look at docs for a particular version; annotations showing which version added a particular declaration to a package; detected license information; symbol search, like [http.Handler]; and reverse imports.

I don't see any functionality on godocs.io that is missing from pkg.go.dev. Unless the comment is about not showing docs without a clear license permitting commercial use.

> I don't understand this comment. (...) I don't see any functionality on godocs.io that is missing from pkg.go.dev.

Sorry, but:

• Where can I access the diagram (not just a list) of the transitive imports graph of a package?

• Quoting straight from https://golang.org/x/tools/cmd/godoc, is the following functionality still present on pkg.go.dev? if yes, how can I access it?

"For instance, https://golang.org/pkg/math/big/?m=all shows the documentation for all (not just the exported) declarations of package big."

And yes, I sometimes found it helpful when it was there.

• Personally, when trying to search or browse the index of entities in a pkg.go.dev page, the auto-collapsing gives me trouble to get a good overview or quickly find stuff. I remember recently having to waste minutes trying to find something in the, of all the things, https://pkg.go.dev/std stdlib ToC, due to directories being auto-collapsed.

pkg.go.dev provides a plainly worse user experience in many dimensions. It's more difficult to see the surface area of a package. It's more difficult to navigate between major versions of a given module. And there are numerous bugs on different browsers that aren't being fixed. The golang.org site provided no-frills but functionally excellent documentation which pkg.go.dev fails to match. The code behind pkg.go.dev is also plainly amateurish and buggy. It's a shame, really.

> It's more difficult to see the surface area of a package. It's more difficult to navigate between major versions of a given module.

This is too vague for me to understand what you mean exactly. If I were rsc I would have no idea how to make you happy. The same goes for the rest of your comment, honestly.

> This is too vague for me to understand what you mean exactly.

When you go to a module's page on pkg.go.dev, the package documentation is hidden and requires a click to expand. The sections which enumerate the identifiers -- constants, functions, types, etc. -- are hidden by default and only become visible when you scroll to them. Major versions of a module are treated as distinct things rather than versions of the same thing. The navigation on the left-hand side breaks if the browser is less than some number of pixels.

For those following along at home, "golang.org/x/pkgsite" redirects to "https://pkg.go.dev/golang.org/x/pkgsite", which declares the repository to be at "https://cs.opensource.google/go/x/pkgsite", which gives a "Permission denied" error page unless you fetch code from Google Tag Manager. So it's all nicely open source, and not proprietary, as long as you subject yourself to Google's tracking mechanisms, or sign into your Google account, and do not license any libraries public domain -- Google will use them, but not show them to you. So as you can see, there's nothing to complain about, and we should all thank Google for their grandmotherly kindness.

It's also available as a mirror at https://github.com/golang/pkgsite. All the golang.org/x/* packages are thankfully available there, making them pretty easy to find.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact