Earlier quoted context omitted.
> The punishment for building your SaaS on AGPL code and having court decide on the virality on a non-favorable way is much more severe, and cannot in general be immediately solved with a little extra money transferred between two companies. This is also FUD. There's no guarantee that Microsoft wouldn't stand on their rights, demand their statutory $50k/infringement, and refuse to sell you any more licenses going for…
There's rarely a singular author of an AGPL library, and that's part of the problem -- the business is not likely to have someone to negotiate with. Microsoft is much more of a known quantity, and the likely risk can be put into dollars relatively easily, compared to the AGPL situation.
The terms of the AGPL are pretty easy to comply with
321–330 of 341 posts
Re: The terms of the AGPL are pretty easy to comply with
#322Hello, While I'm employed to develop an agpl software, and I fond of this license, it's clear that with the wrong actors it can be a threat to some businesses. I'll tell you a little story that happened around 10 years ago: I got a call from a representative of Oracle, he asked me if we where using MySQL, and if I could described him how, because he wanted to help us make Better use of this tool. We where pretty happ…
Your story is a good reminder that these license questions aren't just about some holy war or ideology campaign. These are real people with real problems . We need to be more sensitive about how to structure licenses such as the AGPL. I find I don't want even to use the GPL at times. Why? Not because I want to give away free stuff to Google. Rather, because I don't want to force others to use the same license that I…
Providing the software under an open source licence was a very early choice. But what if a rogue concurrent decided to fork and hire engineers to provide it's own, better version of the soft while keeping it closed source?
The only open source licence providing protection that I'm aware of is the AGPL.
When you throw on the project your lifetime savings, it is quite a reassuring licence.
Re: The terms of the AGPL are pretty easy to comply with
#323Earlier quoted context omitted.
Under the same meeting ask the lawyer about the linux kernel and where the border is for its license. They will likely give a similar answer, through if the company relies on selling devices with a linux kernel the risk vs reward will result in a very different decision in the end.
GPL 2 has been tried in courts many times, and there is a consensus that Linux kernel's license applies to the kernel (publish your patches) and not applications that use the kernel. E.g. Go is shipped under a BSD license, not GPL, and sidesteps libc for quite a few APIs.
Re: The terms of the AGPL are pretty easy to comply with
#324Earlier quoted context omitted.
In the case of ambiguity in a contract, courts look at the intent of the parties to the contract. In almost all cases Moglen will not be a party, and at least one of the actual parties will not be aware of those talks or their content, so Moglen's talks on the matter won't really be of much use. Courts will also look at the bargaining power of the parties. If the party offering the contract is a lot more powerful tha…
It's a little more complex than that. The intent of the parties /drafting/ the contract do matter. Public writings clarifying the intent do as well.
Re: The terms of the AGPL are pretty easy to comply with
#325Earlier quoted context omitted.
>Someone writes a blog post with an 'IANAL' disclaimer on top saying that what Google's army of lawyers have gathered from reading a legal document is false, and I should favor his interpretation instead. I don't know, I'm not exactly convinced. Microsoft with their giant army of lawyers also said GPL is a cancer and they promoted this idea a lot but today Microsoft "loves" GPL. I think you can conclude that you shou…
I was not actually talking about the totality of Google's verdict about AGPL. For some projects in some companies it might just be the right license to use. Rather, I was talking about the particular example of Google Maps and PostGIS. Google's army of lawyers say: If PostGIS 'this' => Google Maps must be 'this'. And the author says, 'no, that's false'. Someone must be wrong here. And if I had to place a bet on which…
Consequently, always treat guidance from folks with law degrees with a degree of skepticism. Do your own research and ideally get your own person with a law degree to develop an opinion you can trust.
Re: The terms of the AGPL are pretty easy to comply with
#326Earlier quoted context omitted.
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…
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.
"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!)
Re: The terms of the AGPL are pretty easy to comply with
#327> Any derivative works of AGPL-licensed software must also use the AGPL. TBH, I'm interpreting this statement just like Google is: > Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. What's the definition of 'derivative work' here?
For what it's worth, the license doesn't use the term "Derivative Work". Rather, it explicitly prohibits bundling AGPL software with other software that you aren't able to license under AGPL: > You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: > [...] > c) You mu…
Re: The terms of the AGPL are pretty easy to comply with
#328Earlier quoted context omitted.
I'm a fan of the GPL etc, but in this article he is saying that in 2011, most of the complex AGPL software that would be useful to Google has a substantially similar version already implemented inside of Google. That's something I could believe about Google, especially 9 years ago. "MongoDB is probably the most prominent AGPL project, he said, but it replicates software already used within the Google back-end infrast…
> the elephant in the room that they may have to share software they don't want to This is certainly not a controversial topic for anyone working in a software company. There are always pieces of software that a commercial entity is not willing to share freely with the whole world.
Re: The terms of the AGPL are pretty easy to comply with
#329I guess if your sole purpose is to conjure money out of thinware then yes, AGPL is going to be poison to your wallet. Capitalism and AGPL simply does not mix well.
But we tend to forget, that the end of the day we're all users and have to consume what we've cooked.
As a user I tend to lean towards AGPL alternatives, It's comfty and let's me relax my legal muscle after the hard workout of summarizing this thread.
Re: The terms of the AGPL are pretty easy to comply with
#330Earlier quoted context omitted.
Your story is a good reminder that these license questions aren't just about some holy war or ideology campaign. These are real people with real problems . We need to be more sensitive about how to structure licenses such as the AGPL. I find I don't want even to use the GPL at times. Why? Not because I want to give away free stuff to Google. Rather, because I don't want to force others to use the same license that I…
Yes and no: I currently work for the editor of iTop (an open source ITSM software). Providing the software under an open source licence was a very early choice. But what if a rogue concurrent decided to fork and hire engineers to provide it's own, better version of the soft while keeping it closed source? The only open source licence providing protection that I'm aware of is the AGPL. When you throw on the project yo…
I know we all have to eat; I'm not a zealot who thinks all software should be open either. But I don't see how developers exercising a monopoly in order to extract rent is software freedom. I just want some rectification of names.