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.<p>"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).<p>There is nothing "fair" about making a company's revenue a criterion for deciding which license terms the company enjoys.<p>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?<p>I am trying to avoid the word "shakedown", but this strikes me as exactly that. From the Medium post announcing the license:<p>"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."<p>Source: <a href="https://medium.com/@fredriknoren/trying-a-new-open-source-model-93a1a5a16a40" rel="nofollow">https://medium.com/@fredriknoren/trying-a-new-open-source-mo...</a>
Reinventing GPL with less care. I can copy the code, re-license as plain-MIT, and now commercial companies can use it for free.<p>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 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:<p>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.<p>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 truncated some of the text to highlight a possible issue with the change written by the Ungit maintainer:<p>> Permission is hereby granted (...) to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies ("Use") of the Software (...)<p>And then:<p>> 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 (...)<p>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!<p>Just the logistical overhead alone justifies a fork for any of the targeted users^wcustomers.
For open-source projects driven mainly by one contributor, I think the model employed by Sidekiq[1] is better than this one.<p>There is a base version with the MIT (or similar) license. Then there is a PRO version which adds some enterprise functionality + premium support.<p>But still a good thing that Ungit is trying this. There is value in experimentation!<p>[1] <a href="https://github.com/mperham/sidekiq" rel="nofollow">https://github.com/mperham/sidekiq</a>
This isn't open source: it discriminates against field of endeavours (point 6):<p><a href="https://opensource.org/osd-annotated" rel="nofollow">https://opensource.org/osd-annotated</a><p>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.
If this becomes a trend I'm afraid it will hurt business use of <i>all</i> 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?
Of course people can license their stuff in whatever weird way they want and I don't have to like it.<p>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.<p>(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.)
Speaking on his pricing, $90/month is more expensive by far than IntelliJ Ultimate/PHPStorm/RubyMine by far with a lot less value.<p>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.<p>Good commentary from Grant Bakker in the discussion: <a href="https://github.com/FredrikNoren/ungit/issues/974#issuecomment-341250490" rel="nofollow">https://github.com/FredrikNoren/ungit/issues/974#issuecommen...</a>
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.<p>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).<p>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.<p>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.<p>[0]: <a href="https://faircode.io/" rel="nofollow">https://faircode.io/</a>
The fundamental problem here isn't the relicense, the problem it's that it's being incorrectly called an "open source model".<p>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: <a href="http://archive.oreilly.com/pub/a/oreilly/tim/articles/gated.html" rel="nofollow">http://archive.oreilly.com/pub/a/oreilly/tim/articles/gated....</a> They've never caught on, in over 20 years of trying, but perhaps this project's experience will be different.<p>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.<p>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.
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.
While I can understand where he is coming from, his stuff is itself largely built on the free licensed software of others.<p>In the end, this seems to me like pulling up the ladder after himself, and ultimately quite selfish.
It is a while that I think about monetizing open source.<p>Honestly, I do not believe that companies will pay to use open source software when they can just download it.<p>Developers will prefer to just download instead of waiting for the legal department and the budget approval.<p>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.<p>However, there is still the problem of what to sell.<p>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.<p>Now if we combine this mechanism with some rate-limiting and price structure.<p>Stuff like:<p>* 10€ for one time download of the current version.<p>* 50€ for one time download of any version forever, when a new version comes out you can download it too.<p>* 10€/month for 30 downloads/months of the current version<p>* 50€/month for 30 downloads/months of any version<p>* 100€/month for unlimited downloads.<p>... and so on.<p>This could already provide several benefits, and be enough for several projects.<p>However we could also go a little forward.<p>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.<p>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.<p>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.<p>In this way:<p>1. We maintain most of the code open.<p>2. There will be incentives to just pay for open source.<p>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)<p>I would love to hear feedback about this idea.<p>So please share your thoughts and if you are interested in trying something like that feel free to contact me via email :)
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?<p>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.<p>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<p>Do people people posting replies here really spend this much time on licensing issues instead of producing?<p>It just seems so needless to me.