On 4 November 2010 19:38, Max Bolingbroke wrote:

On 4 November 2010 08:11, Ivan Lazar Miljenovic wrote:

...

On 4 November 2010 19:04, John Smith wrote:

...

As a beginner, I'm finding HLInt (http://hackage.haskell.org/package/hlint) extremely useful for improving my code. Would it be worthwhile including this in HP?

That would require haskell-src-exts, uniplate, etc. to go into the platform as well; are _they_ ready and worth including?

HLint is an executable, so you could just statically link it to its dependencies and not install them as developer-accessible libraries. This particular reason should not be a barrier to including HLint in the platform.

Except the Platform is based on the sources, etc. ... Not everyone gets the platform as a pre-built Windows installer you know ;-) Also, don't forget the GHC now supports dynamic linking. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On 4 November 2010 08:40, Ivan Lazar Miljenovic wrote:

Except the Platform is based on the sources, etc. ...

This is not really an issue as the makefile can: 1. Install uniplate, src-exts etc into a temporary location and a temporary package list 2. Compile hint wrt. that file 3. Zap the temporary package list and temporarily installed libraries So you still get the source code for those packages in your Platform download but they never show up in "ghc-pkg list" for the user.

Also, don't forget the GHC now supports dynamic linking.

This is also not an issue with the above approach. Just build+link the "private" packages statically. It is still OK for hint to link dynamically to those packages that we intend to actually install. Cheers, Max

On 5 November 2010 09:01, Ivan Lazar Miljenovic wrote:

Ummm... I should be able to download the GHC source tarball (or generic unix binary) + the HP source tarball and be good to go from there.

I think you have misunderstood my proposal. The platform tarball could (and should!) include the source for the "private" libraries. I am only pointing out that such private libraries do not necessarily need to be installed into the system package list in the process of installing the Haskell Platform itself.

Anyway, it's official policy: http://trac.haskell.org/haskell-platform/wiki/AddingPackages#PackageRequirem...

I was not aware of this, thanks. However, the rationale states: """ It may seem that it might be possible to allow shipping packages that are somehow "not blessed" as being part of the platform, however there is currently no obvious way to make a practical distinction between "blessed" and "not blessed". """ Note that this is not true in the special case that "not blessed" packages are used only by an *executable* package. So it looks like the policy could be safely relaxed to admit this special case and hence allow HLint to be included. However, it would require a policy change and I do not know who is capable of making such changes, or if this change would be acceptable. Cheers, Max

On 5 November 2010 13:16, Ivan Lazar Miljenovic wrote:

I think it isn't technically feasible at the moment, since a library is either installed or it isn't; there's no real concept of a "build-time only" library with Cabal.

What I was wittering about earlier with package files is precisely the stuff that would let you have "build time only" dependency for HLint. Roughly (and from memory, and so certainly riddled with bugs): 1. cabal configure --package-db=/tmp/foobar.pkgconf --prefix=/tmp 2. cabal install Now your library is registered only in the foobar.pkgconf file - i.e. not the user or global package file. You can safely rm /tmp and nothing bad will happen to GHC and the packages installed in your normal package files. So to get build time only dependencies: 1. Install the public libraries into the normal package files (user or global) and the standard prefix 2. Install the private libraries into a temporary package file only (and in a suitable prefix, so you can wipe them out later on) 3. Install HLint into the temporary package file but into the normal prefix, so the user gets access to the HLint executable Job done, I think - and all with existing technology! Cheers, Max

Personally I'm neutral on the issue, but I think the Platform avoids GPL code - I can't find the policy stating as such as the Platform website doesn't seem to link to the "meta" discussions and policy.

Hlint isn't a library, right? And as an application, it presumably doesn't for any practical reason need its dependencies in the platform in order to itself be included? On Nov 7, 2010, at 13:13, Neil Mitchell wrote:

HLint is currently GPL licensed, but if that ever became an impediment to anyone doing anything with it I'd be willing to relicense it as BSD, including if that was the only thing blocking inclusion in the platform. HLint relies on cpphs and hscolour which are LGPL/GPL, which may be a problem.

On Sun, Nov 7, 2010 at 8:21 PM, Stephen Tetley wrote:

...

