magnus:

Don Stewart wrote:

...

malcolm.wallace:

...

...

As a Haskell Platform user, I really need the assurance that the licensing situation is straightforward - especially if I'm to promote Haskell at work :-)

My vote would be that non-BSD/MIT license automatically excludes a library from inclusion, even though it would exclude my own project. I wonder if it would be possible to split the Haskell Platform into two parts, platform-BSD and platform-LGPL? The LGPL packages could depend on packages from platform-BSD, but not the other way around. This would guarantee at least one aspect of licence compliance, whilst also making it clear to proprietary users that if they want to avoid the guarantee of freedom, they can simply avoid installing platform-LGPL.

As an aside: are you aware of the problems using LGPL in the context of GHC statically linking libraries by default (in that they degenerate to GPL, or require significant extra workaround).

I'm concerned the burden for satisfying the LGPL while GHC statically links Haskell libraries is too great to impose.

AFAIU the burden remains even when GHC supports dynamic linking of Haskell libraries. The goal of introducing dynamic lib support is sharing of code in system memory, the goal _isn't_ to allow upgrading libraries independently of the executables using them.

I would appreciate input from the HaXml and HDBC authors (our most popular LGPL-licensed Haskell libraries) about what they feel the licensing issues/constraints should be for the Haskell Platform. Here for example, is how we satisfy LGPL with the C library GMP, which is often statically linked, http://haskell.forkio.com/gmpwindows I've not yet seen anyone publish something on how to satisfy LGPL for Haskell libraries. -- Don

On Aug 5, 2009, at 10:16, Malcolm Wallace wrote:

On 4 Aug 2009, at 23:05, Don Stewart wrote:

...

I would appreciate input from the HaXml and HDBC authors (our most popular LGPL-licensed Haskell libraries) about what they feel the licensing issues/constraints should be for the Haskell Platform.

Licensing clarity is important for users I think. But equally some users may desire to use LGPL libraries too. Hence my suggestion that there be a separate platform of free/LGPL code (and GPL tools), which can depend on the proprietary-friendly BSD-licensed platform, but not the other way round.

...

I've not yet seen anyone publish something on how to satisfy LGPL for Haskell libraries.

