Brandon J. Van Every

Google Code tried to solve this awhile ago. From 2006..2010, you got a drop down menu of ~7..9 possible license choices. That's it. The End. No license creativity allowed. They wanted to diminish license proliferation, the kind of confusion you talk about above, and also the minor customizations to license that individual authors would get creative about. They published a justification of their policy and it was defensible, whether everyone liked it or not. But the free market of course can choose other things. I bet GitHub can come up with its own justifications if it wants to.

In 2010 Google Code loosened up and allowed a catch-all menu option, "other open source" license. So a project is steered towards 9 common licenses, thus diminishing proliferation, but projects with more specific needs aren't turned away as before. It's a reasonable piece of menu driven social engineering.

"Professional" software developers have other reasons to avoid amateur projects, not just license vagueness. So pitching license vagueness as the big reason "we're not helping you out" is disingenuous. Young people have a zillion things to learn about making an open source project worth something to others, and this is merely one of them.

When assessing a project, "did you actually release something that works?" is much higher up my list of priorities. I'm highly suspicious of any project that lives continuously out of a source repository and never makes official file releases or packages. I'm not interested in seeing if I can build your software! The vast majority of projects with that attitude, that it's my job to build the software, have lousy builds that don't work. I'm not interested in a time and effort barrier to decide whether a project is worth something; if they care that little for my time as a potential consumer or contributor, the project is probably not worth it.

No communication on a mailing list or forum is bad sign, especially if the lack of communication has gone on for years. Huge buckets of communication at the very beginning of the project is a bad sign, the "hey, let's start a mailing list!" phenomenon. Just check back later if they ever shut up and do any real work.

I am far more sympathetic to a culture of "just commit the effin' code" than not. At least it's a culture of getting things done. So it may not result in perfectly usable licenses. Maybe it'll crash and burn. The kiddies gotta learn somehow, and most open source efforts die anyways for all kinds of reasons. They'll either get back up and try again, lessons learned, or they won't.

Over the years I've run into more than a few projects that had a GPL or LGPL slapped on it. If I cared enough about the value of what they were up to, I've asked why they didn't offer a LGPL or MIT / BSD / zlib license instead. Generally I'm not interested in Copyleft restrictions and seek to diminish them, according to whatever seems reasonable for the library to do. I brace myself for a polemical response. But often enough, the developers hadn't put much thought into the license at all, and grabbed the first thing that they found talked about out in open source land.