Changing the Ungit license from MIT to Faircode
github.com
github.com
"Faircode" seems like an attempt to have it both ways: squeezing money out of people without being labeled copyleft (because that's not cool in some circles).
There is nothing "fair" about making a company's revenue a criterion for deciding which license terms the company enjoys.
What if I make more than $1M but am willing to release all of my modifications? Does that make me less of a friend to the community than people who sell non-free versions, but have had less success with their business model?
I am trying to avoid the word "shakedown", but this strikes me as exactly that. From the Medium post announcing the license:
"Some people have asked my about the difference between this and donations. I think that for a project like Ungit small individual donations would never work; we’d have to convince thousands of people to part with small sums of money. We’re simply not big enough for that. With LYC the idea is to ask a few big players who benefit commercially from the project to part with bigger sums instead."
Source: https://medium.com/@fredriknoren/trying-a-new-open-source-mo...
I do think the terms of this new license are going to be confusing and make it difficult to figure out how to use it legally. As with most if not all "non-commercial use only" licenses (including CC-NC), of which I'd consider this a subset (non-commercial use or commercial use by companies with income under X). But non-commercial-use-only terms and copyleft 'share alike' terms are different things.
Copyleft licenses force people to release their modifications as source code, or pay the copyright owner for an exception (if the owner is open to providing the exception)
Non-Copyleft licenses say "do whatever you want, just give us credit."
"Faircode" says "Even if you release your source code, if you make enough money, you still have to pay us."
Only if you distribute the software.
So sure, it changes the definition of "distribute" as it is used in the GPL - but my understanding of the "why" is to to be explicit about what is really needed to guarantee users the four freedoms (run, study&fix, copy, share fixes).
This is proprietary commercial software with a 100% discount for hobbyist customers. It's very common in other industries, such as with fonts (this is almost identical to the model Blambot uses for some of their comic-book fonts). And there's nothing wrong with that.
Just don't be surprised when the community doesn't respond well when you take an open-license project, accept unpaid contributions from others, and later convert it to a non-open license to pay nobody other than yourself.
Normally, I couldn't care less what someone does with any software I release, so I'd normally prefer to just release code under an MIT or Apache license, but I've reached the point where I honestly no longer want to help the free software movement grow, so I'd like to release my future personal projects under a subtly non-free license. Faircode looks like a very nice option. I remember Tuomo Valkonen, the creator of Ion, moving to a license that would ban LTS distributions from distributing outdated versions of his software (basically, every time he released a new version, all distributions carrying it have 28 days to remove the old version from their archives and replace it with the new one, no matter how stable the distribution is intended to be).
Honestly, the older I get, the more my views on free software are converging with Valkonen's. Half of the reason for the license change was because he was tired of LTS distros carrying old development versions filled with bugs that have already been fixed in newer versions (he was getting flooded with bug reports for things that had already been fixed), but the other half was that he was aggravated by free-software zealots and wanted to make sure he wasn't doing anything that could be seen as contributing to their movement, and he swore that all future software he releases would be closed-source.
I do agree that I wouldn't want to call it "open source", though.
Wrong. "Non-copyleft licenses" are, well, anything that is not a copyleft license. It doesn't have to say "do whatever you want." A standard commercial license is one kind of license that is obviously _not_ a copyleft license.
I'm not really following what point you are trying to make.
Selling software is selling software. Do you consider any kind of selling software to be 'extorting money' (I think that could be a reasonable position honestly, I'm not going to dismiss it out of hand), or something special about the 'faircode' license that gives the software free to some entities but sells it to others that makes it 'extortion'?
Yes, the $90/month cost is going to hurt all the companies that have revenue greater than $1,000,000/year. This will put them out on the streets, I'm sure.
Let's be real: This does not apply to you, and on the off chance that it does, why are you complaining about paying $90 per month for something you should probably already be donating more to?
If your business depends on a tool/library and your revenue is in excess of $1,000,000, and you haven't yet donated to that project, you're just a leech. I guess we could both hope that your revenue falls below the limit so that you can escape these unfair shakedown licenses and continue not contributing in any way to the things you use.
Even a $1m/y company (which is not big at all) will be hard pressed to pay 1k/year for a git wrapper. The whole idea of OSS is that everyone benefits from the exchange and costs are distributed. This won’t scale at all - count your current open source dependencies and imagine paying that sum for each of them.
The sad reality is that costs are not distributed, most companies just grab whatever open source software they can and only contribute the least they can get away with, most of the times nothing at all.
Many projects survive just because of dedicated individual developers and maintainers spending their limited spare time, who end up being burned out.
In an ideal world open source software that brings significant value for companies should be considered as part of their stack, they should either hire or assign someone for supporting it, or pay the existing maintainers, and ideally this should be somewhat proportional to the value they get out of it.
Unfortunately donations as method of payment rarely work(usually end up being paid by individual employees from their own pocket), so the only option to get money from the company itself is to somehow get it charged.
They usually have no problem with being charged money, as long as the price is reasonable for the value it brings and less than would cost to write the same code in-house or to even have a meeting about acquiring it. It also should be significant, they wouldn't go through the bureaucratic procedures for a 10€ one off payment.
Developers don't expect to become rich out of this, they often would settle for less than their full time job, as long as they can work full time on the project they care about and still make a living. But because so few companies share the costs, they tend to be significant for those who do pay, so the prices will be higher at first but should decrease quickly as more companies share the burden.
A dual GPL-commercial license is the correct way to handle this. A more useful contribution to the license landscape would be to define a commercial sibling-license to the GPL that described how license payments would be disbursed.
I decided to go the GPL route, but am not currently accepting contributions. I've managed to successfully license the code under a companion license, which is doable since I'm the only copyright holder.
My thoughts are that there should be a contrib fork for major contributions that authors wish to maintain copyright over, but for minor contributions/bug fixes the author probably doesn't care and it would be better for everyone if the contribution was integrated into the core repository.
What if you die? What if you abandon the project? How can a fork of your project work with that if they want to change the license down the road? Copyright basically lasts forever now, so any choice about "assignment" will last forever.
Personally I really feel we need a solution that allows the current "maintainers" to have control over it. I don't really know what that would legally look like, but I've been hit by issues from open source copyright too many times to consider it a "solved problem".
Perhaps a new license "framework" that allows each contributor to say how they want to allow their contributions to be used in the future? I honestly don't know, but the current solutions are holding us back in some ways.
In any case this is worse if there are multiple contributors each owning their copyright, not simpler.
The easiest way to do this is under the umbrella of a foundation like ASF. But you could create an LLC or any other form of corporation with no income or assets other than the copyrights it holds, if you want. There would be at least some minimal annual registration costs etc.
Any framework that allows contributors to _individually_ set terms for their contributions is going to be pretty unworkable, as the actual terms for the whole product become the union of any term any contributor has ever set or something, a mess.
The real problem for me isn't major contributions, if these started coming in I may reevaluate my position. The problem is minor bug fixes where the complexities of acquiring another copyright holder outweigh the benefits of accepting the contribution.
As above, I don't have a good solution.
You can't relicense someone elses code. You dont have the right to do that.
If you fork this code, only your changes would be under MIT. So you would have a mixed-license project, and users would need to comply with both licenses.
If you don't want to use this license, you have to fork it from before the license change... giving up the changes that were made after the new license takes effect.
(As another commenter said,) sublicensing does not permit you to grant any rights under the new license that you yourself have not been granted under the original.
1) I think this is going to be a trend in the future, for two main reasons, one is that the cloud poses very challenging limits to individuals or small companies to monetize they OSS projects selling services, the second is that many OSS developers are starting to think that it's a bit unfair that incredibly successful companies sold for billions, mostly based on OSS frameworks, libraries, operating systems, don't support the projects they used to reach to such success. And no... releasing your own OSS project to the public, developed for internal interests, is not going to pay back the authors of the projects used to reach the success.
2) If you like this route, better to start ASAP with such a license, or at least start with some restrictive *GPL license and not BSD. Otherwise you are obviously susceptible to forking once you insert such a clause.
I run an open source project which is technical and is designed to integrate into other systems; it's ideal for fast growing companies and large organizations that have money; because of this, inbound leads for consulting, technical support, sponsorship, partnership and contract work trickle in on their own. So in my case, a very permissive MIT license makes sense even financially.
If you have a relatively simple product which is more like an external stand-alone tool (not designed to be integrated into proprietary systems at the API level), then it will be impossible to monetise it through consulting or sponsorship.
Also, other kinds of open source projects which are difficult to monetize are those which implement established and well understood industry standards.
Adhering to standards helps with adoption and greatly increases your project's chance of success but it's not creating any new markets; you're tapping into an existing user base and competing with other implementers in a race-to-the-bottom in terms of performance, efficiency and usability and it's hard to capture any value out of that.
> Permission is hereby granted (...) to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies ("Use") of the Software (...)
And then:
> If you are a commercial entity with a revenue in excess of $1,000,000 (...) you must acquire a commercial license grant (...) to Use this Software (...)
The problem is that according to the license, you can now pay $90 to "copy", "sell", and most importantly "sublicense" the software. Legally, does this work the way the Ungit maintainer intended?
Just the logistical overhead alone justifies a fork for any of the targeted users^wcustomers.
There is a base version with the MIT (or similar) license. Then there is a PRO version which adds some enterprise functionality + premium support.
But still a good thing that Ungit is trying this. There is value in experimentation!
It's likely the maintainer is in the best position to start a company about the product to deliver more features faster and at higher quality along with more inherent trust.
Natural moats are rare and highly sought after and fought for, and is actually much harder to build than a typical business based on product value.
It's extremely difficult for most enterprise customers to donate to FOSS projects. Small donations just aren't part of the normal corporate decision-making process. Very few people within an organisation have the authority to just give away money. Spending relatively small amounts of money on products and services is an utterly mundane part of doing business. If you maintain a FOSS project and don't offer an "enterprise license" of some description, you're leaving money on the table.
https://opensource.org/osd-annotated
Restricting commercial use isn't anything new or a bold new experiment or anything. It's the same lesson we apparently need to relearn from the 1980s.
Well, it's not "free today and $90/mo tomorrow", it's just that they're not going to maintain the one that's under the free license. You don't suddenly have to pay $90/mo for what was already distributed.
It's a fair attempt to make some money, but this license is odious and bizarre. I don't think there's a trend for this.
It is more of a risk for some open source projects than others. Look for example at React – I very much doubt Facebook will try to relicense it into a commercial product, simply because they are not in the business of selling software and probably don't want to get into that business. But, compare that to many small companies who have a product (such as a development tool or database or whatever) and they offer an open source version and a commercial version with extra features–there is a much bigger risk they might decide their open source offering is harming their commercial one, and therefore should be discontinued.
Similarly, an open source project run by a single individual or small community is more likely to be closed up than one run by a large community. On the other hand, a project run by a single individual is likely to be a smaller code base, and hence more feasible to fork or maintain in-house.
So, I think businesses should be aware of this risk, but should evaluate that risk for each open source dependency independently.
But I don't like it when people lie to me. The title is "Trying a new open source model" - the content is "Trying not to be open source any more". If you don't want to do open source then you can of course do that. But if you don't want to do open source any more and still say you're doing open source then you're lying.
(And before anyone answers: No, there's no "other open source" or "a different kind of open source". Open Source is a clearly defined term and such restricted licenses aren't.)
I'm on your side in principle but the distinction is important in this case.
No, I'm not. Please read the open source definition: https://opensource.org/osd-annotated
In practical terms there's very little difference between free software and open source. It's mostly a "philosophical" difference - free software advocates put an emphasis on "freedom", while open source advocates see it more as a business model. But the requirements for the licensing are identical.
Open source is by definition of the phrase, as well as in practical cases, a program whos source is available. Nothing more.
There are many prominent open source programs that also exist as a licensed product.
That's why I have always believed free software (FOSS) to be the other definition where the software cannot be licensed or sold for a profit.
Having worked at an org with $xxMM in revenue, we still wouldn’t have paid for it. We would have chosen to find a different tool. It’s a Git UI. Come on.
Good commentary from Grant Bakker in the discussion: https://github.com/FredrikNoren/ungit/issues/974#issuecommen...
Non-discriminatory terms is pretty much a fundamental precondition for any open-source license. As any lawyer would tell you--and don't forget, licenses are explicit legal contracts--licenses that include discrimination clauses of various kinds (including "fun" clauses like "don't use this for evil") are basically non-starters. It's especially problematic when the discrimination is based on something as malleable as yearly profit, so that someone's inclusion or exclusion on this basis changes every year.
Licenses are legal contracts, and therefore they have the force of law behind them. Rolling your own license is a stupid idea, particularly if you are not a lawyer and you are not retaining a lawyer to give you advice on the matter. Even aspects of major licenses like 3-clause BSD, MIT, GPL, LGPL, Apache, and others have indeterminate legal repercussions, particularly when patents and copyright of contributions come into play.
I like that they are honest about the cost of using the faircode service, right on the frontpage (5% on top of a 2.9% + 30c transaction fee).
I like that they thought about having tools integrated in the ecosystem to allow businesses to easily now what license the deps they're using are on, and how to easily pay for them.
I haven't looked too deep into it, but if it could handle a dual license model as well, then it'd be beyond awesome. I don't want to force companies (even >$1M companies) to pay if they contribute back any improvements they make.
[0]: https://faircode.io/
EDIT: Just tried to sign up, and I triggered an internal error :<
This is not an open source software license, so it's not an "open source model". It's not a Free software license either, as defined by the Free Software Definition. Instead, it's a proprietary license. It's not a new software license model, either; historically this has been called a "gated community license" or "open box license". Here's article from 2000 about gated community license models: http://archive.oreilly.com/pub/a/oreilly/tim/articles/gated.... They've never caught on, in over 20 years of trying, but perhaps this project's experience will be different.
We've had, for decades, a widely-accepted definition for what the term "open source software" means. If someone actually means "open source software" per that widely-accepted definition, then by all means, that person should use the term. Since this project don't actually mean "open source software", then they should not use the term - please call it something else. The world is confusing enough.
I agree with the maintainer that they should be compensated for their time. An open core model works but depending on a project who has the time to set that up? Patreon or Kickstarter has the same issue.
> If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking). You may grant further rights if you adopt a license. If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users.
In the end, this seems to me like pulling up the ladder after himself, and ultimately quite selfish.
Taking advantage of the community and not contributing back for others to benefit (as you have, for free) seems selfish to me.
Maybe if he proportionately (based on LOC or something) donated any income to his upstream dependencies?
...but I suspect that wouldn’t leave much.
Honestly, I do not believe that companies will pay to use open source software when they can just download it.
Developers will prefer to just download instead of waiting for the legal department and the budget approval.
On the other hand, if it was simpler to just download the code/executable and then pay later, without any hassles from the legal department it could be the standard way to use Open Source.
However, there is still the problem of what to sell.
A great idea could be to distribute the executable when it applies, thinking about golang, C/C++, any compiled language. For languages that are interpreter you could distribute the ruby gem, or the python egg or the JS packet.
Now if we combine this mechanism with some rate-limiting and price structure.
Stuff like:
* 10€ for one time download of the current version.
* 50€ for one time download of any version forever, when a new version comes out you can download it too.
* 10€/month for 30 downloads/months of the current version
* 50€/month for 30 downloads/months of any version
* 100€/month for unlimited downloads.
... and so on.
This could already provide several benefits, and be enough for several projects.
However we could also go a little forward.
We could provide an incentive to the buyers to buy the software and that incentives could be to do not distribute the building instruction or the dependencies list as open source.
Of course it will be possible to reverse-engineer the build instructions or the dependencies, however, it will be so time-consuming that any sane actor will prefer to just pay a little fee.
Finally, we could provide, under a restrictive license, the above-mentioned build instruction to whoever wants to contribute to the code base in a non-automatic way. Just send an email, ask for them, explain what you are going to do, promise to do not use them to by-pass the above restriction and you are ready to go.
In this way:
1. We maintain most of the code open.
2. There will be incentives to just pay for open source.
3. There will be a trade-off between new contributors and time/resource the current maintainer will be able to support the project. (I don't believe that somebody willing to dive into the complexity of an open source project to add features will be scared off by contacting the maintainer, explain to him what he wants to add, maybe wait his feedback, and finally get the build instructions. Honestly, I see mostly benefits in this project)
I would love to hear feedback about this idea.
So please share your thoughts and if you are interested in trying something like that feel free to contact me via email :)
I personally, just have to many more important things to do than worry about and waste time on compliance, laws, enforcement. It just seems like such a rediculous waste of time.
I just 2 clause BSD license my code and move on. Compensate me, don't compensate me, I'm busy writing other code, or designing systems, etc
Do people people posting replies here really spend this much time on licensing issues instead of producing?
It just seems so needless to me.