Personally I'm neutral on the issue, but I think the Platform avoids GPL code - I can't find the policy stating as such as the Platform website doesn't seem to link to the "meta" discussions and policy. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Nov 7, 2010, at 4:13 PM, Neil Mitchell wrote:

HLint is currently GPL licensed, but if that ever became an impediment to anyone doing anything with it I'd be willing to relicense it as BSD, including if that was the only thing blocking inclusion in the platform. HLint relies on cpphs and hscolour which are LGPL/GPL, which may be a problem.

Neil's comments indicate to me that he's willing to do some work to get HLint platform ready. While I don't use HLint, I think it would be an excellent addition to the beginner Haskell experience, and give its inclusion as a core developer tool an enthusiastic +1. I would like to propose haskell-src-exts for inclusion into the platform along with HLint. It's an excellent package, well tested, and maintained, which provides a core service for anybody interested in DSLs, metaprogramming, or providing developer tools. At a (near) future point, we could then discuss removing haskell-src from the platform. Uniplate and hscolour are also very good packages, but the former is one of many generics solutions, and the latter is rather special purpose. As such, I don't necessarily want to propose them for the platform at this time. But if there's not a straightforward way to coax cabal into installing the binary without the libraries, then there's always the sledgehammer solution of periodically pulling their repos into the HLint source tree. Speaking of excellent developer tools produced by Neil, we should consider hoogle for platform inclusion as well. Along with uniplate, hoogle also depends on safe. I don't know how others feel, but I consider safe an essential library as well, which provides a standard way to avoid the partial functions of the prelude, and think that it would also warrant platform consideration. Cheers, Sterl.

s.clover:

On Nov 7, 2010, at 4:13 PM, Neil Mitchell wrote:

...

HLint is currently GPL licensed, but if that ever became an impediment to anyone doing anything with it I'd be willing to relicense it as BSD, including if that was the only thing blocking inclusion in the platform. HLint relies on cpphs and hscolour which are LGPL/GPL, which may be a problem.

Neil's comments indicate to me that he's willing to do some work to get HLint platform ready. While I don't use HLint, I think it would be an excellent addition to the beginner Haskell experience, and give its inclusion as a core developer tool an enthusiastic +1.

I would like to propose haskell-src-exts for inclusion into the platform along with HLint. It's an excellent package, well tested, and maintained, which provides a core service for anybody interested in DSLs, metaprogramming, or providing developer tools. At a (near) future point, we could then discuss removing haskell-src from the platform.

I think this would make a great contribution in the January round of proposals.

Uniplate and hscolour are also very good packages, but the former is one of many generics solutions, and the latter is rather special purpose. As such, I don't necessarily want to propose them for the platform at this time. But if there's not a straightforward way to coax cabal into installing the binary without the libraries, then there's always the sledgehammer solution of periodically pulling their repos into the HLint source tree.

Hscolour is an optional dep of Haddock (but it also has a problematic license at the moment). We should think about what to do here. -- Don

On Wed, Nov 10, 2010 at 8:56 PM, Ian Lynagh wrote:

On Sun, Nov 07, 2010 at 11:41:18PM -0500, Sterling Clover wrote:

...

I would like to propose haskell-src-exts for inclusion into the platform [...] At a (near) future point, we could then discuss removing haskell-src from the platform.

(Speaking as someone entirely unfamiliar with both packages, so this may be a crazy idea), I wonder if it might be better rename haskell-src-exts to haskell-src and for this to just be a major version bump. After all, nowadays more and more "extensions" are going to be part of the language, and who would actually use haskell-src once haskell-src-exts is part of the platform?

I'm in favor. Cheers, /Niklas

Ian Lynagh wrote:

(Speaking as someone entirely unfamiliar with both packages, so this may be a crazy idea), I wonder if it might be better rename haskell-src-exts to haskell-src and for this to just be a major version bump. After all, nowadays more and more "extensions" are going to be part of the language, and who would actually use haskell-src once haskell-src-exts is part of the platform?

