[jobvandervoort]

I don't understand the reason the author mentioned that you should use such a license. Why do you have to, in their reasoning?

We've been happily using MIT Expat for everything we open source and have not had any issues with it. Criticism, yes. Issues, no.

[mikekchar]

In my opinion, share-alike licenses are important when you want to establish a level playing field for competition. With a share-alike license nobody has more rights than anyone else. The exception is the copyright holder (if there is only one) who can re-license the work.

There are many situations where this level playing field is useful. For example, consider it like a consortium. If you have many groups in the consortium, you want each group to contribute equally. The only way they are likely to do that is if one group doesn't get an unfair advantage.

So the downside of permissive licenses (like MIT) is that it can (in some cases) discourage cooperation. Let's say you have a library that you license with a permissive license. Your competitor may not want to contribute (publicly) to that library because they fear that you will use their changes in your proprietary code to gain advantage over them. In fact, there is an advantage to consuming permissive code and keeping your changes to yourself as long as you don't mind paying the cost of merging upstream changes.

Conversely, there are times when a permissive license is more appropriate/beneficial. In some cases, there is no real risk that others will "horde changes". For example, if you are the author of a programming language, it is in everybody's best interest to continue to develop it. Nobody really gets any advantage by making their own proprietary Ruby implementation, for instance.

People should think very seriously about which free software license they choose, because it makes a difference. Permissive licenses lower the barrier to entry, but potentially create one-sided advantages for some players. Share-alike licenses ensure that everybody is working with from the same place, but makes the barrier to entry higher.

Generally speaking, if you look at the free software ecosystem, you will see natural divisions. Software that creates an entire application (like a word processor, or image editor, etc) tends to use a share-alike license. They do not want someone to take their work, add some proprietary icing to it and take mind-share from their project. On the other side are development tools and libraries which tend to use permissive licenses. Nobody benefits from making proprietary versions of these things. Even if some tries to do so, nobody will be interested in it.

There are people who feel that ensuring everybody has the same opportunities is morally a better choice. Obviously some people disagree, but I often find it surprising that the two sides can't at least understand the other's point of view.

[joesmo]

Very well thought out. Yes, recommending one type of license for all open source projects is naive. Frameworks and libraries need a different type of license than 'application' type projects. If it's not a MIT/BSD or something similarly permissive, these types of projects will generally not get used as much. I need to be able to modify these things at will, without ever having to think about licenses, especially in the case of bugs or problems that I cannot wait for the community to solve (if they're even going in the direction I am). If I'm going to distribute copies of my app, the license choice becomes one of the definitive criteria points in my choice of framework or library. For 'apps,' it's a much less critical choice and it makes sense to have a license that encourages collaboration.

[ArneBab]

why do you need anyone to agree with your changes with a copyleft library?

[joesmo]

I don't, but I also don't want to release all the code for my app upon distribution simply because it employs a copyleft library.

EDIT: copyleft library that I've modified.

[TuringTest]

The whole justification for share-alike (as opposed to permissive) licensing is traced back to the UNIX wars, where uncertain copyright attribution was a huge hindrance to developers and a source of commercial wars battled through litigation.

Share-alike protects against such fragmentation, allowing any developer to always take any improvements made to a different branch and merge it back to your version; with MIT licenses, that is often not an option.

A modern paradigmatic example is KHTML, the LGPL rendering engine that was the basis for Safari. Without the share-alike, it's uncertain that Apple would have released Webkit, and it would have been almost certainly impossible for Google to fork it as Blink - most improvements would have been unavailable to the public, with Apple using hidden changes as a competitive advantage.

[gsnedders]

> Without the share-alike, it's uncertain that Apple would have released Webkit, and it would have been almost certainly impossible for Google to fork it as Blink - most improvements would have been unavailable to the public, with Apple using hidden changes as a competitive advantage.

Hmm. They may well have eventually released it — WebKit did eventually get released (years after the code dumps of WebCore an JavaScriptCore).

[TuringTest]

Yes, maybe they would have released it, just like they released modified parts of FreeBSD. But the share-alike makes it less likely that they keep the best parts hidden, and more likely that there's a single reference implementation where improvements from competitors are kept close to one another.

[ArneBab]

WebKit did get released after the KDE developers attacked Apple for violating the license of KHTML.

[gsnedders]

Violating it? When did they ever do that, or get attacked for it?

They got complaints for just having code-dumps (or WebCore/JavaScriptCore) alongside releases, which made it hard to have any sort of individual patches. They were still in no way obliged to move to developing it in public, nor were they obliged to release WebKit.