Fair Source is designed for companies that want to deeply engage the developer community with their core products, while being clear about governance and roadmap ownership.
“For companies who want to reap the rewards of free labor, while making sure those do-gooder code-monkeys are kept in their place.”
You are not allowed to make any change to the code which threatens or impedes the “producer’s business model”. This is quite different from a project with a solid BDFL, which you are free to fork at any time; this line implies that a proper fork would be in violation of the license.
You assert that because a company wants to share its source code that it’s also soliciting free work, but that’s far from reality. I’d imagine most Fair Source projects are also Single Source, accepting contributions if they happen to come in, but they don’t rely on them, much less solicit free work.
If a company does attempt to solicit free labor, that’s on them; it’s not the fault of Fair Source, or of Open Source for that matter. In any case, they should reap what they sow.
I hope you can see the value in a company sharing their core product with no strings attached, even going as far as to undergo DOSP.
I understand that you have a direct stake in this matter, seeing as your company just released that you’re switching to this particular licensing scheme.
“…allows use, modification, and redistribution with minimal restrictions to protect the producer’s business model”
Of course, not soliciting free labor in the way that placing a tip jar/bucket in front of a performer/register is not soliciting tips :)
“…even going as far as to undergo DOSP”
“We’ll hand you our abandonware after we’ve deemed it no longer sufficiently profitable.” Yes, very noble.
Note the first word was “allows use”; the primary benefit is being able to run the software yourself (redistribution also includes distributing the software onto servers).
We’ll hand you our abandonware
The goal of DOSP is not to be a “bail out clause” in case the company sours, but even if a project failed to turn into a profitable business doesn’t mean that the source code doesn’t confer value to its users.
Many closed source projects have been released as open source years later and found a sustainable community. For example, FoundationDB was originally closed source, purchased by Apple in 2015, then open sourced in 2018 and is still active today[1]. ID Software released every version of Doom and Quake as open source, years after they were deemed “no longer sufficiently profitable”, but still found plenty of appreciative users.
The idea of DOSP is that it is a legal right, imbued in the source code itself, that you will be granted free permissive use of the source code at some future date. Versus the current status quo which is to depend solely on the good graces of a company who chooses to do so (the examples above re: Foundation DB and Quake).
It’s also worth noting that under Fair Source, the only real restriction now is i.r.t. competition. Meaning, if you want to compete using the source code, you must wait 2 years for the OSS release. Otherwise, you’re free to do what you want now. That’s very fair. In practice, the restrictions effect very little real-world users, because most don’t want to compete with the author; rather, they just want to run the software.
the only real restriction now is i.r.t. competition
The reason that lawyers tell you never to let it in the building is that ‘competition’ is very hard to define. Today, I have no plans to offer a service that’s the same as yours. What happens if your v2 incorporates something that I do? Now we’re competing and I have no migration path. There are a lot of cases like this where you can find that you’re competing. A lot of companies have businesses that slightly overlap with people up the supply chain for them. This is often dynamic. ‘Don’t compete with your channel’ is a good maxim, but sometimes you’ll compete for a bit for a few customers and then move to distinct businesses. The definition is usually written as something like:
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.
The phrase ‘substantially similar functionality’ is the kind of thing that is vague and makes lawyers run away. The ‘any other product or service we offer’ is really painful. Yes, it’s time limited for the current version but if the company releasing this adds a new service that competes with you then you can’t use any future version of the software and that’s an enormous business risk.
I’d imagine most Fair Source projects are also Single Source, accepting contributions if they happen to come in, but they don’t rely on them, much less solicit free work.
If a company does attempt to solicit free labor, that’s on them; it’s not the fault of Fair Source, or of Open Source for that matter. In any case, they should reap what they sow.
What does it mean to “deeply engage the developer community” if not getting developers to contribute for free?
The main benefit of these licenses is that you can run the software yourself in 99.99% of cases (the restrictions vary per-license, but most licenses restrict your ability to compete).
You can also make modifications to your copy of the software if you want; nothing says you need to contribute those changes upstream.
It’s meant to be an alternative to private source commercial or enterprise-licensed source available (e.g. GitLab EE). For example, GitLab’s EE License (which you must pay for) says you grant them the right to use any changes you make:
Fair.io says: “Engage the developer community with your company’s core software products.” And you’re saying this is about developers running their own instances of the software and make changes to their own personal copies? That’s the type of engagement they are pitching to businesses?
If a developer can self-host for free, they can use the software for personal use, if they can use the software, they can write about and recommend the software to their peers, if their peers read about or use the software, they can recommend it to their companies, and companies typically don’t want to self-host, so they recommend the cloud offering. It’s very simple grass-roots marketing from the bottom up.
You’re stuck on free labor (understandably — not everybody is business-savvy), but receiving contributions is not the only form of engagement with the developer community.
Code contributions are not the only valuable contributions and not the only form of free labor. And I’m not stuck on it, I’m just amused by the refusal to be honest about fair.io’s pitch to businesses.
Nobody ever said patches are the only way that a Fair Source company could “engage the community.” The question has always been what they mean by “engaging the community” in their pitch to businesses. And none of you Fair Source defenders have answered that question directly and honestly, your comment above being a perfect example.
I asked: “That’s the type of engagement they are pitching to businesses?” You responded by describing one possible way that developers could engage without contributing code. As an answer to my question, that seems either indirect or dishonest.
I don’t understand what is indirect or dishonest about my response, and I’m done with this weird conversation. If you want to read about more types of engagement, it’s covered in the FAQ under “Why should I adopt Fair Source at my company?”
If you want to say that’s dishonest, you’re only fooling yourself.
You’re prodding for a predetermined answer that isn’t there, because you’ve already made up your mind that Fair Source is a thin veil to solicit free labor for profit when it’s not. You aren’t involved with the companies adopting Fair Source, so you shouldn’t speak on their behalf. Let their actions show what’s true, not your feelings or assumptions; and if you do that, you’d see that you’re wrong.
I can’t speak for all Fair Source companies, but I can speak for Keygen and the answer is no. Like I’ve said elsewhere, if a Fair Source company were to go Fair Source in hopes of soliciting free labor, that’s on them; but to imply that Fair Source as an intiative encourages that or that all Fair Source companies do that or want to do that, with zero proof — even if they theoretically can, just like any commercialized Open Source project can — is a flat out misrepresentation of Fair Source.
The link appears to show that you accepted 9 unpaid commits in the last 6 months, correct? And you are suggesting that you did not want these commits and that you’re not hoping for more as a result of the Fair Source initiative?
I did not ask for them, no, and I continue to not ask for contributions. But I won’t turn away people that want to contribute for their own benefit or others benefit. In the same way I don’t tell my users to not help each other i.e. community-led support. Why would I? To do that would be ridiculous. People are free to help each other. People are free to modify the software and contribute those modifications to the benefit of others, including the author, the same way they’re free to modify the software and not share their modifications. That’s codified into the Fair Source Definition. But nowhere are we stating “you get free labor!” as a benefit of adopting Fair Source.
In any case, I feel like you’re trying to push the conversation in such a way as to make me look like I’m soliciting free work under the guise of Fair Source, so I’m going to stop the conversation here.
Comment was removed after a week so I guess I’ll rephrase it.
Answering the question “are you suggesting that you did not want these commits and that you’re not hoping for more” with “I did not ask for them, no…” is not a direct and honest way to respond.
Nobody ever said patches are the only way that a Fair Source company could “engage the community.”
You’ll have to forgive us, because 90% of the comments here are exactly that.
The question has always been what they mean by “engaging the community” in their pitch to businesses
your comment above being a perfect example.
I don’t see how his comment is dishonest: the primary metric of engagement is usage. Tens of thousands of organizations self-host Sentry, a fair source product, and they’re all developers – if that’s not engagement I don’t know what is. (Full disclosure: I work at Sentry.)
FWIW I don’t mean to dismiss you or anything – you’ve highlighted the text is clumsy and should be made more clear. I agree.
Nobody ever said patches are the only way that a Fair Source company could “engage the community.”
You’ll have to forgive us, because 90% of the comments here are exactly that.
Maybe if you could provide literally one example.
I don’t see how his comment is dishonest: the primary metric of engagement is usage. Tens of thousands of organizations self-host Sentry, a fair source product, and they’re all developers – if that’s not engagement I don’t know what is. (Full disclosure: I work at Sentry.)
Do you consider this to be an honest description of the kind of “developer engagement” that fair.io is pitching to businesses? Businesses are supposed to understand “developer engagement” to mean “developers self-hosting your product”? You think this covers it, with no significant omissions?
I understand the disconnect now. For most of us, “contributing” means patches, because we don’t actually see submitting a ticket on a GitHub project being any different from sending a customer support email or Zendesk widget.
You seem to think differently; that’s okay.
Do you consider this to be an honest description of the kind of “developer engagement” that fair.io is pitching to businesses?
I think I just wrote above that the text isn’t sufficiently accurate and ought to be changed. If you see my comments on here, you’ll see they’re pretty consistently highlighting that end-user usage is the primary benefit.
Like most work, it was put together by humans, and humans don’t always get it right. We’ll try to do better.
Nobody ever said patches are the only way that a Fair Source company could “engage the community.”
You’ll have to forgive us, because 90% of the comments here are exactly that.
Maybe if you could provide literally one example.
I understand the disconnect now. For most of us, “contributing” means patches, because we don’t actually see submitting a ticket on a GitHub project being any different from sending a customer support email or Zendesk widget.
You seem to think differently; that’s okay.
That disconnect does not explain why you wrote “90% of comments here are exactly that.” Accounting for the ambiguity in terminology, you should still be able to show at least one comment claiming that patches OR contributions are the only way a Fair Source company could engage the developer community. Or if you retract that comment, I don’t know maybe say that instead of deflecting?
I think I just wrote above that the text isn’t sufficiently accurate and ought to be changed.
I missed that part. Was that in a different comment chain?
Do you think Stripe has deeply engaged the developer community? I believe most developers would answer “yes.” There are a myriad of other examples, too, of closed source companies deeply engaging the developer community to the extent that those developers become the #1 advocates for the company, fostering growth from the bottom up, yet they don’t contribute a single line of code to the core product.
If a closed source company like Stripe can deeply engage the developer community outside of “free labor”, how much more could a Fair Source company?
A company with a closed-source platform that has a deeply-engaged developer community could decide to pull the rug out from under that developer community at any time, when it’s profitable or ideologically-convenient for the company to do so. Reddit and Twitter have both done this, and there’s no reason to expect that in a year or five years, we don’t be reading a bunch of articles about how Stripe is doing wrong by its developer community over something or other.
That’s completely irrelevant. The question wasn’t “Do you think a closed source company can engage deeply with the developer community and commit to some sort of long term relationship purely on the community’s terms”.
Sure, but now we’ve switched topics from “soliciting free work” to rug-pulls.
But FSS helps prevent rug-pulls in 2 ways —
FSS already provides a clear path to monetization, so there is no need to relicense later.
FSS is delayed Open Source, allowing a community to correct corporate failures.
FSS is permissive enough to allow forks now, even. I can’t speak to all BUSL variations, but the restrictions under FSL/FCL are usually only limited to competition. If you disagree with direction the author is taking, there’s nothing preventing you from forking now. The main restriction is that you can’t spin up a product or service that competes with the author until the 2-year transition, which is fair.
Simply forking isn’t spinning up a commercial product or service, however.
No. You implied that the only way to engage a developer community was through free labor, and I made a point that closed source companies engage developer communities, yet those developers don’t contribute a single line of code to the closed core product. I asked if a fair source company could engage the developer community similarly, without free labor, but it was more a rhetorical question because the obvious answer is yes. I was simply implying there are many other ways to engage the developer community outside of free labor.
So you thought I was implying something that is obviously wrong?
The context was fair.io’s statement that “Fair Source is designed for companies that want to deeply engage the developer community…” So obviously they think there is something about (un)Fair Source that targets developer engagement in a way that other licensing schemes do not.
As I see it, Sentry is a proprietary SaaS with a free tier that happens to allow self-hosting. Using GitHub issues as a customer-facing support portal doesn’t really change that, and anyone who builds a “community” around it is, in my view, in just as much peril as anyone who builds a “community” around any other proprietary software. Treating it as just another proprietary SaaS vendor is what I do and what I would recommend to anyone who asked me for advice.
Also, GitHub claims the main Sentry repo has had over 700 individual contributors. Were all of them paid employees or contractors of Sentry at the time of their contributions?
Eh, I’m like 95% with you. Sentry is a “proprietary SaaS vendor,” sure, but there are a few details that can be said to differentiate it from “just another.” Unmonetized self-hosting is one, especially considering we don’t limit features. Delayed Open Source publication is another. Using GitHub issues as not just a support channel but a shared source of truth between users, product teams, and sales/marketing is a third. In the grand scheme of things a weak version of community at best, I’ll grant you.
Also, GitHub claims the main Sentry repo has had over 700 individual contributors. Were all of them paid employees or contractors of Sentry at the time of their contributions?
Binary answer: no. Longer answer: I did an analysis of commits to getsentry/sentry as part of this post. What I found is that since incorporating in 2015, 3.5% of commits have come from non-staff. In my view that is low enough to support the claim that Sentry is built by Sentry and we’re not out to milk devs for free labor.
In a large project, a small proportion of overall commits is still often quite a sizable absolute number. And I think people can very reasonably have concerns about Sentry accepting those contributions under a license which initially granted a much more fair and equal playing field to contributors, and then switching to one which grants a much less fair and equal playing field. I think contributors who suddenly lost rights to use something which previously had been open source and which still contained code they contributed would also be well within their moral rights to be very angry about that and to develop a negative view of Sentry.
But I’ll just be blunt: I am not philosophically or morally opposed to the existence of what the FSF would call “non-Free software”. I am opposed to what seems to me to be the attempt by quite a few companies to have their cake and eat it too by being effectively proprietary software while also making mouth noises about “open” or various clever synonyms/euphemisms for it.
Personally, I think trying to build a SaaS startup around a piece of open-source software is (for hopefully obvious reasons) a really bad business plan and pretty much always destined to fail and lose all the investors’ money, and if someone really wants to build a SaaS startup around their own software project they should just be full proprietary from day one. That doesn’t build as much buzz among developers as being able to claim “open source”, but it also doesn’t create so many angry developers when sooner or later the rug pullNext Exciting Chapter Of Our Open Journey happens.
So why not knock off the cutesy language games and just honestly be a proprietary-licensed SaaS company? All these attempts to re-brand proprietary licensing – and I call it that because the goal seems to me to be exactly the same, using copyright and license terms to enforce a monopoly on commercial exploitation of the software – as something nicer-sounding are just pointless.
I agree with a lot of what you’re saying. I’m asking some questions not to be leading but because I am genuinely curious about where it is that we’re starting to differ on this, because whereas I have literally zero qualms about this license change and agree with much of your fundamental positions, there’s clearly a divergence when it comes to the “just be all the way proprietary” conclusion.
You call it having cake and eating it too, but isn’t it just that companies see a benefit in a license that opens some aspects but not all? It’s not rebranding, it’s just a change in copyright protection. If people read “Open Source” when they read “Fair Source”, what’s to be done about that?
If you have no moral objection to the license, is it just that you feel that “Fair Source” or other titles coopt “Open Source” terminology in a way that does not honor the underlying ethos or expectations?
I feel that companies which start out under actual open-source licenses and then realize that’s a terrible business plan and suddenly scramble to relicense and try to brand the relicensingNew Chapter Of Our Exciting Open Journey as still being comparable to the former open-source terms are at the very least extremely distasteful, and exploitative of those who contribute during the open-source phase.
Even if all of the Sentry folks’ claims about code contributions not being that big a deal were accepted as-is, there’d still be the fact that they use a public GitHub issues board as a support portal, which inherently extracts unpaid labor from their users (managing an issue tracker is hard work and several actual open-source projects literally pay people to do it!).
Even if that were turned into a non-issue, there’d be the claims about how it’s “safe” to use “fair source” software, but those claims are dubious at best – your right to use the software is conditioned not on what you do, but on what they do, and at any moment their investors might demand they pivot or expand into a field that, by the letter of the license, you are operating in, at which point it is extremely not safe at all to be using the software! This is a risk that traditional proprietary licenses simply do not have.
Even if that were turned into a non-issue, there’d be plenty of others that have surfaced in this and every other long thread about “source available” licensing.
lol is this we’re to spend our one wild and precious life? Clinging desperately to moral outrage on behalf of hypothetical victims? “I will always have an issue! You can’t take that away from me!” lol smh
a license which initially granted a much more fair and equal playing field to contributors, and then switching to one which grants a much less fair and equal playing field
Licensing is only one aspect of the political shape of a project. Dirk Riehle did a comprehensive paper on this in 2011, which he references in this 2020 comment:
When the Open Source Initiative defined open source, it focused only on the license, and ignored the process. Smart entrepreneurs quickly discovered that they could provide to the world their product as open source code and benefit from it, while strictly controlling the process to keep competition at bay. This is called single-vendor open source.
Cramer has always maintained firm control over the process and roadmap and commercialization of Sentry since the first commit in 2008. There has never been any representation to committers that they are participating in a shared-governance community project. Rather, Sentry’s model has always been to hire promising volunteers:
Since as early as Sentry started generating revenue we started investing it back into the project. Not on our own salaries, but on giving back to the community in a variety of ways. One of those ways was to identify people who were helping the project and offer them a running contract. That is, if we saw someone contributing in a meaningful way to one of our repositories, we’d offer them a standing hourly contract paying them for their time. We didn’t need to do this, but we recognize they value they added, and in some cases these were serious time commits that people were voluntarily spending.
I submitted a few PRs with my own job application, fwiw.
Actual Contributors to Sentry Seem to Be Fine
I think contributors who suddenly lost rights to use something which previously had been open source and which still contained code they contributed would also be well within their moral rights to be very angry about that and to develop a negative view of Sentry.
I don’t find any commits from you in getsentry/sentry or any other repo in the org, so I take it that your umbrage is vicarious with reference to Sentry (maybe you have direct experience of rug pulling from another project?). By way of contrast, here’s an HN comment from a Sentry user who finds value in being able to contribute to our repos despite not being on the payroll:
I don’t want to compete with Sentry (or a variety of other open-like applications), but I do want to support my employers identity provider, fix bugs (and push them back), and maybe even add features that I/my team use. As an example, I’ve personally contributed multiple bug fixes, performance improvements and documentation changes to sentry’s libraries. I don’t want to compete with sentry, I want them to maintain my improvements and for other developers to benefit from my work.
I can’t say definitively that there aren’t Sentry contributors out there who resent us for relicensing. I can say that I haven’t heard from them yet, and, if they exist (maybe you have a concrete example or two to share?), their perspective is not the only reasonable one.
Fair Source Is Interesting
So why not knock off the cutesy language games
Fair Source is the brand name we chose for what Dirk named “single-vendor commercial open source.” It was a tough decision, as singlevendorcommercialopensource.com is available. ;-)
and just honestly be a proprietary-licensed SaaS company?
Fair Source licenses are absolutely proprietary licenses, yes. It might be worth stating this more explicitly on fair.io. But the values behind Fair Source and its benefits to developers are real and interesting and differentiated enough from Open Source, closed-source, and the remaining source-available approaches that they are worth branding and standing behind proudly.
Licensing is only one aspect of the political shape of a project
And yet it’s an extremely important one. People contributed to Sentry when it was open source, presumably in the same spirit in which people contributed to many open-source projects: of equitable give-and-take. Sentry then unilaterally changed those terms.
Sentry’s model has always been to hire promising volunteers:
…
I submitted a few PRs with my own job application
…
Actual Contributors to Sentry Seem to Be Fine
So… originally you seemed to be saying quite strongly that Sentry isn’t really doing this to get or take advantage of contributions. But now you’re saying Sentry even uses contributions as a form of unpaid job-interview task, and that everything’s OK because you don’t think the contributors mind what you’ve done with the licensing.
This is what I meant when I made the initial comment that you jumped on as unkind/trolling: here we are, deep in the thread, and the whole facade about contributions has come crashing down.
And this is without even touching any of the other major issues around proprietary licenses of this sort, several of which have been brought up by other commenters.
Sentry even uses contributions as a form of unpaid job-interview task
This might be true if it were required. It’s not. We have relationships with many SDK maintainers, some spanning many years. Some don’t want a contract with us, though we regularly offer. For my part, I voluntarily submitted those PRs because I wanted to stand out and get the job, not because Sentry required it. Honestly, there’s no need to be morally outraged about it on my behalf. :)
presumably in the same spirit
This presumption is the heart of our disagreement. Open Source has contained a crucial ambiguity since the start: many interpreted it to refer only to community-governed projects, while others interpreted it to also include corporate-governed projects. Sentry has never been community-governed, even if some (so far imaginary) contributors, along with some non-contributors such as yourself, may have assumed so.
Regardless of the past, Fair Source resolves the ambiguity for the future by establishing a new term for corporate-governed projects, leaving Open Source to refer to community-governed projects without ambiguity. At the very least, Fair Source benefits you by giving you a clear signal for avoiding projects you want to avoid. That’s intentional. We don’t want contributions you’re likely to resent having given us.
Fair Source is the brand name we chose for what Dirk named “single-vendor commercial open source.” It was a tough decision, as singlevendorcommercialopensource.com is available. ;-)
No. Fair source projects are not open source, so the term does not refer to “single-vendor commercial open source.” Fair Source is a name for single-vendor source-available proprietary software with delayed open-source publication.
I just noticed your comment in a different part of this discussion:
I have worked at smaller shops that have maintained forks of software just to get a feature they wanted that the maintainer rejected, or to extend bugfix support past upstream’s EOL, or to work around an inactive maintainer/abandoned project. People seem to really underestimate how willing companies – even smaller ones – are to fork and maintain a fork.
Maintaining a private fork is possible (and actual) with Sentry. This is another way in which Sentry could fairly be said to be more than “just another proprietary SaaS vendor.”
As others have pointed out, it is very much not safe to run your own instance of “fair source” software or maintain a fork of it. As I said in another reply to someone else, “fair source” licensing gives the licensor the ability to put the licensee into non-compliance by pivoting or expanding into new fields of software that the licensee was already operating in. Statutory infringement penalties being what they are, I would not maintain a fork of “fair source” for any amount of money.
10,000+ users from hobbyists up to FAANG companies have run self-hosted Sentry on Fair Source terms for five years at this point. Your risk assessment is yours to make, of course, and it puts you in an extreme minority. Fair Source is demonstrably safe according to a reasonable interpretation of Sentry’s experience.
How many of those companies maintain forks of Sentry? That’s where the worst danger is, but the whole thing about “fair source” seems to be trying to deny that.
What does it mean to “deeply engage the developer community” if not getting developers to contribute for free?
Good question. I should probably write this up in more detail since it seems to be a common concern (if not always expressed so succinctly). The tl;dr is Sentry optimizes for issues, not pull requests. Both are public (here’s our main repo), and we do occasionally get code contributions from non-staff. Same as like Zeke said, we welcome PRs when we get them, but we don’t optimize for them or depend on them. Instead, we optimize for GitHub issues.
What does that mean? That means we have a highly tuned custom GitHub notification engine for routing inbound issues to the right product team (I count 28 teams right now), which integrates tightly with Slack and with our internal security tooling. We have SLOs defined for response times (one business day to route, two additional business days to respond—business days account for varying holiday schedules and timezones at multiple global offices). We publish weekly reports in Slack for engineering managers to bring visibility to which teams are a) processing the highest volume and b) responding on time or not. We roll this up to a high-level BI dashboard that shows aggregate performance for the past two weeks, and quarterly for the past 3+ years.
It’s actually a pretty dope setup and that is what we mean by “deeply engaging with the developer community.” Turns out many more of yinz want to drop issues on us than want to drop PRs, and that’s fine by us. We love to talk about Sentry with you! :D
I’m confused. Did Sentry write the blurb on fair.io about “deeply engaging with the developer community”?
And you’re saying that the pitch to businesses is that the developer community will engage by contributing bug reports, but NOT that they will contribute code? Both things are free labor anyway.
You are not allowed to make any change to the code which threatens or impedes the “producer’s business model”. This is quite different from a project with a solid BDFL, which you are free to fork at any time; this line implies that a proper fork would be in violation of the license.
I’d also like to point out that this isn’t necessarily true and shows a lack of understanding of the FSL and FCL. The main restriction is that you can’t spin up a commercial product or service that competes with the author until after the 2-year transition to OSS, which is fair. However, simply forking isn’t spinning up a commercial product or service. You can fork under the FSL and FCL, as far as I’m concerned.
I’m a bit surprised at the level of negativity in these comments. The website seems to carefully avoid misusing terms like “open source” and “free software”. Given the license converts to MIT or Apache after 2 years, I’d say it’s much better than all the other proprietary “source available” options I can think of, IMHO.
I’d rather use open source software and it’s hard to see myself contributing to something under this license, but I’d still prefer to see Fair Source than e.g. the Server Side Public License as used by MongoDB, ElasticSearch, Redis.
It’s still moving the Overton window, if I can misuse that, away from free software, which IMO, is what’s in the best interest of the commons.
No surprise though as this is a corporate effort. And started by company who’s domain is blocked on my networks for privacy reasons, so already ethically dubious in my books.
The overton window today feels very binary. Open Source = good, anything else might as well be called proprietary. I happen to think that delayed Open Source is a significant improvement over closed source software.
free software, which IMO, is what’s in the best interest of the commons.
I thought like this for decades. But the fatal flaw at the core of the GNU concept of Free Software is a lack of distinction between individuals and megacorps. Both are considered “users” with rights.
This means Free Software is blind to the economic conditions that lead to proprietary software in the first place. If Amazon is going to reap the economic benefit of your hard FOSS work, you’re more likely to (a) keep it proprietary, or (b), put in less effort to the project.
In contrast, licenses like the FCL carve out a distinction so they don’t get crushed by the likes of Amazon, and will almost certainly lead to more eventual FOSS being released than something like the AGPL ever did or will.
I definitely agree corporations should be held to a different/higher standard, but I still haven’t seen any solution I believe in.
These licenses that devolve into Open Source, and not Free Software, are certainly not it IMO. They also seem to be made with the goal of benefiting corporations, the difference being they’re the creators and give themselves dibs. It just happens that for now the corps pushing these solutions are the smaller ones, but I think it’s the same idea as the “temporarily poor capitalists:” they’re not trying to change the system because they’re actually betting on it.
I think the terms of this license are essentially fine, as far as source-available licenses go. From what I can tell most of the objections in this thread are around the “fair” labeling, which is (evidently!) a contentious value judgement.
I’d still prefer to see Fair Source than e.g. the Server Side Public License
Maybe the negativity is because while you feel this way, for a lot of people (myself included) it literally doesn’t matter. There are licenses that encourage a culture of sharing and protect the users’ freedom to; there are licenses that don’t. I wouldn’t use SSPL licensed software, I wouldn’t use unFair Source licensed code, because they don’t encourage the culture I want to encourage, and they’re actively designed to work against it. If you pick an unFair Source license, you might as well pick no license and reserve all rights. because the only difference is how much damage you want to do to the culture.
If you pick an unFair Source license, you might as well pick no license and reserve all rights. because the only difference is how much damage you want to do to the culture.
This attitude is why there is so much completely proprietary software.
I don’t think it actually is; people who want to provide completely-proprietary software would exist no matter what - the Free Software Movement was an ideological response to the existence of such software vendors in the mid-1980s.
Why does comment engagement need to equate to ‘controversy’? Reading folks discussing topics is part of the appeal to me. Or is it that I have a negative connotation to the word ‘controversial’?
Note that it’s the ratio that is a strong signal for controversy, not the number of comments per se. A post that is seen as positive by the community usually has a ratio closer to 1. People will comment, and upvote the submission. The ratio rises when the only way the community can voice dissatisfaction is “this post is bad and wrong”, because there are no explicit flags for that. And of course, some posts will generate flame wars because they are essentially flame bait.
I should totally jump on liberachat and ask you there, but I’m tethered on a dodgy mobile connection at the moment and I’m having a hard time connecting. Do you have a list of most ratioed posts, and is it posted some place you can share it easily?
The SSPL is one of the newer licenses that I think is closest to being reasonable, but it seems to me that you could read its licensing requirements on supporting software to exclude the use of SSPL software with effectively any copyleft software. If you’re running the SSPL-licensed software as a service, you must release all of the supporting software’s source code under the SSPL. However, if you are running it on top of Linux for example, you can’t do that - you don’t have the authority to relicense Linux’s GPL code under the SSPL.
It includes most of the text and provisions of the GNU Affero General Public License version 3 (AGPL v3),[4] but modifies its provisions for software that is conveyed over a network—requiring that anyone who offers the functionality of SSPL-licensed software to third-parties as a service must release the entirety of their source code, including all software, APIs, and other software that would be required for a user to run an instance of the service themselves, under the SSPL. In contrast, the AGPL v3’s equivalent provision covers only the licensed work itself.
The SSPL is not recognized as free software by the Open Source Initiative (OSI), Red Hat,[5] and Debian[6] as the aforementioned provision is discriminatory towards specific fields of use.[3][7] Specifically, this is discriminatory against users of the software that use proprietary software within their stack, as the license requires the open-sourcing of every part interacting with the service, which under these circumstances might not be possible. This is in violation of Points 6[8] and 9[9] of the Open Source Definition as used by the Open Source Initiative.
The OSI’s interests are not aligned whatsoever with Free Software. It seems like the SSPL is great at combating a lot of the “Open Core” garbage, even though it is not technically a valid FSF approved/GPL-compatible license.
While I could be wrong, I believe the question was not asking “why would OSI/FSF dislike SSPL”, but rather “why would companies go invent yet another license to prevent competition when existing licenses like SSPL already accomplished that goal”.
I sense a spirit of free software in the SSPL. I did some research, but it seems RMS hasn’t had the chance to review it thoroughly yet and appears somewhat dismissive about it. 1
You’ll never make free software people happy. You’re almost always better off going closed source IMO. This topic is a prime example of this - we even have FSF vs OSI lol. I feel bad for keygen, who are likely trying to do the right thing, but will also likely find a scornful response waiting for them, one that they would have ironically avoided by just staying proprietary.
Meh, I expected it. I think there’s a long road ahead, but I believe Fair Source is a good thing, and better than source-available and closed-source. With Fair Source, we lean more towards Open Source, while also valuing sustainability. Besides, clout wasn’t one of the reasons I did this, as the OP dives into.
At the risk of being snarky: one could easily make me happy by choosing a free-er license. :-)
But your observation about the psychology involved is spot on. I don’t mind using closed-source software in general, and there are some closed-source tools I will recommend to others just because they’re a joy to use. But perception-wise, fair source paradoxically feels “worse” than closed, even though it ought to strictly be an improvement over not having the source at all.
Here’s my stab at an explanation. For the last couple of decades, giving someone source code was associated with giving them practically every freedom to do with it what they pleased. And if I withheld the source, it was pretty obvious I didn’t want you tinkering with it at all. But fair source violates people’s expectations by giving the source without all the freedom, and it’s the violation of expectations that makes people mad. (See also: DRMed MP3 files were irritating because they’re a new class of file that could disobey me, unlike any other file I possessed. But I have no problem with using Spotify, I suspect because that’s shaped like an “app” instead of like files.)
At the risk of being snarky: one could easily make me happy by choosing a free-er license. :-)
Not even! Because OSI and FSF can have incompatible views on this lol so you can’t even necessarily do that unless you find the overlap. But even if you did choose a GPL that’s compatible, why is that a goal? We’ve got this terribly ill formed ethical notion of software being “good” or “bad” by virtue of its copyright law, and it’s sort of “checkbox morality”. “You checked off the 10 things the OSI cares about, you’re in the clear!” “Uh oh, you missed one of them? Unethical software!”.
It’s a bit silly, really. No other contemporary moral argument works this way (or at least not any that aren’t literal religious ‘virtue lists’) lol it would never be taken seriously.
giving someone source code was associated with giving them practically every freedom to do with it what they pleased
I don’t think that’s true at all. Certainly if I give you source code without licensing it to you explicitly it’s not free for you to do as you please, it’s extremely restrictive. And we’ve seen a litany of licensing options because, wow, the world is evolving and licenses that we thought made sense in the 80s/90s very arguably don’t make sense today for every single line of code. I don’t believe that people can really meaningfully argue that they’re being deceived, the license is in plain text and there’s a release post about it.
The larger problem with OSS advocacy is it’s making very strong moral claims but it’s just not a meaningful ethical framework to me - OSS is just seen as a fundamental virtue. It is good, that is all there is to it.
If I write code and say “you can read the code but you can’t modify it or sell it without asking me first” am I a bad person? Or if I write code and say “you can run this code if your company has fewer than 5,000 users” ? Honestly, that’s the position that needs to be justified, the very foundation of this is conversation is what is ethical to do with source code. These are primarily ethical claims being made (especially from the FSF).
Even with DRM’d MP3s, I think it is extremely suspect that these are actually inherently unethical practices. That requires a lot of justification.
The irony that I pointed out is that OSS advocates shit the hardest on the people who are trying. They have a business that’s closed source and they want to do better, they want to give people more access to their code, so they open it up as much as they’re comfortable with. And then there’s backlash. Closed source? No backlash.
We’ve got this terribly ill formed ethical notion of software being “good” or “bad” by virtue of its copyright law, and it’s sort of “checkbox morality”. “You checked off the 10 things the OSI cares about, you’re in the clear!”
Well said. If I wrote a flight-control system for drones and released it under a license saying “here’s the code, but you aren’t allowed to use it to assassinate anybody,” the FSF types would complain that it violates Freedom Zero.
Well said. If I wrote a flight-control system for drones and released it under a license saying “here’s the code, but you aren’t allowed to use it to assassinate anybody,” the FSF types would complain that it violates Freedom Zero.
And the “assassinate people” types would still just use your drone control system to assassinate people anyway. So the only thing your release would have accomplished over just using, say, AGPLv3, is alienating the people who should like you most. The assassins would still assassinate. At the end of the day, does that feel like a good use of the time, money, and mental overhead it took you to develop your innovative anti-assassination license?
I suppose my point was that some people seem to consider a software project to be “moral”/“ethical” if and only if it’s released under an FSF-blessed license, while I believe that it’s vital to also consider what the project actually does, and how it might be used, and by whom, and for what purpose.
I like your point. I think it might not be enforceable via licensing. Enforcing a shared moral notion by using quirks of copyright to turn it into copyleft probably only works when copying/sharing is the only bit of the moral notion you’re trying to enforce.
Thinking about assassination is misleading. Entities that don’t respect the law aren’t going to care regardless, so they’re a bad analogy.
However, when it comes to large corporations, who are the real targets of these licenses, they are (somewhat) more bound by the law, or just the fear of a lawsuit, and won’t operate like the CIA.
I fear you’re reading into my comment some things that aren’t there. Specifically, I’m not coming from the position of “Closed-source/DRM is unethical”—rather, I’m trying to puzzle apart why fair-source has a negative connotation to me (and maybe to other people), despite being strictly better than closed source. Which sounds like the same thing that’s puzzling you.
In general, I prefer more permissive licenses and DRM-free media, but I’m not passing a moral judgement on any person or company who goes the other way—in fact, I pay them money for their services.
For the last couple of decades, giving someone source code was associated with giving them practically every freedom to do with it what they pleased. And if I withheld the source, it was pretty obvious I didn’t want you tinkering with it at all. But fair source violates people’s expectations by giving the source without all the freedom, and it’s the violation of expectations that makes people mad.
This is false. Open Source never gave you unbridled freedom until you read and understood the license terms and deemed that is the case, especially when we’re talking about copy-left, which has been used to coerce companies into purchasing commercial terms under threat of legal action through sheer ambiguity.
Besides, the restrictions that Fair Source imposes mainly effect those that want to compete with the author, and let’s be honest, most users don’t want to compete with the author.
So the reality is that most users can do what they want, unrestricted, under Fair Source. And even then, that minimal restriction usually expires after 2 years, so it doesn’t prevent it outright — it just delays it — making sure the author is not taken advantage of.
I see you are the founder of Keygen, so thank you for taking the time to reply to me! You’re absolutely right that most open-source projects do not technically give completely unbridled freedom (unless it’s in the public domain, you usually have to at least leave the original copyright notice in place, i.e., no stealing credit). I also agree that most of your customers aren’t competitors, so the additional restrictions of fair-source ought not to be a burden for them.
There is still a paradox in that people’s knee-jerk reactions don’t line up with the situation (giving your customers more rights shouldn’t get you booed), and that’s the paradox I was trying to explore with my comment. I’m not a FSF purist at all (FWIW I think you’re 100% in the right to license your stuff however you want), yet I still had that same knee-jerk reaction. Why does the psychology work like that? On the face of it, it doesn’t make logical sense. But if other people feel this way, and if fair source is to gain traction, the psychology is worth understanding.
At any rate, best of luck with Keygen, and may you continue to do right by your customers. :-)
Arguably worse than (A)GPL in terms of license compliance are all the software projects with no license at all. There’s a strong expectation of “I can use this” when technically there’s no permission at all. At least with GPLed code, it’s clear that there are some strings attached.
Business news is off-topic for lobste.rs. Self-promoting one’s business is off-topic for lobste.rs. “I am promoting a new form of proprietary software license” is probably off-topic for lobste.rs.
I would argue it’s not “off-topic” seeing as it’s number 2 on the front page and is directly related to the law tag i.r.t. software licensing. There were actually 2 related posts on the front page regarding Fair Source, but they were merged. I also wouldn’t say it’s self-promotion either, as the main point of the article is about why I would relicense from ELv2 to FCL, and what Fair Source is. It’s not really about Keygen at all.
Besides, this is continuing the discussion started by pinjasaur, which began when he leaked the WIP version of the FCL website: https://lobste.rs/s/rvnhee/fair_core_license. I wanted to share the whole story, because a lot of people were lost in that earlier discussion because Fair Source was referenced but hadn’t launched yet.
This is more about Fair Source than anything. If the community disagrees, then I’d say change the link to point to https://fair.io and change the title to “Fair Source” i.e. do a reverse merge.
This is more about Fair Source than anything. […] I’d say change the link to point to https://fair.io and change the title to “Fair Source” i.e. do a reverse merge.
I swapped it around. We try to favor a primary source with announcements/responses merged into it, but the way these got submitted a couple weeks after the /s/rvnhee had me thinking that this was someone adopting the license and then someone resubmitting the main license site as a response to that.
Hm, sorry, definitely wasn’t intending on “leaking” anything. I’ve been incredibly interested in fair source/core after learning about it earlier this year. I’m surprised it’s not being received as well as I would have hoped, but I guess it’s more nuanced than I originally thought. Unfortunately I didn’t see your submission this morning when I posted it and I was at a conf all day so I missed the bulk of the activity + it getting merged together.
That’s okay. I’m sorry if that comment gave off the vibe like I was upset — I’m not. The website was public after all, and the “leak” provided valuable feedback. It was just a little bit earlier than I was expecting, that’s all.
I’m grateful that people are interested enough to pay close attention and share out. That’s working as intended, as far as I’m concerned. Thanks for sharing here and elsewhere, Paul! :-)
And another attempt at diluting the reach, heart, message, and meaning of Free Software tries to rear its ugly head once again. As if the OSI needed anymore help.
The very point of this initiative is to make perfectly clear that something that might be mistaken for free software is actually not free software. it does not dilute, but rather distils the message of the free software movement.
Except the name of “Fair Source” is absurdly presumptive, implying that other licenses are ‘unreasonable/unfair’. It’s gross marketing, and polluting the space.
(I acknowledge that my choice of language is ‘strong’, for what its worth. This particular kind of business is just particularly annoying to me and I very much don’t like it. It’s remarkable how much companies are willing to bend and contort to limit the freedom of their users, while getting the maximum return possible.)
At some point it sounds like “thou shall not have a catchy label” though, because any one-word label will imply something someone else disagrees with. It’s not like everybody agrees the FSF has the only possibly correct definition of Freedom, yet they presume that by “Free Software”, and even someone who disagrees knows clearly what is meant by it in practice.
It is clear that they chose the term Fair Source for marketing (instead of something much more descriptive and honest, a comment from the thread 8 years ago suggested “public source viewing licence (PSVL)”). There is no real justification on their site for coming up with that name beyond marketability.
“Free Software” has manifestos dedicated to the meaning of its name, so much so that even if you do not agree with them, you very likely already know what the “4 Fundamental Freedoms” are (if you’re on this site, at least).
The name Free Software was picked because it identifies with the concepts of Freedom. “Fair Source” was picked purely because its marketable. These are two different things. One cares about their cause (even if you don’t agree with it), the other wants to extract value.
In this case, not the OSI. Rather, in this case, it’s the ones who have skin in the game, who decided to share their company’s core products under mostly-permissive terms so others can benefit.
Implying users of the software have no skin in the game… And of course its for the good of the people, and not hoping to earn goodwill/marketability from developers/‘developer advocates’ by offering a crumb of visibility into the code they would be running on their machine, as if its not already considered a basic right of the user (though so often infringed). I mean, why else would one make such a post to the common developer-centric link-aggregators other than to inform them of the gift you’ve so generously provided them?
I mean, why else would one make such a post to the common developer-centric link-aggregators other than to inform them of the gift you’ve so generously provided them?
Because I believe in Fair Source offering a viable way to monetize software while also valuing user freedom. I believe it’s better than source-available, and I want others to participate in and adopt Fair Source. It ultimately benefits Open Source where source-available and closed-source do not.
By that line of thought, who is the FSF to decide which freedoms are important? I personally favor human freedoms over the freedoms of corporate “persons”, but the GPL makes no distinction, sadly.
The 4 Fundamental Software Freedoms are clearly written out by the FSF, which is remarkably different from purely vague nothing-terms like “balance” and “fair”.
There is a clearly written Fair Source Definition that defines fundamental freedoms across all Fair Source licenses: https://fair.io/about/. Nothing vague about that.
I know what the FSF says the freedoms are. Clarity is not the issue here.
But my conception of freedom applies to humans, not corporations, and I object to the FSF laying claim to the word “free”, in the same way you object to this new license laying claim to the word “fair”.
Both “Free Software” and “Fair Source” are clearly defining an antinomy. Free Software openly and proudly opposes itself to software-as-commerce, software with strings attached.
What, then, is the antinomy implied by “Fair Source”? What is “Unfair Source”? If you don’t like this question, then do not ask it!
Reminder the Boost Software License has used the acronym BSL since at least 2003, but “Fair Source” promoters will refuse to respect that and will afford the acronym to HashiCorp’s unfree license. How’s that for fair?
I think this is less about malice and more about the fact that MariaDB refers to the BUSL as BSL, and so in my experience, the vast majority of people who see BSL think Business Source License, even if that’s incorrect. That’s why BUSL is listed first in the parenthesis — because it’s the correct abbreviation.
Regardless, I’m not sure why you’d even use this as a point to attack Fair Source. Seems like vitriol for the sake of vitriol and the world needs less of that.
Is your project so-called Fair Source or MariaDB? I think it’s fairly obvious why would I use the text on so-called Fair Source’s website to criticise it. It’s not vitriol for the sake of vitriol, it’s pointing out disrespect and the irony of it all. Maybe treat other code authors as fairly as you want to be treated.
I am disappointed that there is no music associated with this page. Also, it doesn’t seem to have an Age of Empires II keygen, so not sure what the point is.
Blame my shareholders. They only allocated resources for including the Frozen or Moana soundstacks right now, and I was unable to get the rights to those.
I’m glad to see this and welcome innovation in licensing that aligns interests between developers, customers, and users.
I love open-source and have done a lot of open-source work, but the incentives of a permissive license like MIT make it hard for the maintainer to support themselves.
Imagine two entrepreneurs competing and both have $100k. The first spends $100k hiring a developer to write MIT-licensed code and launches their product. The second forks code from the first and spends their $100k on marketing. The second will dominate the first because they have everything the first person had and didn’t have to pay anything for it.
I think licenses like FSL and FCL do a good job of balancing interests of developers, customers, and free users so that one can create a sustainable business with software that still allows users to extend and modify the code.
Good to see you here. Appreciate the kind words. Obviously a long road ahead, but like you said, I think Fair Source is a good balance. I’m excited to see other companies adopt it in the future.
somebody could just publicly fork the repo and give themselves, and others, the EE features without any ramifications, a direct threat to my monetization strategy.
Serious question: no matter what license you use, what is your strategy for preventing this? Do you have a big fund for lawsuits sitting around that you’ll be able to use to smack down anyone doing such a thing?
It works as a deterrence. Companies large enough to be worth suing will have a Legal Dept. that will tell them not to touch the code.
Licenses like this are targeted against Amazon making an “Elastic $YourProduct”. Amazon knows that building a product on a copyright violation is not a good strategy.
One irony is that the author of this, in a previous thread, tried to (as I understood it) approvingly cite Redis as an example of using licensing to crack down on “free riders” like Amazon, when Redis-the-company is not the original author of Redis-the-software and Amazon actually has paid at least one core developer of Redis-the-software.
No. If my company shut down, I wouldn’t bother. But larger companies can’t function on promises, so they would still deem it a risk. This is the big pushback that I experienced when selling EE to enterprises under ELv2.
Sorry, I misread the original comment as relating to a company giving themselves EE features in CE in the event of my company shutting down (one of the main topics of the post). To answer your question about license violators — I don’t have a legal fund ready to hound violators. But I would enforce my copyright, especially if the violator is a business. This would be the same for a violator of an Open Source project’s license, too. There’s really no difference i.r.t. Open Source vs Fair Source here — a license violation is a license violation.
There’s really no difference i.r.t. Open Source vs Fair Source here — a license violation is a license violation.
That’s true, and in practice we see that companies routinely violate open source licenses without any consequences, which I guess is where my question came from. When you say “I would enforce my copyright” do you have specific plans on accomplishing that without expensive lawsuits?
I’m not sure what you’re wanting me to convey here, so trying to choose my words. I will enforce my copyright. That may be a DMCA take down request, or a legal warning, or a lawsuit. It all depends on the effects that the violation has to my business, and on who the violator is. This is no different than e.g. an OSS company licensed under AGPL discovering a violator.
Replying to myself as I can’t edit this comment (now or maybe ever?). Didn’t see the OP when I submitted this morning otherwise I would have just added a comment.
2 years huh. Once people really start to keep the mirror and fix the differences via their own implementations (since diffs are available), this license will die.
What do you mean exactly by “this license will die”? Companies have been using other delayed-OOS licenses like BUSL for years and those licenses aren’t “dead.” Keygen is also actively being developed, so all OSS releases will be 2 years behind the canonical repo. (Unless the company shuts down, of course, but then that’s the entire point of the FCL and delayed-OSS.)
There’s a cost in both directions. As the ‘official’ upstream, it’s hard for you to take features from other forks because your code has evolved for two years since they made the change. This means that you’re not getting any of the benefit from external contributors, but if someone forks the project then they can.
This means that your improvements have to be more useful than everyone else’s contributions combined. This is generally easy in one of two situations:
First, if you’re a young project that’s evolving very quickly, you’re adding features and it takes external contributors a long time to learn the codebase and be as productive as you.
Second, if you’re a very big company, you can throw a lot of developers at the project.
I don’t think the second applies to you, but it could apply to a competitor. If, say, Google decided to put a 30-person team full time on the open source codebase and bring it to and beyond feature parity with your version, how does that affect you?
It’s not really clear to me from the web site what this project actually does (is it some kind of license server?), so I can’t really tell how easy it is to copy.
If a big company comes along and decides that what you have is useful, they will typically do one of two things:
Buy you and relicense your product under a permissive license.
Pay someone else (possibly in-house developers) to replace it with something under a permissive license.
The only projects that are immune to the second option are ones that are both big (and so very expensive to recreate) and actively developed (and so catching up is a moving target). If a project is big but not actively developed (or actively developed but slowly due to technical debt) then companies will invest in a narrowly scoped replacement for a subset of its functionality in their highest-value use cases, and then gradually widen the scope until the existing project is gone. If the project is not big, they will simply pay someone to write the permissively licensed version.
The first option may be desirable for you (I guess you wouldn’t say no if MS / Google / Whoever offered you a big pile of cash?) but it will happen only if it’s either cheaper than the second option or if they have time pressure to ship. That increases the risk to your existing customer: if EvilCorp offers you $100M tomorrow and then puts up the price of your commercial offering to everyone who is locked in so that they can recoup that money in the two years until the current version becomes open source, what would they do? For a company, a big part of the value of open source comes from the fact that you can get a second source immediately if not having one becomes too expensive. That’s not the case with a delayed open source license, and so there’s downwards pressure on both what you can charge for the product (you’re higher risk than something properly open) and the company (if it’s cheaper to reimplement, why buy the company?).
I think you’re vastly overestimating how much an individual or company wants to maintain a fork of a project. I’d imagine most Fair Source projects are also Single Source, accepting contributions if they happen to come in, but they don’t rely on them. The authors drive the project forward, and everybody is okay with that.
I just don’t see your hypothetical scenario playing out in the real world. We have years of projects undergoing DOSP to look at and it hasn’t happened to any of them.
I have personally worked with companies that have paid people to develop permissively licensed replacements of GPL’d or shared-source projects. It happens whenever there is a business need for something without vendor lock in that is greater than the cost of developing the replacement. I still don’t really understand what your project does, so I can’t tell how likely that is. It looks like it’s a license server and there are a bunch of open source ones already, so I guess you customers are there because it’s cheaper to use a supported product than roll their own. From the flows in your docs, I honestly don’t see the value. It looks like something that wraps a few basic cryptographic primitives in an RPC layer and then bolts on a tiny bit of ACL management. I don’t see how that would be more than a couple of thousand lines of Go, so I clearly don’t understand what it actually does and why people pay for it.
I have worked at smaller shops that have maintained forks of software just to get a feature they wanted that the maintainer rejected, or to extend bugfix support past upstream’s EOL, or to work around an inactive maintainer/abandoned project. People seem to really underestimate how willing companies – even smaller ones – are to fork and maintain a fork.
I don’t mean to be negative. But I’m thinking about possible infra around projects with these types of licenses. For example a public fork that is being merged every day (not per release! as you mention). Also a private CI that for example runs your HEAD FCL licensed tests on the public fork. Just thinking…
To clarify, under the FSL/FCL/BUSL, a “version” doesn’t have to be an ‘official’ release e.g. cutting v2.1.4. It can be the software being “made available” via a Git commit, publishing a package, cutting a new GitHub release, sending via an email attachment, or mailing out a floppy disk via snail mail.
For example, you could clone a Git repository, run git checkout $(git rev-list -n 1 --before='2 years ago' master) and, given the LICENSE file is FSL/FCL (they have a 2-year change date), use that version under the Open Source terms of the change license.
Actual content aside, I find the Corporate Memphis/Google-esque design of the page’s graphics to be pretty off-putting. I suppose the license is a kinda corporate by nature, but who is this style really meant to appeal to?
I think this license is quite good and I understand where it’s coming from. There is a genuine fear for businesses when they release their source code that another cloud vendor will just undercut them and this license addresses this in a rather good way as users can still get most of the benefits that open source gives.
I do understand though why the website rubs people the wrong way. The name is fair source, at the same time the website faq about why a company should adopt the license is all about how it serves the company. Less support costs! Easier sales! It feels like it’s missing the spirit of the free software while trying to reap the benefits of its connotation. I would’ve liked to see the site talk about why users want open source and the societal benefits it has, and try to convince companies that way instead. Otherwise the license might just start carrying negative connotations to the user (“oh fair source? They’re just trying to take advantage of my free labor”).
My main plan for this sorta “problem”, has always been, depending on the number of customers / amount of net revenue, old releases will begin to be made available under some random license whatever. the more customers/revenue? the closer those releases will be to current version (up until a point, if the project owner desires)
Or in other words: You want more useful code? Give more money!
If it is a trivial fix for something I use & helps myself + others, I would contribute so I wouldn’t be speaking for everyone. Getting to assess the source & pitch in if you want is better than proprietary in my book. The only thing that would grind my gears is a CLA that requires giving up personal, private data.
“For companies who want to reap the rewards of free labor, while making sure those do-gooder code-monkeys are kept in their place.”
You are not allowed to make any change to the code which threatens or impedes the “producer’s business model”. This is quite different from a project with a solid BDFL, which you are free to fork at any time; this line implies that a proper fork would be in violation of the license.
You assert that because a company wants to share its source code that it’s also soliciting free work, but that’s far from reality. I’d imagine most Fair Source projects are also Single Source, accepting contributions if they happen to come in, but they don’t rely on them, much less solicit free work.
If a company does attempt to solicit free labor, that’s on them; it’s not the fault of Fair Source, or of Open Source for that matter. In any case, they should reap what they sow.
I hope you can see the value in a company sharing their core product with no strings attached, even going as far as to undergo DOSP.
I understand that you have a direct stake in this matter, seeing as your company just released that you’re switching to this particular licensing scheme.
Of course, not soliciting free labor in the way that placing a tip jar/bucket in front of a performer/register is not soliciting tips :)
“We’ll hand you our abandonware after we’ve deemed it no longer sufficiently profitable.” Yes, very noble.
Note the first word was “allows use”; the primary benefit is being able to run the software yourself (redistribution also includes distributing the software onto servers).
The goal of DOSP is not to be a “bail out clause” in case the company sours, but even if a project failed to turn into a profitable business doesn’t mean that the source code doesn’t confer value to its users.
Many closed source projects have been released as open source years later and found a sustainable community. For example, FoundationDB was originally closed source, purchased by Apple in 2015, then open sourced in 2018 and is still active today[1]. ID Software released every version of Doom and Quake as open source, years after they were deemed “no longer sufficiently profitable”, but still found plenty of appreciative users.
The idea of DOSP is that it is a legal right, imbued in the source code itself, that you will be granted free permissive use of the source code at some future date. Versus the current status quo which is to depend solely on the good graces of a company who chooses to do so (the examples above re: Foundation DB and Quake).
[1] https://github.com/apple/foundationdb [2] https://github.com/id-Software/Quake
It’s also worth noting that under Fair Source, the only real restriction now is i.r.t. competition. Meaning, if you want to compete using the source code, you must wait 2 years for the OSS release. Otherwise, you’re free to do what you want now. That’s very fair. In practice, the restrictions effect very little real-world users, because most don’t want to compete with the author; rather, they just want to run the software.
The reason that lawyers tell you never to let it in the building is that ‘competition’ is very hard to define. Today, I have no plans to offer a service that’s the same as yours. What happens if your v2 incorporates something that I do? Now we’re competing and I have no migration path. There are a lot of cases like this where you can find that you’re competing. A lot of companies have businesses that slightly overlap with people up the supply chain for them. This is often dynamic. ‘Don’t compete with your channel’ is a good maxim, but sometimes you’ll compete for a bit for a few customers and then move to distinct businesses. The definition is usually written as something like:
The phrase ‘substantially similar functionality’ is the kind of thing that is vague and makes lawyers run away. The ‘any other product or service we offer’ is really painful. Yes, it’s time limited for the current version but if the company releasing this adds a new service that competes with you then you can’t use any future version of the software and that’s an enormous business risk.
What does it mean to “deeply engage the developer community” if not getting developers to contribute for free?
It’s not about contribution.
The main benefit of these licenses is that you can run the software yourself in 99.99% of cases (the restrictions vary per-license, but most licenses restrict your ability to compete).
You can also make modifications to your copy of the software if you want; nothing says you need to contribute those changes upstream.
It’s meant to be an alternative to private source commercial or enterprise-licensed source available (e.g. GitLab EE). For example, GitLab’s EE License (which you must pay for) says you grant them the right to use any changes you make:
https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/LICENSE
Fair.io says: “Engage the developer community with your company’s core software products.” And you’re saying this is about developers running their own instances of the software and make changes to their own personal copies? That’s the type of engagement they are pitching to businesses?
If a developer can self-host for free, they can use the software for personal use, if they can use the software, they can write about and recommend the software to their peers, if their peers read about or use the software, they can recommend it to their companies, and companies typically don’t want to self-host, so they recommend the cloud offering. It’s very simple grass-roots marketing from the bottom up.
You’re stuck on free labor (understandably — not everybody is business-savvy), but receiving contributions is not the only form of engagement with the developer community.
Code contributions are not the only valuable contributions and not the only form of free labor. And I’m not stuck on it, I’m just amused by the refusal to be honest about fair.io’s pitch to businesses.
Nobody ever said patches are the only way that a Fair Source company could “engage the community.” The question has always been what they mean by “engaging the community” in their pitch to businesses. And none of you Fair Source defenders have answered that question directly and honestly, your comment above being a perfect example.
I don’t understand why you believe I’m being indirect or dishonest.
I asked: “That’s the type of engagement they are pitching to businesses?” You responded by describing one possible way that developers could engage without contributing code. As an answer to my question, that seems either indirect or dishonest.
I don’t understand what is indirect or dishonest about my response, and I’m done with this weird conversation. If you want to read about more types of engagement, it’s covered in the FAQ under “Why should I adopt Fair Source at my company?”
If you want to say that’s dishonest, you’re only fooling yourself.
A direct and honest answer would acknowledge that free contributions are one of the ways businesses would hope to engage developers.
You’re prodding for a predetermined answer that isn’t there, because you’ve already made up your mind that Fair Source is a thin veil to solicit free labor for profit when it’s not. You aren’t involved with the companies adopting Fair Source, so you shouldn’t speak on their behalf. Let their actions show what’s true, not your feelings or assumptions; and if you do that, you’d see that you’re wrong.
Are free contributions one of the ways that Fair Source businesses hope to engage developers, or not?
I can’t speak for all Fair Source companies, but I can speak for Keygen and the answer is no. Like I’ve said elsewhere, if a Fair Source company were to go Fair Source in hopes of soliciting free labor, that’s on them; but to imply that Fair Source as an intiative encourages that or that all Fair Source companies do that or want to do that, with zero proof — even if they theoretically can, just like any commercialized Open Source project can — is a flat out misrepresentation of Fair Source.
The link appears to show that you accepted 9 unpaid commits in the last 6 months, correct? And you are suggesting that you did not want these commits and that you’re not hoping for more as a result of the Fair Source initiative?
I did not ask for them, no, and I continue to not ask for contributions. But I won’t turn away people that want to contribute for their own benefit or others benefit. In the same way I don’t tell my users to not help each other i.e. community-led support. Why would I? To do that would be ridiculous. People are free to help each other. People are free to modify the software and contribute those modifications to the benefit of others, including the author, the same way they’re free to modify the software and not share their modifications. That’s codified into the Fair Source Definition. But nowhere are we stating “you get free labor!” as a benefit of adopting Fair Source.
In any case, I feel like you’re trying to push the conversation in such a way as to make me look like I’m soliciting free work under the guise of Fair Source, so I’m going to stop the conversation here.
Comment was removed after a week so I guess I’ll rephrase it.
Answering the question “are you suggesting that you did not want these commits and that you’re not hoping for more” with “I did not ask for them, no…” is not a direct and honest way to respond.
[Comment removed by moderator pushcx: Tenditious insults aren't a good discussion (and make your arguments look very weak, fwiw).]
You’ll have to forgive us, because 90% of the comments here are exactly that.
I don’t see how his comment is dishonest: the primary metric of engagement is usage. Tens of thousands of organizations self-host Sentry, a fair source product, and they’re all developers – if that’s not engagement I don’t know what is. (Full disclosure: I work at Sentry.)
FWIW I don’t mean to dismiss you or anything – you’ve highlighted the text is clumsy and should be made more clear. I agree.
Maybe if you could provide literally one example.
Do you consider this to be an honest description of the kind of “developer engagement” that fair.io is pitching to businesses? Businesses are supposed to understand “developer engagement” to mean “developers self-hosting your product”? You think this covers it, with no significant omissions?
I understand the disconnect now. For most of us, “contributing” means patches, because we don’t actually see submitting a ticket on a GitHub project being any different from sending a customer support email or Zendesk widget.
You seem to think differently; that’s okay.
I think I just wrote above that the text isn’t sufficiently accurate and ought to be changed. If you see my comments on here, you’ll see they’re pretty consistently highlighting that end-user usage is the primary benefit.
Like most work, it was put together by humans, and humans don’t always get it right. We’ll try to do better.
Thanks.
That disconnect does not explain why you wrote “90% of comments here are exactly that.” Accounting for the ambiguity in terminology, you should still be able to show at least one comment claiming that patches OR contributions are the only way a Fair Source company could engage the developer community. Or if you retract that comment, I don’t know maybe say that instead of deflecting?
I missed that part. Was that in a different comment chain?
Do you think Stripe has deeply engaged the developer community? I believe most developers would answer “yes.” There are a myriad of other examples, too, of closed source companies deeply engaging the developer community to the extent that those developers become the #1 advocates for the company, fostering growth from the bottom up, yet they don’t contribute a single line of code to the core product.
If a closed source company like Stripe can deeply engage the developer community outside of “free labor”, how much more could a Fair Source company?
A company with a closed-source platform that has a deeply-engaged developer community could decide to pull the rug out from under that developer community at any time, when it’s profitable or ideologically-convenient for the company to do so. Reddit and Twitter have both done this, and there’s no reason to expect that in a year or five years, we don’t be reading a bunch of articles about how Stripe is doing wrong by its developer community over something or other.
That’s completely irrelevant. The question wasn’t “Do you think a closed source company can engage deeply with the developer community and commit to some sort of long term relationship purely on the community’s terms”.
It’s really not clear what the question was.
How is that not plain enough?
There’s also another question.
[Comment removed by author]
Sure, but now we’ve switched topics from “soliciting free work” to rug-pulls.
But FSS helps prevent rug-pulls in 2 ways —
FSS is permissive enough to allow forks now, even. I can’t speak to all BUSL variations, but the restrictions under FSL/FCL are usually only limited to competition. If you disagree with direction the author is taking, there’s nothing preventing you from forking now. The main restriction is that you can’t spin up a product or service that competes with the author until the 2-year transition, which is fair.
Simply forking isn’t spinning up a commercial product or service, however.
I don’t really get your point. Are you disputing the blurb on fair.io that says Fair Source is designed “to deeply engage the developer community”?
No. You implied that the only way to engage a developer community was through free labor, and I made a point that closed source companies engage developer communities, yet those developers don’t contribute a single line of code to the closed core product. I asked if a fair source company could engage the developer community similarly, without free labor, but it was more a rhetorical question because the obvious answer is yes. I was simply implying there are many other ways to engage the developer community outside of free labor.
(Moved this comment.)
So you thought I was implying something that is obviously wrong?
The context was fair.io’s statement that “Fair Source is designed for companies that want to deeply engage the developer community…” So obviously they think there is something about (un)Fair Source that targets developer engagement in a way that other licensing schemes do not.
It means exactly that, but you’re about to get a dozen comments’ worth of runaround trying to assert otherwise.
Man, James. Really? Sentry is trying to get developers to contribute for free? You should know better than that. smh
P.S. Dropped the “deeply” fwiw.
As I see it, Sentry is a proprietary SaaS with a free tier that happens to allow self-hosting. Using GitHub issues as a customer-facing support portal doesn’t really change that, and anyone who builds a “community” around it is, in my view, in just as much peril as anyone who builds a “community” around any other proprietary software. Treating it as just another proprietary SaaS vendor is what I do and what I would recommend to anyone who asked me for advice.
Also, GitHub claims the main Sentry repo has had over 700 individual contributors. Were all of them paid employees or contractors of Sentry at the time of their contributions?
Eh, I’m like 95% with you. Sentry is a “proprietary SaaS vendor,” sure, but there are a few details that can be said to differentiate it from “just another.” Unmonetized self-hosting is one, especially considering we don’t limit features. Delayed Open Source publication is another. Using GitHub issues as not just a support channel but a shared source of truth between users, product teams, and sales/marketing is a third. In the grand scheme of things a weak version of community at best, I’ll grant you.
Binary answer: no. Longer answer: I did an analysis of commits to
getsentry/sentryas part of this post. What I found is that since incorporating in 2015, 3.5% of commits have come from non-staff. In my view that is low enough to support the claim that Sentry is built by Sentry and we’re not out to milk devs for free labor.Where we do encourage more involvement is with our SDKs, and there we have a long history of paying maintainers who start out as volunteers.
In a large project, a small proportion of overall commits is still often quite a sizable absolute number. And I think people can very reasonably have concerns about Sentry accepting those contributions under a license which initially granted a much more fair and equal playing field to contributors, and then switching to one which grants a much less fair and equal playing field. I think contributors who suddenly lost rights to use something which previously had been open source and which still contained code they contributed would also be well within their moral rights to be very angry about that and to develop a negative view of Sentry.
But I’ll just be blunt: I am not philosophically or morally opposed to the existence of what the FSF would call “non-Free software”. I am opposed to what seems to me to be the attempt by quite a few companies to have their cake and eat it too by being effectively proprietary software while also making mouth noises about “open” or various clever synonyms/euphemisms for it.
Personally, I think trying to build a SaaS startup around a piece of open-source software is (for hopefully obvious reasons) a really bad business plan and pretty much always destined to fail and lose all the investors’ money, and if someone really wants to build a SaaS startup around their own software project they should just be full proprietary from day one. That doesn’t build as much buzz among developers as being able to claim “open source”, but it also doesn’t create so many angry developers when sooner or later the
rug pullNext Exciting Chapter Of Our Open Journey happens.So why not knock off the cutesy language games and just honestly be a proprietary-licensed SaaS company? All these attempts to re-brand proprietary licensing – and I call it that because the goal seems to me to be exactly the same, using copyright and license terms to enforce a monopoly on commercial exploitation of the software – as something nicer-sounding are just pointless.
I agree with a lot of what you’re saying. I’m asking some questions not to be leading but because I am genuinely curious about where it is that we’re starting to differ on this, because whereas I have literally zero qualms about this license change and agree with much of your fundamental positions, there’s clearly a divergence when it comes to the “just be all the way proprietary” conclusion.
You call it having cake and eating it too, but isn’t it just that companies see a benefit in a license that opens some aspects but not all? It’s not rebranding, it’s just a change in copyright protection. If people read “Open Source” when they read “Fair Source”, what’s to be done about that?
If you have no moral objection to the license, is it just that you feel that “Fair Source” or other titles coopt “Open Source” terminology in a way that does not honor the underlying ethos or expectations?
I feel that companies which start out under actual open-source licenses and then realize that’s a terrible business plan and suddenly scramble to relicense and try to brand the
relicensingNew Chapter Of Our Exciting Open Journey as still being comparable to the former open-source terms are at the very least extremely distasteful, and exploitative of those who contribute during the open-source phase.Even if all of the Sentry folks’ claims about code contributions not being that big a deal were accepted as-is, there’d still be the fact that they use a public GitHub issues board as a support portal, which inherently extracts unpaid labor from their users (managing an issue tracker is hard work and several actual open-source projects literally pay people to do it!).
Even if that were turned into a non-issue, there’d be the claims about how it’s “safe” to use “fair source” software, but those claims are dubious at best – your right to use the software is conditioned not on what you do, but on what they do, and at any moment their investors might demand they pivot or expand into a field that, by the letter of the license, you are operating in, at which point it is extremely not safe at all to be using the software! This is a risk that traditional proprietary licenses simply do not have.
Even if that were turned into a non-issue, there’d be plenty of others that have surfaced in this and every other long thread about “source available” licensing.
lol is this we’re to spend our one wild and precious life? Clinging desperately to moral outrage on behalf of hypothetical victims? “I will always have an issue! You can’t take that away from me!” lol smh
Now we’re getting somewhere. :-)
Sentry Has Always Operated Above BoardLicensing is only one aspect of the political shape of a project. Dirk Riehle did a comprehensive paper on this in 2011, which he references in this 2020 comment:
Cramer has always maintained firm control over the process and roadmap and commercialization of Sentry since the first commit in 2008. There has never been any representation to committers that they are participating in a shared-governance community project. Rather, Sentry’s model has always been to hire promising volunteers:
I submitted a few PRs with my own job application, fwiw.
Actual Contributors to Sentry Seem to Be FineI don’t find any commits from you in
getsentry/sentryor any other repo in the org, so I take it that your umbrage is vicarious with reference to Sentry (maybe you have direct experience of rug pulling from another project?). By way of contrast, here’s an HN comment from a Sentry user who finds value in being able to contribute to our repos despite not being on the payroll:I can’t say definitively that there aren’t Sentry contributors out there who resent us for relicensing. I can say that I haven’t heard from them yet, and, if they exist (maybe you have a concrete example or two to share?), their perspective is not the only reasonable one.
Fair Source Is InterestingFair Source is the brand name we chose for what Dirk named “single-vendor commercial open source.” It was a tough decision, as singlevendorcommercialopensource.com is available. ;-)
Fair Source licenses are absolutely proprietary licenses, yes. It might be worth stating this more explicitly on fair.io. But the values behind Fair Source and its benefits to developers are real and interesting and differentiated enough from Open Source, closed-source, and the remaining source-available approaches that they are worth branding and standing behind proudly.
And yet it’s an extremely important one. People contributed to Sentry when it was open source, presumably in the same spirit in which people contributed to many open-source projects: of equitable give-and-take. Sentry then unilaterally changed those terms.
…
…
So… originally you seemed to be saying quite strongly that Sentry isn’t really doing this to get or take advantage of contributions. But now you’re saying Sentry even uses contributions as a form of unpaid job-interview task, and that everything’s OK because you don’t think the contributors mind what you’ve done with the licensing.
This is what I meant when I made the initial comment that you jumped on as unkind/trolling: here we are, deep in the thread, and the whole facade about contributions has come crashing down.
And this is without even touching any of the other major issues around proprietary licenses of this sort, several of which have been brought up by other commenters.
This might be true if it were required. It’s not. We have relationships with many SDK maintainers, some spanning many years. Some don’t want a contract with us, though we regularly offer. For my part, I voluntarily submitted those PRs because I wanted to stand out and get the job, not because Sentry required it. Honestly, there’s no need to be morally outraged about it on my behalf. :)
This presumption is the heart of our disagreement. Open Source has contained a crucial ambiguity since the start: many interpreted it to refer only to community-governed projects, while others interpreted it to also include corporate-governed projects. Sentry has never been community-governed, even if some (so far imaginary) contributors, along with some non-contributors such as yourself, may have assumed so.
Regardless of the past, Fair Source resolves the ambiguity for the future by establishing a new term for corporate-governed projects, leaving Open Source to refer to community-governed projects without ambiguity. At the very least, Fair Source benefits you by giving you a clear signal for avoiding projects you want to avoid. That’s intentional. We don’t want contributions you’re likely to resent having given us.
No. Fair source projects are not open source, so the term does not refer to “single-vendor commercial open source.” Fair Source is a name for single-vendor source-available proprietary software with delayed open-source publication.
I just noticed your comment in a different part of this discussion:
Maintaining a private fork is possible (and actual) with Sentry. This is another way in which Sentry could fairly be said to be more than “just another proprietary SaaS vendor.”
As others have pointed out, it is very much not safe to run your own instance of “fair source” software or maintain a fork of it. As I said in another reply to someone else, “fair source” licensing gives the licensor the ability to put the licensee into non-compliance by pivoting or expanding into new fields of software that the licensee was already operating in. Statutory infringement penalties being what they are, I would not maintain a fork of “fair source” for any amount of money.
10,000+ users from hobbyists up to FAANG companies have run self-hosted Sentry on Fair Source terms for five years at this point. Your risk assessment is yours to make, of course, and it puts you in an extreme minority. Fair Source is demonstrably safe according to a reasonable interpretation of Sentry’s experience.
How many of those companies maintain forks of Sentry? That’s where the worst danger is, but the whole thing about “fair source” seems to be trying to deny that.
Good question. I should probably write this up in more detail since it seems to be a common concern (if not always expressed so succinctly). The tl;dr is Sentry optimizes for issues, not pull requests. Both are public (here’s our main repo), and we do occasionally get code contributions from non-staff. Same as like Zeke said, we welcome PRs when we get them, but we don’t optimize for them or depend on them. Instead, we optimize for GitHub issues.
What does that mean? That means we have a highly tuned custom GitHub notification engine for routing inbound issues to the right product team (I count 28 teams right now), which integrates tightly with Slack and with our internal security tooling. We have SLOs defined for response times (one business day to route, two additional business days to respond—business days account for varying holiday schedules and timezones at multiple global offices). We publish weekly reports in Slack for engineering managers to bring visibility to which teams are a) processing the highest volume and b) responding on time or not. We roll this up to a high-level BI dashboard that shows aggregate performance for the past two weeks, and quarterly for the past 3+ years.
It’s actually a pretty dope setup and that is what we mean by “deeply engaging with the developer community.” Turns out many more of yinz want to drop issues on us than want to drop PRs, and that’s fine by us. We love to talk about Sentry with you! :D
Am I answering your question?
I’m confused. Did Sentry write the blurb on fair.io about “deeply engaging with the developer community”?
And you’re saying that the pitch to businesses is that the developer community will engage by contributing bug reports, but NOT that they will contribute code? Both things are free labor anyway.
That’s like complaining that a company is accepting free labor by receiving a bug report via email…
Who’s complaining?
I’d also like to point out that this isn’t necessarily true and shows a lack of understanding of the FSL and FCL. The main restriction is that you can’t spin up a commercial product or service that competes with the author until after the 2-year transition to OSS, which is fair. However, simply forking isn’t spinning up a commercial product or service. You can fork under the FSL and FCL, as far as I’m concerned.
Ref: https://github.com/keygen-sh/fcl.dev/blob/master/FCL-1.0-Apache-2.0.md#permitted-purpose
This applies to the likes of Amazon using existing FOSS software, too. Shouldn’t we characterize those licenses the same way, then?
I’m a bit surprised at the level of negativity in these comments. The website seems to carefully avoid misusing terms like “open source” and “free software”. Given the license converts to MIT or Apache after 2 years, I’d say it’s much better than all the other proprietary “source available” options I can think of, IMHO.
I’d rather use open source software and it’s hard to see myself contributing to something under this license, but I’d still prefer to see Fair Source than e.g. the Server Side Public License as used by MongoDB, ElasticSearch, Redis.
It’s still moving the Overton window, if I can misuse that, away from free software, which IMO, is what’s in the best interest of the commons.
No surprise though as this is a corporate effort. And started by company who’s domain is blocked on my networks for privacy reasons, so already ethically dubious in my books.
The overton window today feels very binary. Open Source = good, anything else might as well be called proprietary. I happen to think that delayed Open Source is a significant improvement over closed source software.
I thought like this for decades. But the fatal flaw at the core of the GNU concept of Free Software is a lack of distinction between individuals and megacorps. Both are considered “users” with rights.
This means Free Software is blind to the economic conditions that lead to proprietary software in the first place. If Amazon is going to reap the economic benefit of your hard FOSS work, you’re more likely to (a) keep it proprietary, or (b), put in less effort to the project.
In contrast, licenses like the FCL carve out a distinction so they don’t get crushed by the likes of Amazon, and will almost certainly lead to more eventual FOSS being released than something like the AGPL ever did or will.
I definitely agree corporations should be held to a different/higher standard, but I still haven’t seen any solution I believe in.
These licenses that devolve into Open Source, and not Free Software, are certainly not it IMO. They also seem to be made with the goal of benefiting corporations, the difference being they’re the creators and give themselves dibs. It just happens that for now the corps pushing these solutions are the smaller ones, but I think it’s the same idea as the “temporarily poor capitalists:” they’re not trying to change the system because they’re actually betting on it.
They’re certainly not trying to change the system, but we’re stuck with capitalism for the immediate future, and still have to pay our medical bills.
Remember, most people who work full-time on FOSS are employed by megacorps, which entails its own compromises, and also supports the system.
Very few people are independent full-time FOSS devs.
I think the terms of this license are essentially fine, as far as source-available licenses go. From what I can tell most of the objections in this thread are around the “fair” labeling, which is (evidently!) a contentious value judgement.
Maybe the negativity is because while you feel this way, for a lot of people (myself included) it literally doesn’t matter. There are licenses that encourage a culture of sharing and protect the users’ freedom to; there are licenses that don’t. I wouldn’t use SSPL licensed software, I wouldn’t use unFair Source licensed code, because they don’t encourage the culture I want to encourage, and they’re actively designed to work against it. If you pick an unFair Source license, you might as well pick no license and reserve all rights. because the only difference is how much damage you want to do to the culture.
This attitude is why there is so much completely proprietary software.
At least that’s much more honest about what it actually is, and makes it easier to avoid.
I personally don’t want to avoid software that allows me to see and modify the source code, just because it doesn’t allow me to sell it.
I don’t think it actually is; people who want to provide completely-proprietary software would exist no matter what - the Free Software Movement was an ideological response to the existence of such software vendors in the mid-1980s.
That’s okay, that’s their choice. I don’t have to use it or support it in any way.
[Comment removed by author]
You’re surprised that a discussion of free software licensing devolved into a flame war? 😅
At net 12 upvotes and 70 comments, this is fast approaching the most ratioed post on Lobste.rs ever.
Edit it’s not even close. The record for comments/score ratio is 48, and the 10th most ratio’d post has a ratio of 19.
With the recent reverse-merge, we’re top 20 now with a ratio of 18.5. 😅
“Yay”.
Edit please people, don’t continue commenting to drive up the ratio 😉
We’ve at least got to crack the top 10. 😎
Why does comment engagement need to equate to ‘controversy’? Reading folks discussing topics is part of the appeal to me. Or is it that I have a negative connotation to the word ‘controversial’?
Note that it’s the ratio that is a strong signal for controversy, not the number of comments per se. A post that is seen as positive by the community usually has a ratio closer to 1. People will comment, and upvote the submission. The ratio rises when the only way the community can voice dissatisfaction is “this post is bad and wrong”, because there are no explicit flags for that. And of course, some posts will generate flame wars because they are essentially flame bait.
I should totally jump on liberachat and ask you there, but I’m tethered on a dodgy mobile connection at the moment and I’m having a hard time connecting. Do you have a list of most ratioed posts, and is it posted some place you can share it easily?
I spent an enjoyable hour messing with the data and wrote it up here:
https://gerikson.com/blog/comm/Lobsters-top-controversial.html
It was interesting to see which tags recurred most. I thought law and merkle-trees would be more frequent flyers:
It’s a bit depressing because it doesn’t really show the community from its bes, but I’ll try to put something together tomorrow.
What’s wrong with SSPL?
The SSPL is one of the newer licenses that I think is closest to being reasonable, but it seems to me that you could read its licensing requirements on supporting software to exclude the use of SSPL software with effectively any copyleft software. If you’re running the SSPL-licensed software as a service, you must release all of the supporting software’s source code under the SSPL. However, if you are running it on top of Linux for example, you can’t do that - you don’t have the authority to relicense Linux’s GPL code under the SSPL.
I wrote a blog post about this a while back, but I think it could potentially be salvaged with an EUPL-style compatibility clause with other FOSS licenses.
The Wikipedia article has a couple of paragraphs about why it’s not considered an open source license https://en.wikipedia.org/wiki/Server_Side_Public_License
The OSI’s interests are not aligned whatsoever with Free Software. It seems like the SSPL is great at combating a lot of the “Open Core” garbage, even though it is not technically a valid FSF approved/GPL-compatible license.
While I could be wrong, I believe the question was not asking “why would OSI/FSF dislike SSPL”, but rather “why would companies go invent yet another license to prevent competition when existing licenses like SSPL already accomplished that goal”.
I sense a spirit of free software in the SSPL. I did some research, but it seems RMS hasn’t had the chance to review it thoroughly yet and appears somewhat dismissive about it. 1
You’ll never make free software people happy. You’re almost always better off going closed source IMO. This topic is a prime example of this - we even have FSF vs OSI lol. I feel bad for keygen, who are likely trying to do the right thing, but will also likely find a scornful response waiting for them, one that they would have ironically avoided by just staying proprietary.
Meh, I expected it. I think there’s a long road ahead, but I believe Fair Source is a good thing, and better than source-available and closed-source. With Fair Source, we lean more towards Open Source, while also valuing sustainability. Besides, clout wasn’t one of the reasons I did this, as the OP dives into.
At the risk of being snarky: one could easily make me happy by choosing a free-er license. :-)
But your observation about the psychology involved is spot on. I don’t mind using closed-source software in general, and there are some closed-source tools I will recommend to others just because they’re a joy to use. But perception-wise, fair source paradoxically feels “worse” than closed, even though it ought to strictly be an improvement over not having the source at all.
Here’s my stab at an explanation. For the last couple of decades, giving someone source code was associated with giving them practically every freedom to do with it what they pleased. And if I withheld the source, it was pretty obvious I didn’t want you tinkering with it at all. But fair source violates people’s expectations by giving the source without all the freedom, and it’s the violation of expectations that makes people mad. (See also: DRMed MP3 files were irritating because they’re a new class of file that could disobey me, unlike any other file I possessed. But I have no problem with using Spotify, I suspect because that’s shaped like an “app” instead of like files.)
Not even! Because OSI and FSF can have incompatible views on this lol so you can’t even necessarily do that unless you find the overlap. But even if you did choose a GPL that’s compatible, why is that a goal? We’ve got this terribly ill formed ethical notion of software being “good” or “bad” by virtue of its copyright law, and it’s sort of “checkbox morality”. “You checked off the 10 things the OSI cares about, you’re in the clear!” “Uh oh, you missed one of them? Unethical software!”.
It’s a bit silly, really. No other contemporary moral argument works this way (or at least not any that aren’t literal religious ‘virtue lists’) lol it would never be taken seriously.
I don’t think that’s true at all. Certainly if I give you source code without licensing it to you explicitly it’s not free for you to do as you please, it’s extremely restrictive. And we’ve seen a litany of licensing options because, wow, the world is evolving and licenses that we thought made sense in the 80s/90s very arguably don’t make sense today for every single line of code. I don’t believe that people can really meaningfully argue that they’re being deceived, the license is in plain text and there’s a release post about it.
The larger problem with OSS advocacy is it’s making very strong moral claims but it’s just not a meaningful ethical framework to me - OSS is just seen as a fundamental virtue. It is good, that is all there is to it.
If I write code and say “you can read the code but you can’t modify it or sell it without asking me first” am I a bad person? Or if I write code and say “you can run this code if your company has fewer than 5,000 users” ? Honestly, that’s the position that needs to be justified, the very foundation of this is conversation is what is ethical to do with source code. These are primarily ethical claims being made (especially from the FSF).
Even with DRM’d MP3s, I think it is extremely suspect that these are actually inherently unethical practices. That requires a lot of justification.
The irony that I pointed out is that OSS advocates shit the hardest on the people who are trying. They have a business that’s closed source and they want to do better, they want to give people more access to their code, so they open it up as much as they’re comfortable with. And then there’s backlash. Closed source? No backlash.
Well said. If I wrote a flight-control system for drones and released it under a license saying “here’s the code, but you aren’t allowed to use it to assassinate anybody,” the FSF types would complain that it violates Freedom Zero.
And the “assassinate people” types would still just use your drone control system to assassinate people anyway. So the only thing your release would have accomplished over just using, say, AGPLv3, is alienating the people who should like you most. The assassins would still assassinate. At the end of the day, does that feel like a good use of the time, money, and mental overhead it took you to develop your innovative anti-assassination license?
I suppose my point was that some people seem to consider a software project to be “moral”/“ethical” if and only if it’s released under an FSF-blessed license, while I believe that it’s vital to also consider what the project actually does, and how it might be used, and by whom, and for what purpose.
I like your point. I think it might not be enforceable via licensing. Enforcing a shared moral notion by using quirks of copyright to turn it into copyleft probably only works when copying/sharing is the only bit of the moral notion you’re trying to enforce.
Yeah, I suspect you’re right.
Thinking about assassination is misleading. Entities that don’t respect the law aren’t going to care regardless, so they’re a bad analogy.
However, when it comes to large corporations, who are the real targets of these licenses, they are (somewhat) more bound by the law, or just the fear of a lawsuit, and won’t operate like the CIA.
I fear you’re reading into my comment some things that aren’t there. Specifically, I’m not coming from the position of “Closed-source/DRM is unethical”—rather, I’m trying to puzzle apart why fair-source has a negative connotation to me (and maybe to other people), despite being strictly better than closed source. Which sounds like the same thing that’s puzzling you.
In general, I prefer more permissive licenses and DRM-free media, but I’m not passing a moral judgement on any person or company who goes the other way—in fact, I pay them money for their services.
That’s fair
This is false. Open Source never gave you unbridled freedom until you read and understood the license terms and deemed that is the case, especially when we’re talking about copy-left, which has been used to coerce companies into purchasing commercial terms under threat of legal action through sheer ambiguity.
Besides, the restrictions that Fair Source imposes mainly effect those that want to compete with the author, and let’s be honest, most users don’t want to compete with the author.
So the reality is that most users can do what they want, unrestricted, under Fair Source. And even then, that minimal restriction usually expires after 2 years, so it doesn’t prevent it outright — it just delays it — making sure the author is not taken advantage of.
Seems fair to me.
I see you are the founder of Keygen, so thank you for taking the time to reply to me! You’re absolutely right that most open-source projects do not technically give completely unbridled freedom (unless it’s in the public domain, you usually have to at least leave the original copyright notice in place, i.e., no stealing credit). I also agree that most of your customers aren’t competitors, so the additional restrictions of fair-source ought not to be a burden for them.
There is still a paradox in that people’s knee-jerk reactions don’t line up with the situation (giving your customers more rights shouldn’t get you booed), and that’s the paradox I was trying to explore with my comment. I’m not a FSF purist at all (FWIW I think you’re 100% in the right to license your stuff however you want), yet I still had that same knee-jerk reaction. Why does the psychology work like that? On the face of it, it doesn’t make logical sense. But if other people feel this way, and if fair source is to gain traction, the psychology is worth understanding.
At any rate, best of luck with Keygen, and may you continue to do right by your customers. :-)
You cannot practically do anything you want with GPL/AGPL code. AGPL, for example, is completely banned from use at Google:
https://opensource.google/documentation/reference/using/agpl-policy
Yes, I’m aware of the GPL/AGPL!
I never claimed every open source project gave you every freedom ever—just that there’s an association there. GitHub is not the entire open-source world, but the MIT License was the most popular license on there as of 2021, and overall, permissive licenses made up the majority. Similar story for package repos like npm.
Arguably worse than (A)GPL in terms of license compliance are all the software projects with no license at all. There’s a strong expectation of “I can use this” when technically there’s no permission at all. At least with GPLed code, it’s clear that there are some strings attached.
Context for flagging this:
Business news is off-topic for lobste.rs. Self-promoting one’s business is off-topic for lobste.rs. “I am promoting a new form of proprietary software license” is probably off-topic for lobste.rs.
I would argue it’s not “off-topic” seeing as it’s number 2 on the front page and is directly related to the law tag i.r.t. software licensing. There were actually 2 related posts on the front page regarding Fair Source, but they were merged. I also wouldn’t say it’s self-promotion either, as the main point of the article is about why I would relicense from ELv2 to FCL, and what Fair Source is. It’s not really about Keygen at all.
Besides, this is continuing the discussion started by pinjasaur, which began when he leaked the WIP version of the FCL website: https://lobste.rs/s/rvnhee/fair_core_license. I wanted to share the whole story, because a lot of people were lost in that earlier discussion because Fair Source was referenced but hadn’t launched yet.
This is more about Fair Source than anything. If the community disagrees, then I’d say change the link to point to https://fair.io and change the title to “Fair Source” i.e. do a reverse merge.
I agree. Is it too late for this?
cc @pushcx
I swapped it around. We try to favor a primary source with announcements/responses merged into it, but the way these got submitted a couple weeks after the /s/rvnhee had me thinking that this was someone adopting the license and then someone resubmitting the main license site as a response to that.
Not the case, just unfortunate timing on my part. Thanks for moderating.
Hm, sorry, definitely wasn’t intending on “leaking” anything. I’ve been incredibly interested in fair source/core after learning about it earlier this year. I’m surprised it’s not being received as well as I would have hoped, but I guess it’s more nuanced than I originally thought. Unfortunately I didn’t see your submission this morning when I posted it and I was at a conf all day so I missed the bulk of the activity + it getting merged together.
That’s okay. I’m sorry if that comment gave off the vibe like I was upset — I’m not. The website was public after all, and the “leak” provided valuable feedback. It was just a little bit earlier than I was expecting, that’s all.
I’m grateful that people are interested enough to pay close attention and share out. That’s working as intended, as far as I’m concerned. Thanks for sharing here and elsewhere, Paul! :-)
I strongly disagree with this one.
And another attempt at diluting the reach, heart, message, and meaning of Free Software tries to rear its ugly head once again. As if the OSI needed anymore help.
The very point of this initiative is to make perfectly clear that something that might be mistaken for free software is actually not free software. it does not dilute, but rather distils the message of the free software movement.
Except the name of “Fair Source” is absurdly presumptive, implying that other licenses are ‘unreasonable/unfair’. It’s gross marketing, and polluting the space.
(I acknowledge that my choice of language is ‘strong’, for what its worth. This particular kind of business is just particularly annoying to me and I very much don’t like it. It’s remarkable how much companies are willing to bend and contort to limit the freedom of their users, while getting the maximum return possible.)
At some point it sounds like “thou shall not have a catchy label” though, because any one-word label will imply something someone else disagrees with. It’s not like everybody agrees the FSF has the only possibly correct definition of Freedom, yet they presume that by “Free Software”, and even someone who disagrees knows clearly what is meant by it in practice.
I think that’s a false dichotomy.
It is clear that they chose the term Fair Source for marketing (instead of something much more descriptive and honest, a comment from the thread 8 years ago suggested “public source viewing licence (PSVL)”). There is no real justification on their site for coming up with that name beyond marketability.
“Free Software” has manifestos dedicated to the meaning of its name, so much so that even if you do not agree with them, you very likely already know what the “4 Fundamental Freedoms” are (if you’re on this site, at least).
The name Free Software was picked because it identifies with the concepts of Freedom. “Fair Source” was picked purely because its marketable. These are two different things. One cares about their cause (even if you don’t agree with it), the other wants to extract value.
Balancing developer sustainability and user freedom is pretty “fair” if you ask me.
Who says what the ‘fair balance’ is exactly? Or perhaps this is just intentionally vague whitewashing market-speak.
In this case, not the OSI. Rather, in this case, it’s the ones who have skin in the game, who decided to share their company’s core products under mostly-permissive terms so others can benefit.
Implying users of the software have no skin in the game… And of course its for the good of the people, and not hoping to earn goodwill/marketability from developers/‘developer advocates’ by offering a crumb of visibility into the code they would be running on their machine, as if its not already considered a basic right of the user (though so often infringed). I mean, why else would one make such a post to the common developer-centric link-aggregators other than to inform them of the gift you’ve so generously provided them?
Because I believe in Fair Source offering a viable way to monetize software while also valuing user freedom. I believe it’s better than source-available, and I want others to participate in and adopt Fair Source. It ultimately benefits Open Source where source-available and closed-source do not.
Let’s not imply malice where there is none.
By that line of thought, who is the FSF to decide which freedoms are important? I personally favor human freedoms over the freedoms of corporate “persons”, but the GPL makes no distinction, sadly.
The 4 Fundamental Software Freedoms are clearly written out by the FSF, which is remarkably different from purely vague nothing-terms like “balance” and “fair”.
There is a clearly written Fair Source Definition that defines fundamental freedoms across all Fair Source licenses: https://fair.io/about/. Nothing vague about that.
Your reply doesn’t really address my comment.
I know what the FSF says the freedoms are. Clarity is not the issue here.
But my conception of freedom applies to humans, not corporations, and I object to the FSF laying claim to the word “free”, in the same way you object to this new license laying claim to the word “fair”.
Both “Free Software” and “Fair Source” are clearly defining an antinomy. Free Software openly and proudly opposes itself to software-as-commerce, software with strings attached.
What, then, is the antinomy implied by “Fair Source”? What is “Unfair Source”? If you don’t like this question, then do not ask it!
If I remember Stallman’s explanations correctly, this criticism applies even more strongly to “free software”.
Reminder the Boost Software License has used the acronym BSL since at least 2003, but “Fair Source” promoters will refuse to respect that and will afford the acronym to HashiCorp’s unfree license. How’s that for fair?
I think this is less about malice and more about the fact that MariaDB refers to the BUSL as BSL, and so in my experience, the vast majority of people who see BSL think Business Source License, even if that’s incorrect. That’s why BUSL is listed first in the parenthesis — because it’s the correct abbreviation.
Regardless, I’m not sure why you’d even use this as a point to attack Fair Source. Seems like vitriol for the sake of vitriol and the world needs less of that.
Is your project so-called Fair Source or MariaDB? I think it’s fairly obvious why would I use the text on so-called Fair Source’s website to criticise it. It’s not vitriol for the sake of vitriol, it’s pointing out disrespect and the irony of it all. Maybe treat other code authors as fairly as you want to be treated.
I am disappointed that there is no music associated with this page. Also, it doesn’t seem to have an Age of Empires II keygen, so not sure what the point is.
Blame my shareholders. They only allocated resources for including the Frozen or Moana soundstacks right now, and I was unable to get the rights to those.
I’m glad to see this and welcome innovation in licensing that aligns interests between developers, customers, and users.
I love open-source and have done a lot of open-source work, but the incentives of a permissive license like MIT make it hard for the maintainer to support themselves.
Imagine two entrepreneurs competing and both have $100k. The first spends $100k hiring a developer to write MIT-licensed code and launches their product. The second forks code from the first and spends their $100k on marketing. The second will dominate the first because they have everything the first person had and didn’t have to pay anything for it.
I think licenses like FSL and FCL do a good job of balancing interests of developers, customers, and free users so that one can create a sustainable business with software that still allows users to extend and modify the code.
Good to see you here. Appreciate the kind words. Obviously a long road ahead, but like you said, I think Fair Source is a good balance. I’m excited to see other companies adopt it in the future.
Serious question: no matter what license you use, what is your strategy for preventing this? Do you have a big fund for lawsuits sitting around that you’ll be able to use to smack down anyone doing such a thing?
It works as a deterrence. Companies large enough to be worth suing will have a Legal Dept. that will tell them not to touch the code.
Licenses like this are targeted against Amazon making an “Elastic $YourProduct”. Amazon knows that building a product on a copyright violation is not a good strategy.
One irony is that the author of this, in a previous thread, tried to (as I understood it) approvingly cite Redis as an example of using licensing to crack down on “free riders” like Amazon, when Redis-the-company is not the original author of Redis-the-software and Amazon actually has paid at least one core developer of Redis-the-software.
Let’s not throw shade when I already owned up to that mistake, which you well know from that previous discussion. I had my history mixed up: https://openpath.chadwhitacre.com/2024/relicensing-and-rug-pulls/.
Regardless, there are a myriad of other examples that can be used outside of Redis.
Amazon might, but given how many other major tech companies are routinely violating open source and other software licenses I’m not sure.
A deterrence for sure for anyone willing to be nice and play ball, but sadly the people who really want to profit from stuff often don’t.
No. If my company shut down, I wouldn’t bother. But larger companies can’t function on promises, so they would still deem it a risk. This is the big pushback that I experienced when selling EE to enterprises under ELv2.
Sorry, I misread the original comment as relating to a company giving themselves EE features in CE in the event of my company shutting down (one of the main topics of the post). To answer your question about license violators — I don’t have a legal fund ready to hound violators. But I would enforce my copyright, especially if the violator is a business. This would be the same for a violator of an Open Source project’s license, too. There’s really no difference i.r.t. Open Source vs Fair Source here — a license violation is a license violation.
That’s true, and in practice we see that companies routinely violate open source licenses without any consequences, which I guess is where my question came from. When you say “I would enforce my copyright” do you have specific plans on accomplishing that without expensive lawsuits?
I’m not sure what you’re wanting me to convey here, so trying to choose my words. I will enforce my copyright. That may be a DMCA take down request, or a legal warning, or a lawsuit. It all depends on the effects that the violation has to my business, and on who the violator is. This is no different than e.g. an OSS company licensed under AGPL discovering a violator.
Website redesign & relaunch plus new products licensing themselves as “fair source.”
Replying to myself as I can’t edit this comment (now or maybe ever?). Didn’t see the OP when I submitted this morning otherwise I would have just added a comment.
2 years huh. Once people really start to keep the mirror and fix the differences via their own implementations (since diffs are available), this license will die.
What do you mean exactly by “this license will die”? Companies have been using other delayed-OOS licenses like BUSL for years and those licenses aren’t “dead.” Keygen is also actively being developed, so all OSS releases will be 2 years behind the canonical repo. (Unless the company shuts down, of course, but then that’s the entire point of the FCL and delayed-OSS.)
There’s a cost in both directions. As the ‘official’ upstream, it’s hard for you to take features from other forks because your code has evolved for two years since they made the change. This means that you’re not getting any of the benefit from external contributors, but if someone forks the project then they can.
This means that your improvements have to be more useful than everyone else’s contributions combined. This is generally easy in one of two situations:
First, if you’re a young project that’s evolving very quickly, you’re adding features and it takes external contributors a long time to learn the codebase and be as productive as you.
Second, if you’re a very big company, you can throw a lot of developers at the project.
I don’t think the second applies to you, but it could apply to a competitor. If, say, Google decided to put a 30-person team full time on the open source codebase and bring it to and beyond feature parity with your version, how does that affect you?
It’s not really clear to me from the web site what this project actually does (is it some kind of license server?), so I can’t really tell how easy it is to copy.
If a big company comes along and decides that what you have is useful, they will typically do one of two things:
The only projects that are immune to the second option are ones that are both big (and so very expensive to recreate) and actively developed (and so catching up is a moving target). If a project is big but not actively developed (or actively developed but slowly due to technical debt) then companies will invest in a narrowly scoped replacement for a subset of its functionality in their highest-value use cases, and then gradually widen the scope until the existing project is gone. If the project is not big, they will simply pay someone to write the permissively licensed version.
The first option may be desirable for you (I guess you wouldn’t say no if MS / Google / Whoever offered you a big pile of cash?) but it will happen only if it’s either cheaper than the second option or if they have time pressure to ship. That increases the risk to your existing customer: if EvilCorp offers you $100M tomorrow and then puts up the price of your commercial offering to everyone who is locked in so that they can recoup that money in the two years until the current version becomes open source, what would they do? For a company, a big part of the value of open source comes from the fact that you can get a second source immediately if not having one becomes too expensive. That’s not the case with a delayed open source license, and so there’s downwards pressure on both what you can charge for the product (you’re higher risk than something properly open) and the company (if it’s cheaper to reimplement, why buy the company?).
I think you’re vastly overestimating how much an individual or company wants to maintain a fork of a project. I’d imagine most Fair Source projects are also Single Source, accepting contributions if they happen to come in, but they don’t rely on them. The authors drive the project forward, and everybody is okay with that.
I just don’t see your hypothetical scenario playing out in the real world. We have years of projects undergoing DOSP to look at and it hasn’t happened to any of them.
I have personally worked with companies that have paid people to develop permissively licensed replacements of GPL’d or shared-source projects. It happens whenever there is a business need for something without vendor lock in that is greater than the cost of developing the replacement. I still don’t really understand what your project does, so I can’t tell how likely that is. It looks like it’s a license server and there are a bunch of open source ones already, so I guess you customers are there because it’s cheaper to use a supported product than roll their own. From the flows in your docs, I honestly don’t see the value. It looks like something that wraps a few basic cryptographic primitives in an RPC layer and then bolts on a tiny bit of ACL management. I don’t see how that would be more than a couple of thousand lines of Go, so I clearly don’t understand what it actually does and why people pay for it.
I have worked at smaller shops that have maintained forks of software just to get a feature they wanted that the maintainer rejected, or to extend bugfix support past upstream’s EOL, or to work around an inactive maintainer/abandoned project. People seem to really underestimate how willing companies – even smaller ones – are to fork and maintain a fork.
[I picked up on this elsewhere, crosslink.]
I don’t mean to be negative. But I’m thinking about possible infra around projects with these types of licenses. For example a public fork that is being merged every day (not per release! as you mention). Also a private CI that for example runs your
HEADFCL licensed tests on the public fork. Just thinking…To clarify, under the FSL/FCL/BUSL, a “version” doesn’t have to be an ‘official’ release e.g. cutting v2.1.4. It can be the software being “made available” via a Git commit, publishing a package, cutting a new GitHub release, sending via an email attachment, or mailing out a floppy disk via snail mail.
For example, you could clone a Git repository, run
git checkout $(git rev-list -n 1 --before='2 years ago' master)and, given theLICENSEfile is FSL/FCL (they have a 2-year change date), use that version under the Open Source terms of the change license.Actual content aside, I find the Corporate Memphis/Google-esque design of the page’s graphics to be pretty off-putting. I suppose the license is a kinda corporate by nature, but who is this style really meant to appeal to?
I immediately noticed the corporate art work. I think it speaks for the license before you read it.
I think this license is quite good and I understand where it’s coming from. There is a genuine fear for businesses when they release their source code that another cloud vendor will just undercut them and this license addresses this in a rather good way as users can still get most of the benefits that open source gives.
I do understand though why the website rubs people the wrong way. The name is fair source, at the same time the website faq about why a company should adopt the license is all about how it serves the company. Less support costs! Easier sales! It feels like it’s missing the spirit of the free software while trying to reap the benefits of its connotation. I would’ve liked to see the site talk about why users want open source and the societal benefits it has, and try to convince companies that way instead. Otherwise the license might just start carrying negative connotations to the user (“oh fair source? They’re just trying to take advantage of my free labor”).
My main plan for this sorta “problem”, has always been, depending on the number of customers / amount of net revenue, old releases will begin to be made available under some random license whatever. the more customers/revenue? the closer those releases will be to current version (up until a point, if the project owner desires)
Or in other words: You want more useful code? Give more money!
At least the license is a giant neon sign to developers saying “don’t contribute to me!”
If it is a trivial fix for something I use & helps myself + others, I would contribute so I wouldn’t be speaking for everyone. Getting to assess the source & pitch in if you want is better than proprietary in my book. The only thing that would grind my gears is a CLA that requires giving up personal, private data.
[Comment removed by moderator pushcx: Mocking adds nothing to the conversation.]