> Fair Source allows companies to both share a product’s source code and charge for that product. Releasing a product’s source code makes it more valuable to customers by enhancing extensibility and building trust. With open source, releasing the full source code and charging for the product is virtually impossible. Fair Source makes doing both possible.
That's an interesting license and the first I've seen of what I call open-source proprietary outside the dual-license model. I've been encouraging developments in this area given the problems of proprietary and OSS licenses in isolation. Additionally, people seem to have a false dichotomy where proprietary has to be closed/bad and OSS open/free/good. Wrote here, with security focus, that this wasn't the case:
Your license appears to meet many of those requirements. Curious about several things, though, that I figure you could give some straight, English answers to. ;)
How did you come to letting it depend on a user count rather than some other criteria? That's unusual and even reminds me of commercial licenses.
Does the license create a specific amount at that point or allow extortion where locked-in clients are hit with large amounts later?
Is the author able to terminate the project in a way where users are left with a dependency they no longer have access to?
I know you accept modifications under a CLA or something. Let's say, though, you didn't want to distribute some substantial changes. Basically, a fork is in order. How does that work? Do they just assign the whole fork to you where you can optionally offer it to others? Do they keep it onsite? Does it not happen at all? Prior discussions taught me forking is something that should have definitive answers in new OSS licenses.
The ability to make things disappear, get overpriced, or turn to shit arbitrarily are among the largest risks in proprietary OSS projects. So, interested in seeing your company's take on those.
When you go to the source link at https://src.sourcegraph.com/sourcegraph and look at the LICENSE file, it says: "Use Limitation: 15 users" That implies that the project there is the full Enterprise version?
Is there a separate link or some dividing line to the Core source? Or how does one build or access just the core features to abide by the licensing terms if you're a team larger than 15 and want to evaluate Core Sourcegraph?
After comparing the features of Core and Enterprise, it looks like the Core package is not self-hosted à la non-enterprise github. And the source at https://src.sourcegraph.com/sourcegraph seems to be the Enterprise version – minus 24/7 technical support and automatic backups I'd say.
Sourcegraph Enterprise includes the additional features mentioned in the pricing section on https://sourcegraph.com that are specific to very large companies.
Sorry about the confusion. Anything we can do to make that clearer?
Well if the intent is that Sourcegraph Core is "for teams of any size", and the code at https://src.sourcegraph.com/sourcegraph is the Core, then it seems like the LICENCE file in the source should be updated to reflect the intent and not say it's limited.
Sourcegraph CEO here. Thanks for the feedback. We are working on making this smoother/clearer, but the way it works is that the license refers to the posted pricing. The posted pricing on Sourcegraph.com says $0 for teams of any size for the non-enterprise features. When you exceed 15 users, there is also a license you'll receive that explicitly says that, but we wanted to keep it simple when you are just getting started (and not require people to click through a EULA).
Maybe change the README.md file at https://sourcegraph.com/github.com/sourcegraph/srclib Beyang, which says "Sourcegraph is licensed under the MIT License." ... I think you probably mean "The sourcegraph/srclib sub-directory is licensed under the MIT License." ;)
> If I modify the source code, can I redistribute my modified version under the MIT License?
Separate but related question about the Fair Source License: If I modify the source code, can I redistribute my modifications under the MIT License?
The difference being, of course, that one would redistribute the original code under the FSL and so the work as a whole would remain licensed under it.
Completely disagree. Services models seem to very much limit what companies like this can achieve. It also creates a perverse incentive for the company to make a product that needs service contracts to manage. They tend to produce more closed-source "addons" as well.
Exactly. Empirical research I saw showed that most companies in that market don't do so well in either profits or longevity. The majority of them we see here also intend to sell out.
All evidence is to the contrary. The companies making the most profit on software are licensing it somehow while others that are at least successful are using plenty venture capital with SaaS. So, both are the best choices and the use of a proprietary license preserving FOSS-style freedoms is interesting.
Strange how much negativity proprietary OSS gets on HN vs cool, proprietary, closed tech.
I retract my statement for any given commenter that was purely concerned with my misuse of the OSS phrase, which I'm fixing in future comments. However, there's often an overly-negative reaction to anything that involves payment and shared source w/ OSS-like benefits. If they were reacting to that, then it still stands if they don't do similar for cool, closed-source stuff here. Just seems hypocritical to me. That's where I was going with that comment.
> However, there's often an overly-negative reaction to anything that involves payment and shared source w/ OSS-like benefits.
I think you miss that the biggest and most important benefits of open source are tied to the freedom to fork, which is both the source of the greatest security against divergence in interest between the original copyright holder and the user community and the enabler of community-driven innovation.
Put simply, shared-source does not have "OSS-like benefits".
> If they were reacting to that, then it still stands if they don't do similar for cool, closed-source stuff here.
Unlike shared-source stuff like the Fair Source License here, simple closed-source proprietary software generally doesn't try to pretend to be Open Source-like (and, when it does, it is attacked in the same way.)
Gitlab graduated from Ycombinator and raised a 4MM series A round. While these are both tremendous accomplishments and important milestones for any startup, it may be a bit premature to declare their business model a success.
As I said in another comment, many of the companies pushing this model are VC-funded with intent to sell out and their operation disappears into a big company (or disappears). We should distinguish between business models that are just to get an acquisition and that support long-term growth. Cheap addons with OSS/FOSS seems mainly to work in the former.
I agree. I was responding to the parent comment suggesting Sourcegraph should adopt a similar business model to GitLab and I was pointing out that perhaps GitLab's business model has not been proven successful yet
It's made by them as well. It most certainly is not libre/free software. I'm guessing it has minimal legal ability to stand up in court. It is a bastardization of what open source is about... really it's more of a disclosed source setup.
"Insanity?" That's an ideological statement, but it doesn't really hold up to the facts, I think. It has always struck me that the gravamen of the Open Source movement has been to accelerate the improvement of important common libraries by enabling anyone to view and evolve source code, with the 'evolution' taking either the free or a commercial license. The simple fact is that, over the last few decades, there have been good and bad improvements under open licenses and good and bad improvements under commercial licenses. It's the possibility of improvement that is important.
I might go even further, and suggest that if one had to parcel the value created by open source software into two buckets, the one being value created by reason of transparent source code, and the other being value created by reason of no-cost source, the majority of the marginal value creation will have been because of the former, not the latter.
Open source is about the source being open plus certain benefits. Free and open source software, a la Richard Stallman, is a totally different thing with a philosophy akin to how a virus operates.
A glance at fair.io shows an interesting attempt to provide OSS under a proprietary model. Many businesses are fine with whatever gets the job done with main benefits of OSS being reviewing, extending, or just fixing things. A proprietary license allowing that has real value.
Curious, do you write comments like this whenever Google, Amazon, deep learning, etc closed-source tech with benefits are mentioned on HN? How they're insanity and not worth further discussion because the whole stack isn't FOSS?
Additional counterpoint: Even FAQ below their license explicitly states that it is not an Open Source license... So even its creators don't consider it to be one.
It would just be their opinion on the term. They are probably saying it because they know many potential users will have assumptions about what open source means. They wisely avoided going head-to-head with those assumptions to reduce number of negative reactions like seen here in other comments.
I contend that open-source has always been a mix of philosophies which originally included commercial variants. The reason those disappeared probably had a lot to due with the greed of the dominant companies in IT. More utilitarian owners or charters might have had different results. However, there's still companies doing proprietary w/ source code and dual-licensing of proprietary + OSS.
> Open source is about the source being open plus certain benefits. Free and open source software, a la Richard Stallman, is a totally different thing with a philosophy akin to how a virus operates.
This is all wrong. One: Stallman only advocates Free Software, not Open Source, and not "Free and open source". Open Source Software and Free Software are defined very similar in substance (by the OSI and FSF, respectively), what differs most substantially between the respective organization is the philosophy of why they think those definitions are desirable, not the substance of the definition. Virtually all licenses that have been considered by both the FSF and OSI have either been recognized as meeting both definitions, or have been found to be outside of both; there's almost no inconsistency.
"Free and open source software" is a collective term for the common category of software described by the FSF and OSI definitions, typically used by people who are not interested in (when using it) diverting things into a philosophical debate over preferred terminology between "Free Software" and "Open Source".
The license type sometimes described as "viral" espoused by the Stallman and the FSF is copyleft license, which is a kind of Free Software (and/or Open Source) license which has clauses to assure derivative works are licensed under a similar license; the GPL and AGPL are well-known copyleft licenses.
Any suggestion for what to call (a) software with source included in general that doesn't meet OSI & FSF definitions or (b) paid software w/ key benefits of OSI?
> Any suggestion for what to call (a) software with source included in general that doesn't meet OSI & FSF definitions
"Source disclosed" or "Shared source".
> paid software w/ key benefits of OSI?
Since Open Source (and, for that matter, Free -- which means libre, but not necessarily gratis) software can be paid, if paid software actually has the "key benefits" of Open Source, it is probably because it is Open Source.
"if paid software actually has the "key benefits" of Open Source, it is probably because it is Open Source."
You got me thinking on it enough to consult the opensource.org requirements. :) Two jumped out at me immediately:
" Free Redistribution"
"License Must Not Be Specific to a Product"
Many forms of paid software with open-source benefits don't allow this or not for all parties. A license might have to be paid on a per-user, per-product, or per-project basis. Other benefits of OSS can remain. So, it's not traditional definition of OSS but still respects freedoms of paying users to various degrees.
> Curious, do you write comments like this whenever...
Uh.. I actually often do. I would more, but it generally isn't appreciated and is off topic of the main thread. Here, the software license is a key component of the release seeing as it is a unique component of it.
>Open source is about the source being open plus certain benefits.
It's more than that. The key intent of OSS is the right to study, change, and distribute the software to anyone and for any purpose. The source code is just a prereq for that ability.
I did initially use stallman-esque language, since it's terminology most people are familiar with in this field, but I'll approach it from a different point since I personally have problems with strong copy-left licenses.
The primary thing this license doesn't do is allow distribution in the OSS spirit. This is really just a pervasive license, actually in some ways similar to the Stallman-esque virality except with a corporate intent. It simply masquerades as OSS.
"The key intent of OSS is the right to study, change, and distribute the software to anyone and for any purpose. The source code is just a prereq for that ability."
No, the key intent of open-sourcing software is to let one see the source. That's it. Additional intents are added with licensing terms. This goes back to academic and even proprietary (eg Burrough's 1960's MCP) examples that did this. Many models of it formed with examples ranging from permissive BSD to proprietary OSS like LISP machines (esp Genera) letting customers use the source of OS & supporting libs in applications.
So, OSS is a broader thing than you are describing which supports many models. There is no "spirit" so much as many different ideologies competing and pushing their own licensing schemes with various perceived benefits. Now there's one more.
I just cited history rather than ignored it. That included Burrough's and LISP machines as examples past my linked essay in this thread. However, your side is ignoring all historical examples of proprietary OSS and even how non-proprietary OSS operated then vs now. Old model of academia varied from MIT/BSD-style to paid w/ source model.
So, your rendering of open-source history is false both in academia and commercial sector. It's always been a mix with proprietary favoring closed source due to financial incentives, especially lock-in. Nothing precluded more paid OSS strategies aside from culture of organizations involved. As dual-licensed projects and proprietary w/ OSS benefits like this one show.
The phrase itself originally came from the free software movement. The practice pre-dated it. Former is philosophical meaning with strings attached, the latter is a literal definition with many forms. I'm using the latter.
I'd be up for considering a new term to avoid confusion. Paid, non-profit or for-profit, models allow for most benefits of OSS if structured correctly. So, the new phrase must allow for that. I've been calling it "proprietary OSS" or "paid OSS."
It replicates once it attaches to things. This is true even of distributing a large amount of non-free code while someone in organization unknowingly included a tiny amount of copyleft code. Now, FSF etc are usually more reasonable about enforcement and I doubt most would do more than ask it be removed if whole isn't GPL'd.
The image fits the behavior of the code, though. Hence the meme. More accurate description is like an agreement many parties participate in with copyright used to seal the deal for current and future distributions. So, control-freaks enforcing ideology on improvements to what they create rather than virus. ;)
> This is true even of distributing a large amount of non-free code while someone in organization unknowingly included a tiny amount of copyleft code.
If a single work is distributed that is based on copyleft code (not a mere aggregation that includes copyleft code and other code), then not licensing the resulting work as specified in the copyleft license is a violation of the license of the copyleft code. But the license doesn't attach on its own to the work.
Now, it's possible my memory is messing me up again or I bought into a false explanation of the legal issues.
To be clear, your saying that my worry was inaccurate and one person including GPL code into a new, released version of a proprietary app doesn't require the whole, linked source of that app be released under GPL? That happening is very virus-like but if it can't then it wouldn't be virus-like.
It's definitely not GNU OSS. If that's your ideology, this is not going to appeal to you. IANAL, but my understanding of the license is that it's trying to build a new economic model for OSS contributors. I'm pretty excited to see if it takes off, since I think OSS could use some new thinking in this area.
Okay explain to how forking would work with this license. Forking a project is a huge part of creating a OSS community. Would licensing have to go to both parties? I don't see any explanation of how it would work for this license.
Sourcegraph CEO here. Fair Source is not an open-source license. It is intended to be an improvement over closed source (GitHub, Bitbucket, etc.) and open core (where many important bits are closed source). Fair Source is not intended to support forking and independent redistribution.
AFAIK this is similar to how Microsoft licenses Windows: you get the product, and source is available on request (and an NDA [and perhaps only to select customers]). In this case the fee for source access is waived, and in place of an NDA is the spectre of patent and copyright lawsuits. But essentially the licence is similar, the pricing is different?
Makes me a bit sad in the wake of MS liberating a lot of stuff lately, like Visual Studio.
Of course not many other companies have the benefit of collecting an OS tax on hardware - I still think I'd prefer eg the AGPL to this.
This doesn't sound like an improvement to me. It actually takes (just another) SaaS product, and makes it feel like it intentionally does a disservice to it's users.
We released Sourcegraph under the Fair Source License (https://fair.io/), which we worked with a well-known open-source lawyer to draft.
TLDR is that it lets us create the best product for developers by having a sustainable business.
Full info at https://fair.io:
> Fair Source allows companies to both share a product’s source code and charge for that product. Releasing a product’s source code makes it more valuable to customers by enhancing extensibility and building trust. With open source, releasing the full source code and charging for the product is virtually impossible. Fair Source makes doing both possible.