"Simon Marlow"
On the other hand, I certainly don't want to discourage people from contributing because they don't like our license requirements. But things are going to get real messy if every file has its own license. Looking down the hierarchy we have at the moment, much of the existing code (from hslibs, the FFI project etc.) is either under the GHC license or is licenseless. So would it be too painful to ask that anyone who wants to contribute code under the LGPL does it in a separate part of the repository?
Maybe I haven't paid enough attention to the previous discussion about the library organisation, but what are the criteria for libraries to be in the magic set which should not use the LGPL?
I wasn't planning to separate the libraries logically (i.e. you still get all the libraries when you install GHC), only separate them physically by keeping the sources in different parts of the repository. This is I think the minimum we need to do if we have code with different licenses in the same tree. I'll do this on a lazy basis: as soon as someone comes along with LGPL code they want to contribute, we'll set up the repository.
That's certainly a good idea.
The criteria for a library to be in the "magic set" (I'm going to call it the core set for now) is nothing more than conforming to a set of guidelines that we've yet to decide on.
That's, I think, the crucial point. I am happy to define a core for which we ask to use a BSD-style license in terms of how fundamental the provided functionality is. Outside of this fundamental functionality, I am against prescribing a license (except requiring it to be "open source", as defined by the OSI). To give you an idea of what I mean by fundamental functionality. For example, the FFI libraries are fundamental. Their use should be unrestricted. A library like Edison is on the borderline. QuickCheck or HOpenGL are clearly outside of the core functionality. Cheers, Manuel