"Simon Marlow"
Manuel writes:
I don't think that it is a good idea to specify a license. For example, I am convinced that the (L)GPL is the better licence for the community. Incidentally, the GPL is also the license of one of the most successful free software projects ever - Linux - which is certainly also one of the, if not *the* commercially most successful free software project. So, I don't buy this GPL is bad for companies propaganda.
It's not propaganda. The fact is if any of the standard libraries use the LGPL, then some people will be prevented from using them. That's the last thing we want, right? Now you might argue from a moral standpoint that the companies that these people work for are basing their business models on intellectual property and therefore deserve everything they get, but we're not trying to do open source advocacy here, we're just trying to put together a set of libraries that everyone can use.
Depends on the library. I agree with you that the really core stuff and in particular the "language extension"-related libraries should be completely unrestricted. However, many libraries in the current hslibs and, judging from the discussion so far, many new libraries are not belonging to this core. What is the problem if they are LGPL? LGPL code can be linked into proprietary code without any problems. There is lots of proprietary code being based on code generated by gcc and linked against its C library.
Maybe it's possible to use a dual license (ie. "pick one of the following licenses") scheme, but I'm not a license expert.
It is possible. Perl does it. But why? If a license is released under the LGPL, it can be used in proprietary code. Only if the library itself is modified, modifications have to be contributed back. And, yes, if I write a library and somebody improves it and distributes the improvements[1], I want them, too. What's wrong with this? Cheers, Manuel [1] Note that if GPL or LGPL code is modified and only used in-house, there is no need to release the modifications.