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

Unfortunately, it's neither new nor surprising that a director of "Open Source" at a large company would be spreading unfounded doubt about a strongly copyleft free software license. It is ultimately against their employer's interests to be compelled to publish their modifications.

If you're playing the incentive game, you missed the obvious one: the AGPL remains completely untested in court (unlike the other one) and "FUD" is a sensible approach to managing corporate risk in the absence of established precedent. There is a lot of uncertainty about how far the AGPL's requirements will go if the license is pressed in court, and how much of a vendor's proprietary code will be "threatened" (I know this term is loaded, but think from the perspective of the lawyers).

I realize every hacker on the planet feels that they have the finer points of AGPL interpretation under firm mastery and are in a position to explain contract and licensing law to lawyers, but a vast number of lawyers at the large shops have looked at AGPL now and advised caution in dealing with it nearly across the board. If you want to characterize that as "unfounded doubt" (which I've translated to FUD for you instead of pressing you on what "unfounded" means without precedent), you're not technically wrong, but it polarizes what is otherwise a reasonable position of uncertainty on a significant amount of corporate risk. There are people who spend their entire lives managing risk, and hackers are very quick to dismiss such concerns -- even beyond AGPL, a number of various risks could rapidly unravel an entire corporation, and I'm often in conversations where the solution seems obvious to an engineer.

The term FUD itself is dangerous, because very often uncertainty is a perfectly valid approach to a legal problem such as licensing. Belittling uncertainty by equating it to fear creates the flawed impression that we should all act rashly all the time. Sometimes caution is good, even if it's the other side of a debate you feel passionately about, and polarizing it will not help you win over the cautious folks. Understanding their concerns and meeting them at the table will go much further.

Knocking open source groups at large shops with scare quotes like that is a bit weird, too. So Yahoo! starts an open source team, speaks openly about their thinking around licenses, generally invests a lot of thinking in license compliance and how to contribute back (Yahoo! is one of the bigger contributors to FOSS that I can think of -- hello, Hadoop?), and then after all that, free software advocates make comments like this one and cast some aspect of the work as hostile to free software. That seems self-defeating to me and I wish this whole conversation were less polarized, given that most companies don't even have an "Open Source Intern."

Isn't this just a problem with common law? In Civil Law, I would imagine the license in itself would be enough information, no?

No, because there's never been a ruling on legal interpretation of some significant clauses in the AGPL, some of which can create unexpected exposure of IP in unkind interpretations. You are correct in that people licensing under the AGPL are entering into what they feel is their interpretation, but a conflict over the terms of the license has not yet been decided impartially, meaning there is still uncertainty over how such a conflict would play out if pushed. Even for most companies with a progressive FOSS policy there is still a vast ocean of proprietary code and systems, and many companies (including both large companies who have studied the issue in my own career) have decided the uncertainty of that IP exposure is enough to forbid usage of AGPL software in totality.

This is not uncommon in the industry. To preempt that this attitude entails a hatred of free software or GPL-style licenses, I should point out that the same legal teams often approve GPLv3 software (which can be equally contentious).

Applications are open for YC Winter 2019

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