The static-linking exception is the commonest means of working around ghc's technical limitations here. The exception is part of wxHaskell's license (but not Gtk2hs's), and HaXml (+polyparse on which it depends) has the exception too.

I don't think it would be much of a problem to weaken the license of Gtk2Hs to a BSD license. The underlying Gtk+ C library is, of course, LGPL but the C library can be linked in dynamically. Axel.

On Aug 5, 2009, at 15:44, Malcolm Wallace wrote:

...

I don't think it would be much of a problem to weaken the license of Gtk2Hs to a BSD license.

Don't forget you would need to obtain the consent of all contributors, whose patches are also under the LGPL.

True, but if I propose a discussion period on our mailing list during which people can object, then I think that would be sufficient. Axel.

Simon Marlow wrote:

On 05/08/2009 14:58, Axel Simon wrote:

...

On Aug 5, 2009, at 15:44, Malcolm Wallace wrote:

...

...

I don't think it would be much of a problem to weaken the license of Gtk2Hs to a BSD license.

Don't forget you would need to obtain the consent of all contributors, whose patches are also under the LGPL.

True, but if I propose a discussion period on our mailing list during which people can object, then I think that would be sufficient.

I think strictly speaking you have to get explicit consent, rather than the absence of objection.

which GHC and the other BSD-components don't technically get, but it's strongly implied by submitting a patch. Similar for LGPL+exception (technically a contributor would be allowed to distribute a patch under just LGPL, or just GPL, or even GPL-2-only or GPL-3-only if they were silly). Socially, patches are generally assumed to be the same as the source license... Can we get a list of all the Gtk2Hs code-contributors? (in which if a person only ever submitted less than a dozen lines of significant patches, it's probably not copyright significant) Also, does anyone here have an argument against trying to relicense? (and is it allowed, or is Gtk2Hs a "derivative work" of Gtk+ even when distributed separately?... I think it *ought* to be allowed in this particular circumstance, it wouldn't hardly be against the spirit of LGPL since Gtk2Hs is mainly simply a binding, but I'm not a lawyer :-) -Isaac

On Wed, 2009-08-05 at 15:37 +0200, Axel Simon wrote:

On Aug 5, 2009, at 10:16, Malcolm Wallace wrote:

...

On 4 Aug 2009, at 23:05, Don Stewart wrote:

...

I would appreciate input from the HaXml and HDBC authors (our most popular LGPL-licensed Haskell libraries) about what they feel the licensing issues/constraints should be for the Haskell Platform.

Licensing clarity is important for users I think. But equally some users may desire to use LGPL libraries too. Hence my suggestion that there be a separate platform of free/LGPL code (and GPL tools), which can depend on the proprietary-friendly BSD-licensed platform, but not the other way round.

...

I've not yet seen anyone publish something on how to satisfy LGPL for Haskell libraries.

The static-linking exception is the commonest means of working around ghc's technical limitations here. The exception is part of wxHaskell's license (but not Gtk2hs's), and HaXml (+polyparse on which it depends) has the exception too.

I don't think it would be much of a problem to weaken the license of Gtk2Hs to a BSD license. The underlying Gtk+ C library is, of course, LGPL but the C library can be linked in dynamically.

I think it'd probably be sufficient to use a static linking exception, like many other libs do. I don't think it's necessary to go all the way for a BSD license (unless it turns out that the community as a whole decides that the whole HP must be BSD and that LGPL with linking exception is not enough). Duncan

malcolm.wallace:

On 4 Aug 2009, at 23:05, Don Stewart wrote:

...

I would appreciate input from the HaXml and HDBC authors (our most popular LGPL-licensed Haskell libraries) about what they feel the licensing issues/constraints should be for the Haskell Platform.

Licensing clarity is important for users I think. But equally some users may desire to use LGPL libraries too. Hence my suggestion that there be a separate platform of free/LGPL code (and GPL tools), which can depend on the proprietary-friendly BSD-licensed platform, but not the other way round.

...

I've not yet seen anyone publish something on how to satisfy LGPL for Haskell libraries.

The static-linking exception is the commonest means of working around ghc's technical limitations here. The exception is part of wxHaskell's license (but not Gtk2hs's), and HaXml (+polyparse on which it depends) has the exception too.

Ok. That's good to know. Perhaps in the cabal file for haxml you could modify it to be license: Other than, and state somewhere that it is LGPL with static linking exception. Regarding a separate LGPL "non-free" platform, that will have to happen further down the line. -- Don

Don Stewart wrote:

I would appreciate input from the HaXml and HDBC authors (our most popular LGPL-licensed Haskell libraries) about what they feel the licensing issues/constraints should be for the Haskell Platform.

I would be happy to put a static linking exemption into the COPYRIGHT file for all of my LGPL libraries. My intent with using LGPL instead of BSD is not to pollute end users' work or other libraries they use, but rather to keep the LGPL'd library free and open since I am giving out it in a free and open way. That is, I don't want someone to take my LGPL'd library, make it closed source, and sell copies of the library... if they want to sell a different product that happens to use a database and keep it closed source, that's fine with me. Perhaps the community could come up with a standard boilerplate static linking exemption that we could all use? -- John

On 5 Aug 2009, at 21:15, Don Stewart wrote:

The Library is distributed under the terms of the GNU Library General Public License version 2 (included below).

As a special exception to the Q Public Licence, ** you may develop application programs, reusable components and other software items that link with the original or modified versions of the Compiler and are not made available to the general public, without any of the additional requirements listed in clause 6c of the Q Public licence. **

That excerpt is highly confusing. Which is it? LGPL or QPL? In fact, the license of the _compiler_ is QPL, and of the _library_ is LGPL. The compiler has an exception to the QPL, and the library has an exception to the LGPL. The LGPL exception is: As a special exception to the GNU Library General Public License, you may link, statically or dynamically, a "work that uses the Library" with a publicly distributed version of the Library to produce an executable file containing portions of the Library, and distribute that executable file under terms of your choice, without any of the additional requirements listed in clause 6 of the GNU Library General Public License. By "a publicly distributed version of the Library", we mean either the unmodified Library as distributed by INRIA, or a modified version of the Library that is distributed under the conditions defined in clause 3 of the GNU Library General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Library General Public License. Regards, Malcolm

On 06/08/2009 10:26, Malcolm Wallace wrote:

...

Perhaps the community could come up with a standard boilerplate static linking exemption that we could all use?

HaXml uses:

As a relaxation of clause 6 of the LGPL, the copyright holders of this library give permission to use, copy, link, modify, and distribute, binary-only object-code versions of an executable linked with the original unmodified Library, without requiring the supply of any mechanism to modify or replace the Library and relink (clauses 6a, 6b, 6c, 6d, 6e), provided that all the other terms of clause 6 are complied with.

What's the reasoning for dropping 6a-e, but retaining "provided that all the other terms of clause 6 are complied with"? That leaves, amongst other things: ------------ For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. ------------ So I don't think I understand how to comply with this. What "data and utility programs" must I supply with a work that uses the library? And why? The licensee is absolved from having to supply the executable in a way that it can be re-linked with a modified library, so what is the purpose of this part of the license? The other LGPL exception you quoted (from OCaml?) omits the whole of clause 6, which seems a lot simpler. Cheers, Simon

On 06/08/2009 12:45, Malcolm Wallace wrote:

On 6 Aug 2009, at 11:28, Simon Marlow wrote:

...

What's the reasoning for dropping 6a-e, but retaining "provided that all the other terms of clause 6 are complied with"?

The specific para you quote starts "For an executable", and we are talking about libraries here, so it is inapplicable.

No, not at all - the licensee of the library is the person statically linking the library into their executable and distributing it. The license specifically governs their obligations. So what is required in that case? Suppose I want to distribute an executable statically linked with HaXml, what do I have to do to comply with clause 6?

...

The other LGPL exception you quoted (from OCaml?) omits the whole of clause 6, which seems a lot simpler.

Clause 6 also includes the following terms, which you did not quote, and which I think are highly pertinent to retain: As an exception to the Sections above, you may also compile or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License.

Granted, it looks like you do want that bit. Cheers, Simon

On 06/08/2009 15:18, Malcolm Wallace wrote:

...

No, not at all - the licensee of the library is the person statically linking the library into their executable and distributing it. The license specifically governs their obligations.

Oh, my mistake, yes you are right. However I believe the whole para is just a clarification of 6(a).

...

Suppose I want to distribute an executable statically linked with HaXml, what do I have to do to comply with clause 6?

My reading of the phrase "any data and utility programs needed for reproducing the executable from it" is that you may not attempt to get round the requirements of the license by providing the proprietary parts of your software in a format that requires the use of special tools (like a linker) that are not otherwise freely available. This might also be intended to exclude techniques like encryption, unless you supply the key etc.

So, in the specific case of HaXml, there is no additional burden on you.

Ok. Might it be clearer if the LGPL exception stated that this paragraph is also excluded, along with 6(a)-6(e)? Cheers, Simon

As an aside: are you aware of the problems using LGPL in the context of GHC statically linking libraries by default (in that they degenerate to GPL, or require significant extra workaround).

Given that GHC has statically linked *all* the binaries it produces against an LGPL library for at least the last 15 years, I think it is a little bit late for everyone else to start worrying about it! I am aware of the issue (and indeed use the static linking exception in all of my own LGPL-released code) but in any case, dynamic linking (by default) will soon be coming to an optimising compiler near you (or so I hear from the people who are paying for it.) Regards, Malcolm

On 05/08/2009 08:40, Magnus Therning wrote:

On Wed, Aug 5, 2009 at 8:22 AM, Malcolm Wallace wrote:

...

...

As an aside: are you aware of the problems using LGPL in the context of GHC statically linking libraries by default (in that they degenerate to GPL, or require significant extra workaround).

Given that GHC has statically linked *all* the binaries it produces against an LGPL library for at least the last 15 years, I think it is a little bit late for everyone else to start worrying about it!

Which library is that?

GMP, and only on Windows. On Unix systems we normally dynamically link to GMP, if it is availble. Cheers, Simon