The AGPL is an underrated licence. It solves the problem of $bigCorp taking free software, making significant improvements and then renting network access to that improved version without providing their changes to anyone. That's unfair.
In practice, $bigCorp is happy to publicize all of the changes they make to this software.
They can then focus on out-competing anyone by offering a cheaper and/or better integrated managed version then the original creators can. This is explicitly why Mongo moved from the AGPL to a custom non-FOSS license; Elastic followed suite and skipped the AGPL altogether for a similar license.
Overall, $bigCorp love having any changes they make in upstream: less maintenance burden on them for the parts that are not in their direct business, more time spent on working on their value-adds.
Are you writing a library that you want to be kept open when used in a project? GPL will do what you need.
Are you writing an application where communicating over the network isn't a meaningful part of its operation? GPL will work fine.
Are you writing a library or application where communicating over the network is a significant part of its operation? Yeah you probably want to use the AGPL instead. Even then, depending on where it is running, GPL might still be fine. JS on a client? GPL will be fine. JS on a server? You need AGPL.
Really it comes down to:
Does the user interact with this software with a network between them (i.e. user <--> ??? <--internet--> software)? If yes AGPL, if no GPL.
Anytime a vendor sees a GPL3 library, all they have to do is make a network service out of it and the GPL3 license is powerless.
So AGPL3 as the default for strong copyleft software seems reasonable.
As an engineer I'm not going to use an RPC to do an FFT, populate a native UI, access some device, or manipulate a datastructure. Instead I'll just use a tool/library that does what I need while staying in the application's address space.
The disconnect I think is that I work on a lot of embedded software and native applications. In the world I am in, the hoops needed to allow a library to bypass the GPL just mean that I'm not going to use that library and that I'll do everything in my power to keep leadership from using projects with that kind of pointless failure mode.
The same goes for web apps though. If it's delivered to the client and executed by the client, it can just be GPL. They have a copy of the code and are running it. They already have to have access to a copy of the source. AGPL provides no additional protections here.
AGPL has it's place and that place is server side software. If you are writing software that the user directly interacts with and that is running on hardware the user can physically touch, the AGPL provides you no added benefit. If that's not the case, you should certainly feel free to step the license up to AGPL but there's no reason to artificially complicate license compatibility when you already know that it wouldn't be feasible for a user/developer to use your software without complying with the GPL.
> Are you writing an application where communicating over the network isn't a meaningful part of its operation? GPL will work fine.
This might be the case - although I agree with the sibling comment that a lot of libraries can be "artificially" turned into network services.
But regardless, what's the downside of using the AGPL? It's GPL + some additional restrictions, and while those restrictions can sometimes be irrelevant, I can't think of how they could be harmful to a GPL project.
I'd argue it doesn't, really. GPL means it can only be used in software released under the GPL, or any network software (ie: web application) including proprietary.
Specifically, a proprietary vendor can use and/or modify your GPL-licensed library on their server-side application and is not obligated under the terms of GPL to release any changes, so long as they never distribute the app.
I'd argue using GPL for libraries is a good way to not get much usage. Every place I've ever worked has avoided GPL like the plague -- for startups it's a barrier to pivoting (eg: selling an on-prem version) and more importantly to being acquired, and any bigger companies have policy around it.
On a personal level I also tend to avoid it unless it's either the only choice, or I want or already have released under the GPL.
In general, given two library choices where one GPL and the other is MIT, I'm an order-of-magnitude more likely to pick the MIT one, even if it's lacking features compared to the GPL one, and even contribute the missing features. I suspect I'm not alone in this.
Sure but if it doesn't make sense to use that service remotely, then just use the FOSS one instead. If the expected behavior is that the software you are writing will be running on a computer the user directly interacts with and can physically touch, it's probably fine to use the GPL.
Web services and web libraries are a whole different ball game but I'm not going to use a GUI, signals analysis/transform, data structures, CUDA, hardware interface, or other common local library if I have to call it over a network. Doubly so if I now have to fight with an RPC endpoint instead of a DSL or library in my native language.
And when I say GPL, there are a handful of different flavors. I generally think GPL+linker/classpath is a fine choice for most projects that are geared towards commercial use. I'd say LGPL is fine too and it is but there are some small differences between GPL+LE/CPE and LGPL. So for the sake of simplicity, "just default to GPL unless you have a good reason to increase or decrease the copyleft-ness".
Not to discount the feelings of others, but in a sense I only wish I could have these problems.
Also bugs due to "I didn't bother to read the documentation".
Also legitimate bugs with the attitude of "my production env is down because of this, so fix it at once".
The entitlement is strong.
When people refer to "MIT License" they usually mean the Expat License:
> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
So ... I must include the license code when I redistribute the binary of the software?
I don't care about monetization or $BIG_CORP's fascination with it. I developed this thing to stay open. It's not up for grabs.
xGPL family of licenses force contribution back of improvements, and rightfully, it's not about developer freedom, but user freedom.
Most commercial products just write some useless statement like "this software may use open source components" or include a generic MIT license without the original copyright holder statement inside.
Who is telling these companies they are doing it wrong?
Very rare when someone ever does.
These kind of things take several months of efforts by deep expert, when it is done by normal open source developers who think they know about licenses and compliance, it tends to result in poor results even if the output looks "big" from a surface view.
Nor requires them to give anything back.
Putting your code in MIT license is basically slogan "take all of it and give nothing back". Which is why so many corporate developers push for it, no lawyer to talk to when you take MIT-licensed code to use in your project.
> much unlike open-core GNU licenses that promote CLA-s and thwart any competition.
There are no "open core GNU licenses". It is just perversion of the idea and abusing the fact some of them are not restrictive enough that you can still have paid parts that are closed source
The copyleft licenses don't require to give anything back either, they only require to give source code forward to downstream users, who may or may not contribute back upstream to the original project.
If your stuff is complex enough, then it should be easy to outcompete any improvements made by organizations. SQLite, for example, has multiple proprietary tests [1]. Corporations can try to improve on SQLite, but without these tests and the knowledge of Richard Hipp on their side, it will most likely fail.
Deploy if you dare: https://github.com/readthedocs/readthedocs.org
To maintain open source over a long period of time, some durable competitive advantage is probably required yes. With such a moat, competitors can be beaten. Luckily, being open source is also a small moat since it avoids vendor lock-in and some businesses need vendor lock-in to survive (I'm looking at your SAP).
> If Richard gets hit by a bus, and the community tries to keep the project alive according to free and open-source principles, then they’re going to face all the same barriers that a corporation would :/
The project sits inside Richard's company and the company has some other engineers working there.
Personally I go the (A)GPL way all the time.
Yes.
> There is nothing inherently wrong in both positions.
Also, yes.
Hope more people understand this clearly.
> Personally I go the (A)GPL way all the time.
Me, too.
As a developer and end user I cannot use a lot of software because it's compiled into closed source stuff or in locked down devices, thanks to MIT.
On top of that such software and devices are even spying on me. While I'm busy contributing to FOSS for free.
Making the code anything but MIT just means it’s not used at all, not that companies will suddenly start publishing their source code.
The "commercial entities" built 99% on stuff that they got for free ?
How about they keep their 1% of the stuff that was made wholly by them, but give back the 1% of the code they changed in 99% they took ?
No. But GPL at least gives me the ability not the be a cow to be milked and then butchered.
> Making the code anything but MIT just means it’s not used at all, not that companies will suddenly start publishing their source code.
If freeloaders don't use my software it's still better than nothing.
But for larger, more complex projects that have significant skill -- projects that might take man-months to man-years for someone else to replicate -- I tend to want to use copyleft licenses.
And its unsustainable model of development. You need contributions and developers willing to help with maintenance and development otherwise your project will stagnate and no one will use it(xfree86).
I see only one case for permissive licence use, a reference implementation of something. Where it's purpose is for people to take it and incorporate it into their codebase without any changes(or minimal). It have problems with vendors taking source and extending it with their secret sauce(Unix wars, Kerberos(?)) but advantages are greater than potential abuse.
Maybe also a case when you drop code and run in other direction(with no or minimal maintenance). It's not great development process either.
>Right now, 99% of what I write ends up MIT because I just want the shortest and most permissive license for others to use what I create without bothering me.
You still need a lawyer evaluate any licence even short ones. Short ones have problem that they leave more to interpretation/relie more heavily on copyright law/patent law/their interpretation can widely differ based on jurisdiction etc.. So while they can be shorter, interpretation can be as hard as long ones. Especially if copyright owner is hostile.
> Not to discount the feelings of others, but in a sense I only wish I could have these problems.
You started comment with desire for others to use your software. But people won't use it if it's stagnating, lacks features or is unreliable. Especially if proprietary fork covers this problems. To stay relevant you need contributions and development time. And getting contributions can be hard if licence doesn't enforces giving back.
On the other hand, if they take my code and make some changes to it, and then sell access over a network, I want those changes to be brought back upstream.
So to me, something like ALGPL (does that exist?) or A-MPLv2 would be ideal. Then again, I mostly write computer vision pipelines, which are very much on the library side.
I don't have strong opinions for or against AGPL, I'm just not really too sure why the GPL doesn't solve this as well.
https://en.m.wikipedia.org/wiki/Affero_General_Public_Licens...
It solves the "Amazon issue" where company can take open source software, change it, then offer as a service without giving sources.
Under GPL you don't get binary if you access a service provided by open source software so you are not entitled to source code of the application
Under AGPL just interacting with the software is enough for company to have to provide the source code.
Yes. That part is covered by GPL. So, you have to share these changes anyway.
Since the code only runs on my server then no user has the right to request the source code. This is why AGPL is a dangerous extension to the GPL
You are free to implement it yourself instead of using someone else's AGPL code.
In other words, whether you let me download and run the software locally, or you let me run the software remotely on your server, you always need to provide the source code.
Don’t like these conditions? Then don’t run the software. No one is forcing you to run it.
The AGPL is dangerous because it redefines the meaning of "running" a program by extending it beyond your own devices. Of course the AGPL can have its uses as I already explained, but it should not be considered a free license
Like Nextcloud, for example.
Would I like a world where people are always entitled to know what code runs on devices they don't own? Absolutely not.
There's nothing inherently wrong about telling people "Hey, this is the code handling your data, come see for yourself".
And, this is a huge win, and show of confidence, if you ask me.
AGPL is meant to apply the 4 freedoms to anything that is _used_.
By default you are entitled to run only code that you wrote yourself.
You need the copyright holders of anything else to grant you the right to run their code.
Microsoft usually grants the right behind payment.
AGPL authors grant you the right on the condition that you share your changes (if you do any changes) with your users.
If you choose to disobey the terms, two things can happen:
1. Nobody notices and nothing happens.
2. You can be taken to court.
> but it should not be considered a free license
Why not? Which of the 4 freedoms is it taking away?
“The AGPL includes additional [requirements for businesses / freedoms for end-users] which are not included in the GPL” is a feature, not a bug.
If as a software author you want companies to sell access to your software, but without sharing the source code, use GPL. If as a software author you want companies to sell access to your software with sharing the source code, use the AGPL.
If you’re running a company whose business model is “sell access to open-source software”, then it’s up to you if you want to build your business on top of GPL or AGPL software, and if you don’t like that license, you don’t use that software.
The copyleft licenses don't require to share the source code publicly, they only require to give source code forward to downstream users, who may or may not contribute back upstream to the original project. In the AGPL case, that would be only users that you let have network access to the modified AGPL software.
This seems like a reasonable set of requirements to me.
As with the GPL it should be noted that by default linking to [A]GPL code (e.g. by installing it with a package manager) constitute a modification.
So unless the [A]GPL code includes a linking exception your code must be [A]GPL if there is anything [A]GPL in you node_modules folder.
And you are obliged to share the changes you made to the source code publicly. You can share the way you choose, but you have to do it.
Otherwise you’d be fine not distributing it at all (besides some occasional internet outrage).
The copyleft licenses don't require to share the source code publicly, they only require to give source code forward to downstream users, who may or may not contribute back upstream to the original project. In the AGPL case, that would be only users that you let have network access to the modified AGPL software.
Well, you're running the upstream software in that case, so you don't have to share anything, which is logical.
> The copyleft licenses don't require to share the source code publicly, they only require to give source code forward to downstream users...
Well, if you're distributing the software to downstream users via network, you need to share the source code via network. It's also logical and straightforward.
You can't tell that it's GPLv3 and binaries are here, but I won't give you the source. You have to.
If we were in 80s, I'd happily mail you a check and envelope to mail my floppies. One optional set for binaries, and one set for the source.
In both cases the practicality is the same.