10 ms·

I'm really happy that MIT is in the lead by such a wide margin. It's the best license in my opinion.

logn 12y ago
Why do you prefer it over Apache 2.0? Apache discusses patents and contributors and can allow for more complex attribution requirements.
- Aldo_MX 12y ago
  Usually my intention writing software is to build something useful for the people. I'm not interested in the legal mumbo-jumbo and MIT is a license which it's easier to understand for non-lawyers like me.
  - tracker1 12y ago
    I like ISC for similar reasons... just a little bit shorter.
  - technomancy 12y ago
    Code that doesn't have patent protection isn't very useful to people who live in countries with oppressive patent laws.
    - tedunangst 12y ago
      If I could make all my patent problems go away by sprinkling magic Apache License dust on my code, I'd consider it, but I don't think it works that way.
    - Aldo_MX 12y ago
      Code with encryption isn't very useful to people who live in countries where encryption is forbidden, does that mean I shouldn't write code with encryption?
- sergiotapia 12y ago
  Less legalese, I'm here to write code, not interpret law. That's why I prefer the MIT license.
  - Alupis 12y ago
    > Less legalese, I'm here to write code, not interpret law. Is reading/understanding the License one time really that difficult? After your first read through, you basically just copy a text file into the root of your repo for each project and you're done... For me, the license could be 1 paragraph or 1,000 pages. I only have to understand it once then it just becomes a standard part of any new repo I create.
    - Aldo_MX 12y ago
      You must remember that: a) Many people don't speak English natively. b) Jurisdictions are different in every country, and sometimes in every state, the law of where you live takes precedence over what your LICENSE file says. Ex. jurisdictions where encryption is forbidden. c) Some people just make projects "for fun". Reading and understanding different licenses until you find the one you agree the most with is definitely "not fun". d) Nobody recommends a license without a disclaimer of "at your own risk" unless that person is a lawyer and it's getting paid to do that recommendation.
    - bronson 12y ago
      ...until you want to integrate some code that's under a different license. Wading through pages of potential incompatibilities is not the way I want to spend my time. Speaking from experience here.
    - fnordfnordfnord 12y ago
      >Is reading/understanding the License one time really that difficult? Yeah, actually, it is. Otherwise, litigation over these matters wouldn't take months and tens or hundreds of thousands of dollars. >I only have to understand it once Sorry, but just let some judge/jury make a decision that changes or restricts the meaning of a word like "distribute" and you've potentially got a big job ahead of you.
- frik 12y ago
  BSD* and MIT are easier to read than Apache license, and compatible with all GPL licenses. Apache 1.x license is incompatible with GPL. Apache 2.0 license is a free software license and is compatible with GPLv3+, but not with GPLv2. http://en.wikipedia.org/wiki/Apache_License#GPL_compatibility http://en.wikipedia.org/wiki/Apache_License#GPL_compatibilit... GPLv2 incompatibility hurts many open source projects, also in the Linux area (Android code is Apache, Linux GPLv2). The Mozilla Public License and the related CDDL are problematic as well: http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License http://en.wikipedia.org/wiki/Common_Development_and_Distribu... (ZFS and DTrace cannot be included in Linux source)
  - dragonwriter 12y ago
    While the FSF portrays them as GPLv2 and earlier compatible, BSD and MIT both require downstream notices and language not required by any version of the GPL, which makes them incompatible with any version before GPLv3, which allows additional terms of the type at issue.
teamhappy 12y ago
I encourage you to look at the ISC license. Same thing, but shorter. https://en.wikipedia.org/wiki/ISC_license https://en.wikipedia.org/wiki/ISC_license
- frik 12y ago
  The GNU lawyers advise: This license does have an unfortunate wording choice: it provides recipients with "Permission to use, copy, modify, and/or distribute this software…" This is roughly the same language from the license of Pine that the University of Washington later claimed prohibited people from distributing modified versions of the software. [...] to help make sure this language cannot cause any trouble in the future, we encourage developers to choose a different license for their own works. The Expat License and FreeBSD License are similarly permissive and brief. -- https://www.gnu.org/licenses/license-list.en.html#ISC https://www.gnu.org/licenses/license-list.en.html#ISC
  - teamhappy 12y ago
    I never got that quote. Pine's license said "and," and so did the ISC license. FSF pointed that out and ISC changed the license. Now it says "and/or." Both OSI and FSF have approved the license. And then they added (updated?) the text you quoted, complaining about the use of "and/or" ?! The problem with Pine seems to have been that it is/was a registered trademark (compare node.js/io.js). Also note the "Richard Stallman claims [...]" part of the Wikipedia article. Also note that nobody actually sued anyone. And even if they would have, who says they would have won? (Never mind the fact that legal precedents don't really matter outside of the US.) All things considered. I think we're good. --- Nothing wrong with choosing the MIT license though. Or the FreeBSD license. Or zlib, if you don't care about attribution.
