MIT or GPL, that's the question
If you use Free Software, support and believe that it is the best option for software in the future and you are also a software developer, you have no excuses not to release with a Free Software licen
MIT or GPL, that's the question
If you use Free Software, support and believe that it is the best option for software in the future and you are also a software developer, you don't have many excuses for not releasing with a Free Software license. As a side note, note that not only programmers develop Free Software: they also provide the documenters, testers, graphic designers, distributors...
The ultimate argument for convincing yourself that you should release the code you have developed is this: if you keep the code zealously in the drawer, it is likely to die in the drawer! Remember the code you have made and think, as fast as the world of computers is moving forward, if it would still be applicable today. Do the exercise of reviewing your private repositories and be surprised. As an individual developer there is another interesting reason: publishing your work is the best resume you can have. There are even companies dedicated exclusively to talent hunting examining the code posted on GitHub.
If you run a software development company, you may be wondering why you're going to release and let everyone have access to the code.... There are several reasons, but the main one is that software consumers appreciate that the programs running on their computers are OpenSource (auditable, secure, adaptable). In the case of companies that use your software it is essential that they can control their information and that there is no dependence on the supplier (you will have to be good at providing the service, nothing more and nothing less). If you contract with the administration, there will come a day when it will be a prerequisite that software paid for by everyone is for everyone (this is what we citizens must demand!).
Fear that the competition might use it for free.... It's the best thing that can happen to you! You create a dependency on your code and they'll have to name you in the credits. Is there a better business case? What you have to study is whether it makes sense to release everything you develop. Theoretically it's best, but please, if the code is ugly or bad, don't release it! The ideal is to release the code and lead community-based development. Releasing a software that is going to be adopted by the community is, at the same time, supporting it and incorporating the improvements that external developers can provide and creating a product of guaranteed success. If you also free up before the competition, it will be difficult for someone else to take your place or market niche.
By now you should be convinced to release your software and want to know how. Well, it's very easy: you only have to use a Free Software or Open Source license. The decision to use an Open Source license is always better than the proprietary one, but if you add restrictions on its use that prevent it from being Free Software (see the 4 freedoms of the software) it will not be welcomed and you may not receive support from the community. This also limits the possibility of growing up in a network exponentially and may result in a truly free equivalent solution that makes you feel like you've wasted your time.
Within the free licenses you have many to choose from that can be grouped into a permissive "MIT" or a viral "GPL". With MIT you would basically give permission to do whatever you want with your code (preserving copyright), while with a GPL you also impose an obligation for derivative works to remain GPL. If you are purely strict in the definition of freedoms you will choose MIT but run the risk that someone will use your code and then close it in a proprietary solution. On the other hand, with the GPL I would be obliged to produce software licensed also under the GPL with the sense that Free Software tends to prevail over proprietary software.
However, whether it's MIT or GPL, release your code!
Last updated
