Maybe I am missing something. If you release something under a non-copyleft license, as long as I make proper attribution, what I do with it should not be your concern. If you do not want people making money from your software without paying you, use dual copyleft/proprietary licenses instead.
"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."
I don't see the relation. Copyleft licenses and what the faircode license are attempting to do are pretty different things. I don't see any relation between them, other than that they are both licensing terms. They are different licensing terms.
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.
I understand that "Faircode" is not trying to protect downstream users from non-free software. That's my point; It's not about principle, it's about extorting money while appearing to be principled.
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."
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.
I don't think there's anything "wrong" with nearly any license. If your project has been written without including other open-source components, feel free to license it under whichever license you choose. Closed-source commercial licensing is an option, and might be the best option if you're actually expecting to make a living from the code in question.
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.
While I generally disagree with distributing non-free software, at least those who do it usually do not call their software "Open Source". That's what makes "Faircode" so offensive.
To be honest, I am so thoroughly sick and tired of the zealotry in the FOSS community that I no longer have any desire to release software under a FOSS license.
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.
> Non-Copyleft licenses say "do whatever you want, just give us credit."
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'?
Sort of. I think it strengthens "the user is free to run the code", to implying that a user who has that freedom (to run the code) - has the same rights as someone who got a copy of the binary. To (be able to) ask a server to run code through an api, is seen as similar to run code on your own computer (a device, which might not in fact control either, hardware being what it is). It highlights the fact that the GPL is for users. If you use a webmail service, you should be able to fix issues with the code - just as if you ran a desktop mail user agent.
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).
> I am trying to avoid the word "shakedown", but this strikes me as exactly that.
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.
What if the company makes contributions to open-source through other projects - for which no one is paying them? Is it ‘fair’? Who is the leech?
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.
If they do have a problem paying $90 or even $1000 for a piece of software they really need, they are free to ask one of their developers to write one in house from scratch and see how much this sunken time would cost 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.
In the USA, software is licensed, not sold. The licensor is free to set whatever terms they wish on the license (within the bounds of the law and reason), violation of which revokes your right to use the software.
Reinventing GPL with less care. I can copy the code, re-license as plain-MIT, and now commercial companies can use it for free.
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 would like a companion contributors agreement to the GPL that provides the correct legalese to assign copyright back to the project owner.
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.
I personally feel that assigning copyright on commit is a stopgap.
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.
I feel it really depends on the type of project. In my case the code is rather niche and would only really be licensed by a small number of companies doing embedded robotics or AR. However, this type of stuff is also fun for hobbyists, so I wanted to make it available. I don't foresee a huge developer community springing up around this, and since I'm the only person who will realistically be making major contributions and I'm working on it more or less full time, I need a way to fund it.
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.
it's pretty straightforward, there just needs to be a legal entity (ie, a corporation) representing and controlled by 'the maintainers', to assign copyright to.
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.
Seems to me like the authors are trying to restrict the use of the software by commercial pursuits, not the distribution. The GPL does the latter, but says nothing about the former.
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.
You're right, but both the MIT and the non-commercial portion of this new license explicitly grant the right to sublicense. It's not obvious to me that a free use case can't sublicense its use to a huge organization.
sublicense != relicense. You can't remove restrictions. All of the terms of the license would remain. That organization would still need to pay the fee.
If it was possible to re-license something in a way that removed restrictions from the original license, then no license would be worth anything. You could do a relicense end-run around any terms you wished.
(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.
I think actually you can. If you rewrite 75%? 80%? You can relicense it. Legally I think the law views that as new code not a modification. A lawyer may need to correct me but I seem to recall something like this.
Most certainly not. I recall that, in the SCO vs. IBM case, they discussed copyright of individual code snippets, on the range of a dozen lines of code, that were part of a bigger codebase.
I do not want to judge the license change: everybody should be able to do whatever they want with the code for which there is ownership. Just two general observations:
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.
Yes I think it depends heavily on the type of open source project and it shouldn't be frowned upon for certain kinds of projects.
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.
I truncated some of the text to highlight a possible issue with the change written by the Ungit maintainer:
> 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?
Licenses like these are a logistical nightmare. If someone deploys software under that license, paying that person for the job is the smallest item on the bill: Now I have to connect my legal department with my techies and with the finance folks. Let's schedule meetings every 3 months to review for which software we have to pay now!
Just the logistical overhead alone justifies a fork for any of the targeted users^wcustomers.
Yeah, the thing to remember is that "cost" is not a smooth or continuous function of price. There's a very large jump discontinuity between $0 and $0.01. It's not an issue that comes up for most products, because for most products a price of $0 doesn't make sense. But software runs up against this regularly.
I've always wondered, in such cases where you have an open core and plan to monetize on extra features and plugins; what do you do if the community just goes ahead and adds those extra features? Or someone forks the project and adds the features?
The extra features are practically irrelevant. When you're spending other people's money, $995 a year for an "enterprise license" is pretty much a no-brainer, regardless of the actual benefits. It'd cost more than that for legal to check that a FOSS license isn't going to present any issues down the road. $995 a year is chump change, even if all it gets you is explicit permission to use the code in a commercial product.
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.
There are several Sidekiq features others have added but I never trust them. If I am an enterprise I value reliability over price. I would pay a premium for something the Sidekiq owner worked on rather than a random contributor
That's called business competition. Stay in business by delivering greater value.
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.
As someone being in a similar situation, it's a really difficult business model. Unlike many other business models with a natural moat (i.e. by virtue of having all the data, being deeply integrated into organisational processes, etc), commercialising open source is a struggle because simply justifying making money already requires constant improvement.
I've been telling people for ages now that the slow erosion of copyleft mindshare in favor of permissive licensing is going to bring about a return of the bad old days of proprietary software licensing. Now, maybe I'm wrong, but this move doesn't bode well.
If this becomes a trend I'm afraid it will hurt business use of all open source software, since companies will never know if their dependencies are going to suddenly start charging money. Even though you can use the old versions, getting stuck on outdated libraries is a big problem for a lot of projects, where you try to stay up-to-date. It feels like we are only recently at a point where managers and lawyers will permit building on open source software and not force you to use Microsoft and Oracle. But if every repo could be free today and $90/mo tomorrow, will that change?
> But if every repo could be free today and $90/mo tomorrow, will that change?
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.
> since companies will never know if their dependencies are going to suddenly start charging money
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.
Of course people can license their stuff in whatever weird way they want and I don't have to like it.
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.)
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.
This doesn't meet neither the free software nor Open Source license requirements. It might be open source in some colloquial sense, but that's not how the term is usually understood in the trade.
Speaking on his pricing, $90/month is more expensive by far than IntelliJ Ultimate/PHPStorm/RubyMine by far with a lot less value.
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.
This is not an "open source business model", as claimed by the Ungit maintainer, because the new license is not open source under the long standard definition maintained by OSI.
Do you have a proposed counterexample? The OSI definition is pretty much the same in spirit and in practice as, say, the DSFG or FSF definitions.
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 just learned about faircode[0] and I've got to say, I like the idea. I like that right on the frontpage, it shows that I have the choice to keep using the current license, and have it work like a Patreon, or use their own Faircode License (which seems what this story is about). It makes them look honest.
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.
Wow, that's awesome ! You have no idea how happy this makes me ! Thanks for your hard work, I'll definitely be using this and suggesting it to the people around me :D
EDIT: Just tried to sign up, and I triggered an internal error :<
Whoopsie, the error messages are still a bit rough but it looks like the recaptcha wasn't clicked? I've improved the errors on the frontend so should give you a nicer error message if it isn't now! Lmk if that doesn't fix the problem.
The fundamental problem here isn't the relicense, the problem it's that it's being incorrectly called an "open source model".
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.
Has the LYC license been tested in court ? I know GPL has.
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.
I don't think the opencore model works very well. The model that does work well is the Redhat/Fedora model of fast moving, and changing cutting edge of full features, with a premium being charged for the fully tested and integrated product.
He proposes no enforcement. Although I could imagine public shaming of those who are out of compliance. And who knows if others using LYC would want enforcement.
It is interesting and important to think about ways to support open source project contributors, especially when the projects are being used in commercial organizations. It would have been better to see this license change idea through an RFC before a change though, and with an attorney’s advice. If he does really want this to be an experiment it would have been good for him to have a better background on the types of license models available and an attorney’s help with license language changes and implications.
I'd add that 1M in revenue is barely enough to support 4-5 reasonably paid develops + some opex like aws and a small office in a big city. The license change would probably touch most of its commercial users.
I was curious about that myself for a similar situation a while back. Their terms of service do not require a free or open source license:
> 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.
Other contributors were using a very permissive license, that allows sublicensing. They were okay with a proprietary software company embedding their code into a proprietary product and selling it, they should be okay with this as well.
It is a while that I think about monetizing open source.
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 :)
The "You can't say it is open-source" bullshit is just the first in a long line of idiots lining up to comment on it.
Just because OSI don't have a USPTO registered trademark on "open source" doesn't mean that the OSD isn't the de-facto definition of what "open source" means. One may (may) legally be able to call their project with a crappy homegrown license "open source" but they shouldn't do so.
It isn't always just about what's legal, it's about what's right, and about community consensus. And the truth is, Ungit is not open source after this change.
There is a overall accepted agreement about "open source" and just because you're not able to understand it, doesnt mean that this consent about open source is not true.
This is a perfectly moral choice, assuming he has not taken significant contributions from others (or they have allowed this relicense, or granted copyright ownership of their contribution to him). Later in the Issue discussion, they attempt to put a name to the type of license. I propose "Freeware with source". Thoughts?
This thread and the culture of those replying to it fascinate me. Do you really enjoy spending this much time debating licenses, clauses, and legal matters?
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?
I would love to continue producing the rest of my life, without concern for licenses and business. Unfortunately I am running out of savings and will not be able to spend even 20% of my time producing. So I am in support of finding some way of getting a living wage for the software I lovingly produce for free.
Licensing is the difference between building on bedrock or quicksand. The profession has wasted millions of hours on rewrites of stuff that already existed but was entombed in failed projects.
"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...