I am opposed to this proposal as stated. The generated syntax tree of haskell-src-exts is huge and unmanageable if all you need is core haskell, or a subset thereof. I have used haskell-src in situations where haskell-src-exts would have been so much more work as to be unusable. Also, it is very worthwhile to have code which describes exactly the syntax of standard Haskell. In fact, releasing an updated version of haskell-src should be a required step for each iteration of the Haskell Prime process. It may be true that haskell-src-exts is more commonly used and is more appropriate for inclusion in the platform. If so, perhaps some renaming is in order. But please, not at the expense of total elimination of the important haskell-src package from hackage. Thanks, Yitz

On Mon, 15 Nov 2010 16:06:57 +0000, Ian Lynagh wrote:

On Sun, Nov 14, 2010 at 12:42:52AM +0200, Yitzchak Gale wrote:

...

Ian Lynagh wrote:

...

(Speaking as someone entirely unfamiliar with both packages, so this may be a crazy idea), I wonder if it might be better rename haskell-src-exts to haskell-src and for this to just be a major version bump. After all, nowadays more and more "extensions" are going to be part of the language, and who would actually use haskell-src once haskell-src-exts is part of the platform?

I am opposed to this proposal as stated.

The generated syntax tree of haskell-src-exts is huge and unmanageable if all you need is core haskell, or a subset thereof. I have used haskell-src in situations where haskell-src-exts would have been so much more work as to be unusable.

Also, it is very worthwhile to have code which describes exactly the syntax of standard Haskell. In fact, releasing an updated version of haskell-src should be a required step for each iteration of the Haskell Prime process.

In that case we presumably should have haskell98-src (== what is now haskell-src?) haskell2010-src (doesn't currently exist?) haskell-src (== haskell-src-exts)

It isn't actually necessary to rename haskell-src-exts, but haskell-src seems to me like a better name for it. I don't have a strong opinion, anyway.

This could be different modules of the same package as well. For instance one might want to convert from an Haskell 98 source into an Haskell 2010 one, or an Haskell "With Extensions" one. my 0.02 €, -- Nicolas Pouillard http://nicolaspouillard.fr

On Tue, 2010-11-16 at 10:44 +0200, Yitzchak Gale wrote:

I wrote:

...

...

...

It may be true that haskell-src-exts is more commonly used and is more appropriate for inclusion in the platform. If so, perhaps some renaming is in order. But please, not at the expense of total elimination of the important haskell-src package from hackage.

Ian Lynagh wrote:

...

...

In that case we presumably should have haskell98-src (== what is now haskell-src?) haskell2010-src (doesn't currently exist?) haskell-src (== haskell-src-exts)

Yes, that would work.

Nicolas Pouillard wrote:

...

This could be different modules of the same package as well. For instance one might want to convert from an Haskell 98 source into an Haskell 2010 one, or an Haskell "With Extensions" one.

That would perhaps be better, but I think it would be more work in two ways: first It would be necessary to unite the packages and resolve some name-clashing issues. Then we would be left with a larger more monolithic package that would be harder to maintain.

But if you, or others, together with the current package maintainers, decide to go this route, I think it would be fine.

There's two issues here I think, one is the language in question (basic H98/2010 or H+exts) and the other is the general infrastructure. As I understand it, the current haskell-src-exts has many advantages over haskell-src even if you're just using H98. For example, last time I looked, haskell-src could not round-trip code because it forgets all brackets in infix expressions. So if we can have a single package with the sensible infrastructure and within that package have two ASTs, one for "simple" Haskell and one for "extended" Haskell then that seems like an ideal combination to me. Duncan

On Wed, Nov 17, 2010 at 10:47 PM, Yitzchak Gale wrote:

Duncan Coutts wrote:

...

So if we can have a single package with the sensible infrastructure and within that package have two ASTs, one for "simple" Haskell and one for "extended" Haskell then that seems like an ideal combination to me.

The only problem is that it will take some work to adapt haskell-src-exts to Haskell 20nn. I spoke to Niklas about this. He has in principle volunteered to take on the task, but he can't start on it for a few months. And I don't think it would be wise to make the package name changes and end-of-life the current haskell-src until this is done.

Yes, I agree with both Duncan and Yitz here. It would be some monkey work to introduce a "simple" AST, but nothing tricky in principle. I wouldn't mind adding such an AST to haskell-src-exts, and I think that's the best solution long-term. But as I'm on the final stretch of my PhD thesis work, I simply don't need more opportunities for procrastination right now, hence the "few months"... ;-)

So unless someone else can do the work, we may have to wait until the following HP release.

I believe that would be the case regardless, no actual proposal for adding haskell-src-exts has been written yet. Cheers, /Niklas

Hi,

...

The only problem is that it will take some work to adapt haskell-src-exts to Haskell 20nn. I spoke to Niklas about this. He has in principle volunteered to take on the task, but he can't start on it for a few months. And I don't think it would be wise to make the package name changes and end-of-life the current haskell-src until this is done.

Yes, I agree with both Duncan and Yitz here. It would be some monkey work to introduce a "simple" AST, but nothing tricky in principle. I wouldn't mind adding such an AST to haskell-src-exts, and I think that's the best solution long-term.

Niklas has got a lot on his plate without doing this simple AST - I've filed at least 3 bugs against his libraries in the last week! I'm not entirely sure what the intended audience is for this simple AST. Unless someone's going to use it, I don't see much point in it existing. I regularly use haskell-src-exts without caring about lots of extensions, and it just works. Having all the extensions there just means that when I do need them I don't need to switch library/module at all.

...

So unless someone else can do the work, we may have to wait until the following HP release.

I see no reason to even suggest this work be a precondition for inclusion in the platform. I use HSE more than most people, and I'd consider a simple AST to just be adding bulk. Without a compelling use case it seems you're burning the universes entropy for no good reason :-) Thanks, Neil

