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.
Tom
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 (m...@mired.org) wrote:
On 2015-02-28
Mike Meyer <m...@mired.org> wrote:
>
> 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.
The restrictions aren't arbitrary at all. They're based on ethics. On Software
freedom.
Here's a suggestion: We can talk about this forever, because there seem to be
no official guidelines to really discuss. Why don't we put clear guidelines at
hackage.haskell.org ? If these guidelines would be "proprietary software
allowed", then there's a point to discuss. But if the guideline requires
certain tagging - currently all the license tags except all-rights-reserved are
free software licenses - maybe the problem is already solved.
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)
I'd rather that people not have to worry about license issues whenuploading new code, either. They're trying to give the community codeto use. If they want to attach restrictions on that use, it should bethe users problem to comply with those restrictions, not the uploadersproblem. At least beyond the permissions implicit in uploading thesoftware in the first place, anyway.
> - Redistributed unmodified in source formPretty much the definition of open source.
> - Fetched and used locally with no restrictionsSoftare licensed under the AGPL doesn't meet this requirement.
If you want the ability to build a library without modification andthen distribute a binary that uses it, then all the GPL licenses butthe LGPL fail this requirement, and most licenses on the "notcompatible with the GPL" list will fail it as well because the usualreason for incompatibility is adding restrictions to such adistribution.