9 ms·

> AGPL is unchallenged in court. The risk to being wrong about it as huge. It’s risk aversion, not ideology, and it’s important to remember that identifying an

> AGPL is unchallenged in court. The risk to being wrong about it as huge. It’s risk aversion, not ideology, and it’s important to remember that identifying an argument as part of legal review does not call it the correct one. Anyone who’s ever worked with legal matters knows there is no such thing as “correct,” there are rulings. The existence of the argument condemns the license for FAANG, not its validity. Having worked with lawyers, this largely overstates the risk. Companies are happy to discuss, modify and sign new contracts every day. All these contracts are "unchallenged in court", by definition, because they are entirely custom. A lot of software licensing contracts for closed source have complex and restrictive clauses to prevent "renting" such software through SaaS or weakening limitations using legal loopholes. Yet companies still sign such contracts. Another type of custom and complex contract is employment. Furthermore, companies sue each other every other day over contract violation around IP, copyright, trademarks, patents but also employment contracts, rent, building regulations, shipment delays, all of that. The idea that a FLOSS license is some scary monster is propaganda. The goal of such propaganda is to drive the FLOSS community to provide valuable software for free and with zero strings attached - aka free labor.

joshuamorton 6y ago
> All these contracts are "unchallenged in court", by definition, because they are entirely custom. They do, however, very often use existing language, and custom language is minimized. > Another type of custom and complex contract is employment. Where contracts are often almost entirely standard per-company, and often standard between companies. And very rarely is the company in danger from the non-boilerplate clauses. If you want an example of such a clause, consider Google's own IP clause in its contracts, which contend that Google owns basically all of your IP while you work at Google, unless you take steps to declare ownership of it in advance (and Google approves). Will this clause entirely hold up in court? Probably not. Do you want to be the one to test it with your multi-billion dollar startup on the line? The risk of using AGPL software is significantly higher than not, and the benefits are relatively small.
- ran3824692 6y ago
  > They do, however, very often use existing language, and custom language is minimized. Guess what, AGPL does that too. Its only 1 paragraph different than GPL. > Where contracts are often almost entirely standard per-company "standard per-company", means custom and used used throughout the company. That doesn't make it less risky, and its not like these things don't constantly change and are hugely complicated, just look at privacy policies. AGPL is standard for all companies. > And very rarely is the company in danger from the non-boilerplate clauses. Citation needed.
  - joshuamorton 6y ago
    > Guess what, AGPL does that too. Its only 1 paragraph different than GPL. Yes, and the point is that paragraph is particularly risky and untested. > Citation needed. I gave an example.
    - ran3824692 6y ago
      The point people keep talking about here as risky are: what is a derivative work, and what constitutes complete and complete corresponding source definition. Both of those things HAVE been tested. complete corresponding source definition is the same in gplv3, almost exactly the same in gplv2. Derivative work is a general copyright thing tested in many cases. The extra paragraph doesn't have anything to do with them. To recap: 99% of the license is tested, and the "risk" everyone is discussing are about the parts that have already been tested. Basically, what Drew wrote is true.
      - joshuamorton 6y ago
        Derivative work and complete corresponding source has not been tested w.r.t. Google's monorepo (or similar situations), because under the terms of the gplv2/3, Google doesn't distribute any software. There's an entire class of tooling to make sure that GPL-tainted software isn't distributed (https://opensource.google/docs/thirdparty/licenses/#restricted https://opensource.google/docs/thirdparty/licenses/#restrict...), but because the class of software that Google distributes under the GPL is limited (can you think of any?), this is workable, and such things can be isolated. That doesn't work if the definition of "distribution" is broadened significantly. Then the derivative work questions (which aren't as cut and dry as you claim) do suddenly matter a lot more.
rblatz 6y ago
The remedy for a violation is also in play. Private contract between two companies, cutting a 10 figure check makes it all better. Being wrong about AGPL, you have to release a lot of code that you really don't want to release, that is very important to your core business. That's the other side, uncertainty with acceptable error bars vs uncertainty with unacceptable error bars.
- teddyh 6y ago
  > Being wrong about AGPL, you have to release a lot of code That is also false scaremongering. You always have the option to simply cease distributing until you have re-implemented the AGPL code yourself.
  - nomel 6y ago
    Unfortunately, many software companies obtain their revenue through the exchange of money for their software. This is like asking McDonals do stop serving food (and possibly recall all of the eaten burgers?).
    - teddyh 6y ago
      A company which sells that much software can certainly afford to re-implement an AGPL component; or at least implement a good enough stub implementation to make the software run acceptably. Especially if, as Chris DiBona of Google claims, all AGPL software is useless and unneeded. However, the point was that releasing the proprietary (oh so secret) source code is never the only option, and it is indeed false scaremongering to claim that it is.
      - nomel 6y ago
        > afford to re-implement an AGPL component > good enough stub implementation to make the software run acceptably This is what the company I work for does, and most that I've heard about do, but preemptively.
tptacek 6y ago
No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to. At Matasano, it became our practice simply to tell new clients we'd be happy to sign their paper and not ours, because we'd lose weeks just to get to the point where their legal would consider looking at our contracts. At my last company, we non-negotiably used our own contracts, and budgeted a month to legal review for every signup. New contracts are a big deal. And, what's more, the contracts we're talking about are all basically pro-forma. They're nothing like the AGPL, which has, in reasonable interpretations, far-reaching impact on IP across the whole company.
- debiandev 6y ago
  > No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to. [citation needed] > And, what's more, the contracts we're talking about are all basically pro-forma. I had very custom employment contracts with 2 well-known large tech companies. When asking to remove some clauses and add new ones they did not flinch at the ask and let me have meetings with their lawyers. I have many other examples but a quick search on the internet can show how many contract-related discussions happen between large companies, suppliers, local governments & so on Matasano is not the size of a FAANG and similar or maybe it has a small legal team by choice.
  - tptacek 6y ago
    The authors of AGPL packages are also not the size of a FAANG! That's the point! If they were, they wouldn't be negotiating AGPL with Google; they'd be negotiating an actual contract. (I have zero problem with AGPL and happily use it myself for things, but I use it the same way I feel most of my peers use it, as an explicit "no, FAANG, you can't use this code, pay me instead" marker.)
    - cycloptic 6y ago
      >If they were, they wouldn't be negotiating AGPL with Google; they'd be negotiating an actual contract. This would stop being true if (and when) FAANG figured out how to effectively use AGPL internally. In my opinion, this is inevitable as long as software continues to be published under this license. From their perspective it seems they don't even have to do anything besides wait for other smaller companies to get in legal disputes and set a precedent. Or better yet, wait for a potential acquisition to come along that happens to have won one of these disputes.
s17n 6y ago
Google doesn't really care that much about the FLOSS community's contributions - they have in house projects to do everything (even a kernel or two!) just because they have so many engineers. Pretty sure the main reason they don't just ban the use of open source software internally is because it would cause their developers to riot, and the cost savings are a secondary factor. If anything, Google probably would like to see more software released under AGPL just to screw with Amazon.
- im3w1l 6y ago
  The further you deviate from using a standard stack the more you have to spend on training.
  - s17n 6y ago
    Google doesn't really use any of the "standard stack". They use open source libraries for things like SSL but when it comes to the things that matter for quickly ramping up - source control, build/test infra, release management, linters, etc - basically the only thing that isn't in-house is the languages themselves, unless you're using Go or Dart, and the text editor, unless you're using their internal web-based ide.
wglb 6y ago
Having worked for a software producer who all but owns one segment of the industry, while they do discuss with their potential clients modifications to the contract, it is fair to say that the terms discussed all relate to fees. There are certain things with respect to IP that are totally not up for discussion. Additionally, every use or purchase of software undergoes strict legal review, and there are some licenses that are flat not accepted. This is not propaganda, and it is not in particular motivated to do anything economic to the FLOSS commmunity.

joshuamorton 6y ago

> All these contracts are "unchallenged in court", by definition, because they are entirely custom. They do, however, very often use existing language, and custom language is minimized. > Another type of custom and complex contract is employment. Where contracts are often almost entirely standard per-company, and often standard between companies. And very rarely is the company in danger from the non-boilerplate clauses. If you want an example of such a clause, consider Google's own IP clause in its contracts, which contend that Google owns basically all of your IP while you work at Google, unless you take steps to declare ownership of it in advance (and Google approves). Will this clause entirely hold up in court? Probably not. Do you want to be the one to test it with your multi-billion dollar startup on the line? The risk of using AGPL software is significantly higher than not, and the benefits are relatively small.

ran3824692 6y ago
> They do, however, very often use existing language, and custom language is minimized. Guess what, AGPL does that too. Its only 1 paragraph different than GPL. > Where contracts are often almost entirely standard per-company "standard per-company", means custom and used used throughout the company. That doesn't make it less risky, and its not like these things don't constantly change and are hugely complicated, just look at privacy policies. AGPL is standard for all companies. > And very rarely is the company in danger from the non-boilerplate clauses. Citation needed.
- joshuamorton 6y ago
  > Guess what, AGPL does that too. Its only 1 paragraph different than GPL. Yes, and the point is that paragraph is particularly risky and untested. > Citation needed. I gave an example.
  - ran3824692 6y ago
    The point people keep talking about here as risky are: what is a derivative work, and what constitutes complete and complete corresponding source definition. Both of those things HAVE been tested. complete corresponding source definition is the same in gplv3, almost exactly the same in gplv2. Derivative work is a general copyright thing tested in many cases. The extra paragraph doesn't have anything to do with them. To recap: 99% of the license is tested, and the "risk" everyone is discussing are about the parts that have already been tested. Basically, what Drew wrote is true.
    - joshuamorton 6y ago
      Derivative work and complete corresponding source has not been tested w.r.t. Google's monorepo (or similar situations), because under the terms of the gplv2/3, Google doesn't distribute any software. There's an entire class of tooling to make sure that GPL-tainted software isn't distributed (https://opensource.google/docs/thirdparty/licenses/#restricted https://opensource.google/docs/thirdparty/licenses/#restrict...), but because the class of software that Google distributes under the GPL is limited (can you think of any?), this is workable, and such things can be isolated. That doesn't work if the definition of "distribution" is broadened significantly. Then the derivative work questions (which aren't as cut and dry as you claim) do suddenly matter a lot more.

rblatz 6y ago

The remedy for a violation is also in play. Private contract between two companies, cutting a 10 figure check makes it all better. Being wrong about AGPL, you have to release a lot of code that you really don't want to release, that is very important to your core business. That's the other side, uncertainty with acceptable error bars vs uncertainty with unacceptable error bars.

teddyh 6y ago
> Being wrong about AGPL, you have to release a lot of code That is also false scaremongering. You always have the option to simply cease distributing until you have re-implemented the AGPL code yourself.
- nomel 6y ago
  Unfortunately, many software companies obtain their revenue through the exchange of money for their software. This is like asking McDonals do stop serving food (and possibly recall all of the eaten burgers?).
  - teddyh 6y ago
    A company which sells that much software can certainly afford to re-implement an AGPL component; or at least implement a good enough stub implementation to make the software run acceptably. Especially if, as Chris DiBona of Google claims, all AGPL software is useless and unneeded. However, the point was that releasing the proprietary (oh so secret) source code is never the only option, and it is indeed false scaremongering to claim that it is.
    - nomel 6y ago
      > afford to re-implement an AGPL component > good enough stub implementation to make the software run acceptably This is what the company I work for does, and most that I've heard about do, but preemptively.

tptacek 6y ago

No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to. At Matasano, it became our practice simply to tell new clients we'd be happy to sign their paper and not ours, because we'd lose weeks just to get to the point where their legal would consider looking at our contracts. At my last company, we non-negotiably used our own contracts, and budgeted a month to legal review for every signup. New contracts are a big deal. And, what's more, the contracts we're talking about are all basically pro-forma. They're nothing like the AGPL, which has, in reasonable interpretations, far-reaching impact on IP across the whole company.

debiandev 6y ago
> No, companies are not happy to discuss, modify, and sign new contracts every day. They are quite hesitant to. [citation needed] > And, what's more, the contracts we're talking about are all basically pro-forma. I had very custom employment contracts with 2 well-known large tech companies. When asking to remove some clauses and add new ones they did not flinch at the ask and let me have meetings with their lawyers. I have many other examples but a quick search on the internet can show how many contract-related discussions happen between large companies, suppliers, local governments & so on Matasano is not the size of a FAANG and similar or maybe it has a small legal team by choice.
- tptacek 6y ago
  The authors of AGPL packages are also not the size of a FAANG! That's the point! If they were, they wouldn't be negotiating AGPL with Google; they'd be negotiating an actual contract. (I have zero problem with AGPL and happily use it myself for things, but I use it the same way I feel most of my peers use it, as an explicit "no, FAANG, you can't use this code, pay me instead" marker.)
  - cycloptic 6y ago
    >If they were, they wouldn't be negotiating AGPL with Google; they'd be negotiating an actual contract. This would stop being true if (and when) FAANG figured out how to effectively use AGPL internally. In my opinion, this is inevitable as long as software continues to be published under this license. From their perspective it seems they don't even have to do anything besides wait for other smaller companies to get in legal disputes and set a precedent. Or better yet, wait for a potential acquisition to come along that happens to have won one of these disputes.

s17n 6y ago

Google doesn't really care that much about the FLOSS community's contributions - they have in house projects to do everything (even a kernel or two!) just because they have so many engineers. Pretty sure the main reason they don't just ban the use of open source software internally is because it would cause their developers to riot, and the cost savings are a secondary factor. If anything, Google probably would like to see more software released under AGPL just to screw with Amazon.

im3w1l 6y ago
The further you deviate from using a standard stack the more you have to spend on training.
- s17n 6y ago
  Google doesn't really use any of the "standard stack". They use open source libraries for things like SSL but when it comes to the things that matter for quickly ramping up - source control, build/test infra, release management, linters, etc - basically the only thing that isn't in-house is the languages themselves, unless you're using Go or Dart, and the text editor, unless you're using their internal web-based ide.

wglb 6y ago

Having worked for a software producer who all but owns one segment of the industry, while they do discuss with their potential clients modifications to the contract, it is fair to say that the terms discussed all relate to fees. There are certain things with respect to IP that are totally not up for discussion. Additionally, every use or purchase of software undergoes strict legal review, and there are some licenses that are flat not accepted. This is not propaganda, and it is not in particular motivated to do anything economic to the FLOSS commmunity.