Hi

...

I'm not entirely sure what the intended audience is for this simple AST. Unless someone's going to use it, I don't see much point in it existing.

When you just use the AST, you can ignore the bits that you don't need. But when you need to transform it, there is no way to ignore parts of it. And that creates a huge amount of extra work and boilerplate code with the current feature-loaded AST.

If you aren't using a boilerplate removal library, and are working with haskell-src-exts, then you are very probably doing it wrong! I recommend Uniplate, but there are plenty of other options including SYB and anything with the phrase generic and Haskell in it from the last 15 years. I really cannot stress how much difference a boilerplate removal library makes. I'd also love a "Core Haskell" library, like HSE but with desugaring/type-checking/name-resolution etc. That's not what HSE does, but it is a niche that needs filling.

In addition, a high-quality parser whose AST more faithfully reflects the Haskell 20nn standard is very useful in many ways in the area of verification, validation, and certification.

Making a parser faithfully reflect the standard is not a trivial proposition, and one that I don't think anyone is actually going to check. A parser that kinda-might reflect the standard doesn't help with verification/validation/certification.

If people are absolutely keen on getting haskell-src-exts into the platform immediately with its new name, another strategy could be to rename haskell-src to haskell98-src and haskell-src-exts to haskell-src.

I always talk about HSE, so if the name changes I'll need a new acronym, and HS doesn't sound like a great choice :-) I'm happy with any name, and I don't really have an opinion about including HSE or not (it's awesome, but it being in the platform doesn't really benefit me massively, as it's so easy to install with cabal). All I care about is Niklas not using up his valuable time on a project that doesn't pay off for users. Thanks, Neil

...

If you aren't using a boilerplate removal library, and are working with haskell-src-exts, then you are very probably doing it wrong!

Oh?  Why is that?

By wrong I don't mean "incorrect results", I mean hideously ugly. Take the example of stripping out all type signatures in patterns, since you want to get rid of that extension. Without a boilerplate removal library that would take ~100 lines of code, perhaps more, and be very sensitive to which extensions your parser supported. With Uniplate I can write: import Data.Generics.Uniplate.Data removePatternSigs = transformBi f where f (PatTypeSig _ x _) = x f x = x If I didn't use Uniplate, I'd find the extra syntax extensions in HSE to be very annoying. Since I do use Uniplate, I only need to think about them when I'm working with them - so I transparently support them, and when I do need them, they're already there. I'm using Uniplate as an example since I think it's the nicest boilerplate removal library, but I'm biased, and any boilerplate removal library should be able to do similar tricks. Thanks, Neil

On 10 November 2010 18:55, Don Stewart wrote:

Libraries with non-BSD deps haven't been considered for the HP, and would be problematic, in my opinion. Applications are far less of a concern, though guaranteeing that anything in the platform can be hacked freely for any use would be a positive statement.

Yes, at some point before the next proposal round opens I'd like to propose a policy along the lines that HP packages must be usable for developing software under any reasonable license including proprietary licenses. That would allow GPL tools (e.g. gcc is GPL but is used to compile proprietary code) and allow LGPL libs but would exclude GPL libs. I expect the contentious point in such a discussion to be around LGPL libs (partly because there tends to be a great deal of unnecessary confusion around it anyway). Duncan

On Thu, Nov 11, 2010 at 1:52 PM, Malcolm Wallace wrote:

...

...

Libraries with non-BSD deps haven't been considered for the HP, and would be problematic, in my opinion.

I'd like to propose a policy along the lines that HP packages must be usable for developing software under any reasonable license including proprietary licenses.

I've been wondering whether there is any mileage in having a secondary, separate, "free" Platform, that is, containing only LGPL libraries and GPL tools.  This way, it would be much easier to ensure that BSD libraries in the standard Platform do not depend inadvertently on LGPL'd libraries.  If a Platform user wants to be unburdened from licensing worries, they can use the BSD Platform only.  If they care about software freedom, then they can overlay the LGPL/GPL Platform on top.

And what of BSD libraries in the standard Platform that (would like to) deliberately depend on LGPL'd libraries? We have a concrete example: haskell-src-exts (BSD) depends on cpphs (LGPL), not as a tool but as a library. Cheers, /Niklas

On 11 November 2010 13:29, Niklas Broberg wrote:

On Thu, Nov 11, 2010 at 1:52 PM, Malcolm Wallace wrote:

...

...

...

Libraries with non-BSD deps haven't been considered for the HP, and would be problematic, in my opinion.

I'd like to propose a policy along the lines that HP packages must be usable for developing software under any reasonable license including proprietary licenses.

I've been wondering whether there is any mileage in having a secondary, separate, "free" Platform, that is, containing only LGPL libraries and GPL tools.  This way, it would be much easier to ensure that BSD libraries in the standard Platform do not depend inadvertently on LGPL'd libraries.  If a Platform user wants to be unburdened from licensing worries, they can use the BSD Platform only.  If they care about software freedom, then they can overlay the LGPL/GPL Platform on top.

And what of BSD libraries in the standard Platform that (would like to) deliberately depend on LGPL'd libraries?

We have a concrete example: haskell-src-exts (BSD) depends on cpphs (LGPL), not as a tool but as a library.

In principle there is no problem with BSD code depending on LGPL code, just as there is no problem with LGPL code depending on BSD code. In both cases you must comply with both licences. (As a practical issue it is important to make sure users are aware that they must comply with both licenses, so the labelling is important.) Under Malcolm's proposal you'd have to move the BSD code into the other layer. Duncan

On 11/11/2010 11:07, Duncan Coutts wrote:

On 10 November 2010 18:55, Don Stewart wrote:

...

Libraries with non-BSD deps haven't been considered for the HP, and would be problematic, in my opinion. Applications are far less of a concern, though guaranteeing that anything in the platform can be hacked freely for any use would be a positive statement.

Yes, at some point before the next proposal round opens I'd like to propose a policy along the lines that HP packages must be usable for developing software under any reasonable license including proprietary licenses. That would allow GPL tools (e.g. gcc is GPL but is used to compile proprietary code) and allow LGPL libs but would exclude GPL libs. I expect the contentious point in such a discussion to be around LGPL libs (partly because there tends to be a great deal of unnecessary confusion around it anyway).

+1 But I vote against allowing LGPL libs in. For a start, wouldn't it have to be LGPL + static linking exception anyway? And exactly what form should the static linking exception take? There are already several of them floating around, some harder to understand than others. See previous thread here: http://www.haskell.org/pipermail/libraries/2009-August/012309.html Cheers, Simon

On 11/11/2010 20:29, Duncan Coutts wrote:

On 11 November 2010 14:50, Simon Marlow wrote:

...

But I vote against allowing LGPL libs in. For a start, wouldn't it have to be LGPL + static linking exception anyway?

In principle no static linking exception is required. It is possible to ship code in a relinkable form.

What you do is to compile your app to .o files, link them together into one big app.o file, then link this statically with the dependent packages to make your app.exe. Then you ship the app.exe and the app.o (or a promise to provide it). Any user can then relink the app.o to get the app.exe.

I have done this and automated it with Cabal. It would probably be useful to other people to add this feature to Cabal directly (I implemented it in a Setup.hs).

Obviously it is rather tricky to generate a modified library that has the same ABI but the LGPL makes allowance for that. The LGPL-2.1 states: "It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.". Current GHC does put us at the rather extreme end of that interpretation. Of course there is the same ABI issue with shared libs.

Right, my main objection has always been that since GHC makes it impractical to do the modify/relink that the LGPL requires, LGPL Haskell code isn't really complying with the spirit of the LGPL here. I get the impression that people who use the LGPL for Haskell don't care deeply about this - they're using the LGPL because they want modifications contributed back. In which case, wouldn't it make sense to add an exception for the modify/relink too? Are there Haskell authors out there using the LGPL who really do care about modify/relink? Cheers, Simon

On 12 November 2010 11:14, Simon Marlow wrote:

...

I get the impression that people who use the LGPL for Haskell don't care deeply about this - they're using the LGPL because they want modifications contributed back. Are there Haskell authors out there using the LGPL who really do care about modify/relink?

As someone who uses the LGPL, I can confirm that, for myself, requiring distributors to contribute back their modifications (which one *hopes* are improvements...) is the main reason for the licence choice. The ability for any end-user to modify and relink would be a "nice-to-have" in addition, but it is not crucial to me. However, I would be reluctant to give a blanket exception merely on the basis that a particular compiler has technical difficulties complying with the spirit of this requirement. There are other compilers for which this is not problematic, and like I say, the property is a "nice-to-have" - if it were possible to achieve it, I would prefer that. Having said that, I do indeed give the "static-linking" exception for many of my packages. Also, if some entity wishes to distribute my code as part of their own product, but be released from the L/GPL requirements, I am happy to offer a commercial licence. (Which in many cases will not cost any money - although I'm open to offers :-) Regards, Malcolm

On Fri, Nov 12, 2010 at 12:56:26PM +0000, Simon Marlow wrote:

Some of us have to get licenses past corporate lawyers, and they generally don't even agree about what the LGPL means.

I think this is an important point. I think the goal of the HP is to be usable by everyone, and it doesn't matter whether or not /we/ think everyone can use LGPLed libraries, because if other people aren't confident they can use them then they won't do so. Thanks Ian

since we have after all been shipping GPL tools and LGPL C libs along with ghc for some years.

Indeed. For many years, every program compiled by ghc (using libgmp to implement the unbounded Integer type) automatically fell under the terms of the LGPL. Is that still the case? Regards, Malcolm

The IHG did some work to move the GMP dependency from the RTS to a new integer-gmp package. The base library now uses this package to implement the Integer type. It is also possible to use an alternative integer package but you have to rebuild base and the rest of the world. The default remains integer-gmp.

So what you are saying is that the Haskell Platform already includes (by default, unless someone goes to unusual lengths to avoid it), an LGPL library, which no-one has (yet) objected to.

I'm pretty sure that under a strict reading we're violating the licence of the H98 and FFI reports because we do not reproduced them in their entirety.

The H'98 (pace H'2010) licence says: "The authors and publisher intend this Report to belong to the entire Haskell community, and grant permission to copy and distribute it for any purpose, provided that it is reproduced in its entirety, including this Notice. Modified versions of this Report may also be copied and distributed for any purpose, provided that the modified version is clearly presented as such, and that it does not claim to be a definition of the language Haskell 98[2010]." Distributing the source code of the H'98 (2010) libraries is indeed a failure to distribute the Report in its entirety. But as long the source code makes it clear that it does not claim to be an unmodified _definition_ of the language (or libraries?), then I think the licence permits it. Regards, Malcolm

...

"The authors and publisher intend this Report to belong to the entire Haskell community, and grant permission to copy and distribute it for any purpose, provided that it is reproduced in its entirety, including this Notice. Modified versions of this Report may also be copied and distributed for any purpose, provided that the modified version is clearly presented as such, and that it does not claim to be a definition of the language Haskell 98[2010]."

Ah, so you read the second sentence as an alternative, so you can comply by picking either the first or the second. Does that mean if we pick the second that we do not need to include the notice? :-)

