Fair Source: Sustainability with no customer risk
pepicrft.me
pepicrft.me
I get that this post is about choosing a certain non-Free license, but it seems very weird to me to describe businesses leveraging the permissive terms of permissive licenses as "predatory" behavior. Permissive licenses were created in response to hereditary licenses like the GPL specifically to allow the kind of behavior that the author is referring to as "predatory". Blaming anyone but yourself for choosing to license your code with a license designed to enable behavior you don't like seems quite silly.
> Other organizations seek protection by adopting AGPLv3, which many companies have policies against, and selling dual licenses and enterprise features. Those businesses are often referred to as Open Core.
Open core is related to, but not the same as the dual licensing pattern they are describing. Open core is basically the same as dual licensing, but the different licenses actually apply to different sets of software under the Open core model.
If they want specific behaviors, they should put them in the license or in a contract. Businesses will probably not use it over permissive software, though.
But that's exactly the point of the article, isn't it?
Whenever permissively licensed software is used, is it acceptable to have an expectation that one should be able to use it against the business that originally created it?
If by "use it against the business" you mean in the literal sense, such as using it to access the businesses systems without authorization, using it to harass company employees, etc. then no, it doesn't really matter if they made the software or not.
Intuitively: if I named my political party “the party without stinky feet,” it’s clear that I’m indirectly saying that other parties do have stinky feet. In a similar manner, labeling yourself the “fair” one indirectly suggests that other licensing schemes, including OSS ones, are somehow unfair.
I'm not talking about if someone uses left-pad as part of a billion LOC project, but more like if a company builds its entire stack on top of something like, say, ffmpeg, or ImageMagick, and the original devs never see even a smidgeon of thanks.
I think this can be fair. But I would love to have seen that communicated as "we wrote the license to address the problem of fairness in corporate usage of OSS," not "this is a/the fair license." The latter is a value judgment that isn't universalizable.
(I agree that "medium source" sounds very weird. Maybe they could have called it the "Availability License" or something similar to emphasize that this is about finding a sweet spot between monetization rights and exposing the source code to the public eye. I don't think that would carry the same baggage as "fair," but it also certainly doesn't have the same marketing flair to it.)
It is perfectly fine to choose Fair Source as a license; that's the prerogative of whoever is writing the code. But don't let these people marketing Fair Source circulate the idea that FOSS licensing is "unfair". It's just another sleazy tactic they're trying after their attempt to redefine open source to include their proprietary Fair Source licensing got rebuffed by the community.
Now look, I can understand the argument that one should have known what they were signing up for, but so many people just do not consider what they are signing up for, or even do but think that the worst case situation is unlikely, but later find it happening and that they don't actually entirely not care.
That's basically exactly what I'm trying to point out though. Many developers make the determination that they don't want or need to monetize their code. Then someone else does it and then they feel it is unfair.
I consider this a perfectly valid way to feel and I don't really consider it a skill issue at the time of choosing the license.
That most projects don’t require that is typically a result of “it doesn’t matter until it matters”.
> Whenever you add Content to a repository containing notice of a license, you license that Content under the same terms, and you agree that you have the right to license that Content under those terms. If you have a separate agreement to license that Content under different terms, such as a contributor license agreement, that agreement will supersede.
While one can argue that even in the absence of that notice, that might be how it works, there is no real legal agreement to that. You could legally walk back on your contribution and claim that you never gave a license to it. I have seen that happen once indirectly when a contributor informed me that the company that they worked for did not allow the person to contribute.
I've never personally seen a CLA where you weren't signing away ownership, where you were just stipulating that your contributions were under the same license as the rest of the code. Do you know of any cases of this? I'd be curious to see them.
> As you might know, we aim to make Tuist a fully open project.
> So I think a fully open Tuist platform could unfold this way: [...]
The intention is clearly to NOT be fully open.
> We can only build the best in class productivity platform if we embrace openness.
They are not embracing openness. They are trying to reap the benefits that come with being open, such as code contributions and a higher level of trust, while not actually being open.
Is fair source more open than source-available? Yes.
Is open source more open than fair source? Yes.
I don't see any attempt at communicating otherwise. Nobody is claiming fair source is as open as open source. Fair source is very clearly defined as not being open source, but it is closer to open source than the alternatives, and even becomes open source, and that's a good thing. We should all be happy about that. But people still find fault...
The OSI doesn't have a monopoly on the word "open." It has meaning, and in these cases it's being used appropriately. It's not an attempt at openwashing.
The world isn't so black and white.
> and that doesn't make any sense.
It makes sense to quite a lot of other commenters here. I'm afraid you're coming across as trying a bit hard not to understand the issues being raised.
No, it's being presented as an alternative to being properly closed source.
IMO, it’s silly to insinuate the OP is obtuse while looking quite obtuse yourself.
- https://pepicrft.me/blog/2024/08/02/commercial-oss
- https://pepicrft.me/blog/2024/07/22/openness-as-a-tool-of-tr...
I invent something, AWS find it useful and start providing it as a service.
Now I want a piece of the action and start a business myself.
Does that means AWS have to stop offering the service?
Also same if I change direction of my business, to begin competing with a company providing the service.
If that is the case, I don't see why companies would touch anything with that license...
Sentry's license is a fantastic alternative to just never opening up the source, and that's how we should be thinking about it.
Whether or not you are offering the software itself as a service, the license does not allow it to be commercially offered as a service directly at all.
For services using the software, it prohibits the user making the software available to others as part of a commercial product or service that "substitutes for any other product or service we offer using the Software that exists as of the date we make the Software available", with the "Software" being "each version of the software".
That would seem to mean, for simply using the software, that AWS could continue offering the service, but after that point, would not be able to update to the next version of the software. It seems like the other prohibitions would prevent them from forking it, but possibly not from working around the old version in other code.
In practice, it would likely mean no one would use the software commercially for two years, or would simply use two-year-outdated versions, perhaps with patches.
1) substitutes for the Software; 2) substitutes for any other product or service we offer using the Software that exists as of the date we make the Software available; 3) or offers the same or substantially similar functionality as the Software."
So if you haven't started your business yet when you make the release, the second criteria wouldn't have any effect. Once you start your business, any release you make after that point would have that restriction. If you change your business, only releases made after you change your business would be restricted in regards tot he new business, and releases made prior would be restricted in regards to your prior business.
Honestly, its a lot to keep track of for a user, and a lot of risk, I would always prefer open source alternatives.
(Serious question, as this is the business model I'm pursuing.)
The open-source code lets you modify and distribute. There’s either no risk (permissive) or well-understood. Proprietary licenses often don’t allow freedoms like that. So, some of the new licenses are addressing modification and redistribution of source-available, proprietary code.
Far as AGPL, it’s very unpopular even among FOSS users. Just using it almost guarantees less adoption of your code. Whether that’s fair or not, I’m just saying it’s a reality that you might be limiting the impact of FOSS code if it’s AGPL.
Citation, please. I would say this is very untrue but would like to see the sources of this claim. I hope you are not calling Big tech employees "FOSS users".
https://github.blog/open-source/open-source-license-usage-on...
AGPL-licensed projects are almost non-existent compared to many others.
(Disclaimer: I contributed to the FCL: https://fcl.dev)
* Merge a bad change which makes the project worse, because it'll unblock a contract that stands to make your company a lot of money.
* Iterate on support for a proprietary workload from one of your customers, who has not licensed that workload publicly and indeed may consider it a trade secret.
2. Don't name customers in commits.
what? This sentence appears to be literally untrue. In what way?
While businesses can obviously use AGPL licensed software, some (like Google) explicitly choose not to.
[0]: https://fcl.dev
There's also the FUTO License https://gitlab.futo.org/videostreaming/grayjay/-/blob/master... but since donations don't work...
> - substitutes for the Software; > - substitutes for any other product or service we offer using the Software that exists as of the date we make the Software available; or > - offers the same or substantially similar functionality as the Software.
I'm not sure what you'd target with B2C, these licenses exist explicitly to allow end users to run their own versions for private use.
Why is it all these companies try to change the meaning of "open source" rather than open their source?
2 years is constant pressure on the creator to be innovative, maintained and secure. Then two years ~public domain compared to Disney's 95 years or patents 20 years.
GPL is somewhat broken, AGPL is so broken it's not fit for purpose, it's un-enforceable.
MIT is amazing, but people need money.
The only concern is if people start forking licenses and making it all a mess. MIT (or freer) matters, a short time period also matters. People need to stick together on one license.