Skip to main content

MIT License

License agreements tend to be very long and annoying to read. We see them all the time, creating accounts, using services, etc... They are everywhere. They go on for pages and pages and no one ever seems to read it. They just click the agree button and carry on. For the most part, users don't run into problems, but company's still need to protect themselves in the case that something out of the ordinary does happen. They protect themselves by creating their terms and conditions.

In these terms and conditions, there is usually other licenses that need to be followed as well. One license in particular that I want to talk about is the Massachusetts Institute of Technology license or better knows as the MIT license.

This license is short, in fact it's only 171 words long. It's easy to read and for the most part is clear about the information it is trying to tell. I personally found it easy to read. I found it unnecessary to dig deeper and look into every section a few words at a time.

Kyle Mithcell who is in both law and technology has a blog post who examines the license extensively and intensively. He digs deep into the meaning of every word and every part of the license.

A few things I found interesting is that this is a license where anyone can take anything and use it for their own gain. Meaning that they can sell it and profit from it without giving a percentage to the owners. It's an odd license and it sounds like something that no business would ever want because a business is supposed to make money. Which leads me to the next interesting part.

This license lets people take what's already there and implement it in another way or create a different use for it. They are free to do as they wish but there is one catch. They cannot blame the creator for any of their problems. If the created software gets hacked, they have absolutely no one to blame but themselves because they have to follow the license agreement to use the software. This opens up innovation with current software but it's risky because all responsibility is on the users of the software.

There is absolutely no warranty with this agreement. People are free to do whatever they want and if something goes wrong, they can't turn around and say there's something wrong with your code. They have absolutely no right to do so. They agreed to it and the owners are not responsible for any reason.

Overall, this is an interesting license that would be used for certain scenarios. The best scenario I can think of is students work that can potentially impact the world. An idea that they have can be implemented by bigger companies with much more resources and they can see their name on the license. Although not much credit is given, the name is in the license section and they can proudly say I started this.

Comments

Popular posts from this blog

Fixing Bugs Again

I started working on Open Source Projects again and I had a difficult time getting started again. A big part of my problem was not having enough storage on my computer. After moving some things around and deleting files and programs I don't use, I was able to clone a couple projects and I was finally ready to start running them and replicating the issues.  This time around, I worked on three projects; Thimble, Brackets, and Balrog. The bugs that I fixed for Thimble turned out to be fixes on Brackets so the pull requests were made there but referenced from Thimble. Overall, getting started was much easier than last time because I already had the experience and possibly the necessary files on my system to begin. After being assigned a couple bugs, I began to work on them and I have made a couple pull request for the fixes. They have passed all tests and I am just waiting on it to be accepted and merged into the actual project! That is my goal. I will need to follow up if anyth

Second Attempt At Fixing Open Source Bugs

In my second attempt at fixing open source bugs, I want to prove that I have grown from the first attempt. My first attempt was fixing a single bug, requesting a pull request, and getting approved! My goal this time around is to work on more than one bug, I plan to work on 2-3 and my ultimate goal is to get all of them approved! There is no better satisfaction than getting approved!  Since I was working with Mozilla projects before, I decided to stay in that bubble and work on Thimble/Brackets. I have currently asked to work on a couple bugs like this  and this  and once I get the okay to do so, I will begin to try to fix them. As of right now, I am still researching for more bugs to work on, but at the time of this blog post, I do not have any backups.  Due to the strike, a lot of things are altered in my schools semester. Surprisingly, all my teachers were very accommodating and they dropped tests and assignments and overall, it's making the end of the semester less over

Documentation

Documenting everything is extremely important. It gives everyone the information they need whenever they need it. Github makes it very easy to have beautiful pages written in markdown rendered automatically. It's nice and easy to do. Creating a README in the root of the project is common practice and is even automatically rendered when the project is open in Github, under all the file names. I've been looking at quite a few different projects and they all have README files. It usually includes an introduction to the project, how to set it up, how to run it, how to contribute to it, major credits to people, etc... Essentially, it holds important information about the project that anyone has access to. Along with the README file, we can comment on our actual code so hackers who read the code can know what does what. It allows the creator to recall what they wrote in the past and it invites new people to understand what has been written. It is really important that comments are