It seems to me that if you distribute a modified version of the Report, but still include the notice, then you are explicitly disobeying its terms. Regards, Malcolm

On 12/11/2010 20:22, Malcolm Wallace wrote:

...

...

"The authors and publisher intend this Report to belong to the entire Haskell community, and grant permission to copy and distribute it for any purpose, provided that it is reproduced in its entirety, including this Notice. Modified versions of this Report may also be copied and distributed for any purpose, provided that the modified version is clearly presented as such, and that it does not claim to be a definition of the language Haskell 98[2010]."

Ah, so you read the second sentence as an alternative, so you can comply by picking either the first or the second. Does that mean if we pick the second that we do not need to include the notice? :-)

It seems to me that if you distribute a modified version of the Report, but still include the notice, then you are explicitly disobeying its terms.

As we well know, Engilsh is a very poor language for specifying things precisely. The intent of the license as it applies to us is pretty clear though - we have to say where we got the code from, and say that it does not constitute a definition of Haskell 98/2010. We have to include the notice in as much as it applies to downstream distributors, because they're also distributing modified versions of the report. Cheers, Simon

On 4 December 2010 00:04, Simon Marlow wrote:

On 12/11/2010 19:38, Duncan Coutts wrote:

...

On 12 November 2010 18:58, Malcolm Wallace  wrote:

...

...

since we have after all been shipping GPL tools and LGPL C libs along with ghc for some years.

Indeed.   For many years, every program compiled by ghc (using libgmp to implement the unbounded Integer type) automatically fell under the terms of the LGPL.  Is that still the case?

Yes.

Well, it's not clear that the license on GMP applies to executables that just dynamically link against it.  There is considerable disagreement on that point, AIUI.  But executables that dynamically link against GMP are in compliance with the LGPL anyway, so it doesn't really matter.

We also use system calls, and yet the Linux kernel is GPL'd...

~/src/linux/linux-2.6$ head COPYING NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not ...

On 12/11/2010 16:48, Duncan Coutts wrote:

On 12 November 2010 12:56, Simon Marlow wrote:

...

On 12/11/2010 12:12, Duncan Coutts wrote:

...

Secondly, yes I agree that people tend not to care too deeply about this. To play devil's advocate, if people don't really care then instead of saying that means we must have an exception, perhaps that means that we're ok to comply with the letter of the law but not the spirit. It is a big hassle to work out wording for an exception and get all license holders of each project to agree (I did it once with Gtk2Hs and LGPL-2.0->2.1). If people do not actually care, why bother?

Because while the authors might not care, potential users of the library might well care a lot. Some of us have to get licenses past corporate lawyers, and they generally don't even agree about what the LGPL means. The more of the LGPL we can exclude, the easier this process might be.

