For the record, the current behaviour is as follows. A package with AllRightsReserved as a license or a missing license is now rejected by “cabal check” with the following: == * The 'license' field is missing or specified as AllRightsReserved. Hackage would reject this package. == A package with an unknown license such as “Foo” is rejected with the following: == * 'license: Foo' is not a recognised license. The known licenses are: GPL, GPL-2, GPL-3, LGPL, LGPL-2.1, LGPL-3, AGPL, AGPL-3, BSD2, BSD3, MIT, MPL-2.0, Apache, Apache-2.0, PublicDomain, AllRightsReserved, OtherLicense Hackage would reject this package. == However, a package with OtherLicense is indeed accepted. It would be good to specify that we ask that OtherLicense indeed be another recognized open-source license. That said, I do not feel strongly about how much care we take to enforce this. We should definitely better document this and other elements of hackage policy, and I know discussions about that have in fact been underway. I agree that being able to filter Hackage packages on license and other considerations (say, build reports on various systems) would be a great feature. Some such improvements have been floated as GSoC projects. I would encourage those that feel strongly about such features to consider getting involved with development of the hackage server. Cheers, Gershom On February 28, 2015 at 4:29:39 PM, Mike Meyer (mwm@mired.org) wrote:

On Sat, Feb 28, 2015 at 2:59 PM, Francesco Ariis wrote:

...

Those restrictions would be, in my opinion, a good idea. Rejecting say CC-SA (CC0 is FSF approved), etc. code means rejecting licences with clear and documented problems in them, problems which would cause quite a lot of headaches down the road.

I don't have a problem if you want to do that. But by disallowing those licenses on Hackage, you've taken away *MY* ability to decide if those problems are problems for my use case.

There are open source projects that are systematically excising GPL'ed software because of the problems it shares with ShareAlike licenses. Should we disallow the GPL because some people have problems with it?

Making Hackage better to help users sort out which licenses they are willing to accept in their project - which I personally would like to do on a project-by-project basis! - is a solution to these problems. Restricting the licenses that are acceptable on Hackage to meet some arbitrary set of criteria is a knee-jerk. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Hello, Hackage accepts source packages only anyway. Why would anyone upload propertiary code and risk it being stolen? Noone uploads non-free software to Hackage, it's safe to assume noone will ever do (except perhaps as an act of trolling, and such packages could be just flat out removed), so why fix it when it isn't broken? Also, as it was already pointed out by Mike Meyer, a list of pre-approved licenses doesn't solve the problem of compatibility and permission to actually build and distribute binaries at all, and it would be better solved by providing some tools to view and check licenses of the transitive closure of dependencies of a package (which would, incidentally, make it easy to weed out non-free packages too, for anyone who desires so) Best regards, Marcin Mrotek

On Tue, Mar 03, 2015 at 04:58:10PM +0100, Marcin Mrotek wrote:

Hackage accepts source packages only anyway. Why would anyone upload propertiary code and risk it being stolen? Noone uploads non-free software to Hackage, it's safe to assume noone will ever do (except perhaps as an act of trolling, and such packages could be just flat out removed), so why fix it when it isn't broken?

As Gershom B's messages states, as now AllRightsReserved would be rejected on hackage. I agree with you nothing is broken with this behaviour and I am not trying to 'fix' it in any way!

Also, as it was already pointed out by Mike Meyer, a list of pre-approved licenses doesn't solve the problem of compatibility and permission to actually build and distribute binaries at all, and it would be better solved by providing some tools to view and check licenses of the transitive closure of dependencies of a package (which would, incidentally, make it easy to weed out non-free packages too, for anyone who desires so)

This is not about solving the dependencies problem (kudos to the person coming up with such a package), it's about asking the developer, if s/he doesn't pick a licence known by cabal, to please choose some recognised open-source licence. It seems to me a sensible and straightforward documentation of what is already happening on hackage and I fail to see how this can look controversial.