May 2001 - Libraries - Haskell.org

RE: The next step
by Simon Marlow 03 Jun '01

03 Jun '01

> > 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. 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. I'm drafting up a proposal at the moment. Cheers, Simon

3 3

RE: The next step
by Simon Marlow 02 Jun '01

02 Jun '01

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.

4 4

RE: Draft Libraries Document
by Simon Marlow 01 Jun '01

01 Jun '01

> http://www.haskell.org/~simonmar/libraries/libraries.html has been updated, now contains descriptions of the top-level names in the hierarchy, and some text in the programming conventions section (mostly copied over from the hslibs docs). Cheers, Simon

5 4

RE: The next step
by Simon Marlow 31 May '01

31 May '01

> "Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > > > 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. > > To link your code with LGPL code, you effectively must either provide > the user with object files for your code, or arrange for the LGPL code > to be contained in a shared library (the actual requirement is that > the user be able to modify the LGPL code and obtain a version of your > program that uses these modifications). The former option is a > significant cost in terms of how annoying it is to distribute your > code. I don't know if the latter is even possible -- can all the > Haskell implementations create shared libraries? > > At any rate, while it is certainly possible to link proprietary code > with LGPL code, I wouldn't say that the combination is "without any > problems". Thanks, I wasn't aware of that particular restriction in the LGPL. And having thought about it, I don't think it is reasonable to put libraries under the standard LGPL in Haskell. Here's why: - the license requires that any program linked with the library is provided as object code that can be relinked with a modified version of the library. In order to do this with GHC, you have to compile your application with all cross-module optimisation turned off (although the license does have a cryptic sentence in section 6(a) that sounds like it might apply to this situation, but I don't know what a "definitions file" is). The LGPL also goes into some detail about when a program becomes a derived work by virtue of "including things from header files", in particular it says that inline functions may be "ten lines or less" If we translate this to mean cross-module optimisation, it essentially means that we have to turn off this optimisation or change the license to say something that makes sense for Haskell. - You can't make any local incompatible modifications to GHC and not distribute them, if you intend to link your non-free program with LGPL libs (since you have to be able to recompile modified versions of the libs and re-link to the original program). - Similarly, you can't use a non-free compiler. - You have to be able to compile your modified version of the library. That means the library can't depend on any non-free libraries, which places extra restrictions on what you can do with any BSD licensed libraries you're using, if I'm not mistaken. In a nutshell, the LGPL makes sense when (a) there is a well-defined calling convention between application and library, and (b) compilers are interchangeable. Neither of these is true for Haskell (indeed, they are becoming less true for C and C++ these days). Given these extra restrictions, I imagine that anyone producing a non-free program would have to avoid the LGPL libraries altogether. Cheers, Simon

2 1

RE: Library hierarchy, contd.
by Simon Marlow 31 May '01

31 May '01

> On Wed, May 23, 2001 at 05:43:01PM +0100, Simon Marlow wrote: > > Edison -- (opt, uses multi-param type classes) > > Prelude -- large self-contained packages should have > > Collection -- their own hierarchy? Like a > vendor branch. > > Queue -- Or should the whole Edison tree be placed > > ... -- under [Data.]Structures? > > In this particular instance, I'd like to use the Edison structures, > and I'd like them to be available in a standard place. But maybe this > just means there should be copies of some of these libraries under the > Data hierarchy. The only reason that Edison is in a subtree of its own is that no-one has "decided" what the API for the standard versions of these libraries should be. Maybe that choice will be to adopt Edison as-is, but that would rule out using these modules from NHC because of Edison's use of multi-parameter type classes. Cheers, Simon

3 2

Draft Libraries Document
by Simon Marlow 30 May '01

30 May '01

I'm drafting up a document along the lines I mentioned in my previous message. For the time being, I'll keep the latest version here: http://www.haskell.org/~simonmar/libraries/libraries.html it's pretty minimal at the moment with only a few sections containing material. Suggestions and comments on what is there already are welcome. Cheers, Simon

1 0

Re: The next step
by cwitty＠newtonlabs.com 29 May '01

29 May '01

"Manuel M. T. Chakravarty" <chak(a)cse.unsw.edu.au> writes: > 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. To link your code with LGPL code, you effectively must either provide the user with object files for your code, or arrange for the LGPL code to be contained in a shared library (the actual requirement is that the user be able to modify the LGPL code and obtain a version of your program that uses these modifications). The former option is a significant cost in terms of how annoying it is to distribute your code. I don't know if the latter is even possible -- can all the Haskell implementations create shared libraries? At any rate, while it is certainly possible to link proprietary code with LGPL code, I wouldn't say that the combination is "without any problems". Carl Witty

1 0

RE: The next step
by Simon Marlow 29 May '01

29 May '01

> > Sure, but if the code in the proprietary source ends up > looking similar > > enough to the GPL code, it might be hard to prove that it wasn't a > > derived work. This is a risk you just don't want to take if your > > business depends on keeping your sources non-free. > > This is the first time, I have heard about such a scenario > and I don't think that it is realistic. For an infringement > of copyright (rather than a patent), non-trivial amounts of > code must be basically the same. This won't happen unless > the programmer has a photographic memory or actually copies > parts of the code. Right or wrong, the L?GPL simply scares the bejeezus out of corporate types (with notable exceptions like IBM & HP). I'm not going to argue whether this is right or wrong - I'm just asking whether those who favour the LGPL could compromise slightly and make life a little easier for some of us. There's no problem with "external" libraries like Gtk+Haskell, just the libraries we're going to keep in the main repository (call it the core set or whatever, basically the libraries we're going to end up distributing with GHC). 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? Cheers, Simon

3 2

RE: The next step
by Simon Marlow 29 May '01

29 May '01

> > I imagined putting the standard libraries in a single > source repository. > > By the "standard libraries", I mean loosely speaking those libraries > > which are going to be distributed with most compilers (i.e. like the > > current hslibs setup). The libraries could have a standalone build > > system, but at least for GHC this would mean duplicating most of the > > fptools build system in the libraries tree (because we need > to support > > ways, GHCi .o files, DLLs, split object files etc. etc.), > but NHC and > > Hugs require a much more minimal build system. > > Technically, I think, it might be cleaner to have build > system for the libraries that works with all compilers, > rather than different build systems for different > compilers. The problem with this is, the Hugs & NHC guys don't want the GHC build system, and I don't want to rewrite our build system to do the same stuff it already does (and likely the Hugs & NHC guys wouldn't like the results anyway :-). We are doomed to multiple build systems I'm afraid. Cheers, Simon

2 1

RE: The next step
by Simon Marlow 29 May '01

29 May '01

> On 2001-05-28T16:14:29+0100, Simon Marlow wrote: > > As I understand it, the situation is worse than that. The mere > > existence of GPL code poses a threat to commercial software: if a > > programmer happens to read some GPL code and then goes on > to use similar > > techniques in proprietary code, the owner of the > proprietary code is in > > a legally difficult position. > > Really? I've assumed that GPL only deals with copyright, and > techniques one uses in code are matters of patents and trade secrets. Sure, but if the code in the proprietary source ends up looking similar enough to the GPL code, it might be hard to prove that it wasn't a derived work. This is a risk you just don't want to take if your business depends on keeping your sources non-free. Cheers, Simon

3 2