AGPL License
en.wikipedia.org
en.wikipedia.org
Does anyone have any experience with this? Are there pitfalls to using the AGPL for a regular program that I'm not thinking of?
https://itextpdf.com/en/how-buy/agpl-license
Since our product was proprietary, we had to remove the library since our product would also come under the AGPL license or we would have to buy their commercial version, for which we can get a "quote"(https://itextpdf.com/en/how-buy)
Why wouldn't iText deserve your money if you were using it in your commercial product?
Because they're not even saying how much money. "Call us for a quote" usually means "Let's start the sales dance in which we try to gauge how much we can fleece you for", which also means it's not going to be a quick answer.
For me it means the software is immediately categorized as "to be considered only once all other options have been exhausted".
The request a quote style of pricing is almost exclusively for corporate buyers. It allows them to go out to lunch and get the purchasing department involved and make management feel like an important part of the process.
A developer might be quite willing to go to their manager with, "Hey, can we buy X? It will cost $Y, and save us $Z worth of time." But "Call for a quote" is a quagmire: They can't (and don't want to) negotiate prices themselves, and they also don't want to annoy their boss by causing them to spend the next 3 months being hounded by sales people.
"Call for a quote" means they expect to have their sales staff talk to your management or procurement department to negotiate a price, do a face-to-face meeting if possible, so they can see how much you're willing to pay.
From their background section: It is a fork of iText version 4, more specifically iText svn tag 4.2.0, which was hosted publicly on sourceforge with LGPL and MPL license headers in the source code, and lgpl and mpl license documents in the svn repository. Beginning with version 5.0 of iText, the developers have moved to the AGPL to improve their ability to sell commercial licenses.
But if that's not a concern then I would agree that AGPL is exactly how the GPL should look like in the age of SaaS, PaaS and all the other ?aaS.
You're right about GPLv2 though.
If you license all of your code under the AGPLv3, you will at least see if someone is using it out in the wild and maybe even get some contributions to your project.
To me, the biggest problem with the AGPL is that nobody really knows what the implications are. A lot of people say a lot of things, but that's all we have. I find it to be a greater burden to figure out what the license actually means than to just pick another software system that uses a permissive license. Large companies like Google seem to agree with me.
Not sure where to find a good list of who allows what.
The latter makes sense. The former does not, as you can relicense any time you want.
It’s also why you shouldn’t sign a CLA if you disagree with that possibility.
Not that I sympathise with Google here, they can afford to give something back to FOSS (not just when it advances their agenda).
The goal of this license is to encourage more companies to contribute to open source, not to encourage usage.
The problem I have is that I think truly free software is relatively unsustainable. Look at Docker's financials after basically revolutionizing how software is distributed and deployed. Look at big projects like Kubernetes; do you think you would convince investors to fund a project with a pitch like "we're going to give it all away for free with no encumbrances". Nope. It only works when you already made money from writing proprietary software. The AGPL attempts to be a middle ground, which I do respect. I am personally afraid to touch it. So are many other people.
Its goal is not to help corporations, but to give end users freedom to control software they use.
No, this is wrong. The OSI has the AGPL in its list of approved licenses. https://opensource.org/licenses/AGPL-3.0
When discussing the goals behind AGPL, it definitely shouldn't be described as Open Source license (although it technically is one), but a Free Software one, since the whole difference between those two terms (highlighting the political issue as opposed to technical one) is actually relevant to the intention behind the license.
The goal behind licenses written by FSF is to ensure that distributors of your code do not restrict freedoms of the users that the license guarantees them. If you think it's about "encouraging more usage of open source", you clearly miss the point of copyleft licenses.
If you are on the other hand in a highly competitive market then re-implementing code and delaying launches can result in being replaced by some with more flexible approach. My go-to example is the gaming industry. As an example, if you have a webbased ticket system it might not matter much if there is a download button, and developer time is much better spent on finishing the actually game than writing one more ticket system.
Game studios in general seems to have very flexible approach to licenses. To my knowledge they will apply all methods if it means saving time, as long as they can keep the game itself proprietary and sell copies. They will any software directly if they can, buy if it makes economical sense, or even just ask the author for an exception (with attribution in the credits).
Maybe you modified it to use some new data source, and to display it for internal use. Say O365 as a custom data source. You aren't giving away any real secret sauce by sharing your modifications. Anything sensitive is probably the actual data, not the code.
The license warrants caution. But not an outright ban.
The problem with a policy of "AGPL is allowed sometimes but not others" is who makes the judgement call on when it is appropriate and when it isn't? Can you trust the engineer implementing/consuming the component – and the average engineer isn't very familiar with licensing issues – to make that judgement call, especially when there could be significant legal and financial risks of getting it wrong? Probably not. So then the policy has to be "you can use AGPL but you have to ask for approval".
But, that's not too different from an AGPL ban – most bans have a process to ask for an exception. And, in practice, it de facto amounts to a ban, because most people will probably decide to just use some non-AGPL alternative instead of asking for formal approval (which probably has to go via legal and relatively senior management).
https://redmonk.com/dberkholz/2012/09/07/opening-the-infrast...
https://softwareengineering.stackexchange.com/questions/5803...
1. If you have code, let's say FooProject, that's AGPL. In which of these scenarios is someone in the wrong for using it?
1a. Google uses FooProject in delivering one GoogleApi, but does not opensource GoogleApi with AGPL.
1b. Facebook uses FooProject in an internal project, FacebookInternal, that's not exposed to the internet, but does not open source FacebookInternal with AGPL.
1c. Microsoft uses FooProject in a special version of Office, which is only distributed via BluRay and does not open source Office under AGPL.
1d. Netflix uses FooProject in AlienNetflixViewer, which is used over the internet, and makes some modifications to FooProject as its used in AlienNetflixViewer. They open source ModifiedFooProject under AGPL, but not AlienNetflixViewer
2. If you have FooProject, and you have 3 libarires, LibraryOne, LibraryTwo, and LibraryThree included in FooProject that are under the MIT license, can someone take Library[Number] and use it under the MIT license? Let's assume these are not actually separate projects, and for all intents and purposes it's the same project as FooProject, but for whatever reason the folders associated with each library has its own license.
3. Assuming someone uses an AGPL project and does not follow the license, what's the penalty? What if its so incorporated into its project its effectively impossible to remove?
4. How do you enforce someone using the AGPL?
5. If you go to a public facing site and suspect that they're using an AGPL project (perhaps because of the nature of the API calls or the client facing JavaScript) can you demand to see the full source?
1a: Not allowed provided because of AGPL (though would be allowed if it is GPL)
1b: Allowed, provided it is purely internal (as described here: https://www.gnu.org/licenses/gpl-faq.html#InternalDistributi... )
1c: Not allowed (this is a distribution, and actually is also in violation of general GPL)
1d: Not allowed, linking against the library means using it, which means GPL violation.
2: If (x) is licenses as MIT and does not contain AGPL underneath (it shouldn't, they are not compatible), you can take X under that MIT license. Regardless of actual repository layout.
3: Penalty is a pretty grey area, and this is a civil suite, not a criminal suite. As a result it goes into damages etc
4: I reckon EFF etc. Look for "GPL enforcement" (AGPL is not very different)
5: You can try.. but I reckon only in the discovery etc for a lawsuit a judge can force them to give access to the source-code to verify your claim.
For all intents and purposes, AGPLv3 is GPLv3 with the addendum that distribution also covers "As a Service". Also.. at our company we completely banned AGPL because we simply don't want to deal with any potential violations. So I reckon 1b in your example would also not happen in a place like Facebook (I reckon all 4 companies have an AGPL ban in place :) )
> 1a. Google uses FooProject in delivering one of its GoogleApi, but does not opensource GoogleApi with AGPL.
Depends. GoogleApi may fall under any of these three cases:
i) is considered a covered work (A "covered work" means either the unmodified Program or a work based on the Program.), then it must be AGPL, therefore it falls under paragraph 1 of section 13, which means Google must offer the source of GoogleApi and FooProject. https://www.gnu.org/licenses/agpl-3.0.en.html#section13
ii) is considered combined/linked with FooProject, then GoogleApi may be AGPL or GPL (paragraph 2 of section 13). If it's AGPL, then same as point i; if it's GPL then I believe Google would only have to redistribute the code of FooProject if modified (but not GoogleApi because GPL doesn't require it)
iii) neither, eg. if GoogleApi communicates with FooProject over an internal network: then I don't know.
> 1b. Facebook uses FooProject in an internal project, FacebookInternal, that's not exposed to the internet
AGPL only considers users (ie. people who can access the software): "your modified version must prominently offer all users interacting with it remotely through a computer network"
> 1c. Microsoft uses FooProject in a special version of Office, which is only distributed via BluRay and does not open source Office under AGPL.
Basically the same as GPL: "You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License" https://www.gnu.org/licenses/agpl-3.0.en.html#section6
> 1d. Netflix uses FooProject in AlienNetflixViewer, which is used over the internet, and makes some modifications to FooProject as its used in AlienNetflixViewer. They open source ModifiedFooProject under AGPL, but not AlienNetflixViewer
see 1a
> 2. If you have FooProject, and you have 3 libarires, LibraryOne, LibraryTwo, and LibraryThree included in FooProject that are under the MIT license, can someone take Library[Number] and use it under the MIT license?
That's the definition of them being under MIT license.
> 3. Assuming someone uses an AGPL project and does not follow the license, what's the penalty? What if its so incorporated into its project its effectively impossible to remove?
licenses like AGPL grant the right to use software if the user follows certain restrictions. ("user" means developers using the code, here.): All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program." https://www.gnu.org/licenses/agpl-3.0.en.html#section2
If you do not follow these restrictions, then you do not have the right to the software, so it is a copyright violation.
> 4. How do you enforce someone using the AGPL?
Sue for copyright infringement, because someone used your program without permission.
> 5. If you go to a public facing site and suspect that they're using an AGPL project (perhaps because of the nature of the API calls or the client facing JavaScript) can you demand to see the full source?
I don't know. All I can find is that: "If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so."
So: 1a. violation
1b. ok if used internally and employee doesn't request the code
1c. violation, doesn't matter here the fact that is AGPL, is a violation also for the standard GPL
1d. if AlienNetflixViewer uses FooProject is derived work and thus must also be released under the AGPL
2. yes, as long you use only the code with the MIT license you can do that under their license
3. he can be sued for violation of the copyright. In practice it's rare that he will get any penalty in real life, especially if we talk about a big corporation...
4. Same as previous answer, in theory you can sue someone if he violates the license
5. Again, if you suspect a violation of the AGPL you can try to sue them. But it's rare that you will get anything done, also if someone is not stupid he will use the code under AGPL and masquerade that, so you will have no way to know (it's difficult to know if someone violates the GPL, good luck finding someone that violates AGPL).
In practice AGPL is a license that is practically impossible to enforce.
1) What would a judge/jury perceive as the full copyrighted work, in contrast to individual parts.
2) In all copyright cases there is a author who can enforce copyright. People who want permission to do something which copyright would make illegal need to prove that they are in compliance to the conditions, and its on them to raise the fact that they have a legit license.
So to give some quick answers, if judges would see googleapi as the "complete work" then the author of the AGPL could sue Google for not having a license to use FooProject in GoogleAPI.
AGPL do have some exceptions which allow internal use, so facebook could raise the AGPL in court and say that the license do give them permission to use FooProject in facebookInternal. It would also depend on the question if the judge/jury perceive FacebookInternal as an individual work or as a part of facebook itself.
The AGPL is an additional condition over GPL that restrict work that has an interface that get accessed over a network. The condition would unliekly apply for microsoft BlueRay, through the GPL part would.
If Fooproject is a part of AlienNetflixViewer then AlienNetflixViewer need to be under AGPL.
When the FooProject is distributed the AGPL license also apply to the MIT licensed parts. If people use the MIT licensed parts exclusively then they only need to follow the MIT license.
If a person does not follow the conditions under the AGPL then they do not have the permission for which the license grants. A person who do not have a permission to distributed a copyrighted work and still do it commits the crime of copyright infringement and depending on where, why and what get fined or risk imprisonment. If it is so incorporated into its project its effectively impossible to remove then you either get permission from the author or stop distributing the copyrighted work.
Enforcement of copyright depend on local law. It could be as simple as going to the police and file a police report, but usually it involves getting lawyers involved.
If a user suspect that someone is infringing copyright then they could inform the author. Knowingly accessing copyrighted material from an illegal source could also be illegal, depending on local law.
If the only link between my software and AGPL software is through SAML (and the customer DB), is there any "link" between the two programs for AGPL purposes?
"It is not worth the trouble to use copyleft for most small programs. We use 300 lines as our benchmark: when a software package's source code is shorter than that, the benefits provided by copyleft are usually too small to justify the inconvenience of making sure a copy of the license always accompanies the software."
[0] https://www.gnu.org/licenses/license-recommendations.html#sm...
With libraries it's obvious that you are doing it for the benefit of application developers and most of those are proprietary but they are not competing against you, they are collaborating. Therefore a permissive license for libraries is a much better choice.
https://www.zerotier.com/on-the-gpl-to-bsl-transition/
Lots of open source people don't like it as it is not technically an OSI open source license. I'm not in love with it either, but it was the best solution available for now. We are exploring other alternatives.
The problem with the AGPL is unfortunately that it has the letters G, P, and L in it.
You'd be shocked to learn just how many potential customers have no-GPL policies or are otherwise just allergic to the GPL. There is a lot of FUD and misconceptions out there. Lots of companies won't allow anything GPL to be used internally in connection with any code or product. (Linux seems to get grandfathered in, but they don't like GPL for anything new.)
Most of this is fallout from Microsoft's 1990s - early 2000s anti-GPL FUD campaign, and the memes from that are still circulating. Lots of people think GPL code is "viral" in the sense that if it touches your code in any way whatsoever it somehow magically GPLs it. MS spent millions to muddy the waters around the GPL.
Yes it's FUD and it's typically rooted in misconceptions, but it's very common and from a sales point of view it's a waste of time to try to fight it. It's hard enough to educate customers about your product without also having to educate them about the license.
If it weren't for this issue we'd consider AGPL, but it's really not perfect.
What we really need is a modern license that addresses the "SaaSification" phenomenon, which AGPL does partly but not fully, while at the same time being simple to understand and compatible with as much of the rest of the OSS ecosystem as possible. AGPL is more complicated than I would prefer while also not being quite the right thing.
I'm starting to think we'll have to make one. If we do we will open source it for others to use.
Please consider adding a non-commercial use exemption, for charities and academic research. These organisations can't afford the cost of open-sourcing their entire project.
> Open Source is Not About You
> The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects.
Yes, "dumping source code" is simple and cheap. Managing the implications of doing so are not. I know of many cases where companies backed away from open sourcing software due to the overhead it would entail, even when they could afford it in principle.
As a couple elementary examples, it greatly increases your exposure to claims of patent and copyright infringement based on the actions of your employees, both intentional and inadvertent. It significantly increases the risk that the company's trade secrets and other non-public IP accidentally end up in the public domain. You must ensure that open sourced code does not come in conflict with contractual agreements with other parties. And that is after you get every outside stakeholder in the business's strategic objectives to sign-off on it, which isn't always easy.
When an organization decides to open source a bit of code, they have to run a formal diligence process to ensure there is minimal risk of any of the above and then put a process in place to help ensure that going forward. I've seen this process at multiple companies, it is not lightweight and involves lots of lawyers and documentation that would never happen otherwise. Many companies decide it isn't worth the money or distraction.
Who cares, as long as you make it clear that it's a pure research project?
The problem with Actix was that they marketed it as production-ready.
A charity might have a public but internal management system for staff or related organisations to organise on.
In either case, being open source increases security risk.
The data being processed (personal info) has nothing to do with the source code. You can release the code while keeping the data private.
There's non-trivial risk there, enough to make it an ethical concern.
So, in order to use AGPL software, you have to open source your entire source code, which means you have to go through a long and arduous risk assessment which will likely decide you can't.
There are a massive number of systems that are completely bespoke for small organizations or even individuals, and their user base isn’t going to grow.
What’s more, these systems are extremely liable to rot- the contract developer writes the system and moves on. That means library versions in the repo aren’t going to get updated when new vulnerabilities are found. So now this random 1 GitHub Star system is siting unpatched out for anyone to see.
Now what might have been a hard to find but exploitable issue risks getting a black hat spotlight shown in it.
Many academics and charities don't provide services, so it doesn't affect them.
When you write "enough to make it an ethical concern", is that a hypothetical concern of your own making?
Many academics must go through institutional review boards or other ethics committees.
Many academics also develop and distribute free software for analyzing sensitive data where IRB oversight is required.
If what you are saying is a real concern, then I expect it would have been brought up long ago.
Can you point to examples?
I believe your argument is equivalent to those saying that Linux-based free OSes cannot be used for secure platforms because the source code is available, so anyone can potentially break in.
So why is it that many people doing research which requires IRB oversight use Linux-based OSes?
I agree with tokai - you're arguing for security-by-obscurity, and there's no evidence that that increases security.
I think the evidence shows that the ethical concerns you suggest don't actually exist.
This is blatantly false. Any claim that closed source is provides any form of security is entirely a claim in security by obscurity.
If open sourcing your code presents any risk to sensitive personal information, then that means that you are already grossly mishandling this information. Whether or not your open source your code at this point doesn't matter—the harm is already done.
This is also clearly false.
For example, take this scenario:
- You use web framework Omega, but minimise indicators of this (suppress HTTP headers, etc).
- At 2am, a critical security vulnerability is discovered for Omega and a patch is released shortly after.
- Malicious actors scrape GitHub to find sites that use Omega, and try compromise them.
- At 9am, you apply this patch.
If your project is open source, there is a 7 hour window where you are clearly and publicly broadcasting that you are vulnerable.
If your project is not, there is a 7 hour window where you are vulnerable, but this is not easily apparent to attackers.
How would you prevent this risk?
Well - unless there is a targeted attack _against you_. In this case the attacker will search for known vulnerabilities in Omega and maybe even try to come up with some new ones. Having source helps the attackers here, but then again, it has helped researchers fix the vulnerabilities too. So it's a mixed blessing.
Attackers either flood you with every attack under the sun, or tear your site apart and will know exactly how it works.
Imagining that you can hide the function of your site is again security by obscurity.
The key idea here (I forgot the name of the law, but others' mentioned it in the tread) is that regardless of what you do, the adversary will end with complete understanding of how your system works.
Therefore, any security based entirely on the adversary not learning about implementation details is entirely defective.
Furthermore, an attack exists for days, months or even years before fixed, it takes time to fix and release, and it takes time for you to discover the advisory and deploy.
You were not vulnerable for 7 hours. You were vulnerable for weeks, months or years.
AGPL requires open-sourcing your entire project (authentication, payment platform, etc) just to link to a backend PDF processing library.
AGPL does not have a linking exception.
Might also be a startup idea: AGPL servers as a Service. Someone else runs it for you, you make requests against it.
I think in these cases one should try to understand what the IPR holder had in mind when they picked AGPL and not for example GPL or Apache. Trying to find loopholes might just get you into trouble in future.
Any charity that goes out of its way to produce proprietary software doesn't deserve anyone's money to begin with; they're wasting funds.
The product of government-funded academic research is already primarily going to private, for-profit journals, being effectively stolen away from the taxpayer. Proposing that we should make it easier for academic research to completely ignore the common good is ridiculous.
- if I allow users to use an AGPL product on my server and that AGPL licensed product connect to a commercially licensed application server or database on my intranet, will that be a problem?
- will it be a problem if the commercial application server connects to the AGPL licensed product to fetch data?
Except for these two points I now feel I'm starting to understand the AGPL, kind of.
1. Same application, dll linked
2. Same computer, IPC linked
3. Different computer, HTTP/etc linked
Companies that use AGPL will tell you that all three are covered by AGPL.
More reasonable people will tell you that 1 is definitely covered, and 2 is a grey area.
Only a court can make the final decision about whether a work is a derivative work or not. As developers we need to use our common sense to determine whether what we are doing is creating new or derivative works. We've seen from Google vs Oracle that it is not necessarily clear cut as to the extent a work is covered, which is why you should never assume that it's OK to ignore license terms for some perceived "grey area," and if you have any doubts, you should seek a professional opinion.
Generally, no. The AGPL work is a distinct work and not a derivative of the commercial work. You can redistribute code copies of this AGPL work even if such copies are useless to others because they don't have access to your other application which it communicates with. Nobody can prevent you from licensing your own works however you wish.
This question is more about the proprietary work rather than the AGPL work. Does the proprietary license allow you to make it available to others over the network? If the proprietary work is your own, there are no problems, at least on your part.
The problems may arise for users of your AGPL work though. They face uncertainty as to whether the proprietary work being accessed is covered by patents, or whether its API is covered by copyright - and thus, are unlikely to use your AGPL work without completely replacing the parts which communicate with your own service.
> Will it be a problem if the commercial application server connects to the AGPL licensed product to fetch data?
If the commercial application is internal to you or your business, there is no issue connecting to AGPL works.
If the commercial application is made available over the network, then the question comes down to whether it can be considered a derivative work of the AGPL work or not.
As I understand Stallman's free software philosophy -- the GPL -- the idea is that code must respect the person running it / using it.
Under this philosophy, if I am communicating with you, it's not up to me what tools you use in formulating your responses. And whether those tools respect your freedom or not. So GPL only applies to those directly using the code, not others they interact with using the outputs of that code.
I'm wondering if the AGPL is supposed to come from a different philosophical foundation, or if it would be better understood as an economic / power-structure tool?
Nowadays people run code remotely, and GPL didn't take that into account. AGPL is still about giving users freedom to control the code they use, and works regardless whether the code is run on a local machine or a remote server.
I’m all on board with copyleft in general, but the “service provider loophole” just seems like anti-business sentiment. People using modified free software to provide services useful enough to pay for is a good thing.
Forcing someone to publish their own changes simply because they run a business always seems to me like violent coercion, using copyright as a stick; much moreso than forcing someone to release source for object code they are already releasing.
Free software is a tool. Using that tool to create a successful business isn’t cheating anyone out of anything.
The software is absolutely not free as in freedom if I have one set of rights with the ethernet cable unplugged and a different set of rights with the ethernet cable connected.
Stop the service provider hate and avoid the AGPL and AGPL software.