- vezzy-fnord 12y ago
  Even more terse, there's the "0-clause BSD" (Toybox) license [1] and the Fair License [2]. The first one is essentially akin to releasing in the public domain, whereas the second is the MIT/ISC license distilled down to its very core. [1] http://landley.net/toybox/license.html http://landley.net/toybox/license.html [2] http://opensource.org/licenses/fair http://opensource.org/licenses/fair
cpach 12y ago
That’s interesting indeed! I get the feeling that the GPL has lost a lot of mindshare over the last fifteen years or so.
- tracker1 12y ago
  I don't think that is the case at all... I think it depends on how high level you get... when you are building simple libraries in JS, that are abstractions on top of abstractions, MIT makes more sense because you can use it much more broadly. When you develop an operating system or driver, GPL makes far more sense because it won't lock things away... the closer you are to the hardware, the more GPL makes sense. The Apache-style licenses make a bit of sense for the stuff in between.
  - quadrangle 12y ago
    Actually, the GPL makes total sense for end-user software. In fact, lots of people argue that it makes the most sense for downstream software since it protects user freedom and won't be used in a way where compatibility is an issue. But you're right it makes sense for the OS too. I guess the GPL just makes sense, period.
    - tracker1 12y ago
      Maybe it's just a matter of a complex system, vs something more simple... a JS module can be used much more broadly as MIT/BSD/ISC than with GPL... and for the most part, because JS is typically open (though obfuscated as an artifact of minification)... where something like a complete application, or OS would have a greater desire for those safeguards... A client library to an application, less so.
- Aldo_MX 12y ago
  It really depends on the scope of your project, if you are writing a library (for example), GPL is a bad choice because you limit your audience to strictly GPL grounds (unless you really want that). Many libraries have changed their licenses from GPL/LGPL to MIT because GPL/LGPL have proved to be troublesome for specific platforms (ex. Mobile Devices). There are many political views involved, but the reality is that users are the ones who suffer the consequences.
belorn 12y ago
Remember that the statistics need to be read in the context where it was gathered from. The data looks completely different if you look at packages in distributions like Debian and derivatives, Redhat, and so on.

logn 12y ago

Why do you prefer it over Apache 2.0? Apache discusses patents and contributors and can allow for more complex attribution requirements.

Aldo_MX 12y ago
Usually my intention writing software is to build something useful for the people. I'm not interested in the legal mumbo-jumbo and MIT is a license which it's easier to understand for non-lawyers like me.
- tracker1 12y ago
  I like ISC for similar reasons... just a little bit shorter.
- technomancy 12y ago
  Code that doesn't have patent protection isn't very useful to people who live in countries with oppressive patent laws.
  - tedunangst 12y ago
    If I could make all my patent problems go away by sprinkling magic Apache License dust on my code, I'd consider it, but I don't think it works that way.
  - Aldo_MX 12y ago
    Code with encryption isn't very useful to people who live in countries where encryption is forbidden, does that mean I shouldn't write code with encryption?
sergiotapia 12y ago
Less legalese, I'm here to write code, not interpret law. That's why I prefer the MIT license.
- Alupis 12y ago
  > Less legalese, I'm here to write code, not interpret law. Is reading/understanding the License one time really that difficult? After your first read through, you basically just copy a text file into the root of your repo for each project and you're done... For me, the license could be 1 paragraph or 1,000 pages. I only have to understand it once then it just becomes a standard part of any new repo I create.
  - Aldo_MX 12y ago
    You must remember that: a) Many people don't speak English natively. b) Jurisdictions are different in every country, and sometimes in every state, the law of where you live takes precedence over what your LICENSE file says. Ex. jurisdictions where encryption is forbidden. c) Some people just make projects "for fun". Reading and understanding different licenses until you find the one you agree the most with is definitely "not fun". d) Nobody recommends a license without a disclaimer of "at your own risk" unless that person is a lawyer and it's getting paid to do that recommendation.
  - bronson 12y ago
    ...until you want to integrate some code that's under a different license. Wading through pages of potential incompatibilities is not the way I want to spend my time. Speaking from experience here.
  - fnordfnordfnord 12y ago
    >Is reading/understanding the License one time really that difficult? Yeah, actually, it is. Otherwise, litigation over these matters wouldn't take months and tens or hundreds of thousands of dollars. >I only have to understand it once Sorry, but just let some judge/jury make a decision that changes or restricts the meaning of a word like "distribute" and you've potentially got a big job ahead of you.