Avoiding all this nonsense entirely is for some people by far the easiest option, though of course I recognise the right of authors to choose whatever licensing terms they want for their work. I mainly want to ensure that there is a meaningful option for users who want or need to avoid the GPL/LGPL for whatever reasons.

Presumably you mean that users might need to re-review the LGPL in how it applies to Haskell code when compiled by GHC, since we have afterall been shipping GPL tools and LGPL C libs along with ghc for some years.

Tools are somewhat easier, and we have a way to avoid the LGPL lib (GMP) if necessary. Also, policies change over time, and new license dependencies are often subject to more scrutinee than those for software that is already being used.

So the theory is that the corporate lawyers might re-OK it for Haskell code if it's clear that the only place where Haskell might be different there is an exemption anyway. On the other hand there's the danger they'll grumble even more about license extensions written by non-lawyers.

This is true, yes - non-standard licenses might make more work, not less. Usual NAL disclaimers apply, but I imagine that an exception of the form "ignore paragraphs X--Y" ought to be unambiguous and might make the license/software usable for some people where it wasn't previously.

I know it's not trivial getting any open source code past corporate layers. I've had to go through the process myself (BSD and LGPL C and Haskell code). I've noted that our tools are not as good as they could be, e.g. in collecting all the LICENSE files of all dependencies (I've had to do it by hand). I'm sure that lots of us are regularly violating the letter of the BSD license. Galois have been working on some features to add to Cabal to help us all automate some of this (we've done one round of patch-review so far).

Yes, I like the sound of that. Cheers, Simon