Thank you for your suggestion. You’re absolutely right; we are actively exploring licensing options, including AGPL, to ensure that our product remains protected.
We value input from the community and are open to suggestions and assistance in making this decision. Our goal is to prevent unauthorized copying and resale of our product under different names while fostering a collaborative and innovative environment.
While the community may be a good source for ideas, you should retain an attorney. The community is not your lawyer.
There's also the BSL. It specifically calls out competitive products. It automatically falls away for code older than a given time to another OSI license: https://en.wikipedia.org/wiki/Business_Source_License. Per the Wikipedia article this still has issues: contributors are handing over their work for to you for free for that duration, they can't use their own work for profit.
The AGPL does make your project extremely unattractive to competition, without affecting your contributors. The issue is that it is still possible to compete with you using it, so long as your competition releases all their code (i.e. infra, billing, etc.) under AGPL.
I would personally go for AGPL because it will keep the worst offenders (Amazon, Microsoft) away from your code.
The Business Source License allows for redistribution and modification of code. Calling it not open-source because it restricts third-parties from slapping a logo on it and selling licenses seems like a stretch. imo licenses like the BSL are really the direction that open-source should be heading in, because they allow the original author to retain their rights while avoiding exploitation by rando corporations.
This feels like splitting hairs and unnecessary gatekeeping, and I'm not sure for what purpose or for who's intended benefit. The movement needs to evolve to better protect the rights of the people actually doing the work, because they are the ones who are benefiting the least by the narrow definition being pushed by the OSI. Maybe we need a new term if this is how "open-source" is seen in the broader community.
The term is "source available," but I guess with that, companies can't use "open source" as a marketing term then pull the rug after they got enough contributions, like so many that converted to BSL and others now. By creating rights for those companies such that they cannot be competed with, you actually remove the rights of users, which is the whole reason the open source and free software movements got started in the first place. They are and always have been about the rights of users, not of corporations.
What are you talking about? I don't know where you live or what project you are referring to, but it's not possible to retroactively remove someone's rights in the American legal system by publishing a new license. If you committed code under a MIT license without signing anything else, you don't lose anything when later versions are published under BSL, AGPL, or whatever. The fact that the MIT license arguably allows willy nilly relicensing by anyone should be seen as a flaw with that license, not BSL. Also the context of this conversation is what license is appropriate for a new project. It makes less sense to apply a BSL to a MIT licensed project that has been around for a while than it does to start off with a BSL.
I'm not even sure how what you're saying relates to what I said; of course no license can be retroactively changed and I never said anything to the contrary. By rug pull, I mean companies like Sentry or MongoDB starting off as open source then changing their license such that they are no longer open source, making it a much more difficult legal minefield for whomever uses their product, even if they aren't competing with them, as they are now source available companies. As a copyright holder, any license can be changed for the future, whether it be MIT, AGPL, or BSL. With regards to a new project, sure, they can license it however they want but if it's not open source, they should expect to get way fewer contributions than if it were.
Well that's certainly disappointing but not really a rug pull so much as just what eventually happens with every project, which is that at some point the original authors stop contributing to the original vision. Both of the mentioned projects also don't use BSL, which I feel it is worth reiterating is still a very permissive license. If you aren't planning on selling licenses to the project you are contributing to, then a BSL isn't going to meaningfully restrict you. Sure, fewer contributions is a theoretical concern, but fully permissive licenses also suffer from contributions not looping back into the original project. Or if you use something in the GPL family there are other implications. I've been reading a lot about licensing lately and there don't seem to be any obvious choices for authors who care about how their work is used. I'm gravitating towards BSL though because it is relatively simple and feels like it retains the most important aspects of open source, which are redistribution and modification.
> This feels like splitting hairs and unnecessary gatekeeping, and I'm not sure for what purpose or for who's intended benefit.
The line must be drawn. Open-source absolutely needs to have a firm definition, otherwise it will be whittled away to nothing. Microsoft already tried that with "shared source".
If you think the difference between BSL and AGPL is just splitting hairs, then why not just use the AGPL?
There is less of a difference between BSL and MIT than between any GPL license, as I'm sure you are aware. If I'm giving away software including source in the open, for free, while allowing redistribution and modification, then I'm not sure how to convey that without offending patrons of the OSI and FSF. Not feeling like walking around on eggshells to give things away that's for certain.
> There is less of a difference between BSL and MIT than between any GPL license, as I'm sure you are aware.
Nonsense. There is an enormous difference between the MIT license, which grants you permission to use and sublicense something without any restrictions, and the BSL, which does not.
> If I'm giving away software including source in the open, for free, while allowing redistribution and modification, then I'm not sure how to convey that without offending patrons of the OSI and FSF.
If you put limitations on how that software is used, then no, you're not giving it away. That part is something the OSI and FSF have been very clear about for decades - see e.g. the FSF's "four freedoms", which are about as clear and simple as you can get.
Even silly "camel's nose" limitations count, and have to count, otherwise there is no place to draw the line; see the OSI and FSF's comments on the HESSLA or the (pre-2021) JSLint license. Again this is something they've been clear about for decades.
> Not feeling like walking around on eggshells to give things away that's for certain.
If you want to give things away for free then do so. If you want to pull a Columbia Record Club "it's free, no wait you have to pay us" scam then of course people aren't going to support that.
Brother, let's agree to disagree. I'm not involved in any of these licensing dramas as I don't have any feelings of entitlement to free labor. People can give away as little or as much as they please.
There's no "agree to disagree" when you're doing something that (whether you intend it that way or not) will end up scamming people. Don't tell people your code is open source when it's not open source. Don't tell people your code is free when it's not free. It's not entitlement to expect people to keep their word, even if you didn't pay them.
Accusing people of "scamming" you by giving you something for nothing, and putting their extremely permissive terms in clear writing, is acting entitled. You're not the lifeguard on this beach, so draw your lines in the sand somewhere else. Good day to you sir.
Do you really not understand that the colloquial use of these terms differ, and that most people don't even know about the FSF and OSI? On the other hand, the license has always been the law and everyone knows that. If you're just going off someone mentioning they "open-sourced" their work, not checking the license, and importing that into corporate projects, then you could end up with anything and would frankly be lucky to later find a FSL or BSL rather than something in the GPL family. Being scammed and just being dumb are two entirely different things, and you have yet to point out any real scams.
> If you're just going off someone mentioning they "open-sourced" their work, not checking the license, and importing that into corporate projects, then you could end up with anything and would frankly be lucky to later find a FSL or BSL rather than something in the GPL family.
You would expect to be able to run the program freely, including as part of your production services, without incurring any obligations. And under any open-source license (including GPL-family) you can, because that's part of what open-source means. Getting presented with a bill because the program turned out to be BSL and the way you were using it means you need a commercial license is absolutely a scam.
Note that anything other than MIT will immediately remove one of your major advantages over the competition. No enterprise wants viral licenses in their environment, it’s simply not worth the anxiety when there’s so many options.
If you want to compete on being open source your license has to be free.
You can also expressly state that you have a commercial license too. Your entire license can be something like “ If you’re using it for commercial purposes, you must see a commercial license with XYZ. Otherwise, for all noncommercial uses, you may use the software according to the terms of the AGPL license.”
Wait which non-commercial uses would there be for this product? I guess you'd only use it as an issue tracker for open source projects with no funding?
Regardless, by doing that the software would no longer be open source, and it seems like being open source is a significant part of the marketing strategy currently.
Please define "commercial use", because it means different things to different people.
Also, lots of organisations have a blanket ban on AGPL, so offering it under an alternative commercial license is a great approach to enable them, but explicitly blocking it for "commercial use" makes it no longer free software, which would be a shame.
You could certainly iterate on the terms to strike the balance you want. You could make the source available to commercial clients as well. Each client can have a licensed tailored to their exact needs at a price that works for the people that make this software.
It's much more nuanced than that... Sure, we can agree that if I host and charge users to use the service it is commercial usage... but:
- If my limited company use it to manage internal development, but we aren't yet profitable (making money), is it commercial use?
- If a company uses it to manage internal development, but it isn't the product itself, is it commercial use?
- If I as an individual use it to manage a non-commercial side development project, and when it is then finished, I decide it is worth value and I sell it, does it become commercial usage, and my previous usage turns out to be non-compliant?
- Is a charity using it to manage an internal development project "making money"?
- If I as an individual provide a professional service to deploy this to "non-commercial" users, is this compliant by the license?
You really can drive a truck through the definition of "commercial use", it is nearly as bad as the original JSON license, which stated "The Software shall be used for Good, not Evil." - which is helluva subjective.
You can make a license with any terms you want. You can embed the exact text of the AGPL into another license. And that license can have an if-else branch where the predicate is “are you making money with this or not?”
AGPL doesn't prevent anyone from taking your code wholesale and hosting the entire thing. They didn't make any changes so they don't have to contribute anything back per AGPL. OP can make any part that interacts with it, such as billing and infrastructure code, closed source as they are the copyright holder and thus do not have to abide by AGPL or any license themselves. If they make every contributor sign a CLA, then even better.
But that only stipulates that the third party has to make the code available if they've modified it.
This is fine if you expect people to want to modify the backend, but it won't stop people who only care about cloning the service.
Which is sort of the point, good software made available to as many people as possible as cheaply as possible, but it's not really protection against others who would monetize the software you wrote.
I am not an IP attorney but this is undecided territory: as I understand it your integrations may be considered modifications, and thus may be subject to the terms of the license, depending on the interpretation.
If Amazon can successfully do it such that other companies whose products they were hosting had to relicense to source available from AGPL, then, based on the strength of their lawyers, it is likely that those integrations are not actually needed to be released. And even if they were, it doesn't really matter, people don't use AWS for their source code.
I am not sure how to interpret what you have written. Are you suggesting Amazon operated and sold AGPL-licenses software, and thus made a licensed program available over the network, but did not comply with the terms of the license? I am not aware of any evidence of such.
Amazon repackaged MongoDB, an originally AGPL licensed work, and did indeed comply with AGPL, but that means nothing because they did not modify the source code at all, they merely packaged it up into a hosted service. Because they followed the terms of the license but were accused of "leeching off" of MongoDB, even though they clearly licensed it to be used as such, MongoDB then changed their license to a source available one. My point is that if Amazon's lawyers, which are likely better and stronger than most anyone here on HN's, approved such actions with regards to AGPL works, then it's very likely that they were within their rights to do so via the terms of AGPL without open sourcing their integrations too.
What evidence is there that they repackaged MongoDB? How did they "comply" with the AGPL? It seems like they reimplemented it which would be no AGPL licensed works are involved.
This sounds like a myth. There is no way AWS legal would allow providing access to an AGPL licensed work over the network.
So what? Amazon is perfectly content distributing the source code, because they don't actually modify it, only host it. That was the main issue that caused many companies to relicense to source available.