frik 12y ago
BSD* and MIT are easier to read than Apache license, and compatible with all GPL licenses. Apache 1.x license is incompatible with GPL. Apache 2.0 license is a free software license and is compatible with GPLv3+, but not with GPLv2. http://en.wikipedia.org/wiki/Apache_License#GPL_compatibility http://en.wikipedia.org/wiki/Apache_License#GPL_compatibilit... GPLv2 incompatibility hurts many open source projects, also in the Linux area (Android code is Apache, Linux GPLv2). The Mozilla Public License and the related CDDL are problematic as well: http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License http://en.wikipedia.org/wiki/Common_Development_and_Distribu... (ZFS and DTrace cannot be included in Linux source)
- dragonwriter 12y ago
  While the FSF portrays them as GPLv2 and earlier compatible, BSD and MIT both require downstream notices and language not required by any version of the GPL, which makes them incompatible with any version before GPLv3, which allows additional terms of the type at issue.

teamhappy 12y ago

I encourage you to look at the ISC license. Same thing, but shorter. https://en.wikipedia.org/wiki/ISC_license https://en.wikipedia.org/wiki/ISC_license

frik 12y ago
The GNU lawyers advise: This license does have an unfortunate wording choice: it provides recipients with "Permission to use, copy, modify, and/or distribute this software…" This is roughly the same language from the license of Pine that the University of Washington later claimed prohibited people from distributing modified versions of the software. [...] to help make sure this language cannot cause any trouble in the future, we encourage developers to choose a different license for their own works. The Expat License and FreeBSD License are similarly permissive and brief. -- https://www.gnu.org/licenses/license-list.en.html#ISC https://www.gnu.org/licenses/license-list.en.html#ISC
- teamhappy 12y ago
  I never got that quote. Pine's license said "and," and so did the ISC license. FSF pointed that out and ISC changed the license. Now it says "and/or." Both OSI and FSF have approved the license. And then they added (updated?) the text you quoted, complaining about the use of "and/or" ?! The problem with Pine seems to have been that it is/was a registered trademark (compare node.js/io.js). Also note the "Richard Stallman claims [...]" part of the Wikipedia article. Also note that nobody actually sued anyone. And even if they would have, who says they would have won? (Never mind the fact that legal precedents don't really matter outside of the US.) All things considered. I think we're good. --- Nothing wrong with choosing the MIT license though. Or the FreeBSD license. Or zlib, if you don't care about attribution.
vezzy-fnord 12y ago
Even more terse, there's the "0-clause BSD" (Toybox) license [1] and the Fair License [2]. The first one is essentially akin to releasing in the public domain, whereas the second is the MIT/ISC license distilled down to its very core. [1] http://landley.net/toybox/license.html http://landley.net/toybox/license.html [2] http://opensource.org/licenses/fair http://opensource.org/licenses/fair

cpach 12y ago

That’s interesting indeed! I get the feeling that the GPL has lost a lot of mindshare over the last fifteen years or so.

tracker1 12y ago
I don't think that is the case at all... I think it depends on how high level you get... when you are building simple libraries in JS, that are abstractions on top of abstractions, MIT makes more sense because you can use it much more broadly. When you develop an operating system or driver, GPL makes far more sense because it won't lock things away... the closer you are to the hardware, the more GPL makes sense. The Apache-style licenses make a bit of sense for the stuff in between.
- quadrangle 12y ago
  Actually, the GPL makes total sense for end-user software. In fact, lots of people argue that it makes the most sense for downstream software since it protects user freedom and won't be used in a way where compatibility is an issue. But you're right it makes sense for the OS too. I guess the GPL just makes sense, period.
  - tracker1 12y ago
    Maybe it's just a matter of a complex system, vs something more simple... a JS module can be used much more broadly as MIT/BSD/ISC than with GPL... and for the most part, because JS is typically open (though obfuscated as an artifact of minification)... where something like a complete application, or OS would have a greater desire for those safeguards... A client library to an application, less so.
Aldo_MX 12y ago
It really depends on the scope of your project, if you are writing a library (for example), GPL is a bad choice because you limit your audience to strictly GPL grounds (unless you really want that). Many libraries have changed their licenses from GPL/LGPL to MIT because GPL/LGPL have proved to be troublesome for specific platforms (ex. Mobile Devices). There are many political views involved, but the reality is that users are the ones who suffer the consequences.

belorn 12y ago

Remember that the statistics need to be read in the context where it was gathered from. The data looks completely different if you look at packages in distributions like Debian and derivatives, Redhat, and so on.