Hacker News new | ask | show | jobs
by durin42 2150 days ago
Or listen to Daniel Berlin, who's both an accomplished GCC hacker and a lawyer:

https://news.ycombinator.com/item?id=9956542 https://news.ycombinator.com/item?id=13979443

This isn't settled law, and DannyBee would be quick to point out that the practice of law has a major component of risk management.

1 comments

I don't think Daniel contradicts Eben, at least in the link here...

There are good rationales and bad rationales for a decision. Google made a good decision with a bad rationale. Daniel made a good decision with a good rationale. Why does this matter? If I'm running my own business, my business context won't be the same as Google's. There are times to pick AGPL, and times to not pick it, and that requires accurately understanding the law.

You realize that Daniel works for Google, and is one of the people who makes such decisions about OSS for Google, so if you think he made the decision with a good rationale, then so did Google, since his decision was Google's.
I did not realize that. I read the one link. That's all I know about Daniel. He sounded reasonable there and what he wrote made sense.

There are quite a few logical leaps between:

1) Daniel writing a reasonable post on HN 2) Daniel being correct in everything he does 3) Daniel making all decisions for Google 4) Daniel being the one who handles all communications about those decisions

All I know is #1.

The logic chain can break at any of those points. Perhaps Google made the decision with good rationale which was simplified or changed for communications. Perhaps someone else at Google decided. Etc. I don't know.

Some of Google's policies, viewed from the outside, look crazy ("Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office."), but may have valid justifications too. For example, Google could have automated systems which do audits which would choke on this sort of thing.

What I do know is that many companies have an irrational, unjustified fear of the AGPL, and that it often makes good business sense.

I also trust Eben for his legal judgement. He's brilliant, and usually right.

None of those follow. The implication is Daniel wrote a post about why Google made a decision.

That's the entire chain of reasoning. Nothing about him always being right, only him being right in a context where your already admitted he was right. Nothing about him anyways being a decision maker, just the belief that he isn't lying about Google's reasoning.

In that case, your post was a complete non sequitur. Drew is responding to this aggressive and misleading Google page:

https://opensource.google/docs/using/agpl-policy/

He is not responding to a random post from a Googler on HN, or to Google's internal policies or decision-making processes. Google has a bunch of scary-sounding public-facing FUD about the AGPL, containing a bunch of legal nonsense, which is scaring a lot of people. That's out-of-line with Google's former policy of not being evil. This whole discussion has that as the overarching context.

That a reasonable Googler posted a reasonable argument somewhere about why Google made the internal decision has no connection to this discussion. If Daniel's rationale is why Google made the decision, Google should by all means post it on the page above.

As a footnote, most companies I know which use AGPL code keep a clean bright line between AGPL and non-AGPL. That's a pretty sensible policy. AGPL is mostly used for things like stand-alone apps, which don't link to anything, rather than for things like libraries which link to internal systems. People contribute code to AGPL projects without hesitation if there's a bug.

Can you explain what about Daniel's explanation is incompatible with what's at your link? I don't see how they disagree.

> AGPL is mostly used for things like stand-alone apps, which don't link to anything, rather than for things like libraries which link to internal systems.

Right, except for when they don't, which is just as (if not more) important from a legal perspective.