It does include a special exception not requiring source code release of combined worked, but still I agree that having it be LGPLv3 even with the exception will hurt its adoption with the wider Go community. The vast majority of widely used 3rd party Go libraries just use the standard Go license here:
Using that license just leaves things totally clear and unambiguous, if you're using the language you must already be okay with the license. I've worked with a number of companies that just don't want to touch anything *GPL with a 10 foot pole in Go where static linking is non-optional other than over a CGO bridge (which makes Qt's own LGPL usage palatable). This may be a sticking point for them even with the exception (just because of the extra work required in getting legal clearance, not because the license as written actually harms them).
License aside, this is a pretty great library and this is what I think is the most practical solution to providing a cross-platform GUI solution for Go in that it puts all the heavy lifting of platform independence on Qt without having to expose the entire large Qt API to Go via wrappers.
I was actually working on something like this a few months ago (mentioned in HN comment: https://news.ycombinator.com/item?id=6055043) but got side-tracked due to serving jury duty on a 6 week trial (ugh). This solution is a lot further along and benefits greatly from Go 1.2 support of compiling cpp files in CGO (mine was being written against Go 1.1 and required an extra intermediate static library build step). I may possibly continue working on mine anyway just to side-step the licensing issue altogether (which, again, I think is more of a perception problem than an actual practical problem, but still a problem).
Although I respect whatever decision you make, please note that there's absolutely nothing I could use as an argument for a license change there, other than "George will work on something else if we don't change it.", which is pretty hard to sell. If you do have valid arguments, please mail me with them so we can have a more focused conversation on actual issues.
And by the way, Qt is also LGPL, so not wanting to link with LGPL software when working on linking with LGPL software is also a curious choice.
To be honest, I probably don't have a better argument than what was already presented because I don't think LGPLv3 with the exception already given is a real practical problem, it is just a problem of companies not wanting to deal with uncertainty. I've run into this quite a bit in the real world, particularly with companies burned by using LGPL on iOS.
Go presents a similar issue to the iOS one in that dynamic linking of Go code to Go code is not an option (at least not without using gccgo), but it is easy to explain this away when using CGO linked code like Qt itself which lives in its own .so/.DLLs because they already understand that the dynamic link barrier shields them from the LGPL issues. But getting them to use Go code with LGPLv3 with exception that will statically link with their own Go code requires some direct involvement from legal/IP to "okay" it. Which could range from being a minor annoyance to a showstopper depending upon the company, in my experience.
If you know about someone that is actively trying to use it and cannot because it is LGPLv3, please ask them to mail me with more details. I'll be happy to go over the perceived issues with the legal team.
Cheers, it doesn't affect me personally - I just know from experience that some companies are vehemently anti-(L)GPLv3. It doesn't help that FUD is spread about it from both in and outside the FOSS community.
> "As a special exception to the GNU Lesser General Public License version 3
("LGPL3"), the copyright holders of this Library give you permission to
convey to a third party a Combined Work that links statically or dynamically
to this Library without providing any Minimal Corresponding Source or
Minimal Application Code"
I'm not sure if there are any other issues with using LGPLv3?
