He's on HN, BTW: http://news.ycombinator.com/threads?id=wingo

At this point, though, for me anything that is not BSD licensed is a non-starter. I'm not that much of a license zealot for other things, but for programming languages I think it's pretty important. A lot of the value in a language comes from having lots of users (and thus libraries, support, etc...), so cutting off people who want to include it in a proprietary product seems like a bad idea.

Shh, don't tell ;)

Guile is licensed under the LGPL, by the way. In a normal dynamically-linked environment, the only restriction this imposes on you is the requirement to redistribute any modifications to Guile itself. You probably knew that, but I just wanted to be clear.

Guile has a "linking exception", explicitly permitting you to include the interpreter/compiler in a proprietary product. You do still have to release any changes to Guile itself you make, but that seems like a pro rather than con for popularity of a language, since operationally-different commercial forks with no source available are hardly the sorts of things that give a language value. The intended case, where you just embed the interpreter as-is and use it as the scripting language for your app, is perfectly fine to do from proprietary apps.

I'm just not convinced that the "proprietary fork" thing happens that often in languages to justify a license that scares people who only have a superficial understanding of it. For example, Tcl has had plenty of problems, but companies doing that was not really one of them, despite its popularity, and despite being included in a wide range of proprietary products.

The sad thing is that it is a bad business decision to not submit changes back to an open source project. If your company makes a change, the best outcome for the original project to adopt the code and assume the cost of maintaining the code. The worst (most costly) is your your company maintaining a fork. Never mind the loss of recruiting opportunities.

Agree completely: which is why I wouldn't worry about 'proprietary forks'. For almost any reasonably popular language, the community version's progress will quickly outstrip almost any company's version. If the company's smart, they'll try and stay as close as possible to the original, submitting patches and so on.

Yeah, that's a good point--- Lua is another example of an MIT/BSD-style licensed embeddable language that in practice doesn't seem to have produced proprietary forks.

I've heard about several in-house forks of Lua, but usually, they happened because companies settled on a specific version (e.g Lua 4.0) and imported it into their project. Lua's small enough that maintaining a private fork of the whole language is reasonable, though.

The only public fork of the whole language I've heard of is Metalua, though.

That used to be the case, up to Guile 1.6. Guile 1.8 is LGPLv2+, and 2.0 (next month?) is LGPLv3+.

The only (?) common license that is incompatible with LGPLv3+ is ironically GPLv2 (without +).

Oops, I missed that change. Are there practical differences between LGPL and GPL-with-linking-exception? I thought the GPL with a linking exception was more or less what the LGPL was...

Guile being LGPL allows its code to be _included_ into other LGPL software. Other than that it's the same, just a bit simpler to think about.