search

FredrikNoren / ungit

The easiest way to use git. On any platform. Anywhere.
MIT License
10.45k stars 640 forks source link

Trying a new open source model (Ungit license change) #974

Closed FredrikNoren closed 6 years ago

FredrikNoren commented 7 years ago

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: https://github.com/FredrikNoren/ungit/commit/cf582d48952f49df21cadf71e54efe4ed2e52413

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.

ricardobeat commented 6 years ago

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'.

floatingatoll commented 6 years ago

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?

waldyrious commented 6 years ago

Just in case someone's wondering why the sudden influx of comments (starting here): This thread has been shared on Hacker News.

jsjohnst commented 6 years ago

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.

david-a-wheeler commented 6 years ago

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.

mkeedlinger commented 6 years ago

@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.

FredrikNoren commented 6 years ago

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).

FredrikNoren commented 6 years ago

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)

thblt commented 6 years ago

@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 :)

FredrikNoren commented 6 years ago

@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?

thblt commented 6 years ago

@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 :)

ghost commented 6 years ago

@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:

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.

FredrikNoren commented 6 years ago

@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.

FredrikNoren commented 6 years ago

@bakkerthehacker Thanks for pointing out the xkcd license violation, I've fixed it now.

Fatalityap commented 6 years ago

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?

exsilium commented 6 years ago

@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 :(

FredrikNoren commented 6 years ago

@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).

thblt commented 6 years ago

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...

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.

exsilium commented 6 years ago

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' šŸ’”

FredrikNoren commented 6 years ago

@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).

FredrikNoren commented 6 years ago

@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.).

FredrikNoren commented 6 years ago

Ok, so I have two announcements.

1) 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). 2) 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

FredrikNoren commented 6 years ago

Thanks everyone who backed the Kickstarter for a legal review of the license so far, almost 20% completed in the first 24h! :O

bakkerthehacker commented 6 years ago

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.

FredrikNoren commented 6 years ago

@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.

ghost commented 6 years ago

@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/

bakkerthehacker commented 6 years ago

@omouse https://www.blocktrail.com/BTC/tx/8b09724579bf17996bdce6fa39df1fa3ec845a03b4c95c3cb6ef8eb622e2b5ae

jung-kim commented 6 years ago

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.

exsilium commented 6 years ago

@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.

FredrikNoren commented 6 years ago

@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:

Let me know if there are more aspects to this that weā€™re currently not addressing.

exsilium commented 6 years ago

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?

thblt commented 6 years ago

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.

thblt commented 6 years ago

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.

FredrikNoren commented 6 years ago

I see, so the two things I take away from your comments are:

1) ā€œcascadingā€ with the current Faircode license text is unclear and possibly problematic. I think this is a real issue we need to address. 2) 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).

thblt commented 6 years ago

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? :-)

FredrikNoren commented 6 years ago

@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.

ryantheleach commented 6 years ago

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.

thblt commented 6 years ago

Sorry about the joke, but think my point still stands: since it is agreed (https://github.com/FredrikNoren/ungit/issues/974#issuecomment-344539700 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.

ryantheleach commented 6 years ago

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/

FredrikNoren commented 6 years ago

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.)

ryantheleach commented 6 years ago

Don't bother, I've done more research and I'm probably wrong about a lot of my points.

ashishkushwaha commented 6 years ago

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?

ghost commented 6 years ago

@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.

LeahDWood commented 6 years ago

@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.

FredrikNoren commented 6 years ago

@LukeDWood Thanks for the suggestion, I think that's a good idea. Adding it here: #991

ashishkushwaha commented 6 years ago

@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.

thblt commented 6 years ago

@ashishkushwaha Before going full CLI you may want to have a look at https://github.com/exsilium/mungit, a MIT-licensed fork

FredrikNoren commented 6 years ago

@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

FredrikNoren commented 6 years ago

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.

FredrikNoren commented 6 years ago

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.