AGPL License(en.wikipedia.org)
en.wikipedia.org
AGPL License
https://en.wikipedia.org/wiki/Affero_General_Public_License
110 comments
Google can afford to re-implement software. It is questionable if they even get hurt much by release delays, especially if the new product is within their eco system. Thats the benefit of having monopoly or monopoly-like position in a market.
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).
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).
If you work in a startup, it will bite you during due diligence when a potential acquirer is evaluating your intellectual property. I would give the AGPL a wide berth.
You can always change the license.
except you cannot, once its AGPL youre stuck with it
If you're the owner of the code, all the past versions of the project are and will be AGPL forever (or MIT, or BSD) but all the new versions will be whatever you want. You can also dual license. If someone forks the old AGPL version (or MIT, or BSD) they can keep that license on the fork, but they can't use your new code.
Yes, this is why so many projects have Contributor License Agreements - so the project owner can relicense at will.
It’s also why you shouldn’t sign a CLA if you disagree with that possibility.
It’s also why you shouldn’t sign a CLA if you disagree with that possibility.
This is why I avoid AGPL projects for potential ideas / side projects that could potentially turn useful.
You avoid using it, or avoid using third party code that uses it?
The latter makes sense. The former does not, as you can relicense any time you want.
The latter makes sense. The former does not, as you can relicense any time you want.
Only if you are the sole copyright holder, i.e. no (nontrivial) external contributions.
Which is why I avoid it directly, unless I'm not touching the code at all. If I'm just using it as-is, then I don't care.
Sounds like it's working as intended: preventing services from restricting the rights of their users to run, modify & share source code.
IMO, the goal of open source licenses is to encourage more usage of open source. If AGPL is preventing companies from using it, then it is accomplishing the opposite.
Every license has different goals - that's the whole point of having different licenses.
The goal of this license is to encourage more companies to contribute to open source, not to encourage usage.
The goal of this license is to encourage more companies to contribute to open source, not to encourage usage.
A license is a legal document that specific under what conditions that the author allow others to use their software. Nothing more, nothing less. Open source licenses and free software licenses are standardization of common goals and conditions, and encourage usage is one such goal, but its not the only goal. Some authors want more like share-alike, attribution, and fair competition.
I agree with you. I am pretty sure the AGPL exists so that you get the "warm fuzzies" of "open source", but the company that wrote the software can still profit from it as though the source wasn't available. It is also administratively easier than making a "hobbyist edition" for people that want to screw around with the software in their free time in the hopes that they someday make money with it and buy the full version. (Also, in the event that you do license the software and need to make a small customization, it's administratively easier. Just edit the code and you're done, as opposed to the company having to set up a meeting with your team, looping in the sales engineer to see how much to charge you, then having a year of weekly status update meetings to see how your feature is proceeding.)
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.
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.
[deleted]
AGPL is not an Open Source license, but a Free Software license.
Its goal is not to help corporations, but to give end users freedom to control software they use.
Its goal is not to help corporations, but to give end users freedom to control software they use.
>AGPL is not an Open Source license, but a Free Software license.
No, this is wrong. The OSI has the AGPL in its list of approved licenses. https://opensource.org/licenses/AGPL-3.0
No, this is wrong. The OSI has the AGPL in its list of approved licenses. https://opensource.org/licenses/AGPL-3.0
No, this is not wrong (but you're not wrong either).
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.
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.
This! I am quite sure that most projects, in exchange for some negligible part of Google's money, would be more than happy to offer the software under a different license. My guess is that it's the difficulty of ensuring that the new license terms are not breached (the license would need to be checked by lawyers, approved,...) that is the real deal breaker.
Not that I sympathise with Google here, they can afford to give something back to FOSS (not just when it advances their agenda).
Not that I sympathise with Google here, they can afford to give something back to FOSS (not just when it advances their agenda).
It makes a lot of sense. If a lick of AGPL hits any of their web services, they have to make the source available. I imagine they use plenty of FLOSS on their back-end servers, and I imagine quite a bit is GPL, BSD, MIT, Apache and so on.
A lot of other companies have the same policy. Google is unusual in being publicly open about it. Most companies, internal policies on what open source licenses are allowed are maintained by the legal department and as such are company confidential by default.
Seems shortsighted. There are categories of software where even corporate drones shouldn't worry about AGPL. The ThoughtWorks tech radar is a decent example: https://github.com/thoughtworks/build-your-own-radar
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.
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.
> Seems shortsighted. There are categories of software where even corporate drones shouldn't worry about AGPL... 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).
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).
Same here.
Not sure where to find a good list of who allows what.
Not sure where to find a good list of who allows what.
Not sure but maybe https://tldrlegal.com/ helps
OP is speaking hypothetically- the question is perfectly valid and asks for which of the scenarios are okay.
We considered AGPL but recently adopted the BSL:
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.
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.
I license all my software under the AGPL. Best license IMHO.
Not common that you see a philosophy more radical than Stallman's.
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?
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?
SaaS is a workaround for GPL, and AGPL is a bugfix for that.
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.
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 don’t think that copyright enforcement should be used against me based on whether or not I run a webserver alongside a modified application or not.
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.
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.
Copyleft, and AGPL specifically, seems like a good fit for large applications, whereas more permissive licenses work well for smaller libraries.
I specifically use it because while I'm committed to writing free (as in freedom software), my downstream users may not be. I'd rather they didn't have more options than I do if they decide to compete against me. Free software empowers the downstream user, so I kind of think of it a bit like surfing. You potentially have all this extra energy, but that energy can crush you if you don't walk a very tight line. As the upstream author you have a bit of an advantage, but it's easy to squander it if you don't think carefully about what you are doing. I'm always a bit perplexed when people write free software but intentionally avoid copyleft. There are lots of places where permissive licenses are the right way to go, but also a lot of places where your are just creating an uneven playing field with yourself in the worst position.
I use the AGPL for user facing applications. I personally have nothing against someone taking my project and improving it as long as the project stays opensource. If they somehow manage to turn that into a business model it's fine too but what I have seen is that companies use their resource advantage to destroy the original project if it is permissively licensed.
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.
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.
For a lot of people, free software is about collaboration, not competition.
Enforcing and incentivizing collaboration also seems like a good argument for licensing open source projects with the AGPL. It prevents people who are not willing to contribute things made using your software back to open source from using it.
Using more permissive licenses for smaller programs is what the FSF recommend:
"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...
"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...
I've always wondered about whether the AGPL is a good fit for software that isn't accessed over the network. At first glance this would appear to offer the exact same rights as the GPL in this scenario, however you then have the protection of the AGPL if the software was ever incorporated into a networked program.
Does anyone have any experience with this? Are there pitfalls to using the AGPL for a regular program that I'm not thinking of?
Does anyone have any experience with this? Are there pitfalls to using the AGPL for a regular program that I'm not thinking of?
The thing about modern code is that anyone can take a project, turn it's function into a webpage, and charge money without revealing that you could run the program on your own machine.
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.
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.
This is called "SaaSification" and there is a debate over to what extent it violates the spirit of open source and what if anything ought to be done about it.
How is it different in spirit from taking a product, adding a feature to it, and distributing? It's still removing freedom from the user. That's what the AGPL is for, for removing runtime host as an excuse to not let users control their use of software.
AGPLv3 is the only solution I see.
I recently used the iText Library for PDF parsing in java.
Everything was alright until I discovered their AGPL license.
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)
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)
I'm pretty sure that's the intended effect in this case: force you to either open source your product or buy a commercial license (or use the ancient version from before the license update).
There is an actively maintained fork of iText: https://github.com/LibrePDF/OpenPDF
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.
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.
What did you replace it with?
Why wouldn't iText deserve your money if you were using it in your commercial product?
Why wouldn't iText deserve your money if you were using it in your commercial product?
> 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".
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".
I agree with your feelings on this last point. I wonder how it's working out for them as I imagine it's a turn off for corporate buyers as well as lone devs and small shops.
I imagine it's a turn off for corporate buyers as well as lone devs and small shops.
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.
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.
I doubt it's a turn-off for corporate buyers in the large, but it's absolutely a turn-off for dev teams within corporations. Especially nowadays in an increasingly Agile world where everything is due 2 weeks from when you start work on it.
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.
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.
Hunting for a replacement seems more work than making a phone call.
It's not just a phone call, of course. If they had a concrete pricing model they could just tell you on the website.
"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.
"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.
We are awaiting a response from IText for the license, but for now Apache PDFBox got us the same results
you won't use itext, their quotes are hilarious.
nonetheless, I found their library pretty easy to use and faster compared to the competitors. Sadly due to the licensing issues, I think I won't be using it for sometime ( or ever incase quote is above and beyond expectations )
Probably yes, because seems their licensing policy is not very user-friendly or straightforward.
On their How-To-Buy Page (https://itextpdf.com/en/how-buy) the licensing model is pretty convoluted
[deleted]
A potential pitfall is that only AGPLv3 and GPLv3 are directly compatible (in the sense of producing programs created from both AGPLv3 and GPLv3 code without violating either license). That's not possible with GPLv2 or AGPLv1 in any combination, and there's still some code-bases that will be GPLv2 forever.
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.
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.
That's not entirely true. GPLv3 and AGPLv3 have explicit clauses that allow the linking of GPLv3 and AGPLv3 code into a single work without violating either license: https://en.wikipedia.org/wiki/Affero_General_Public_License#...
You're right about GPLv2 though.
You're right about GPLv2 though.
But GPLv2 is the one that allows for tivoization, and whether that violates the spirit of free code does not have a consensus.
Nothing has consensus, that's why there are so many licenses.
People seem to be doing this. ArgyllCMS (cms = color management system) uses this model. I am not sure what the practical implications of this are. 99.9% of people just ship their calibration software to the user's desktop, so probably don't care if they have to make the ArgyllCMS source code available.
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.
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.
I have some questions about AGPL if anyone has answers:
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?
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?
IANAL (ofcourse) but in my limited experience:
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: 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 :) )
In practice applies the same rules as the GPL except that they cover not only the distribution of copies of the software but also the use of the software in a network service. In practice if something is considered derived work under the GPL is the same also for the AGPL, and the source code must be released to all the people that uses the service (if the service is used internally, you can avoid to do so, also with the standard GPL).
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.
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.
There is two basic principles to look at when answering those question.
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.
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.
[deleted]
On a related note, say I have proprietary software A, but want to offer my customers the ability to use AGPL software hosted by me (Redash) on their data.
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?
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?
IANAL
> 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."
> 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."
If you're considering adopting AGPL and the reason is to prevent commercial abuse of your work:
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.
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.
Why would charities and academic institutions be writing anything but free software?
I never understand this. I get not wanting to build a community around a project, handling contributions, etc. But why not just dump the source code somewhere?
Because it's huge (perceived) risk for (often) little gain. These projects (I'm especially familiar with research) aren't known for code quality and following best practices regarding security etc. So you open yourself for shaming and casual hacking for some unquantifiable benefit of open-source contributions.
> and following best practices regarding security
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.
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.
Because it’s effort. People will want you to make enhancements and maybe expect changes. It may link to proprietary libraries. Open source is not really just about dumping code on GitHub.
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
> 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.
https://news.ycombinator.com/item?id=18538123
> 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.
https://news.ycombinator.com/item?id=18538123
To be clear, if someone wants to just do a code dump under an open source license, ignore it, and send any communications about the code to /dev/null that’s their choice. Probably not a very useful one but a valid one.
The mechanics of putting a tarball somewhere on the Internet are simple and cheap, but that action also directly and indirectly greatly increases the potential for liability. This effectively requires the organization to create additional management and processes to mitigate this increased potential for liability. It is a headache many organizations want to avoid or can't afford.
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.
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.
Which liabilities? Most open source licenses come with a WITHOUT WARRANTY OF ANY KIND clause.
Open sourcing creates multiple classes of risk outside the scope of the license which any properly run company must manage.
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.
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.
Dumping the code somewhere is next to useless. NASA open-sources a ton of code (https://www.github.com/nasa), but the vast majority of it gets open-sourced at the end of a project and there's no money set aside for maintenance so it's mostly abandoned. I have one such project that I keep up the maintenance on my own time, but if I ever leave NASA I won't be able to even do that.
They could be using some third-party code/services with closed source or under proprietary/non-AGPL-compatible license, and thus they can't open-source those parts under AGPL, as AGPL demands, even if they wanted to.
A research project might be collecting sensitive personal information.
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.
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.
> In either case, being open source increases security risk.
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 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.
> If open sourcing your code presents any risk to sensitive personal information, then that means that you are already grossly mishandling this information
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?
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?
It doesn't work that way. Attackers don't check if you are using "Omega", they check if you are vulnerable. There is simply no difference if you are hiding framework indicators here.
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.
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.
This doesn't matter at all.
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.
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.
> A research project might be collecting sensitive personal information.
The data being processed (personal info) has nothing to do with the source code. You can release the code while keeping the data private.
The data being processed (personal info) has nothing to do with the source code. You can release the code while keeping the data private.
The source code will indicate where/how the data is input, processed and stored. It might help an attacker compromise the application in any number of ways.
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'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.
You only have to open source the AGPL'ed code if it's providing a networked service.
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.
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.
Security through obscurity is not security at all.
https://en.wikipedia.org/wiki/Kerckhoffs's_principle
https://en.wikipedia.org/wiki/Kerckhoffs's_principle
I’ve always felt this argument breaks down with smaller scale targets. I’d argue security through obscurity is not security, but there can be safety in obscurity.
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.
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.
They also can use and improve it and give these improvements back to the source.
What improvements?
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.
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.
Putting it in a microservice should get around that, right?
That’s the difference about the AGPL - you have to open source the things that call it too. Putting it in a microservice is literally the thing that AGPL was written to prevent you from doing to work around it
I’m getting downvoted, but this is the stance of the company behind a popular AGPL library mentioned in this comments page based on emails I received from them after asking the same question.
That might be the only way, which is kind of sad, till they patch that loophole, if it's not already patched.
Might also be a startup idea: AGPL servers as a Service. Someone else runs it for you, you make requests against it.
Might also be a startup idea: AGPL servers as a Service. Someone else runs it for you, you make requests against it.
That’s a pretty good question. And likely there won’t be a definitive answer until there’s a decision from court.
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.
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.
[deleted]
Absolute malarkey. All academic research should use and produce free software. This used to be the case; that it isn't now is terribly stupid, especially now that distribution costs have gone from "little" to "nothing." It doesn't "cost" anything to throw a tarball on the internet.
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.
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.
My questions are:
- 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.
- 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.
My understanding is you can simplify it into roughly three tiers of "connection":
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.
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.
I've recently read someone who I think is affiliated with FSF say that MongoDB(?)and others have misinterpreted the AGPL intentionally to create necessary FUD to sell commercial licenses, so this is my opinion as well but when I tried to find out on the FSF page earlier this week the was still not a word in the FAQ about it.
My understanding of copyright is that the method of linking is more of a vague guideline than any set in stone legal principle. Copyright determines whether or not some work is a derivative work of an already covered work. If you simply proxy access to a covered work through a different communication interface, but still depend on it for the essential functionality of your own work, you are unlikely to get a free pass to evade the terms of the license.
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.
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.
> 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?
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.
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.
I was thinking that ALGPL is a worthy addition. We need a licence that still applies to use in microservices and other code that is not shared with the user but still shows consideration for investment into proprietary code and only limits its provisions to the code under the given license. I would gladly license my work under ALGPL if it existed.
These references also argue for ALGPL:
https://redmonk.com/dberkholz/2012/09/07/opening-the-infrast...
https://softwareengineering.stackexchange.com/questions/5803...
https://redmonk.com/dberkholz/2012/09/07/opening-the-infrast...
https://softwareengineering.stackexchange.com/questions/5803...
https://opensource.google/docs/using/agpl-policy/