
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. Maybe it's possible to use a dual license (ie. "pick one of the following licenses") scheme, but I'm not a license expert. Cheers, Simon PS. usual employer-related disclaimers apply.

On Mon, May 28, 2001 at 10:17:03AM +0100, Simon Marlow wrote:
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.
If there is an LGPLed library then you can write a new version which matches the spec and release it under the BSD license if you wish. Then in a similar way to how the implementation of a library you have may use GHC extensions (say) you could use an implementation with a BSD license. I would suggest that the specs be public domain and the compilers can chose to ship whatever version they think best. Ian

"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.

Manuel M T Chakravarty
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.
In particular, I would be unhappy to see the Hugs or GHC distributions change from being pure BSD license but I'd like to see all the major libraries come as part of the standard distribution. The "purity" aspect is as important as the choice of license - it is hard enough to understand one license but if you get a package which is covered by multiple licenses then you're pretty-much hosed. This was an issue we faced in releasing my component compiler: we wanted to release the whole thing under a BSD license but on careful inspection we found that the distribution contained emacs code covered by the GPL, a patched LaTeX library covered by the GPL, some code from the Hugs and GHC distributions (both covered by BSD but with different copyrights) and, of course, the main BSD-licensed compiler and documentation. This was really tedious and it took a long time to find a way of describing the license that conveyed the fact that 99% of the distribution and, in particular, all the tools, were BSD-licensed while a few non-essential parts were covered by more restrictive licenses. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/

Alastair David Reid
Manuel M T Chakravarty
writes: 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.
In particular, I would be unhappy to see the Hugs or GHC distributions change from being pure BSD license but I'd like to see all the major libraries come as part of the standard distribution.
When the number of libraries grows it may also be technically more feasible to seperate them into extra packages. GHC, for example, is already pretty big. For teaching purpose I want to recommend my students to install it at their machines at home, but they don't need all libraries and are happy about smaller installs. Just as an example.
The "purity" aspect is as important as the choice of license - it is hard enough to understand one license but if you get a package which is covered by multiple licenses then you're pretty-much hosed.
If it is distinct libraries where the difference lies, I don't see it as much of a problem. When you buy a Linux CD, you also get a wild mix of licenses - also with the pre-installed libraries. Still this doesn't seem to lower the popularity of Linux much. Cheers, Manuel
participants (4)
-
Alastair David Reid
-
Ian Lynagh
-
Manuel M. T. Chakravarty
-
Simon Marlow