3 ms·

> most people do not have any conceptual qualms with the AGPL. Some claim that if AGPL is very toxic, and that even viewing AGPL code might taint any project y

by bb88 3y ago

> most people do not have any conceptual qualms with the AGPL. Some claim that if AGPL is very toxic, and that even viewing AGPL code might taint any project you work on later. The reasoning goes that if you see something useful in an AGPL project and decide to use it (not copy and paste but actually recode it from scratch), the AGPL license follows that code in your head. It's not dissimilar to a certain argument of patents. The more you read patents the more liability you potentially have in a lawsuit, so literally ignorance is bliss.

jchw 3y ago
> Some claim that if AGPL is very toxic, Google (and other large enterprises) definitely claims this, though honestly I think the main problem with the AGPL is the mechanism by which it works, not necessarily the idea behind it. > and that even viewing AGPL code might taint any project you work on later. Never heard this before. I also have no idea why this would be any different from other potentially-not open source software licenses. > It's not dissimilar to a certain argument of patents. The more you read patents the more liability you potentially have in a lawsuit, so literally ignorance is bliss. For patents I understand why this is the case even if it's not necessarily an ideal situation, but for AGPL it's still just copyright law at play, regardless of what the restrictions are. I don't understand how this differs from other licenses so strongly.
- bb88 3y ago
  >Never heard this before. I also have no idea why this would be any different from other potentially-not open source software licenses. If code from agpl licensed product is found in a closed source SaaS offering, then the entire SaaS offering must be made open source. Copying can be accomplished through either copy/paste or mental reading and retyping. This is different from BSD where just the copyright notices need to follow the code.
  - jchw 3y ago
    Huh? I am not a lawyer, but I think you have this a bit wrong. It doesn't require that at all. AGPL "virility" is just like GPL virility. If you link to AGPL code, from code that is otherwise compatible with the AGPL, then in order to comply with the AGPL, you need to ship the source code of your entire program, with the same semantics about linking as the GPL. That does NOT at ALL mean you need to ship the entire SaaS offering, just the offending component. It does not include things that communicate with that program over the network. And that's only if that is your choice to remediate the license violation in the first place: if you really "mentally copied" some code, you can have the code in question rewritten. You may be confusing the AGPL with SSPL. MongoDB switched to the SSPL from the AGPL, wherein terms were added that would imply that you essentially do have to open source the entire SaaS offering, not just the components that make up the program. Whether this is even enforceable or not is curious to me, because honestly, it seems dubious: how can a copyright license apply to other copyrighted works arbitrarily that are otherwise unrelated? However, AGPL is even less stringent than it seems. Because it aims to be a copyright license rather than a contract, the AGPL is phrased in such a way that it is not "triggered" unless the code is actually modified[1]: With the AGPL, there are two triggers that both have to occur for the source code sharing requirement to kick in: 1. You’ve modified the program. 2. You make the modified program available to people remotely through a computer network. This is at least in part why the AGPL is arguably not that great, but it's a minor point in the grand scheme of things. [1]: https://fossa.com/blog/oss-license-compliance-expert-heather-meeker-agpl/ https://fossa.com/blog/oss-license-compliance-expert-heather...
    - dragonwriter 3y ago
      > AGPL "virility" is just like GPL virility. The usual somewhat pejorative figurative term used to describe the requirement for using the same license on derivative works is “virality”, in reference to being like a virus, not “virility”—“the quality of having strength, energy, and a strong sex drive; manliness”.
    - bb88 3y ago
      I once saw a presentation once given by a lawyer where the GPL meant different things to different communities (again I'm talking about the GPL here). I believe it was Van Lindberg that gave that talk. https://www.linkedin.com/in/vanlindberg/ https://www.linkedin.com/in/vanlindberg/ Basically the license was read differently based upon the community -- particularly in subtle ways. You can say, "Well... it's the GPL it means this and exactly this." But that presentation convinced me that different licenses can have different readings -- particularly depending upon the community. It's worth noting this is google's take on it AGPL is here: https://opensource.google/documentation/reference/using/agpl-policy?ref=fossa.com https://opensource.google/documentation/reference/using/agpl... "...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."
kelnos 3y ago
> Some claim that if AGPL is very toxic, and that even viewing AGPL code might taint any project you work on later. Oh please, that's nothing but FUD. If this were true, then working on closed-source proprietary code for your employer would taint any project (open source or proprietary) that you work on later. Clearly that's not the case. > It's not dissimilar to a certain argument of patents. It's quite dissimilar. Patents and copyright are two very different legal regimes.
- NoZebra120vClip 3y ago
  Back in the early 90s, of course the Unix wars were raging hotly. It was posited as a legal strategy by SCO attorneys, that if some developer for BSD had read Unix source code at any point, they would thereby become "Mentally Contaminated" and unable to perform clean-room development of the freely-licensed BSD systems. https://www.paulaoki.com/.admin/930108.oppose.html https://www.paulaoki.com/.admin/930108.oppose.html So some of us thought this was a hilarious concept, and some joker printed up tons of mugs, tee shirts, and baseball caps which read MENTALLY CONTAMINATED, and they sold them at the Usenix conferences for a while. It was good for a laugh.
  - bb88 3y ago
    IIRC 386BSD was very popular at the time. AT&Ts lawsuit were largely effective at pushing people over to Linux. And that's why Linux won. My friend at the time said Linux's codebase was terrible compared to netbsd....
    - NoZebra120vClip 3y ago
      There were more factors than that. One was the burgeoning hegemony of the Wintel architecture, standardized with the PCI bus, cheap disks and fast interfaces, etc. The ability of BSD and Linux to leverage this hardware figured mightily into toppling the proprietary giants of the Unix world. Some of these vendors even realized it, such as Sun Microsystems, who introduced PCI-based systems late in the game. I'd say it was a perfect storm in this regard. Sure, the lawsuit gave proprietary Unix a bad name. But that, in itself, wouldn't have been a death knell, if it weren't for these other practical factors.
seba_dos1 3y ago
Some claim that the Earth is flat too.

by bb88 3y ago

jchw 3y ago

> Some claim that if AGPL is very toxic, Google (and other large enterprises) definitely claims this, though honestly I think the main problem with the AGPL is the mechanism by which it works, not necessarily the idea behind it. > and that even viewing AGPL code might taint any project you work on later. Never heard this before. I also have no idea why this would be any different from other potentially-not open source software licenses. > It's not dissimilar to a certain argument of patents. The more you read patents the more liability you potentially have in a lawsuit, so literally ignorance is bliss. For patents I understand why this is the case even if it's not necessarily an ideal situation, but for AGPL it's still just copyright law at play, regardless of what the restrictions are. I don't understand how this differs from other licenses so strongly.

bb88 3y ago
>Never heard this before. I also have no idea why this would be any different from other potentially-not open source software licenses. If code from agpl licensed product is found in a closed source SaaS offering, then the entire SaaS offering must be made open source. Copying can be accomplished through either copy/paste or mental reading and retyping. This is different from BSD where just the copyright notices need to follow the code.
- jchw 3y ago
  Huh? I am not a lawyer, but I think you have this a bit wrong. It doesn't require that at all. AGPL "virility" is just like GPL virility. If you link to AGPL code, from code that is otherwise compatible with the AGPL, then in order to comply with the AGPL, you need to ship the source code of your entire program, with the same semantics about linking as the GPL. That does NOT at ALL mean you need to ship the entire SaaS offering, just the offending component. It does not include things that communicate with that program over the network. And that's only if that is your choice to remediate the license violation in the first place: if you really "mentally copied" some code, you can have the code in question rewritten. You may be confusing the AGPL with SSPL. MongoDB switched to the SSPL from the AGPL, wherein terms were added that would imply that you essentially do have to open source the entire SaaS offering, not just the components that make up the program. Whether this is even enforceable or not is curious to me, because honestly, it seems dubious: how can a copyright license apply to other copyrighted works arbitrarily that are otherwise unrelated? However, AGPL is even less stringent than it seems. Because it aims to be a copyright license rather than a contract, the AGPL is phrased in such a way that it is not "triggered" unless the code is actually modified[1]: With the AGPL, there are two triggers that both have to occur for the source code sharing requirement to kick in: 1. You’ve modified the program. 2. You make the modified program available to people remotely through a computer network. This is at least in part why the AGPL is arguably not that great, but it's a minor point in the grand scheme of things. [1]: https://fossa.com/blog/oss-license-compliance-expert-heather-meeker-agpl/ https://fossa.com/blog/oss-license-compliance-expert-heather...
  - dragonwriter 3y ago
    > AGPL "virility" is just like GPL virility. The usual somewhat pejorative figurative term used to describe the requirement for using the same license on derivative works is “virality”, in reference to being like a virus, not “virility”—“the quality of having strength, energy, and a strong sex drive; manliness”.
  - bb88 3y ago
    I once saw a presentation once given by a lawyer where the GPL meant different things to different communities (again I'm talking about the GPL here). I believe it was Van Lindberg that gave that talk. https://www.linkedin.com/in/vanlindberg/ https://www.linkedin.com/in/vanlindberg/ Basically the license was read differently based upon the community -- particularly in subtle ways. You can say, "Well... it's the GPL it means this and exactly this." But that presentation convinced me that different licenses can have different readings -- particularly depending upon the community. It's worth noting this is google's take on it AGPL is here: https://opensource.google/documentation/reference/using/agpl-policy?ref=fossa.com https://opensource.google/documentation/reference/using/agpl... "...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."

kelnos 3y ago

> Some claim that if AGPL is very toxic, and that even viewing AGPL code might taint any project you work on later. Oh please, that's nothing but FUD. If this were true, then working on closed-source proprietary code for your employer would taint any project (open source or proprietary) that you work on later. Clearly that's not the case. > It's not dissimilar to a certain argument of patents. It's quite dissimilar. Patents and copyright are two very different legal regimes.

NoZebra120vClip 3y ago
Back in the early 90s, of course the Unix wars were raging hotly. It was posited as a legal strategy by SCO attorneys, that if some developer for BSD had read Unix source code at any point, they would thereby become "Mentally Contaminated" and unable to perform clean-room development of the freely-licensed BSD systems. https://www.paulaoki.com/.admin/930108.oppose.html https://www.paulaoki.com/.admin/930108.oppose.html So some of us thought this was a hilarious concept, and some joker printed up tons of mugs, tee shirts, and baseball caps which read MENTALLY CONTAMINATED, and they sold them at the Usenix conferences for a while. It was good for a laugh.
- bb88 3y ago
  IIRC 386BSD was very popular at the time. AT&Ts lawsuit were largely effective at pushing people over to Linux. And that's why Linux won. My friend at the time said Linux's codebase was terrible compared to netbsd....
  - NoZebra120vClip 3y ago
    There were more factors than that. One was the burgeoning hegemony of the Wintel architecture, standardized with the PCI bus, cheap disks and fast interfaces, etc. The ability of BSD and Linux to leverage this hardware figured mightily into toppling the proprietary giants of the Unix world. Some of these vendors even realized it, such as Sun Microsystems, who introduced PCI-based systems late in the game. I'd say it was a perfect storm in this regard. Sure, the lawsuit gave proprietary Unix a bad name. But that, in itself, wouldn't have been a death knell, if it weren't for these other practical factors.

seba_dos1 3y ago

Some claim that the Earth is flat too.