- Libraries - Haskell.org

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

01 Jun '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 30 May '01

30 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 30 May '01

30 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

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

29 May '01

> Don't libraries need their own build system anyway if they > are to be portable? 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. > How do we want to handle libraries (eg, Gtk+Haskell) that > > * are in a different repository (Gnome repository) and/or > > * need special tools (C->Haskell)? I wasn't planning to do anything differently to the way we have it now, except that Gtk+Haskell gets allocated a place in the hierarchy. It can still be distributed separately and have a different license - and for GHC at least you'll have to give extra flags such as '-package gtk' in order to be able to import Graphics.UI.Gtk. Cheers, Simon

2 1

RE: The next step
by Manuel M. T. Chakravarty 29 May '01

29 May '01

"Steinitz, Dominic J" <Dominic.J.Steinitz(a)BritishAirways.com> wrote, > Can someone explain what licenses are commonly avaible and > what they mean or point me at some references? Here is GNU's take of the license landscape: http://www.gnu.org/philosophy/license-list.html And that of the OSI (Open Source Initiative): http://www.opensource.org/licenses/index.html Hope that helps, Manuel

1 0

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

29 May '01

Frank Atanassow writes: > Some people don't see it that way. They would say that the > GPL is the _less_ > restrictive license because it ensures that everybody > benefits (equally) from > everybody else's improvements. From that perspective, > companies benefit also > since they may use and improve the code, provided they > "publish" it. Will they > lose some potential revenue that way? Possibly. 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. So not only is a programmer working on GPL code not generating any revenue, they are potentially threatening the intellectual property that the company already owns. Better all round for them just to avoid GPL code altogether. Cheers, Simon

2 1

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

29 May '01

> -----Original Message----- > From: Steinitz, Dominic J > [mailto:Dominic.J.Steinitz@BritishAirways.com] > Sent: Monday, May 28, 2001 2:06 PM > To: Simon Marlow > Cc: chak; libraries > Subject: RE: The next step > > > Can someone explain what licenses are commonly avaible and > what they mean or point me at some references? > > Dominic. > > -------------------------------------------------------------- > ----------------------------------- > 21st century air travel http://www.britishairways.com >

1 0