Open Source License Business Perception Report
writing.kemitchell.com
writing.kemitchell.com
[1]: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
[2]: https://writing.kemitchell.com/2016/05/13/What-Open-Source-M...
[3]: https://writing.kemitchell.com/2016/05/13/License-from-Who.h...
If and when you find typos or misfires, please feel free to send me patches via GitHub. I'm always happy to give credit where it's due.
However I don't get why every copyleft licence get a minimum of two ?'s. They write that it is a measure of popularity and quality, but for example
"EPL-1.0 Best copyleft license. Clear patent license. Professionally drafted."
"GPL-2.0 Most popular “community” copyleft license. Can hire compliance pros."
Highly "professional" community of _developers_
Copyleft license conditions beg interpretive questions about what actions trigger copyleft requirements and what actions satisfy those requirements. Common copyleft licenses differ in their triggers and requirements, as well as how they express them in the legal text.
They're not liked by companies that want to be able to take everything for themselves and never give back. This article is just typical anti-copyleft FUD.
And I've talked to lawyers! And I still stay far away from the popular copyleft licenses. There's far too much gray area in what constitutes a derivative work and what obligations I might unwittingly take on even when well-advised.
I said that they aren't liked by companies that want to be able to take everything and never give back. I never said that they were ONLY liked by those companies, and I can't believe you're both capable of writing software and not capable of understanding that distinction, which leads me to believe that you must be either lying (about writing software) or trolling.
You can stay away from whatever licences you like. Their interpretation is very clear and well-known. If you think that something might be 'borderline' then don't do it. Even if it's technically fine it's almost certainly going against the intent of the licence, which is morally wrong.
The only obligation you could possibly take on is the conditional obligation that if you convey a derived work then you must make the source code available. That's not a difficult obligation, because you are already distributing the source code, because you aren't a fucking terrible human being (right?).
What you did was try to break out a cheap rhetorical trick to try to paint anyone who expresses a concern about copyleft, knowing you could always back out with "well, I never said that..."
And of course in your most recent comment you did it once again, sneaking in a back-door assumption that people who would have a problem with copyleft are "fucking terrible human beings".
You should stop doing that. Because you aren't "a fucking terrible human being", right?
Meanwhile, I'm pretty sure I've had this exact debate on HN before, but:
We went any number of rounds of this with Django a while back, precisely because there's such a large gray area. I still don't honestly know whether someone could claim we've accidentally triggered the GPL by providing a database backend module in Django that can talk to GPL'd MySQL drivers. We've just navigated as carefully as we can, there.
And no, it is not some sort of simple, settled, well-understood thing, so maybe you could stop presenting it as if it is? That'd be great.
The pain rating is "how difficult is compliance" and the confusion rating is "do I trivially understand the concepts" (and apparently copyleft is hard). It was a bit of a disappointing read as I was expecting some more analysis than one-line descriptions.
edit: that was probably a bit unfair of me, since the author has dissected several free software licenses on their blog in separate articles, which I recommend reading
I should have said for-profit software instead of companies, really; the legal entity is quite irrelevant in this case. I said companies because they are entities that: 1) stand to be sued in case of license violations (you typically don't sue a hobbyist project) 2) have the perceived need to maximize profits, and as a consequence want to veer off from anything that might require releasing source code, which might offset a competitive advantage. Thus a hobbyist project being a licensing clusterfuck is a less critical issue, although it is of course an important one (and certainly, depending on the project’s popularity, there may be a vocal portion of people wanting to clarify the situation).
The pain and confusion ratings also do not go into the details which are useful for OSS projects, such as how do licenses interact with each other, how is attribution and re-licensing managed, etc. Not to mention the ratings do not differentiate between pain/confusion for the developer, and pain/confusion for other future developers (e.g. in case of a lib).
(I admit that I tend to forget that there is also hobbyist closed-source software, for reasons I never understand)
I've heard this again and again, and yet every time I see open source used by a company, there are patches being applied, compliance concerns and audits, and integration efforts.
Sometimes this effort costs less than writing the code yourself (such as integrating with a database), but not always.
Apple and Microsoft, for example, have taken significantly from BSD/Apache-like code for their own OSes.
They wouldn't have been able to do that with GPL-like code.
Apple at least has contributed a lot back - they are a major force behind clang for example.
Then explain Android.
an android phone is oss android plus a bunch of proprietary (non oss) google bits.
I like the GPLs and what they stand for. In another post, also popular here on HN, I wrote:
> The last [great idea in open-source licensing], not found in The MIT License, builds off license conditions: “Copyleft” licenses like the GNU General Public License use license conditions to control how those making changes can license and distribute their changed versions.
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
In another post, again channeling my own thoughts and feelings, rather than those of a broader, abstracted business community, I wrote:
> As an attorney, for one, and a coder who came up on FSF software, for two, it kills me to see students and pre-exit programmers write off good licensing hygiene as unnecessary. It makes me queasy to read, via the closed, hood-welded-shut social network du jour, that "open source has won". How smoothly both disdain for "corporate interests" assailing community values, on the one hand, and utter disdain for the GPL, its politics and its moralism, on the other, roll off the tongue. It’s a cruel, cruel world.
https://writing.kemitchell.com/2016/05/13/What-Open-Source-M...
Copyleft licenses are more complex than permissive licenses by design. GPL-family licenses add idiosyncratic style and politics to that mix. There is a whole body of signals and accepted practices filling in interpretive fissures in that complexity---for FSF projects, for Linux, for MongoDB (AGPL). Consider the recent "enforcement principles" release and the disagreements that led to it. Corporate copyleft users have to do that homework. Corporate permissive users get the night off.
Fair criticism. This was by design.
I'd originally set out to follow the table with a commentary section on each license. But judging by the first few sections drafted, that was shaping up to be a very long read. The pain-and-confusion bit is terse and cartoonish to begin with. Blocks of additional text weren't going to change that. So I erred on the side of brevity.
I'm not sure what the rightsholder situation is with regard to ZFS (that is, I don't know if they had a copyright assignment for contributors), but it'd be really interesting if someone could convince Oracle, who I assume is the owner, to re-license it under the GPL. Oracle seems to have at least equal commercial interest in Linux as Solaris at this point. I'm not sure what the benefit is in keeping the license incompatible anymore.
It's true that Oracle can issue an update to the CDDL that would automatically apply to (past) versions of ZFS, since the CDDL delegates to them (nee Sun) as the license steward and ZFS was being distributed with "or later" terms. Last I checked, though, the current ZFS project maintainers decided to patch that by opting out of the "or later" terms for future versions. At least this was true when I spoke to ryao about it last year.
This was around the time that there was a lot of attention on ZFS on Linux. Eben Moglen did a compelling writeup at that time arguing that ZFS is most likely freely mixable with GPL nowadays, because users have been able to accept it on GPL terms ever since Oracle has shipped Linux versions that include ZFS and doing so without making it available under GPL would be a violation of the kernel's rightsholders' copyright.
CDDL is still a total quagmire. I'll repeat: there's no good reason to adopt CDDL today, and there's lots of reasons to avoid it.
Probably because of the patent uncertainty. You can copy the code legally and still get in trouble for using another entity's IP. Practically speaking, that will probably be more costly than a battle over copyright.
The FSF https://www.gnu.org/licenses/license-recommendations.html seems to agree with that.
Can we take that conclusion away and go with it henceforth? Are there any downsides to it at all?
say I'm releasing a document that say it's gpl v4 and assign all ownership to me. or the FSF goes corrupt.
1. Nobody forces you to upgrade to the latest version, it's only an option that people can exercise if they have a copy of your code.
2. In GPLv2 the FSF is the only entity that can create new versions, while in GPLv3 there are provisions for the original author to create a proxy (allowing them to delay the application of a newer GPL).
3. If the FSF goes corrupt, it is unlikely the new GPL will apply because the GPL states that newer licenses will be "in a similar spirit to this license". Given how much documentation the FSF has on their philosophy, it would be very clear if a newer GPL version violates their stated philosophy.
Also, finally, you can't have a license that "assigns all ownership". Copyright licenses and CLAs aren't the same thing -- and I doubt that you can retro-actively force people to give up their copyrights like that.
You should always use or-later because if you don't then you're just asking for trouble when the next GPL version is released and you have to ask every contributor whether they want to relicense their contributions. If you make it or-later in the beginning then there's no issue. If you don't like a GPL version you can always add restrictions to the all-later clause.
I think Linux is a good example of this. Maybe users would be better off with GPLv3, but the copyright holders decided not to relicense. It's not asking for trouble to avoid relicensing until you can see the new license.
Legally speaking, you're right.
Practically speaking, if you're running a project with a lot of contributors, hunting them/their heirs down and getting buy-in for a license change could be a huge project in and of itself.
Sure, but the FSF's drafting process is open. Not to mention that if you don't like the drafts (or the final version) you can always restrict "or any later version" by saying "or any later version, except versions X, Y, Z". Sure, this'll mean your old code could be used under that license, but new code won't. By the way, the MPL (and CDDL) has the "or any later version" clause built into the license without an option -- by using MPL you are allowing Mozilla to relicense your code whenever they want.
> It's not asking for trouble to avoid relicensing until you can see the new license.
Until you find out that some of your contributors have passed away, and either:
a) Their copyright is in an estate, making it effectively impossible to get anything re-licensed.
b) Their copyright has passed to their next of kin, who might have no understanding of what the deceased's views on free software were and thus probably will do something like ask for money to relicense it (or just refuse outright).
Not to mention that if you're a large project, you're asking for trouble. In most cases, the only contact information you have about a person is their email address -- and since email addresses change all the time it's unlikely you'll be able to contact everyone. Mozilla went through a bunch of trouble trying to re-license all of their code because of problems like this.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation.
Secondly, you can't revoke rights previously granted. A project licensed under GPLv2 will continue to be distributable under the GPLv2 regardless of future license versions. So even if the GPLv4 says 'You have to sign your copyright over to the FSF, mwahahah' then you are free to ignore that change.
gotcha.
just for argument's sake, what prevents me to become an incorporated entity under Free Software Foundation in a different country?
That would be a voilation of GNU GPLv3 itself (by FSF which is legally wrong). Such a GPL v4 license won't be considered as a later version of GNU GPLv3.
See section 14 of GNU GPL v3:
The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
If the later version is not similar (Of course, it is hard to explain this term) to the spirit of the present version, it will not be considered as a later version of current license.
Also, by having 'or later' in the license won't revoke the previously granted permissions.
Not a lawyer, but MIT/BSD ignore patents, (software patents IIRC didn't exist when these licenses were created)
whereas Apache2 provides indemnity against any users from related patent suits by contributors.
(Sort of 'copylefting' associated patents, in a limited sense)
This isn't really an 'edge case' at scale - many large tech entities have patents.
Again, not a lawyer, I'd suspect this is 'best' here for adoptors of software using this license at smaller firms because lawyers reading the license know they are clearly protected from patent litigation by other contributors - that doesn't necessarily imply it's best overall - e.g. large companies with a large patent portfolio which is largely unrelated might not wish to even theoretically weaken their ability to use patents, or this might be a block to software adaptation/contribution due to bureaucratic reasons (e.g. all licenses must be approved by legal, who won't consider anything that mucks with their patents, even if it's not an issue here).
Further, there is potential for the patent indemnity clause to make litigation murky - for example, if a patent is covered by this license, but a user further expands the code in an 'infringing' capacity, or infringes elsewhere, the indemnity provided by the base code might protect them against litigation where it is actually warranted..
Probably some things on the flip side too - e.g. by accepting the indemnity clause, you might be recognizing the validity of the customers patent which could then be applied elsewhere against you, etc.
And as best I know (again, not lawyer and not up on details here) there isn't much case law around these licenses to clarify the murkyness.
Again, not a lawyer at all, but 'best' is dubious - I do have a preference for the BSD/MIT because they avoid this whole quagmire - although I'm somewhat anti-software patents for most cases, and licenses such as this also legitimize them, the biggest thing for me here is that this clause makes the 'free use' of the software itself much more dubious and less clear cut.
It would be interesting to have some more fine-grained information about biases/perspectives/rationales in this survey to help quantify the summary data..
Yeah, this is an issue with Apache 2 License. Say, the user can take only the patented code (and modify to meet his/her needs) and keep the rest of the code to have any license (including proprietary), and the user is at the safe side.
In the case the code is licensed under GNU [A]GPLv3, the whole (modified and linked) code requires to be in [A]GPLv3. So no non-free derivations possible. If the user didn't free the code, the original author (who owns the patent AND wrote the [A]GPLv3 code) can sue the user (because the user has violated GNU [A]GPL).
* https://news.ycombinator.com/item?id=13942104
* https://news.ycombinator.com/item?id=13945492
* https://news.ycombinator.com/item?id=13946588
and you will find that we cannot.
- with American and Common Law concepts and terms such as "copyright" translated to concepts meaningful in the EU
- covering "moral rights" (like German UrhG law which has certain rights that you can't transfer at all, such as claiming to be the author of something)
- avoiding overly broad (and hence void) non-liability provisions
- with provision to determine the venue/court to bring cases to.
The EUPL has provisions to integrate EUPL-licensed works into other works and for relicensing under more liberal/non-copyleft licenses, but the cavalier attitude when it comes to copyleft makes it unclear to me whether the EUPL actually is a strong copyleft license (cf what the FSF says about it [2]).
[1]: https://joinup.ec.europa.eu/community/eupl/og_page/eupl
[2]: https://joinup.ec.europa.eu/community/eupl/news/new-fsf-stat...
https://www.gnu.org/licenses/license-recommendations.html
While Kyle Mitchell seems to discourage the use of the AGPL, the description on the FSF site seems to be pretty much what I as a developer who cares about free software would want for server software.
- GPL wants to care about the users, but actually cares only about those who install the software on their computer. Back then, these groups were identical, but in the time of remote applications (web apps, services, etc.) this means: The owner of the server, not the end user, receives the rights granted by GPL.
- AGPL actually does care about the users, no matter how they interact with your application. The rights given by the AGPL are granted to everybody down the chain.
Of course, this line of thinking only applies if you want a strong copyleft license. If you want non-copyleft, e.g. for very small projects, just stick with the ISC license (which is a more modern and slightly shorter version of MIT license).
It is a bit tricky here. Based on the situation, the same software can be some times be open source AND free software, or open source only (ie, not free software).
Eg: Linux kernel. When it is run on your computer, usually it is mostly free-software (linux-libre would be fully free). When it is run on your router, they (vendor) shall give you the source code, but may not allow you to modify it. This is violation of freedom 1 (The freedom to study how the program works, and change it so it does your computing as you wish). Then it won't be a free software, but just open source. You can't even confirm whether the source code they gave corresponds to the binary run in the router.
not at all true.. not being able to easily modify the binaries on your router is not the same as modifying the code which they distributed to you..
it is a license for the source code - not the runtime application of the source code.
> it is a license for the source code - not the runtime application of the source code.
That is a fundamental difference between "open source" and "free software".
See https://www.gnu.org/philosophy/free-sw.en.html, specifically the explanation of freedom 1.
> It is not worth the trouble to use copyleft for most small programs.
and they recommend Apache 2.0. What are you disagreeing with?
I like the MIT/BSD licenses. Short, clear, understandable.
We might think short lines are clear and understandable and the best. But that is just for us. When it comes to law(yers), it might be interpreted in extremely insane ways.
So the terms has to be explicit, and this is why GPL/Apache have very long lines, stating each detail explicitly.
Have you ever seen any serious EULA for any proprietary software (or service) short and clear?
Now there are those who always preferred the BSD-style over the GPL-style, which is fine. But I find it strange to prefer the GPL over the AGPL...
E.g.
- I have a database.
- I have a closed-source website that uses this database
- I have an APGL service that uses this database
Do I have to opensource the website? APGL companies say yes.
Which is why the weaker LGPL excludes linking, AGPL is stronger, so definitely includes linking.
Every hypothetical I've seen addressed with the AGPL involves a company running a server for users and then modifying that server and having to give the code to those users. But rarely is anything that clear: if I have a task queue that processes internal jobs, do I need to provide the code to end-users? Or are the "clients" just my app and the queue workers? If I don't, can't the whole AGPL be trivially circumvented with a reverse proxy?
I would give the AGPL more than three "?"s.
This particular use case is where the implicit dualism of GPL software-centricity (vs people-centricity) falls apart/becomes absurd in my opinion - yes, the OSS version of the software is 'always free as in libre', but it is also always controlled by a creating entity who is using the license to create a defacto monopoly on it's commercial use, so the people are always beholden in some sense to the original code owners.
It's up to every publisher of open source software to weight business, community, personal, political, and other preferences to their taste in picking a form license. I tried to make big-co preferences more accessible, in a distilled form. Not to elevate them above all other concerns.
I get that the 2.0 versions have been in use a lot longer, and have had some tests in court. But, my understanding was that part of v3.0's purpose was to clarify the license and remove uncertainty about its meaning. They certainly had a lot more resources and experience when constructing the v3.0 versions. It's been many years since I read them side-by-side, but I recall liking the language in 3.0 more than in 2.0.
A normal human being reading the license will get the almost-certainly-correct impression that the author of the code will not come after them for anything they do, especially if it's a small usage. Lawyers must worry about two reasonable scenarios: First, some large usage causing the original licenser to decide to change their mind [2]. To put it in terms most of HN will understand, what if you release some code under the WTFPL license and discover that the Trump administration is using it. Would you be tempted to wedge your way into the legal ambiguity and sue them over it? Your specific answer doesn't matter; you need merely believe that there are plenty of people jumping out of their seats and yelling YES! to make my point, as that is enough to send shivers down a big-company lawyer's spine.
And second, even if you are confident that the original author wouldn't sue, if the rights to the package get transferred to someone else, you have to worry about whether that licenser will change their mind as above. If a new party changes their mind about the license, some of your legal defenses get a lot harder. The bigger you are as a target, the more you have to worry about being a bit, juicy target. A 5-person unfunded startup doesn't have a problem where Google does.
It isn't really a license so much as an assertion that the author won't come after you if you use or modify their code with no legal meaning.
[1]: https://en.wikipedia.org/wiki/Estoppel
[2]: http://dev.hasenj.org/post/3272592502/ibm-and-its-minions
So it seems to me there is a real difference here between licenses that proactively are clearly giving you some sort of rights, even if what those rights are may be up for debate, vs. the WTFPL license, which is still technically probably establishes that the author meant to grant you some stuff, but it is not terribly clear what.
Revoking a license means that permissions previously granted are no longer applicable to any acts taken in the future, so no action requiring a license under copyright (such as copying) would generally be permitted (promissory estoppel protects, to a limited extent, those who initially relied on a promise that the license would not be revoked before it actually was revoked, but generally only to the extent that they had reasonably expended resources in that reliance and would be suffer unjust loss due the violation of the non-binding promise.)
> You can close your future development but if someone takes the old code under the old license and continues work on it, I can think of no case where that was stopped, or even challenged.
Thats because no one has ever actually revoked an open source license on code in significant use, rather than merely not offering it for future versions. And there's a good reason: most people offering open source licenses, even if they change their mind on a particular work, want open source to keep working, which actually relies very much on the shared belief that gratuitous open source licenses won't be revoked, even though the law of gratuitous licenses clearly allows that.
If it ever happens (and courts don't just completely rewrite the law on gratuitous licenses in defiance of precedent to save open source), the whole illusion of safety comes crashing down.
The one downside that EPL has is that, unlike MPL (without "Incompatible With Secondary Licenses" notice) or LGPL, it is incompatible with the GPL-family of licenses. It specifies different conditions for providing the source code and has a governing law clause (New York).
It is popular in the Java ecosystem (Eclipse, Clojure, etc).
I use the MPL for most of my projects that aren't under MIT simply based on the fact that it feels like the GPL but without infecting any larger projects that want to use my code.
Or am I overlooking something as a IANAL?
That is, does a downstream user have option to choose either license ever, or would best practice be to announce which license you default to on usage?
It is confusing for me. If the project has GPL and MIT license I can't contribute GPL code to it, can I? Because it has to be also MIT.
Generally more restrictive license is more important in case of contributions. More permissive license is more important in case of use and modifications not contributed back. It is a fork welcoming licensing.
* Easy for nonlegally minded people to read
* Legally obvious with little room for interpretation
* Easy to be incorporated into larger projects
But it doesn't have any language about patents.
https://opensource.org/licenses/MS-PL
Not sure how "easy" it is to read, I think it's fine? I'm no lawyer, just another developer.
Even simple programs, made robust enough to run anywhere, get pretty damned big.
That makes the Apache 2.0 license a simpler choice than a MIT style license (from the point of view of a lawyer), as it's incredibly explicit and battle tested.
I disagree that it's "niched" to Perl, though; it's much less so than its predecessor at the very least.
1. If you want to dual license, use either AGPL or GPL (possibly even EUPL) Choice depends on what's your intent is. Choose carefully (EUPL has licensor warrant requirement). AGPL can be perfect for small companies who want to use licensing to generate revenue. Remember to be clear that dual licensing is an option. You can always switch to more permissible license later when you own all the code.
2. Use Apache-2.0, or MIT if you want the code just to be open source.
I would like to hear disagreeing legal arguments.
1)GPL or LGPL for things you want to stay free.
2)BSD or MIT for everything else. This is important for things like firmware, where offering source code can be rather silly. Also, some people don't have an issue with companies incorporating their code into closed products and these offer an easy way to allow that.
I always felt the OSI did a huge disservice by encouraging companies to create their own licenses. There really aren't that many things people want from a source code license, so a few that broadly cover those cases is important. All the others just create license-compatibility issues that limit the usefulness of the code.
Okay, is there evidence of this? who else has done it? is there existing legal precedence for this action? will presenting something that says "WHAT THE FUCK" in it cause me embarrassment in a corporate setting? how is our exposure for implicit vs explicit license agreements?
As a Lawyer myself, I am certainly not. Free Software and Open Source Licenses are a great way for developers to get protected, worldwide, at a very low cost - and to achieve their goals and values besides their software itself.
I currently prefer Unlicense but 0BSD looks very nice…
A tactical position in the legal arms race is of course clearer than some implicit assurances of peace.
[0] https://writing.kemitchell.com/2015/02/13/FTC-2014-Year-in-R...
It takes at least a full working day to round up all the FTC actions for a year, read them, code them, categorize them, synthesize, write it up, and proofread. I had that kind of time back in early 2015, when I'd just started my own practice, and wasn't backed up with client work to do. I holed myself up in the San Francisco Law Library for it, as I recall.
Thanks for all of your work on the blog. Very interesting material.
npm install legally -g
legally
From what office does this opinion stem?
Just curious.
Please note that it is not possible to do this with some License X and GNU [LA]GPL. Because it is an additional restriction which is not allowed as per the terms of GNU [LA]GPL.
https://wiki.creativecommons.org/wiki/CC0_FAQ#May_I_apply_CC...
However the OSI didn't approve it and don't recommend it, mainly because it explicitly does not cover patent rights:
That was not the reason. If so, [L]GPLv2, MIT or several other licenses won't be accepted by OSI.
The issue is CC0 explicitly disclaim any conveyance of patent rights (from the linked faq).
I've been using it for a long time as a "socially acceptable WTFPL" and thought it did, well, exactly the same as WTFPL, let any person in possession of the source do whatever the fuck they want. But apparently with CC0 there are some things they can't do even if the local law allows it?
> Unless expressly stated otherwise, the person who associated a work with this deed makes no warranties about the work, and disclaims liability for all uses of the work, to the fullest extent permitted by applicable law.
If you don't explicitly disclaim warranty then you can get hit by this in Common Law jurisdictions, see [0]
It's a socially and legally acceptable WTFPL — it includes:
- a "do not sue me" clause for jurisdictions with implied warranty
- a BSD-style permissive license for jurisdictions that do not recognize public domain or do not allow directly putting something into it (e.g. Russian law explicitly says that disclaiming authorship is bullshit)
Fine with commercial users not giving anything back? Apache2.
The best shot to dual-license your free software? AGPL3.
Care about patent attorneys' working hours? EPL1.
Dyslexic? MIT.
If I recall right, it was written originally by Sun a long time ago, to allow them to open-source their software while giving clear terms to entreprise users to let them combine/integrate software together.
It is unique in some aspects and it is friendly for entreprise.
https://en.wikipedia.org/wiki/Common_Development_and_Distrib...
I feel sad every time new code uses CDDL.
Can we just simplify the licenses or does everyone need to write their own? Why not just have MIT for all open source and be done with it?
The large majority of projects use MIT, GPLv2, GPLv3, Apache, or a common variant like LGPL or BSD. Older projects often use other licenses for historical reasons, and modules often use the same license as the core software.
Asking why everyone doesn't just use your favorite license is a good way to start a flame war. The MIT license doesn't address patents, and some people like copyleft.