One easy way is not to offer a license at all. Just like when you visit a news website, for example. No license is being given to you. You're just a consumer of the website. If you're selling a SaaS, all your work is copyright unless you license it to someone, so just don't.
If you're selling something that can be built or downloaded on someone else's computer, there are lots of proprietary licenses you can use and even some open source ones. I hate AGPL, for example, but it is a license that would prevent AWS from selling your software as a service without disclosing a lot of stuff they won't disclose (their other software that makes AWS run).
That's not really fair. You can want to have an "open enough" collaborative community without a trillion dollar company ($cloud_provider) steamrolling you and your work.
Open source is a religion, fair code or source available licensing is a pragmatic compromise to balance community contributions and usage with a reasonable mechanism to encourage or require economic support. Lot of open source folks going hungry and having to beg to get any income. Let the religious preach while the pragmatic get paid and cover their rent and grocery bills.
The median number of contributors to GitHub repos is 1. One. The "community" of open source is mostly a myth. Big important FOSS projects are paid for by FAANG companies who use that software. They can't rely on a "community" to fix bugs, so they pay people for that.
Even if this is true, the sheer number of dotfiles and such type of repos is probably the biggest factor to this. Or people using it for random stuff. A repo doesn’t mean it is intended to have community contribution.
That's exactly fair. MongoDB Inc. et. al. love to take others' contributions alongwith their rights too. This applies to everyone who demands a copyright assignment or exemption. They don't "collaborate" with the public to build something for the public, they take public contributions to enrich only themselves.
Open Source allows us to build software greater than any single contributor. Any single contributor can go out of business and the software still has a chance of surviving. Any single contributor can decide to take their work a different direction and other people can still build what they want with it. We've seen this happen so many times, over and over, and the world is in a much better place because that happened.
Closed, source-available, software vendors are the anti-thesis of that. They want others to participate and contribute, but they want to keep all the rights and benefits to themselves. If they go out of business, or just decide to drop development on a piece of software, the software dies. If they decide they don't want a certain feature in that software, you've got no recourse. That's them having the cake.
But if I offer them some code under the same license they hold everyone else to, using the same copyright rules they use against everyone else, they demand I sign over my rights and use a different license. Were MongoDB to accept a patch, under their own SSPL, under fair collaborative conditions, they'd have to actually abide by the intentionally-insane conditions of their SSPL. But that's impossible, so do they stop taking public contributions? Absolutely not. They take contributions, when accompanied by the contributors rights, just fine. This is them eating it too.
This environment actively discourages collaboration. The parasitic demand for copyright assignment deters me from even touching the concept of improving their code. When I have a client with an insurmountable database problem that could be solved by going to the source code, I'm glad when it's a database that has an actually collaborative approach, like Postgres or ClickHouse. In cases of both those databases, I've been able to actually collaborate with the maintainers and improve the software. When a client has an SSPL version of Mongo? I can't even take a look at the source code.
That last client had actually already paid MongoDB Inc. to come in and have a look at the problem. 10K USD later, the consultant gives up and says, "I'm sorry, this will never work." At least the guy was honest, as opposed to the company, which in their report says, "We promise we can bring down your latencies to single-digit milliseconds. Just move to Atlas."
What can the client do? Nothing. What can I do? I have some ideas, if I could modify the source code of the DB to add some acceleration engines specifically for this client. But I can't. Not out of technical limitations, but legal. Because of a hostile license that was itself plagiarized (illegally) from the AGPL.
So the client moves to ClickHouse, and along the way ClickHouse gets some improvements.
> Closed, source-available, software vendors are the anti-thesis of that. They want others to participate and contribute,
Whatever makes you claim they want others to contribute? They have a large engineering team, it probably wastes more of their time to review external “contributions” than add value.
> if I could modify the source code … But I can’t … legal.
You absolutely can. Where did you get the idea that you cannot?
> Whatever makes you claim they want others to contribute?
1. They started out, and achieved their success partly, by making an Open Source database. When you publish something under that moniker, into the Open Source community, it is generally assumed you want to collaborate. That's the default. Projects that want to publish Open Source software but don't want collaboration (e.g., SQLite, AOSP, etc.) make it clear and explicit that they do not take contributions. Because collaboration is the default.
2. They set up contribution guidelines[1]. Their words: "MongoDB welcomes community contributions!".
3. They set up their own trackers and tools to classify issues/tickets for external contributions. Their words, again from [1]: "tickets of an appropriate complexity for new engineers are marked with a “neweng” label."
4. They evangelise Open Source contributions. Even when they demand copyright assignment to accept any contribution.
To distribute a modified version of MongoDB to a client, without breaking the conditions of the SSPL, I shall have to license my changes under the SSPL itself, and distribute a copy of the SSPL with it. I cannot legally convey a copy of the license text, even if MongoDB Inc. permits me to "copy and distribute verbatim copies" of the license document, when I know that they may not even have the copyrights to do so, and that the legal copyright holder of said document does not allow changes to it.
You are right that most big FOSS projects don't want your contributions, another ugly fact behind the open source myth. And why would they? How could you control code quality if you let randos write your stuff? You can't. No reasonable organization that is trying to make money from software would rely on people outside that organization to write or fix it.
> How could you control code quality if you let randos write your stuff? You can't.
Huh? You use the pull request mechanism on Github. That's what it's there for. If people want to contribute, the PR needs to be up to standards. Just to pick one example, Elastic uses this method for ElasticSearch. [1] ES gets PRs from hundreds of unique contributors each year.
Pull requests don't mean the code gets integrated. It's just someone sharing a suggestion. Unless that suggestion happens to be on the project's to-do list or it fixes an open bug, I'd say it's unlikely to get merged.
Elasticsearch's top contributors (the three I checked) seem to work for Elastic, which goes to what I'm saying. No profit-making business can have its workflow dictated by the public. Even if a pull request is accepted, the team has to go through all the same code review and testing processes as if the code had originated in-house, and that's not always feasible or on the timeline when the request comes in.
> Unless that suggestion happens to be on the project's to-do list or it fixes an open bug, I'd say it's unlikely to get merged.
There are lots of open source projects that contradict your assertion. Here are 3 projects that have been quite liberal about accepting PRs from outside.
* MySQL - MySQL AB was very open about accepting external patches. Oracle still does today.
* ClickHouse - Yandex team has the most commits, but accepts PRs from hundreds of outside contributors.
* Superset - Apache project that is supported by Preset. Again, pretty open to new PRs as far as I can tell.
Overall it's a question of how the community is governed. A lot of us view open source communities as sources of innovation. That being the case, why would you refuse a good PR? Somebody just solved a problem for you, maybe one you didn't even know existed.
Yes, well since many companies (notably Google and probably Amazon, too) have absolute bans on AGPL software, I don't think it's working out.
The "religion" of open source is wonky. The truth is that the real value of software is nothing because it costs nothing to reproduce. The real value of software is in people who host it for you, configure it for you, and support you in using it. That, you can charge for. This is the basis of Red Hat's business model which isn't the least bit snarky and, demonstrably, worth paying for.
You have just assigned zero or near-zero value to software, art (prints etc), music recordings, video recordings, books, sheet music, etc. Most copyrighted works.
Plenty of companies make money selling software, and purchasing hosting and support is often not possible or not required. Your own company even does this, I see you sell a lifetime license to the desktop version.
Software was originally free. It was necessary to use the machines so it was supplied by their makers. (I worked at IBM when this began to change.) It was also all open source before that went away in favor of closed and proprietary licenses, which customers pushed back on greatly.
While some companies do make money selling software, they're fewer and further between than ever. Most of the money in the software business is in hosting, service, support, or advertising. The biggest players in our industry make more money from that stuff than from selling licenses. Microsoft, Google, Facebook, Netflix, and Amazon are all software-based businesses but software licenses aren't their source of revenue.
The vast majority of software is worth nothing. Statistically, most computer programs will only be used by one person -- the person who wrote them. There are millions of GitHub repos full of software with absolutely zero monetary value, as evidenced by the fact that no one pays for it. A tiny, tiny fraction of software programs reach "escape velocity" and become important enough to pay for, and to pay people to work on. This is definitely the exception and not the norm.
None of this is a condemnation of software or other copyrighted works. I'm a published author and artist as well as a software developer and I definitely get it. As for our desktop software, we charge for the fact that we packaged it into the desktop version. That's human work and it was quite difficult. If you don't need that, you can get (and setup) an almost identical product for free.
Is it? AGPL prevents the operating company from hosting modified version of the application without releasing changed code but doesn’t prevent actual hosting.
This might as well be the same thing. GPL variants are viral and the big corporation lawyers won't touch it with a mile long stick as a result.
It's a perfectly competitive license and fair. If they change your code and offer it as a service, they must publish the changes which will benefit you, the original author. There's also a chance it will require they open source some of their other code as AGPL.
It's the perfect trap and most corporations won't touch it. What constitutes a change is very fuzzy since it covers access over a network.
Thanks for more details. I do understand how AGPL and GPL work. Both are strong copyleft license. My experience with AGPL is: lawyers would review the request to use AGPL code on a case-by-case basis because of the risk of having to expose modifications to the source code and would always make a decision based on the context of usage. AGPL and GPL are definitely a problem in embedded world but not so for hosted systems.
I would argue that, for a player committed to host an AGPL licensed system, it narrows down to properly fencing the system from proprietary systems.
I personally maintain an AGPL based project but I treat the "lawyers will not touch it" as a case of "security by obscurity".
There's nothing fuzzy about access over the network:
> The GNU Affero General Public License is based on the GNU GPL, but has an additional term to allow users who interact with the licensed software over a network to receive the source for that program. We recommend that people consider using the GNU AGPL for any software which will commonly be run over a network.
If a corporation hosts an unmodified or even modified version of the AGPL system, where they can afford to share their modifications, they can still leverage their scale / network effect and take the creator out of business.
If your project is so successful that AWS starts selling it as a service you're in the top 0.00001% of open source projects. You're doing great and it's a great problem to have. Don't let the fear of a what if 0.00001% problem stop you from getting started.
The Business Source License is designed for this sort of use case. It’s not technically open source, but is just about as close as you can get if you want to restrict usage of your open source project.
> What license to use to prevent AWS et al. from selling my project as a service?
It's perhaps more useful to start instead with "what business can I build that will compete effectively with SaaS services?"
SaaS is now the standard way to deploy enterprise software. If you have a successful OSS project in the enterprise space and don't figure this out, somebody else will do it for you. Amazon is just one of many potential competitors. I get worried about collaborating with or using any OSS-based service that does not get this.
29 comments
[ 3.9 ms ] story [ 74.3 ms ] threadIf you're selling something that can be built or downloaded on someone else's computer, there are lots of proprietary licenses you can use and even some open source ones. I hate AGPL, for example, but it is a license that would prevent AWS from selling your software as a service without disclosing a lot of stuff they won't disclose (their other software that makes AWS run).
They want the feel-good tailwind and community aspects of marketing the project as "we're open source" without, well, actually being open source.
Open source is a religion, fair code or source available licensing is a pragmatic compromise to balance community contributions and usage with a reasonable mechanism to encourage or require economic support. Lot of open source folks going hungry and having to beg to get any income. Let the religious preach while the pragmatic get paid and cover their rent and grocery bills.
Open Source allows us to build software greater than any single contributor. Any single contributor can go out of business and the software still has a chance of surviving. Any single contributor can decide to take their work a different direction and other people can still build what they want with it. We've seen this happen so many times, over and over, and the world is in a much better place because that happened.
Closed, source-available, software vendors are the anti-thesis of that. They want others to participate and contribute, but they want to keep all the rights and benefits to themselves. If they go out of business, or just decide to drop development on a piece of software, the software dies. If they decide they don't want a certain feature in that software, you've got no recourse. That's them having the cake.
But if I offer them some code under the same license they hold everyone else to, using the same copyright rules they use against everyone else, they demand I sign over my rights and use a different license. Were MongoDB to accept a patch, under their own SSPL, under fair collaborative conditions, they'd have to actually abide by the intentionally-insane conditions of their SSPL. But that's impossible, so do they stop taking public contributions? Absolutely not. They take contributions, when accompanied by the contributors rights, just fine. This is them eating it too.
This environment actively discourages collaboration. The parasitic demand for copyright assignment deters me from even touching the concept of improving their code. When I have a client with an insurmountable database problem that could be solved by going to the source code, I'm glad when it's a database that has an actually collaborative approach, like Postgres or ClickHouse. In cases of both those databases, I've been able to actually collaborate with the maintainers and improve the software. When a client has an SSPL version of Mongo? I can't even take a look at the source code.
That last client had actually already paid MongoDB Inc. to come in and have a look at the problem. 10K USD later, the consultant gives up and says, "I'm sorry, this will never work." At least the guy was honest, as opposed to the company, which in their report says, "We promise we can bring down your latencies to single-digit milliseconds. Just move to Atlas."
What can the client do? Nothing. What can I do? I have some ideas, if I could modify the source code of the DB to add some acceleration engines specifically for this client. But I can't. Not out of technical limitations, but legal. Because of a hostile license that was itself plagiarized (illegally) from the AGPL.
So the client moves to ClickHouse, and along the way ClickHouse gets some improvements.
Whatever makes you claim they want others to contribute? They have a large engineering team, it probably wastes more of their time to review external “contributions” than add value.
> if I could modify the source code … But I can’t … legal.
You absolutely can. Where did you get the idea that you cannot?
1. They started out, and achieved their success partly, by making an Open Source database. When you publish something under that moniker, into the Open Source community, it is generally assumed you want to collaborate. That's the default. Projects that want to publish Open Source software but don't want collaboration (e.g., SQLite, AOSP, etc.) make it clear and explicit that they do not take contributions. Because collaboration is the default.
2. They set up contribution guidelines[1]. Their words: "MongoDB welcomes community contributions!".
3. They set up their own trackers and tools to classify issues/tickets for external contributions. Their words, again from [1]: "tickets of an appropriate complexity for new engineers are marked with a “neweng” label."
4. They evangelise Open Source contributions. Even when they demand copyright assignment to accept any contribution.
1: https://github.com/mongodb/mongo/wiki
----
>> if I could modify the source code … But I can’t … legal.
> You absolutely can. Where did you get the idea that you cannot?
The SSPL is itself a copyright infringement, being an unlicensed and unauthorised modification of the AGPLv3. From the AGPLv3 license text: "Copyright © 2007 Free Software Foundation, Inc. <https://fsf.org/> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." Hell, MongoDB Inc. even kept the same conditions in their unauthorised copy, while replacing the copyright claim of FSF with their own.
To distribute a modified version of MongoDB to a client, without breaking the conditions of the SSPL, I shall have to license my changes under the SSPL itself, and distribute a copy of the SSPL with it. I cannot legally convey a copy of the license text, even if MongoDB Inc. permits me to "copy and distribute verbatim copies" of the license document, when I know that they may not even have the copyrights to do so, and that the legal copyright holder of said document does not allow changes to it.
Huh? You use the pull request mechanism on Github. That's what it's there for. If people want to contribute, the PR needs to be up to standards. Just to pick one example, Elastic uses this method for ElasticSearch. [1] ES gets PRs from hundreds of unique contributors each year.
[1] https://github.com/elastic/elasticsearch/pulls
Elasticsearch's top contributors (the three I checked) seem to work for Elastic, which goes to what I'm saying. No profit-making business can have its workflow dictated by the public. Even if a pull request is accepted, the team has to go through all the same code review and testing processes as if the code had originated in-house, and that's not always feasible or on the timeline when the request comes in.
There are lots of open source projects that contradict your assertion. Here are 3 projects that have been quite liberal about accepting PRs from outside.
* MySQL - MySQL AB was very open about accepting external patches. Oracle still does today.
* ClickHouse - Yandex team has the most commits, but accepts PRs from hundreds of outside contributors.
* Superset - Apache project that is supported by Preset. Again, pretty open to new PRs as far as I can tell.
Overall it's a question of how the community is governed. A lot of us view open source communities as sources of innovation. That being the case, why would you refuse a good PR? Somebody just solved a problem for you, maybe one you didn't even know existed.
The "religion" of open source is wonky. The truth is that the real value of software is nothing because it costs nothing to reproduce. The real value of software is in people who host it for you, configure it for you, and support you in using it. That, you can charge for. This is the basis of Red Hat's business model which isn't the least bit snarky and, demonstrably, worth paying for.
Plenty of companies make money selling software, and purchasing hosting and support is often not possible or not required. Your own company even does this, I see you sell a lifetime license to the desktop version.
While some companies do make money selling software, they're fewer and further between than ever. Most of the money in the software business is in hosting, service, support, or advertising. The biggest players in our industry make more money from that stuff than from selling licenses. Microsoft, Google, Facebook, Netflix, and Amazon are all software-based businesses but software licenses aren't their source of revenue.
The vast majority of software is worth nothing. Statistically, most computer programs will only be used by one person -- the person who wrote them. There are millions of GitHub repos full of software with absolutely zero monetary value, as evidenced by the fact that no one pays for it. A tiny, tiny fraction of software programs reach "escape velocity" and become important enough to pay for, and to pay people to work on. This is definitely the exception and not the norm.
None of this is a condemnation of software or other copyrighted works. I'm a published author and artist as well as a software developer and I definitely get it. As for our desktop software, we charge for the fact that we packaged it into the desktop version. That's human work and it was quite difficult. If you don't need that, you can get (and setup) an almost identical product for free.
It's a perfectly competitive license and fair. If they change your code and offer it as a service, they must publish the changes which will benefit you, the original author. There's also a chance it will require they open source some of their other code as AGPL.
It's the perfect trap and most corporations won't touch it. What constitutes a change is very fuzzy since it covers access over a network.
I would argue that, for a player committed to host an AGPL licensed system, it narrows down to properly fencing the system from proprietary systems.
I personally maintain an AGPL based project but I treat the "lawyers will not touch it" as a case of "security by obscurity".
There's nothing fuzzy about access over the network:
> The GNU Affero General Public License is based on the GNU GPL, but has an additional term to allow users who interact with the licensed software over a network to receive the source for that program. We recommend that people consider using the GNU AGPL for any software which will commonly be run over a network.
http://www.gnu.org/licenses/licenses.html#AGPL
If a corporation hosts an unmodified or even modified version of the AGPL system, where they can afford to share their modifications, they can still leverage their scale / network effect and take the creator out of business.
It was originally "What license should I use to prevent AWS e. al. from selling my open-source software as a service?"
It's perhaps more useful to start instead with "what business can I build that will compete effectively with SaaS services?"
SaaS is now the standard way to deploy enterprise software. If you have a successful OSS project in the enterprise space and don't figure this out, somebody else will do it for you. Amazon is just one of many potential competitors. I get worried about collaborating with or using any OSS-based service that does not get this.