Trying a new open source model (Ungit license change)
FredrikNoren opened this issue · comments
Hi everyone,
I just changed the Ungit license from MIT to LYC (edit: now called Faircode), which is a semi-commercial license. You can read about the change here: https://medium.com/@fredriknoren/trying-a-new-open-source-model-93a1a5a16a40, code change is here: cf582d4
Feel free to post comments / thoughts / concerns here. I'm running this experiment because I want to find a better model for anyone who works on open source, so happy to hear what people think! I'll leave this issue open for a few days.
Hi @FredrikNoren. For future reference, could you point out who has agreed to the license change? Not that this bothers me personally, but I suspect it could be a potential concern for others, especially since this change aims to introduce a financial aspect to the project.
I'd assume at least the top 6 contributors, who have all contributed more than 10 commits to the project, would be a reasonably conservative estimate for the group of people who have contributed non-trivially to the IP of the project, and would therefore need to consent to having their contributions relicensed (the pedantic estimate would be all 60 contributors, while even the most liberal estimate couldn't be less than you, @codingtwinky and @campersau, IMHO).
@waldyrious , IANAL, but MIT is a very permissive license that has very few restrictions in place. The contributions done under MIT will continue to be MIT licensed and the license change of Ungit to LYC is only effective from cf582d4 going forward. For those who don't like the change of the license, are able to fork the project and keep rolling the MIT badge.
Having said that, I do understand the personal motivations for the license change, but I dislike the trend in general - License Zero. There are various efforts going on monetizing personal projects but the permissive license of BSD/MIT is something that allows someone else (individual or business) to build something else out of the code or include code without limitations - LYC will not allow that going forward. Putting in place some arbitrary clause which is revenue based is in my mind silly and counter-intuitive because it is something that can make you unlicensed or at breach of license at some future point.
It seems like the term of Open Source is becoming a little vague. I can see parallel with Cloud9v3, which has the source in GitHub but the license allows you to only use it for personal or Plugin development purposes.
I think Facebook proved with the React.js and BSD+Don't-sue-me-with-patents-license how messy licenses can become if you add attributes to it, opting for the MIT in the end. 🎉
As LYC is not listed as an approved license by OSI, please don't call Ungit Open Source going forward.
@waldyrious I spoke to @codingtwinky and @campersau before making the change.
@exsilium The idea for the license was to make it as permissive as possible, while still opening up a revenue stream from big companies. It's supposed to enable an individual to clone Ungit, make changes to it (if they want), re-sell that or sell it as part of a product, and only if they make > $1M / year do they ever need to pay a license fee back. And even at that point it's a license fee of $90 / month. Do you read the license differently?
I had not heard of license zero before, looks interesting. I'll have to take a closer look at that.
When it comes to calling it open source: I'm not sure I agree with that webpage's definition, and as far as I can tell they weren't able to trademark it (https://opensource.org/pressreleases/certified-open-source.php). The source code of Ungit is still available for anyone to poke around with, modify, copy and do what they want with. The only change from MIT is that if you use it to power a business you need to contribute back.
Good comments so far! I'd love to hear more thoughts; this is very much an experiment in my mind. If people feel like it's a horrible idea we can always change it back. But my dream with this experiment is to enable a lot more people to live of off their open source work; I think that would be really cool.
@FredrikNoren , just to be clear. I'm not challenging your personal motivations for changing the license nor your dream to experiment. Although I can't deny the hope that you would change the license back at a future date, I still hope it brings you the solutions you are hoping for. 👍
OSI has been around for almost 20 years as a global non-profit organization for promoting Open Source Software, the very fact that you allow people to tinker with the Source doesn't make the application open source :) It is a philosophical question, Indeed - there are many people who also feel differently from OSI but still, I was making my point that you are defining your application as open source against the majority consensus of what is regarded as open source to begin with.
PS! Probably you need to fix this:
Line 94 in 2eda2a4
@exsilium Whoops! Thanks, I've fixed it now :) (package.json)
I have created ungit-extension for Brackets and VSCode. With the new license, I have a few questions:
- As the owners of those editors (Adobe and MS) certainly qualify for the restriction are they allowed to redistribute an extension containing the ungit code in their "extension stores"?
- In case of Adobe, I think they are also using the same source for a commercial version of the editor which supports the same extensions.
- The license specifies "using" ungit as requiring a commercial license, do I need to include a warning in my extension that large companies cannot use them without that license?
This license is making things rather confusing.
Additionally, I am not sure if it is semver-conform to change it in a patch-level release.
To publicize my point of view:
- I'm not a lawyer but I do think this complicates things
- I wish for little and infrequent license changes
- I'm not sure if this will help or hurt community because this is all new to me
- I just want to write codes to help people
@Hirse That's exactly the types of tough questions I was hoping we'd see with this! I'm going to do them in reverse order. However I really have to point out here that I'm not a lawyer and I'm just offering my interpretation.
-
I think there are three ways to view an extension as yours.
If we interpret it as a new product, which is using Ungit, then you can license your product under whatever license you choose (you can license it under MIT for instance). Both MIT and LYC requires a notice to be included, but that's all. This is how vscode includes notices: ttps://github.com/Microsoft/vscode/blob/master/ThirdPartyNotices.txt, you can probably do something similar; a text file somewhere and a link to it from your extension.
If we interpret it as a sublicense, it's also quite straightforward. Both MIT and LYC permits sublicensing, so you may choose whatever license you want (kind of the same thing). The same thing here applies; you just need to include the notice somewhere.
The third interpretation is that you're redistributing Ungit. In this case it would be the Ungit license which would be applicable (just like how we're being redistributed through npm). In this case I think you would just have to refer to the Ungit license.
To the best of my knowledge you can choose between these. The only restriction is the >1$M/year restriction, meaning that if you make more than that you need to pay the Ungit license fee to do any of this.
-
I think this depends on the above. But regardless of which one you choose, my best guess would be that the license would be between you (or us) and the end user, not with Adobe/MS (I'm not sure what their terms for using the extension store say but I would assume it says something like that). The situation is kind of the same with us and npm; we use it to distribute Ungit but the license agreement is directly between us and the person using it.
-
Under LYC it shouldn't matter if a company is using a project for a free product or paid product, the same restrictions apply.
All of the above are my interpretations and guesses, lmk if it makes sense.
@codingtwinky
- It does, and I'm sorry for that. I hope that the complication is worth it in the end though, if it can help other open source devs live of their work.
- Yup.
- I really hope it doesn't! But I feel that it's important a community can have a discussion about topics like these without it being a bad thing.
- Me too! :) And I want to help others be able to do that too.
Thanks for your interpretations.
I have this license section, would you think that is enough? Do you see any other changes I might have to make?
@Hirse Yeah, I don't think you need more than that.
Just so everyone's aware: I'm renaming License Your Code to Faircode (hence the link changes in the license file and updated badge in the readme). I made a new landing page that I hope explains the concept as well: https://faircode.io/
So it's the same thing but with a new name. Got it.
I still believe that if you want to monetize on Ungit (or any personal project for that matter), a better option from changing a license would be to register OpenCollective group and/or setup a Patreon account and let the community chip in whichever way they can.
As a fyi, for now, i've forked from ungit to mungit purely due to philosophical issues and all MIT compatible fixes are welcome!
@exsilium I'm actually experimenting with open source licensing options for Faircode as well: The idea is that you'd be able to keep your open source license but Faircode would help you charge companies who use the code (even if they legally aren't required to, it may be in their interest if they're using the code).
The reason I don't want to use Open Collective and Patreon is because I don't think they fundamentally scale well. They do work for big, well known projects, like vue.js, who's founder has a very successful Patreon campaign. But even he has said that he doesn't think it's the model that can work for most people (https://changelog.com/rfc/12).
With Faircode, the idea is that instead of convincing many people to pay small sums; you charge a few companies bigger sums. And I think that a model like that could enable a lot more people to live off of making code as independent open source developers. I think that's both in developers interest (less work to "market" your thing to a big community) and in companies interest (increase chances the software you're based on is stable and long lived).
Yes, Vue.js is an excellent example of success and if you view their webpage you'll notice that many of the Patreon sponsors are actually businesses - not sure how many of them cross the magic $1M revenue bridge, but still.
I don't really see how Faircode.io helps with the scaling issue but as it's a young platform and everything is an experiment it would be too early to judge. Allowing an open source licence without attributes would be a good direction as any custom license is something that potentially turns customers/backers away from the project. Good luck!
With Faircode, the idea is that instead of convincing many people to pay small sums; you charge a few companies bigger sums.
It's worth noting that this might actually not be desirable from the point of view of long-term sustainability and stability of projects supported in this manner. As Scott Santens (who has a successfully built a Patreon campaign) points out, community-supported projects actually benefit from having their income spread out over many people contributing small sums:
[My Patreon income] relies on about 150 people as I write this. [...] For anyone with a normal job, they can be fired by one person. As a result, their income can fall from $1,000/mo to $0/mo. For me, I would have to be "fired" by 150 people to fall from $1,000/mo to $0/mo. If "fired" by one person, I can fall from $1,000/mo to $990/mo. It is this decentralization of income that creates for me a greater sense of security that is far greater than a standard full-time job situation.
[This observation] prompted me to create a new milestone on Patreon, where my new goal is not to gain a larger income [...], but to instead create a more widely distributed income floor.
@waldyrious Yeah I think that's a great point. My long term plan to address that is to create something like "collectives" in Faircode, where multiple people can share income from their various projects. That way, the idea is, you can get more stability long term. I want it to be possible to even spend like a year or two building something, but with the security of a "collective". But this is just an idea at this point, I need to solve a lot of the basics to even get there first :)
.
I know developers that would like to use the software and may even contribute, but they're unlikely to be able to get their company to pay the license fee so they won't be using it. Given that @exsilium forked and MIT version, I expect that's what they will be using at work now.
@jpschewe It is mentioned in the changelog, version 1.1.32. This is all part of an experiment to see if it's possible to make a living as an open source developer by licensing the software to companies (well, opinions differ on what qualifies as open source, but whatever it would be under the Faircode License). And if peoples reactions is to simply fork the project and switch to that, than I'd definitely consider the experiment failed :) (That's probably what would happen to other open source devs too)
Kind of, it says "Show license notification on first start". It doesn't say that the license changed. I suppose as soon as someone upgrades and sees the new license they can uninstall.
OK, I see it there now, thank you. I retract my comment about it being a bait and switch.
I dislike this change and I am opposed to it entirely. I will not be using any future ungit versions released under this license.
Faircode is not a free software license nor is it an open source license.
@bakkerthehacker Can you elaborate on why you feel that way? I'd love to get everyone's opinion on this.
The core idea is to change open source licensing; from free for everyone to free for individuals and small businesses, but for profit for bigger companies
This change FUNDAMENTALLY excludes the licensed code from being open source, specifically because it 5. is discriminating against a group of persons and 7. does not follow distribution of license.
When it comes to calling it open source: I'm not sure I agree with that webpage's definition, and as far as I can tell they weren't able to trademark it (https://opensource.org/pressreleases/certified-open-source.php).
I can understand a few people not agreeing with or recognizing OSI as having any authority on what constitutes open source code and what does not. However, there is a very, VERY large and powerful body of people that have come to an agreement in regards to this matter, and have agreed upon such a governing body. Decisions made by OSI do influence legal proceedings throughout the world.
The source code of Ungit is still available for anyone to poke around with, modify, copy and do what they want with. The only change from MIT is that if you use it to power a business you need to contribute back.
This statement is just false. Ungit is NOT available for anyone to do these things, only groups which the license deems acceptable. Part of this group acceptance is revenue numbers, and part of it is a commercial license grant. This is discrimination, whether you think it is or not.
We will not be enforcing this in any way
This is not how licenses work. You cannot choose to not enforce licenses. Companies cannot choose to ignore licenses.
For companies, my hope is that it will be an easy way to pay for the open source that runs their business; a single combined invoice for all open source code they use each month.
This is, by far, one of the least easy ways for a company to contribute money. Changing the license ADDS a TON of additional work that must be done before you see any money. Talking to legal teams, auditing the actual text of the license, managing the commercial license grant, expense reporting. These are just a few of the things I can think of that would make this licensing sytem completely non-viable or just not worth the effort. What happens if https://faircode.io/ goes down? What happens if you decide (for whatever reason) to not grant the commercial license? What if critical infrastructure depends on this?
Adding a donate button would be much easier, both from a large-company-standpoint and a developer-who-wants-to-buy-another-developer-a-beer standpoint. Ungit has been insanely useful, both for work and for hobby projects. If you had a donate button on the ungit page, I would definitely have already used it. And I probably could have gotten my employer to match the donation.
On top of all of this, there is a very large problem in general with editing licenses and adding additional clauses to them. The two biggest examples I can think of are the patent clause in the react license and the "not Evil" clause in the JSMin/JSLint license. These additional clauses sneak under many peoples radar as the license looks very similar to their non-edited counterparts. As silly and unenforceable as "The Software shall be used for Good, not Evil" seems, it can easily prevent large organizations from using the code. These seem to be the same organizations that you are expecting to receive money from. I can't really see any organization that the $1M revenue clause applies to actually going forward with using this code.
These are the reasons I am opposed to the Faircode license.
@bakkerthehacker Thanks for a very well articulated response!
I'm not sure I agree with the terminology of discrimination. Many companies give away a free version of their product and no one would call that "discrimination". For instance Unity is free for individuals and small businesses. I understand that in this case OSI has a slightly different meaning in mind than what people would think in general. They mean discrimination as in "you have to offer the same thing to everyone" not as in "you can't discriminate against particular groups of people". The difference is subtle but I think it's a bit misleading, the first meaning is nothing I have a problem with (for instance I think charging companies money for something and giving it away for free to individuals can be a good thing) whereas the other meaning I strongly reject.
When it comes to the complications for companies with a license vs. donations; the idea is that a company only have to do this once, and that for any subsequent Faircode Licensed software they wish to use it's a simple press of a button. This, my hope is, would make it easier for other open source projects to also charge for their software, and thus sustain themselves. I appreciate it complicates things when only looking at a single pieces of software though (and I'm sorry for that!).
Anyway, many good points! Like I said Faircode is still an experiment. I wanted to try this over donations because I was hoping to find a solution that would scale to other people too (and I've heard from many OSS developers who struggle to make money of off donations, even though they're building something awesome that is worth a ton to companies).
Many companies give away a free version of their product and no one would call that "discrimination".
Yes, and exactly this is one of the fundamental differences between a Proprietary software that in certain scenarios costs 0 money to use vs Free (as in Freedom (FSF)) or Open Source software.
I'm not sure I agree with the terminology of discrimination.
I am going to ignore literally everything you say after this statement. Let us come to an agreement about what this this term "discrimination" and all its other English forms mean. Let me quote the merriam-webster dictionary, wikipedia and the urban dictionary at the same time circa 2017 to ensure i am covering my bases here (potentially including any relevant and offensive definitions that may appear in these texts). I will omit similar and related definitions, such as Discriminate.
The merriam-webster definition:
Definition of discrimination
1 a :the act of making or perceiving a difference :the act of discriminating
a bloodhound's scent discrimination
b psychology :the process by which two stimuli differing in some aspect are responded to differently
2 :the quality or power of finely distinguishing
the film viewed by those with discrimination
3 a :the act, practice, or an instance of discriminating categorically rather than individually
b :prejudiced or prejudicial outlook, action, or treatment
racial discrimination
The wikipedia definition:
In human social affairs, discrimination is treatment or consideration of, or making a distinction in favor of or against, a person based on the group, class, or category to which the person is perceived to belong rather than on individual attributes. This includes treatment of an individual or group, based on their actual or perceived membership in a certain group or social category, "in a way that is worse than the way people are usually treated".[1] It involves the group's initial reaction or interaction going on to influence the individual's actual behavior towards the group leader or the group, restricting members of one group from opportunities or privileges that are available to another group, leading to the exclusion of the individual or entities based on logical or irrational decision making.[2]
Discriminatory traditions, policies, ideas, practices and laws exist in many countries and institutions in every part of the world, including in territories where discrimination is generally looked down upon. In some places, controversial attempts such as quotas have been used to benefit those who are believed to be current or past victims of discrimination—but they have sometimes been called reverse discrimination. In the US, a government policy known as affirmative action was instituted to encourage employers and universities to seek out and accept groups such as African Americans and women, who have been subject to discrimination for a long time.[3]
The urban dictionary top definition:
Etymological definition: To note or perceive differences between things. (Strictly speaking "discrimination" makes no mention of race, gender, nor disability; nor does it make mention of placing one thing at a disadvantage to another.)
White Unicorn definition: Any policy that treats people equally regardless of race, gender, or disability.
Real world definition: Any policy that doesn't place white males at an extreme unfair disadvantage.
Equivalently, any policy that doesn't specifically mention race and gender in the context of "protected minorities receive X benefits", where X is greater than those received by white males.
In the real world, any policy based strictly on academic merit, financial status, or any other non-race based trait, even those claimed by tolerance experts to not be correlated to race, is discriminatory unless it specifically allots a handicap to women and non-whites.
Dictionary nerds: The act of selecting toothpaste based on each item's price and advertised benefits is an example of discrimination.
What the media wants you to think: A bunch of people of all races and genders holding hands around a 1000 year old tree is the ideal discrimination-free environment.
What's really happening: Michigan placed a ban on using race and gender as a factor in college admissions. While this seems like the ultimate move in preventing discrimination, as it would be impossible to discriminate based on race or gender if these factors were absent in a college application, the measure was struck down by a federal court.
They claimed the policy harms minorities and is unconstitutional; as it would then also be impossible to give PREFERENTIAL treatment to minorities as well.
The more you know
#distinction#discernment#distinguishing#oldspeak#ungoodfullness
Are there any definitions of "discrimination" listed here that you agree with, @FredrikNoren ? Are commercial entities with a revenue in excess of $1,000,000 of the previous fiscal year, and/or organizations with a budget in excess of $1,000,000 subject to this discrimination? Are persons in these or other groups subject to discrimination?
@bakkerthehacker I agree that we must make our definitions clear for the discussion to have a common ground and be productive, but come on -- let's not pretend that what @FredrikNoren means is utterly inscrutable. I hope we can all agree that what he's talking about is discrimination with conscious intent to unfairly disadvantage a group of people, which is a point of view even the sources you quote clearly recognize (emphasis mine):
In some places, controversial attempts such as quotas have been used to benefit those who are believed to be current or past victims of discrimination—but they have sometimes been called reverse discrimination.
(here admitting implicitly that it's common --although certainly not universally agreed upon-- for discrimination to be perceived generally as having a moral direction --a negative one-- thus justifying the notion of a "reverse".)
Etymological definition: To note or perceive differences between things. (Strictly speaking "discrimination" makes no mention of race, gender, nor disability; nor does it make mention of placing one thing at a disadvantage to another.)
(again, here the need for the caveat representing an admission that that perception is common.)
So can we start from there, and debate the parts we actually disagree on (e.g. whether systems of reverse discrimination are acceptable or not, in particular in the context of software licenses and the open source movement)? There's no need to discuss the basic definition of words when the real disagreement never truly lied at such a low level anyway.
Honestly, I think if @FredrikNoren would have announced that Ungit is going commercial with source-available proprietary model with different price tiers, we wouldn't have this (long) discussion :)
In FOSS licensing world, the word "discrimination" is used simply by favoring someone differently and here I agree that the LYC/Faircode attributes to the license becomes discriminating against a certain group. The license change of ungit is presented as "Trying a new open source model" - and here I think that the author doesn't really have full understanding what Open Source is. OSI is not working in isolation when coming up with definitions and standards and FSF is even harsher in defining and protecting the rights than OSI. If anything, OSI has been criticized in the past of accepting attributed licenses to it's list which in view of FSF limits freedom. But I digress...
In my view, the majority consensus is presented and articulated by organizations setup to protect the foundations of open source and free software (OSI and FSF). I don't think it's fair (and right) to add attributes to a license text and still present it as an Open Source project/model - because by definition it's not and it creates confusion!
The Open Source Initiative's (OSI) definition is recognized by governments internationally as the standard or de facto definition. In addition, many of the world's largest open source software projects and contributors, including Debian, Drupal Association, FreeBSD Foundation, Linux Foundation, Mozilla Foundation, Wikimedia Foundation, Wordpress Foundation have committed to upholding the OSI's mission and Open Source Definition through the OSI Affiliate Agreement.
@exsilium I think you have a really good point. Maybe I misstepped in calling it an Open Source (capitalized) model, not realizing how much meaning and interpretation people would attribute to that. I think that "commercial with source-available proprietary model with different price tiers" is a little long, but maybe we can come up with a shorter name for the model that would sound better ;)
@FredrikNoren I thought you had written your thoughts on this, but can't locate the exact passages, so perhaps it was just my impression: did you deliberately choose not to go with a dual-licensing setup? That's already a common approach in the FOSS world, e.g. Qt, so most FOSS consumers already know how to handle it.
Of course, this would only work in practice if the Ungit was released under a commercial license combined with a protective Open Source license like the LGPL. (The latter is needed for this arrangement since the permissive MIT license allows unrestricted commercial uses.)
While I don't advocate this approach myself, I believe people might find it more acceptable than creating a new license.
@waldyrious That's very interesting, I had not considered dual-licensing. I'll have to think about that option a little bit.
@bakkerthehacker I agree that we must make our definitions clear for the discussion to have a common ground and be productive, but come on -- let's not pretend that what @FredrikNoren means is utterly inscrutable. I hope we can all agree that what he's talking about is discrimination with conscious intent to unfairly disadvantage a group of people, which is a point of view even the sources you quote clearly recognize (emphasis mine):
I would like to make these assumptions, but @FredrikNoren 's directly questioning the word and complete lack of reply in this matter have not made any indication we have come to an agreement about whether Faircode license is discriminating.
The use of Randall Munroe's xkcd 1597 under the Faircode License violates the CC BY-NC 2.5 license it was released under.
The Faircode utilities for node and rust are also just completely missing any actual license text although they claim in their config files to be MIT.
The poor way in which this whole situation appears to me is just becoming more and more apparent as I look into it.
@codingtwinky I appreciate the code change you submitted in #984 to fix my issue but I cannot use it.
Good luck, I've been thinking of working as a full time open source developer and will be following this closely, Thank you
It's important to note that you're not actually allowed to do what you've done here.
The code or contributions by others to your project are still owned by the people who made them. You can not change which license their contributions are under unless you get a license to their copyrights, or unless they sign off on a project-wide relicensing.
Every one of them. Luckily you've used git, so you can find those people. It was much harder for Mozilla and other older projects when they did these things.
And even then, after you've got public permission from all of them to relicense your codebase, you still can't retroactively relicense older releases. You can of course remove those releases from github (and any other distribution method you control), but if I for example have an old ZIP file of an older release, I am still entitled to use it under the licensing regime it was under at the time.
I'm not a lawyer, but I have been involved in two major relicensing efforts.
And I'm not saying these things to discourage you or just to be negative; I'm saying it because a big company knows the above.
Also, as a postscript, it's worth noting that since most of your source files lack a licensing header, that significantly limits your actual legal avenues for enforcement of your licensing terms - depending on which country the offender is in.
I applaud your intentions, and I have a question about wording. Specifically...
Ungit is free for individuals and small businesses.
What about charities? Or non-profits? Or Governments? Or community hack-spaces?
(Disclaimer - I work with all those sorts of organisations.)
At the moment, I think it is ambiguously worded.
The above argument that charging money is discrimination and therefore it’s not an open source license is invalid. The OSI itself publishes a license that flat outright denies all profits, not just $1mil+ profits:
https://opensource.org/licenses/NPOSL-3.0
In that respect, your license is actually less discriminatory than theirs, as it permits revenue under a threshold. Best of luck!
The above argument that charging money is discrimination
That's not the argument. The argument is that charging money for use of the software only to a certain group of users, constitutes a discrimination (in the technical sense outlined in Merriam Webster's definition, 1a, quoted above) incompatible with point 5 of the Open Source definition, which explicitly states that for a license to be Open Source, it "must not discriminate against any person or group of persons.".
@floatingatoll, NPOSL is an Open Source license - It's the licensor, not the licensee, that needs to be a non-profit.
Surprised that no one has mentioned licensing under the GPL and then having companies pay for licenses that are not GPL. Dual-licensing is a valid model that works and doesn't put strange restrictions like this.
I'm happy that someone did note that copyright reassignment is probably needed.
Keep in mind that this is not a free software license as it doesn't provide required freedoms to the big businesses. Additionally, due to the weird way this license was written, it's ambiguous whether categories other than so called "individuals and small businesses" (say, non-profits) are allowed to use this software. It's also not clear if you can use this software if you work for a big business. tl;dr - This license is legally problematic, especially when building software that uses it internally (perhaps plug-ins to text editors).
Please seriously consider following alternatives so that the software stays free:
-
Relicense under GPLv3+ with an option of proprietary relicensing. GPLv3+ is a free software license which gives freedoms to use, modify, redistribute provided that the code will stay free.
-
Dual-license, as above. A badly written license is hardly an issue when you can use GPLv3+ instead, which is a well written license.
-
Use a well recognized software license, but put a statement on download page that you are only allowed to download this software from official download location if you aren't representing a business with a revenue of at least $1M / year.
It's fine for free software vendor to not provide software to everybody (and there are cases of that, for instance due to cryptography export laws), provided that license allows redistribution to everybody without discrimination. Free software is not about cost but freedom, free software definitely can cost $1000 ($500 for students, $20000 for Microsoft because author of software hates Microsoft) and still be free software as long as it allows free redistribution to anyone. Note that this is easy to workaround by getting the software from another source, so you may want to use one of above options.
Sorry if the question was asked before. Won't read the whole thread.
How did you handle that you have 60+ contributors with a license change? I've never seen a case where all contributors could be reached and agreed upon with on the new license. And usually you need written approval of each one of them to change even a comma.
If this came up before and you find it annoying to answer again, please add the answer to the first post (and please still ping me).
@floatingatoll I even said that I haven't read the whole thread and argued why. Now you only add spam. You haven't even added a link, lol. Next time just do a thumbs down and be done with it.
As for NPOSL... well, actually OSL designed for non-profits (and easily changeable into OSL if needed), this license is not compatible with GPL, which is a good reason to avoid it.
(I do admit that ideally I would prefer only those free software licenses to exist: GPL3+, LGPL3+, MIT/X11, 2-clause BSD and Apache 2, the more different licenses there are (especially the worst kind of those, slight modifications of already existing licenses by people who don't have any idea of how law works like adding non-free "The Software shall be used for Good, not Evil"), the harder it is to analyze the compatibility of various licenses)
Just asking, but since MIT license allows sublicensing, couldn't relicensing (as long as at least a change between the last MIT-licensed version and the first whatever-non-MIT-licensed version gets introduced) be just considered (legally speaking) as an edge case of sublicensing, hence requiring absolutely no formalities? That is, the original, MIT licensed program could be considered "included" into a "new", whatever-licensed program.
(I am not arguing in favor of this specific relicensing of a free software under a non-free licence, I'm just trying to get a better understanding of the legal implications. Don't thumbwar me please :)
It's important to note that you're not actually allowed to do what you've done here. The code or contributions by others to your project are still owned by the people who made them. You can not change which license their contributions are under unless you get a license to their copyrights, or unless they sign off on a project-wide relicensing.
@folknor, no, he's actually allowed to do that.
Ungit was using the MIT license, which is a very permissive license and allows sublicensing. Contributors therefore have already allowed the relicense by releasing their contributions under the MIT license. In fact, since contributors 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.
(This is not to mean that I think this is a good idea; I think it's reinventing GPL dual licensing badly. But the important point is that also a relicensing to GPL+proprietary doesn't require buy in from past contributors, even though it may require a CLA from future contributors).
Dual-licensing seems to be a much saner option, especially if it comes with some form of support plan. Something else to take into account: $1m revenue is really not that much; a small company with a handful of clients can reach that pretty quickly. Nevermind the practicality of how/when to calculate it.
Projects today will easily use dozens to hundreds of open-source tools, if all of them ask for $90/month, they could end up paying 10-20% of their revenue to "open-source" software. Besides sustainability, I believe this 'open until it's not' software model goes against the core ideas of open-source, and is essentially the same as a commercial license + 'free for educational purposes'.
The current license does not require a CLA from future contributors, since it's wholly derived from MIT and the added clause does not interfere with its described permissiveness. What benefits would switching to GPL+proprietary provide other than GPL compatibility, which is itself not necessarily a benefit?
Just in case someone's wondering why the sudden influx of comments (starting here): This thread has been shared on Hacker News.
Several folks seem to have the misguided assumption that "Free Software" == "Open Source Software". That is completely incorrect and here is a good explanation of why:
https://www.gnu.org/philosophy/open-source-misses-the-point.en.html
I am not saying that this license change meets the definition of "Open Source" (because it doesn't per OSD bullet 6), but there is a fair bit of commentary that seems to be convoluting free software and open software as the same.
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. They've never caught on, in over 20 years of trying, but perhaps your experience will be different.
We've had, for decades, a widely-accepted definition for what the term "open source software" means. If you actually mean "open source software" per that widely-accepted definition, then by all means, use that term. Since you don't actually mean "open source software", then don't use that term - please call it something else. The world is confusing enough.
@FredrikNoren, I personally side with keeping the project purely "open source" (there has been some discussion on what that means, but you get what I'm saying) because of most of the reasons said earlier in this thread.
I would however like to mention how much I appreciate your being cordial despite many who disagree with you and not getting defensive. That means a lot in today's internet, so I just though I would mention that. Well done.
Thank you all for some great comments! I'm digesting the comments here and on hacker news right now, and we'll see what the next steps are :)
In the meantime, if people have links to dual-licensing examples they felt were good examples of how to both be open source and charge companies, I'd love to see them! (Or other examples of licensing that solves this problem).
A question for the licensing experts: would there by any restrictions on the commercial license when dual licensing? Or could it be anything and the project would still be considered Open Source as long as one of the licenses are Open Source?
(Edit: Uhm, "licensing experts" sounded ironic but I meant people who have read a lot / know a lot about this)
@FredrikNoren as long as your project is released under at least an open source license, it will be considered an open source project. Most commercial/OSS dual-licensed software use a relatively restrictive license (GPL or AGPL) in conjunction with their commercial licenses. This means every user can either accept the terms of the GPL/AGPL/whatever OS license (including viral effects), or buy a commercial license which doesn't include such effects.
Edit: IANAL, of course :)
@thblt Thanks!
Another question: What would it actually mean for an application like Ungit to be GPLv3 licensed? If I understand things right, the dual licensing model relies on copyleft being something companies want to avoid (to not have to release their code to the public), but I can't see how that would work with an application like Ungit, which isn't part of any companies application, just used to produce them?
@FredrikNoren Legally, that won't have much effect, I'm afraid. (It is possible that some companies may prefer to pay than run GPLed software, but I have absolutely no idea if this actually happens). The model I described seems to work well for libraries, but I'm not sure it would apply to application software. I've seen a few companies releasing such software under [A|L]GPL while advertising it as commercial and selling it, but I have no idea if this worked at all. Macromates seem to have tried this with TextMate 2, but the project appears to have died before it reached stable (latest blog post is from 2014). Maybe you could ask the author(s) what their inspiration in doing so were, and what feedback they've received.
Again, please take all this with a grain of salt. I think I know the GPL licenses and their effects reasonably well (still not a lawyer, though) but my experience with the ways companies actually determine whether to use a given piece of software and whether they should buy commercial licenses for free/commercial dual-licensed software is nonexistent :)
@FredrikNoren you may want to look at the android app store as an example; there are lots of apps that are free/open source, users are basically paying for an already-built binary.
The barrier for users is that they don't want to download the source code and build it themselves.
In ungit's case, you need to set up a barrier to divert developers/companies who can pay to actually pay.
Your competitors are charging the following prices:
- SmartGit - $99
- Tower - $79
- Aurees - $8/year, $25/year, $100, free (ad-supported)
- GitAhead - $49
So it is possible to charge money for a git client. You may want to just try setting up a landing page for your product with a typical sales flow (landing page -> buy button -> checkout -> success) and see what happens.
Be direct and tell developers who download your software that they can support its development by redirecting a company to the sales page. Don't be afraid to add an advertisement for this option within the software to remind developers that someone has to pay for support. That one advertisement to pay/donate could be removed by paying the license fee! The software would still be MIT or GPL or whatever free/open source license you want, but you're layering on a payment system and funneling people who want to pay into the right area.
@thblt @omouse Thanks, really interesting!
A small note on the other git clients pricing; as far as I can tell those are per user (except Aurees which gives you two license per purchase), compared to Ungit which is per company. That said, I do think the current pricing model for Ungit/Faircode is a bit too inflexible; for small companies (with maybe just one user) it's really expensive and for big companies it's (potentially) really cheap.
@bakkerthehacker Thanks for pointing out the xkcd license violation, I've fixed it now.
Hi, as far as I read from license - Acquiring a commercial license grant affords you no additional rights, guarantees, support or services. . Why large companies will buy this license? What will motivate them to do so if it is no support, no services, no additional benefits?
@Fatalityap Good points! I think that's one of the reasons dual-licensing idea is promoted where the commercial license would potentially grant additional benefits to the licensee (Support, priority issue handling etc.)
I agree that there are no motivators in place today. As it currently is, the license is messy and the most likely scenario is to freeze at a previous version of Ungit or to move away from the product entirely :(
@Fatalityap @exsilium The only way for anyone at a company with a revenue over $1M to (legally) use Ungit (or anything licensed under Faircode) is by purchasing a license subscription. Like any other product or service; if a company finds value in it they can choose to use it, but must pay to do so. It's not about adding benefits; it's about simply charging for the value that is already provided.
Again, Ungit is a test for this. My motivation is Open Source developers I've seen around the internet who want to make a living from their projects, but are failing to do so even though the projects themselves are awesome and easily worth money. Donations can solve this problem for some of them, but donations require good marketing skills (you have to get a large group of people to believe in you and your product and want to support it). But charging for software, in my mind, requires only writing good software that someone wants to use (you probably still have to market the software itself somehow if you want people to use it, but you don't then need to also convince them about sponsoring your project. If they use it, and are in the category of companies mention, then they simple would be legally required to also pay for using it).
Will companies pay for software? I don't know. I think it would be awesome if we could prove they would, because then maybe there would be space for many people to make their passion projects into their full time work.
I do however believe this does not need to be a complicated thing for companies, if there is a central platform to handle these types of charges. Sure, the first time you need to pay for Faircode licensed software you'll likely need to go through a process. But the second, and third and so on times, it should be a much smother process. Perhaps even automatic, just based on what software you've used (hence the tools for Faircode).
The current "Faircode" license is ambiguous enough that for the moment, I believe you're only spreading FUD against yourself, which is never the best move. I'm still no lawyer, but consider this:
If you are a commercial entity with a revenue in excess of $1,000,000...
- What $ is this? According to wikipedia, quite a few countries use the $ sign to designate their currency.
- I'm not a commercial entity, I'm a human being. So well, as a human being, I consider myself allowed to use your software for free for my work a Very Big Corp, Inc. I am, am I not?
Acquiring a commercial license grant affords you no additional rights, guarantees, support or services
So as a commercial entity (which I'm not, but I'll now assume I am) I'm not allowed to use the program without acquiring a license, but buying it doesn't give me any additionnal, hence doesn't give me any rights to use the program.
It takes lawyers to write licenses. IMHO, Faircode in its current iteration makes your program unusable by anyone except for hobby projects, and even then, better not use it for your hobby projects if you happen to sell things on the side.
Like any other product or service; if a company finds value in it they can choose to use it, but must pay to do so. It's not about adding benefits; it's about simply charging for the value that is already provided.
From my personal experience, when a company procures any product/service, the buyer expects support and warranties when buying something. If you ask money for your product and at the same time state that no liabilities, warranties or support is provided with the cost - that doesn't look good. Experiences vary but companies that generate already that kind of revenue, it's not the actual engineer who is purchasing licenses... there's usually a process that needs to be followed and certain foundational check-marks/ground rules that needs to be passed... just sayin' 💡
@thblt I agree with you! (And those comments are spot on, def needs to be fixed). The Faircode License is far from good enough in it's current state. I'm currently working on setting up a repo for the license to gather feedback, comments, analysis, case studies etc. in a more structured way, so that we can tweak and iterate it into something that actually feels solid and makes sense. Expect it to be up within the next few days (maybe even tomorrow). (More details to follow then).
@exsilium I think that's a fair point, and perhaps also something needs to be tweaked with the license. Also something I'd like to gather more input on in the repo I mentioned above (for instance how other software license look, what processes different people have at their companies etc.).
Ok, so I have two announcements.
- Faircode.io now supports dual licensing. I’ve only added AGPLv3 + Faircode for now, if there are needs for other dual licensing options in the future we can look at it. (Edit: Note, Ungit is still just Faircode; as discussed above it's still unclear what dual licensing means for applications).
- I’ve put the Faircode license on a GitHub repo to collect feedback, comments and to track the work towards a 1.0 version of the license (I consider the current one an alpha version). You can find the repo at https://github.com/faircodeio/faircode-license. If you feel this approach (licensing) has promise and want to get involved helping to shape this, I’d urge you to engage there. Also I feel that the license itself is “bigger” than the Faircode website. Even if people don’t end up using the website I think there’s value in having this type of license freely available for anyone to use.
@thblt I’ve also fixed two of the three things you noticed, and updated the Ungit license version
Thanks everyone who backed the Kickstarter for a legal review of the license so far, almost 20% completed in the first 24h! :O
It still blows my mind that you are trying to CHARGE $90 A MONTH for a +219 -153 diff on top of an open source project. All of these additional changes have been contributed by @codingtwinky @campersau and @wormeyman . Given the questioning in this faircode issue, these submissions may have already violated the Faircode license. Using ungit under this license is a liability, and probably has put these developers in a very awkward spot in regards to their employers.
npm install -g ungit@1.1.30 is still free, libre and gratis.
npm install -g mungit is still free, libre and gratis.
@exsilium has added a donation button to mungit and will probably receive $90 from me every once in a while.
It is too late. Ungit 1.1.30 already exists. It is MIT. If you want to try Faircode on something, try to build something else new that is worthwhile. I don't care. License it however you want. But stop screwing over this amazing thing you have made.
STOP USING A +7000 STAR GITHUB REPO AS YOUR LEGAL EXPERIMENT! If you want to learn about all this stuff, this is not the right way to do it. It is clear to me you are unfamiliar with the legal side of software development given your questions.
@bakkerthehacker I agree the $90 is a little steep, I'm working on a solution for it (some kind of tiered pricing).
So far 11 projects have signed up to faircode.io, 4 of which have opted for the Faircode license. While I agree that it's unfortunate that I'm pulling Ungit through this somewhat messy process, I hope that the ultimate goal of helping those people will justify it.
Please help me try to improve this system instead of asking me to go back to the old one. I believe strongly in a vision of a larger number of developers who can sustain themselves from their passion projects, and I think this is the path to get there. But it won't happen unless someone tries to make it happen. Right now, software is in a price war to 0, which means the only thing people can charge for are things that are around the software, such as support, access to their community, extra functionality etc. But I fundamentally refuse to believe that well written software isn't worth anything. For people who want to build and make a living from building such software, there needs to be a clear, simple path to do that. It won't happen over night, but it's something I think we can get to.
That's why I'm trying this with Ungit. If Ungit doesn't try this, then who will?
Again, sorry for the pain! But I want us to collaboratively work towards something positive here.
@bakkerthehacker please post a screenshot when you do once in a while contribute $90 to that other project. I hope it does well.
@FredrikNoren thanks for trying to experiment and find a more sustainable way to build free/open source software. Zed Shaw wrote a piece a while ago on why they used GPL/AGPL/LGPL: https://zedshaw.com/archive/why-i-algpl/
Hi @bakkerthehacker, I do appreciate the many valid points that you have brought on that was over looked. And perhaps blind and deaf could hear and see your disagreement. I myself is not without disagreement, there are some actions and words that I wish were different.
I'm not writing this to persuade you, I'm not legally savvy nor have sufficient amount of experiences within licensing or open source community. I just wish that you would give little more credit to @FredrikNoren. Although his focus has shifted since Ungit has started, this project would not have existed without time, engineering and idea that he came up with. In fact I still remember my timid email that I've sent out asking questions about contributing and his guidance on a language that I've never professionally wrote before.
This may will be a failed experiment, like I've said I myself have my doubts. But I hope you would give little more credit to thoughts and intent of @FredrikNoren. I don't think he is screwing with the project. He is not stoping forking, he is trying to make free version still available and tring to listen to the community.
I hope you would receive this experiment as an experiment. I hope you can help make it better as you have in some comments and don't become completely dismissive of the the effort.
@codingtwinky I appreciate your insight on this topic as you are currently the most active maintainer of Ungit. If you feel that some of your future work is something you'd be willing to MIT license, your pull requests to mungit are very welcome 😃 🍾
I think no one is trying to belittle the work that @FredrikNoren has done with Ungit and also I can understand the larger issue at hand - find a sustainable model for Open Source developers. I can agree with @bakkerthehacker that the approach that has been taken to implement this change leaves a lot to be desired. However, I do wish we can keep this discussion civil and avoid toxicity when expressing our points.
If we look at this change only from Ungit perspective, it would have been much more productive to find ways to support the developers directly via donate/patreon/kickstarter whatever means. This model wasn't even tried.
I believe strongly in a vision of a larger number of developers who can sustain themselves from their passion projects, and I think this is the path to get there.
Leaving the whole OSS ethos aside that I expressed earlier. I'm worried what actually would entail IF Faircode would become successful and set a trend in Node.JS/Ruby/[Any] modern stack development. I still remember the time when coding projects was done largely in isolation. Sure, there were Open Source libraries, but nothing as convenient as today's Ruby's gem or Node's npm. People were re-inventing the wheel over and over again. Today, you can bootstrap/scaffold a project with couple of commands and 💥 - you have laid down the foundation to your next project that would have taken perhaps thousands of man-hours to achieve. To add to this, if you are developing in the open, there are hundreds of businesses ready to support your project by Free plans/tiers like GitHub/Travis/etcetc.
Ungit is based on the Open Source fabric it now tries to commercialise via Faircode. If you look the dependency map of what happens if you run npm i you will see the huge stack of projects being pulled in and the dependencies they are built upon - both by organizations (Commercial and Non-Profit alike) and aficionados . Majority of the npm/JavaScript ecosystem is MIT/BSD/[A,L]GPL licensed. So if faircode.io is something that should be fair, scalable and so on to the projects, let's run with the thought experiment what would happen if all those dependencies that Ungit relies upon would turn to Faircode and to whom the licensee should pay in that case.
To be honest, the Kickstarter money that will be spent on lawyers reviewing yet another license could have been in my opinion much better served by this project's maintainers themselves.
@exsilium I agree that the resources we have available today freely and openly are what makes projects like Ungit possible. But I don’t see it as a problem if they were all Faircode licenses. If Ungit by some miracle made $1M / year (extremely unlikely to ever happen, despite the large number of stars very few people use Ungit) I would be happy for us to pay those developers so that they could improve the software we rely on. We have multiple dependencies that seems to have died or are dying. That’s what we could help stop.
True; closed source and people closely guarding the use of their code was a problem of the old. But this is not what I’m proposing with Faircode. I don’t see why we can’t both be open (which is why I’d prefer to call Faircode open source; but let’s not get into that one again) and sell licenses to companies.
You also mention that this change leaves a lot to be desired. So far the major points I’ve heard are:
- we shouldn’t call it Open Source: I’ve changed the Faircode website to fix this
- the license text is wonky: I’ve set up a repo to iterate it, and I’m currently working with a law firm to help finalize the text. It’s going to take a little while, so I ask for some patience here.
- this would have been better with dual licensing: I’ve implemented this for faircode.io. I haven’t changed Ungit to be dual licensed, but I’m not putting it out of the question either I just want learn a bit more before we do another license change
- the pricing is off: I agree and I’m working on a solution to this
Let me know if there are more aspects to this that we’re currently not addressing.
If Ungit by some miracle made $1M / year (extremely unlikely to ever happen, despite the large number of stars very few people use Ungit) I would be happy for us to pay those developers so that they could improve the software we rely on.
That's not how license cascade would work in this case. I think you missed my larger point I was trying to make. The point was that if the dependencies would also be licensed under Faircode and would require companies to pay 90$/month the end-price of using Ungit would be multiples of 90$ and multiple licenses would be required to be obtained by the company that has crossed the revenue bridge. Imagine if Knockout / Octicons / Glyphs / Fonts / or even Git itself would be Faircode licensed software - How would that work and how scalable Faircode would be in that case?
To build up on @exsilium's excellent remark: if, in the contrary, only Ungit had to pay for the Faircode-licensed components it uses, and not the final user of Ungit, then anyone (with a revenus < $1M) could just wrap Ungit into a MIT-licensed wrapper and release it for completely free, defeating the whole purpose of Faircode (or worse, wrap it in Faircode license but sell it half the price!)
I'm afraid Faircode seems to be self-defeating, unless it completely gives up on the MIT inspiration and become a standard "free for personal use/small orgs" commercial license. Since Faircode currently gives (provided a revenue below the threshold) the right to relicense a program, what prevents someone from just forking ungit and relicensing it under pure MIT, BSD or GPL? It's a matter of five lines of shell script to automate this :)
Again, I have absolutely no objections to monetizing free software (even the GPL provides for that), but I'm afraid Faircode is a step in the wrong direction.
Btw, just an example of monetizing a project very similar to Ungit: Magit kickstarter collected CHF 72809 (USD $73000) for its author to be able to work full time on it for a year + $309/month on his patreon. All this with a much smaller user base, since Magit is an Emacs program.
This is a very serious and obviously working alternative to commercial licensing, with real chances of success, since companies have a very strong incentive in keeping the tools they use alive.
I see, so the two things I take away from your comments are:
- “cascading” with the current Faircode license text is unclear and possibly problematic. I think this is a real issue we need to address.
- the current Faircode license text doesn’t protect the creators enough (the sublicense clause). This is something I’ve been thinking about as well and I agree it needs to be thought through more.
Thank you both, I’ll see if I can do something about these issues. Let me know if there are other problematic areas you see.
@thblt I think that’s great, and again maybe it could work for Ungit. But I want a system that can work for more people than that. Donations will work well up to a limit, and I think that limit is our attention. I can only donate to projects I pay attention to (need to visit their project pages etc.). With Faircode, I want to take it to the next step and enable revenue by usage. Ungit has probably thousands of indirect dependencies who are (mostly) solving specific problems for us. I don’t think it’s scalable for me, and for every other user of Open source, to find out exactly which of these are looking for donations. But I’d love to contribute to all of them (who are looking to sustain themselves on it) that I use. (Of course we need safeguards to make sure I don’t accidentally pull in a dependency that costs me hundreds of dollars, but that’s a technical problem).
I don't mean to be rude, but you understand you're in the process of reinventing proprietary software and "free for non commercial use" clauses, right? :-)
@thlblt every idea and concept can be reduced into something else. Uber was just taxis. Netflix just streaming video. Snapchat just messaging. Obviously Faircode doesn’t belong among names like those but my point is that you can always say that. It’s often more about what and who something enable. With Faircode, the idea is to enable open source developers to make a living from their code by charging companies for it.
Looking at the current ungit repository, where is the required MIT license that it was originally published under?
From what I understand, you are free to sub-license the original project, and your contributions (and any other contributions that people signed over to you), or anyone that also agree's to the new terms.
But it looks like you didn't do the due dilligance of actually getting that permission from all the contributors.
At the moment, you have a modified version of the MIT license, but the previous MIT license said, "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
So it really comes down to, whether the remaining contributions were 'substantial portions' of the software. If not, you are in the clear.
Licenses can never take away the rights of the original authors, for better or worse, unless they were signed over.
Sorry about the joke, but think my point still stands: since it is agreed (#974 (comment) that Faircode cannot be an OSS licence by any commonly accepted definitions, what differentiates Faircode licensed software from the myriad other proprietary software in existence? I see how Uber is not like taxis or Snapchat not just yet another messenger service, but I fail to see Faircode's own specific difference.
Also, if you take 'sub license' to mean 're license' what's to stop me (not a company making 1M) from re-licensing it back under MIT given that your license allows me to do so?
If you disagree that it's allowed to re-license as meaning of sub license, have contacted people to allow re-licensing, then I can still take the old project which is under MIT, take the diff of your current project, and as long as the current diff isn't a 'substantial portion' merge them back, and once again, license under MIT, as the diff doesn't need the new 'faircode' license because I didn't take substantial portions.
There just seems to be so many holes, no matter how you interpret it.
At the end of the day, you are likely going to end up fine, because any company is more likely to pay you the $90 per month, rather then the legal fee's it could potentially cost to fight it / research it, and whilst people might disagree, it's largely still in spirit of open source, makes sure the project continues to have supported development.
I'm more worried about the situation of a disgruntled contributor DMCA'ing your repository for mislicensing their code. It happened to https://github.com/Bukkit/CraftBukkit/
Quick update: I changed the pricing to be more flexible (per-seat instead of fixed) and introduced an annual billing discount. It's $8 per seat per month, or $6 per seat per month if billed annually. Still completely free for individuals and small businesses of course.
(@ryantheleach Thanks for the comments, I've read them, I'll get back to them as soon as I have time.)
Don't bother, I've done more research and I'm probably wrong about a lot of my points.
I am confused about one thing (read the entire thread but can't find the answer). What if I work with Ungit in a big company setting, but I am the only one using it (within the company/team). Everyone else prefers using the command line Git. I simply use it because its easier/simpler/more intuitive than command line. My company doesn't mandate us on using it, but we are allowed to use free or open source software at work (like I use VSCode as my editor of choice, whereas everyone else uses other commercial paid editors).
In this scenario is use of Ungit considered individual use or company use?
@ashishkushwaha you should ask your company to pay for a license to Ungit; they're already comfortable paying for IDEs/editors, and Ungit is a valuable tool. You can spin it as "trying it out so the rest of the team can try it too" and do a presentation on it. Basically you're persuading the company to pay for a single license in the same way you would persuade them to pay for a single license to Windows, OS X or Adobe or some other proprietary tool.
@FredrikNoren
With this change it might be a good idea to place a small link to the licence page within the UI of the application. There's the notification when you first launch but aside from that I can't see a way to access the licence outside of github.
@LukeDWood Thanks for the suggestion, I think that's a good idea. Adding it here: #991
@omouse - I will try, but most likely it won't get approved since they will just ask me to use command line (like everyone else is doing). I might have to master command line eventually.
Thanks for clarifying though.
@ashishkushwaha Before going full CLI you may want to have a look at https://github.com/exsilium/mungit, a MIT-licensed fork
@ashishkushwaha I would love to hear what your experience is like if you try, and don't mind sharing, so we can improve for other people. I created a ticket for this: #992
I'm also extremely happy to announce that today someone decided to pay for Ungit!! It's the first person to decided to do so since we launched this!
I'm very excited about this because this may be a path towards many more people being able to hack on their passion projects as their full time occupations! I know this experiment hasn't been without controversy but I'm proud of everyone in the community pulling through with it.
I just published "Faircode, an alternative to Open Source that aims to get developers paid"
, which goes a bit into why I think this is important to try.