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.
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.
Google's page has toxic and false anti-AGPL FUD like this:
"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."
Daniel's explanation doesn't have false FUD like this. It has reasonable legal analysis of the effect of AGPL when you have a large labor pool, which is in-line with everything else Eben, I (not-a-lawyer), or any sane lawyer would say. It's a simple distinction.
Google lies that if you so much as touch the AGPL, you risk your business imploding and the end of Google products like Maps, GMail, etc. which suddenly become open source! That's really scary! That's a lie that scares a lot of people.
There is no "viral effect" -- that's smear language designed to scare people about having a commons -- there's a share-alike. And that implosion cannot happen -- it's simply not the result of a copyright violation. It doesn't take Eben or Daniel to tell you that. If you make an accident, the worst-case outcome is you pay damages. Damages aren't a trillion dollar punitive thing -- they're designed to set things right. You pay either:
* Statutory damages (peanuts for Google)
* Profits (how much you would have made if you hadn't used the AGPL code but e.g. licensed the code otherwise)
* Damages (how much the other party lost due to your use; typically zero)
And a little bit of engineering work to remove the AGPL stuff so the violation does not continue. Then you move on.
AGPL provides no dangers beyond those of normal, licensed commercial code. If I pay for five licenses and accidentally install ten, or similar, the exact same thing happens. The AGPL is careful NOT to explode as Google describes, exactly for this reason. It's a simple rights grant. If you do X you can do Y. If you don't, that doesn't mean I can suddenly force you to do X; it reverts to traditional copyright.
There are decades of GPL enforcement actions out there, so the no precedent stuff is nonsense too; you don't need to go to a Supreme Court to understand how these things behave in the real world. It hasn't gone to a court of appeals precisely because it doesn't need to. There is little unsettled law here.
There is a little bit of ambiguity about where the line for 'derivative work' sits, but it's also not the sort of scary thing Google makes it out to be. There is some case law around this as well, just not around the AGPL. It's not rocket science to translate.
Google is trying to kill an open ecosystem, adopting exact tactics from Microsoft's nineties-era anti-Linux playbook, right down to adopting the exact same mean, dirty language to scare people. That's a nasty, dirty thing to do.
(and in the meantime, Microsoft became, by some metrics, the world's largest open source contributor; how times change!)
> Google lies that if you so much as touch the AGPL, you risk your business imploding and the end of Google products like Maps, GMail, etc. which suddenly become open source! That's really scary!
I mean, this isn't a lie though. Statically linking AGPL software, even by accident, does put all of Google's services at risk. It's not a certainty that they'd need lose, but you're denying that it's a risk. That's false.
Consider the values: We link AGPL software and there's an x% chance we have to spend 10 billion dollars in litigation, engineering effort, and fines to keep our stuff closed source. At what value of X do you make this rule?
> Damages aren't a trillion dollar punitive thing -- they're designed to set things right. You pay either
Punitive damages exist. They're a thing. Why are you pretending that they aren't?
> Google is trying to kill an open ecosystem, adopting exact tactics from Microsoft's nineties-era anti-Linux playbook, right down to adopting the exact same mean, dirty language to scare people. That's a nasty, dirty thing to do.
I don't follow this argument at all. What ecosystem is Google trying to kill? The AGPL "ecosystem", which is what exactly? You yourself keep insisting that AGPL only really makes sense for products, not libraries, so in what sense is there an ecosystem to kill? A random collection of products isn't an ecosystem.
> Consider the values: We link AGPL software and there's an x% chance we have to spend 10 billion dollars in litigation, engineering effort, and fines to keep our stuff closed source. At what value of X do you make this rule?
That X% is at most the same for using proprietary software. AGPL does NOTHING beyond an ADDITIONAL license grant beyond that. You can pretend AGPL code was Copyright (c) All Rights Reserved. Google ought to ban all software not written in-house under that argument.
In practice, since you've set the bar at $10 billion, that X% is 0%. There is no AGPL software in existence where damages would go over a few million dollars. If you're gonna swing around paranoid conspiracy theories with 10 billion dollar numbers, as you seem prone to, you should build all your data centers underground in case aliens form Mars attack. At what X% does that stop making sense? You're risking a TRILLION dollar business.
> Punitive damages exist. They're a thing. Why are you pretending that they aren't?
You're clearly not a lawyer here. You're confusing copyright law, normal business law, and tort law. Can you please name a realistic scenario where Google might be at risk for punitive damages under the AGPL?
In a worst-case, if the copyright violation is intentional, which is astronomically unlikely, you'd be looking at treble damages. Which goes from peanuts to 3x peanuts.
re: last comment. I apologize I accused Google about lying. Never confuse malice for stupidity. It's very possible Google is just being grossly idiotic. I still have vague memories of the old Google which used to hire smart people, so perhaps I just overestimated the company.....
> That X% is at most the same for using proprietary software. AGPL does NOTHING beyond an ADDITIONAL license grant beyond that.
Can you explain to me how I'd import proprietary software into google's source code repository? The concern is about source code under the AGPL. Google treats AGPL source the same way as proprietary source: you don't stick them into the source repository unless you have access under a dual (or in the case of proprietary, single) license.
> There is no AGPL software in existence where damages would go over a few million dollars.
While I was incorrect about punitive damages, you're also incorrect about "profit" as damages, it's not the lost profit of the infringed, but the illegitimate profit of the infringer. So the potential loss isn't the cost of a negotiated license, but the total profit of Gmail or Youtube or Ads or all three over the infringing period. Yes, that's potentially billions in copyright claims.
See for example the Oracle v. Google case, where the copyright claim is for $8.8 billion in damages. So we have prior art for a ridiculous sounding copyright case with ~10Bn in damages that's currently awaiting a supreme court ruling. So X is clearly >0.
> Can you explain to me how I'd import proprietary software into google's source code repository?
You grab a .dll file with a library you like, or a .so, and you commit it into git. Voila! This happens all the time.
> The concern is about source code under the AGPL.
No, the concern is about AGPL programs in general touching anything Googly. Google has batshit crazy text like this: "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." If you run an AGPL drawing program, you've broken Google policy.
> While I was incorrect about punitive damages, you're also incorrect about "profit" as damages, it's not the lost profit of the infringed, but the illegitimate profit of the infringer. So the potential loss isn't the cost of a negotiated license, but the total profit of Gmail or Youtube or Ads or all three over the infringing period. Yes, that's potentially billions in copyright claims.
No, you're incorrect about everything so far. I gave a correct explanation of how damages are calculated in this thread:
"1) How much did Google profit from the code? 2) How much did the other party lose?3) Are statutory damages greater? Pick the highest of the three. If it's intentional -- and in this case it isn't -- you triple it. You might toss in legal fees."
Profit isn't "total profit of Gmail or Youtube or Ads or all three over the infringing period." That'd be fuckadumb. Profit is the DIFFERENCE in how much Google made with the AGPL code compared to if didn't have that code (so loss in profit from a bit less functionality in Gmail/Youtube/Ads, cost of licensing the functionality elsewhere, or cost of developing similar functionality).
Java is core to Android. Ergo, potential damages were high. If Google decided to replace gmail with an AGPL email client, than you're correct. Perhaps if everyone at Google is as dumb as this conversation suggests, you're right, that might happen without a policy like this. In that case, X>0, and this policy makes perfect sense. If your employees can't tie their shoelaces, you need draconian policies to prevent really dumb things from happening. I was assuming a slip-up where a little bit of AGPL code slipped in, though. Not something like that.
The alleged logic behind it doesn't make sense, but I can see why Google wouldn't post "Our employees are idiots, so we won't allow the AGPL. We might shoot ourselves in the face with it if we did. We're installing padded walls too, because our hiring didn't work out, and we don't want the liability if someone runs into the wall repeatedly." Perhaps Google is saving face here.
> You grab a .dll file with a library you like, or a .so, and you commit it into git. Voila! This happens all the time.
This would also violate Google's source code policies. So yes, the policies are remarkably consistent here.
> No, you're incorrect about everything so far. I gave a correct explanation of how damages are calculated in this thread:
Yes, and then you later gave an incorrect (overly limited one)one.
> Profit is the DIFFERENCE in how much Google made with the AGPL code compared to if didn't have that code (so loss in profit from a bit less functionality in Gmail/Youtube/Ads, cost of licensing the functionality elsewhere, or cost of developing similar functionality)
Note I said "potential". I agree that for an accidental temporary misuse, use the value wouldn't be astronomical. But for long term use it would be. As is evidenced by the current Oracle litigation.
But note what this means: Google can't intentionally use any AGPL software in any of its products on purpose, because that opens them up to legitimately huge damages. So there's basically no legitimate business reason to import them. Accidental misuse is also potentially bad, though yes only hundreds of thousands or millions of dollars bad, not billions. But there's no upside. You can't use the software for legitimate business purposes.
So banning it is completely rational, and banning it on the reasons stated is also completely rational, because there is only downside.
I won't bother correcting legal technical errors in what you wrote, since you don't seem to care, and since I don't get paid to educate strangers on the Internet, but I will once again point out your shifting goalposts:
I never said banning wasn't rational. I said Google SMEARING, AND LYING was a dick move, and an evil move.
P.S. To make a more consistent policy, Google should ban employees from having .dll or .so files on their company laptops, and make public page about how libraries are DANGEROUS. :)
> That X% is at most the same for using proprietary software
In general (leaving out the specific $10 billion threshold, which I would agree is silly but detracts from the valid point being made), no, it's not, because AGPL software is far more likely to have lots of copyright holders who haven't transferred copyright, each of whom could sue Google, widening the litigation risk, and those copyright holders are more likely to be ideologically rather than financially motivated, which means they are more likely to pursue a case when the cost of litigation is disproportionate to the potential returns.
Years of GPL enforcement don't show this to be the case.
In either case, the outcome is damages. If I've contributed 5 lines of code to an AGPL program, damages to me are peanuts. If Google makes a reasonable settlement offer, and I decline, I'm likely on the hook for Google's legal fees.
Just looked at hg absorb. It seems like a very useful feature but I understand it is an extension by Facebook. Can't someone make a similar extension for git?
I'll see what I can do. Because it's Google code, it may not be feasible. But we have a whole team of hg developers ourselves, maybe I should bug them before putting it on you. :)
How long ago was this? And what OS? I know we're faster than unzip on some platforms, but IIRC we just found a pretty awful performance issue on...linux? I think?... that meant our parallelized approach to writing files was burning a ton of time in the kernel filesystem locks or something.
Just a few days ago. Parabola GNU/Linux-libre (like Arch Linux). On btrfs, if that makes a difference.
From what I could tell, whatever the slow part is, it wasn't parallelized at all; of 16 cores, 15 were idle, and 1 was pegged at 100% (and very low disk-wait).
I've been meaning to dig in to this more. I'd tried adding --stream, figuring that maybe it was re-compressing the entire repo; but that just lead to a warning about "server doesn't support streams" or something like that. I'll definitely try ygra's suggestion to try --pull, and if that doesn't yield good results, I'll actually dig in to the sources and see what's going on.
In any event, if you're enthusiastic about this kind of thing, we'd love to have more eyes on making hg checkouts consistently fast, even in the face of filesystems undermining those efforts. ;)
That's not really the right story. The motivating factor is that we'd like to write /less C/, not /less Python/. It's likely in the long-term that parts of the code that are performance sensitive will move out of Python, but we've been doing that for years, and we just keep finding new things to optimize as the scale of Mercurial repositories keeps increasing.
Go isn't really a huge win for hg, and it doesn't support being used as a shared library, so we couldn't easily use it as a replacement for C for native extensions. main() has to be in Go, and even then you've got two GCs in the mix which is not great.
Using rust for a shared library implementation seems like it would mean a big improvement for mercurial's tooling in the long run. Right now the options are command line invocation or using the python library (effectively puts a requirement on implementation). Though I'm not sure the integrations I'm aware of[0] would benefit from a shared library.
There's pretty broad consensus that we'd like to do Rust and not C for future extension work, but the current plan is that a pure-Python hg will also be something we support. The "rust binary that embeds Python" approach looks like a straightforward win on Windows, where we have a native .exe that embeds Python anyway. I'm not sure if that'll make sense on non-Windows, but we'll see.
I've done some poking around with milksnake, which seems extremely promising for writing native speedups.
Do you know what is the current status for Hg on PyPy? (I guess that besides portability that was also a motivation for keeping the pure python bits around.
Last I knew it worked fine, but hg doesn't tend to run long enough for the JIT to warm up enough and be an unambiguous win. Fijal complemented us on how good our C was.
I think it does work if you do chg with a commandserver in pypy.
Apache2 seems to be talking only about suing regarding the patent related to the work in question:
> such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted.
Facebook's version applies if you sue Facebook for any patent assertion.
Say you have a startup in talks to being bought by Google. The are suing Facebook because Facebook stole their ad click fraud detection algorithm. Now they'd be an additional worry about that patent claim.
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.