[Haskell-cafe] Hackage and Free Software

[fr33domlover]

Hello haskellers!

I would like to make a proposal regarding the license of software in Hackage.



One of the major parts of the Haskell community infrastructure in the package
database server Hackage. As far as I know - please correct me if I'm wrong -
Hackage makes no restriction on the license of packages upload to it. But as a
community working in cooperation to make good software, the Haskell community
has embraced licenses like (L)GPL, MIT and BSD, which are free software
licenses.

Actually the all-rights-reserved tag in Hackage [1] has only two packages
tagged by it - the dummy no-op project HNop, and another package whose COPYING
file contains a broken link and whose README says "BSD style license".



Software freedom is an ethical basis for collaboration on making software
that's truly good and loayl to its users, and providing them control and
freedom to access and use their computing resources.

It seems to me that the Haskell community is already enbracing this ethical
basis, but Hackage doesn't provide any guarantees and it means that you'd have
to check each package to be sure. By having that all-rights-reserved tag it
also in a way welcomes software that doesn't go by these rules - however it
seems that no packages do that even in the presence of the possibility.




I'd like to make a suggestion: have Hackage accept only packages released under
free software licenses. This is probably true for most/all packages there, but
making it official will both send a strong message to and from the community,
and provide people with the security and peace of mind, knowing their software
is free as in freedom.

It is also possible that companies use Haskell to create proprietary software
using permissive-licensed libraries and tools from Hackage. I hope this isn't
true, but even if it is, this software isn't offered by Hackage and I hope its
existence doesn't affect the community's use of Hackage and free software.



Would you consider to embrace free software officially, including in Hackage?



Thanks for reading,
waiting to hear from the community and from haskell.org maintainers,
fr33domlover



[1] http://hackage.haskell.org/packages/tag/all-rights-reserved

---
fr33domlover <http://www.rel4tion.org/people/fr33domlover>
GPG key ID: 63E5E57D (size: 4096)
GPG key fingerprint: 6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D

[Francesco Ariis]

On Sat, Feb 28, 2015 at 07:27:16PM +0200, fr33domlover wrote:
> I'd like to make a suggestion: have Hackage accept only packages
> released under free software licenses. This is probably true for
> most/all packages there, but making it official will both send a
> strong message to and from the community, and provide people with
> the security and peace of mind, knowing their software is free as
> in freedom.

I was pretty sure there was a note somewhere on hackage to only upload
software with open source licences, but alas I cannot find it now...
(maybe I am confusing myself with another package archiver?).

I agree having a "please use a licence approved by the OSI/FSF" could
prevent problems and seems a sensible choice in any case.

_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

[Mike Meyer]

On Sat, Feb 28, 2015 at 11:27 AM, fr33domlover <fr33do...@riseup.net> wrote:

> Hello haskellers!

> I'd like to make a suggestion: have Hackage accept only packages released under

> free software licenses.

Anything that excludes software that we could use, or otherwise

discourages people from making software available to the community, is

a bad idea. A restriction to OSF-approved licenses would exclude

anything released under a Creative Commons license, since the OSF

doesn't list those, which makes sense as they aren't "software

licences" per se. And your restriction of "released under a license"

would exclude public domain software - at least in countries that

recognize such a thing.

Yes, these are nits, but these are nits that could cause someone to

decide not to put software that is otherwise perfectly acceptable on

Hackage.

> Actually the all-rights-reserved tag in Hackage [1] has only two packages

> tagged by it - the dummy no-op project HNop, and another package whose COPYING

> file contains a broken link and whose README says "BSD style license".

This is a general problem on any site that offers downloads with a

license type tag. What happens if the selected license tag and the

included license have different rights? My suspicion is that if it

went to court, you could justify using it under either license,

meaning that such things are effectively dual licensed. We might make

add a statement making that explicit.

In particular, an "all-rights-reserved" tag implies that you may have

to ask someone's permission to even download the package from Hackage,

so it doesn't make a lot of sense. Given that - with the dual license

interpretation - it effectively isn't used, removing it might make

sense. Or renaming it to "other not listed" may be more appropriate.

       <mike

       

[fr33domlover]

Hello Mike,


First of all, thanks for the feedback.

On 2015-02-28

Mike Meyer <m...@mired.org> wrote:

> On Sat, Feb 28, 2015 at 11:27 AM, fr33domlover <fr33do...@riseup.net>
> wrote:
> > Hello haskellers!
> > I'd like to make a suggestion: have Hackage accept only packages released
> under
> > free software licenses.
>
> Anything that excludes software that we could use, or otherwise
> discourages people from making software available to the community, is
> a bad idea. A restriction to OSF-approved licenses would exclude
> anything released under a Creative Commons license, since the OSF
> doesn't list those, which makes sense as they aren't "software
> licences" per se. And your restriction of "released under a license"
> would exclude public domain software - at least in countries that
> recognize such a thing.

As to creative commons - indeed they aren't meant for software (maybe except
for CC0, which is basically like public domain). But I also don't think people
want to use them once they see the problem: If you want it permissive, you have
Apache for example (also BSD/MIT), and if you want copyleft you have GPL (also
AGPL, etc.).

As to public domain: It's actually just fine! It's true than most countries
recognize lack of license as "all rights reserved", but I also think it's a
very small and trivial task for a maintainer to add a few license lines to
state that the software should be globally treated as public domain.

So public domain software is just fine, free software.

In some websites it's common to publish code snippets under Creative Commons -
if I'm not mistaken StackOverflow is like this - but Hackage is a package
database and not a snippet manager, so the snippet situation is probably
irrelevant, I hope.

> Yes, these are nits, but these are nits that could cause someone to
> decide not to put software that is otherwise perfectly acceptable on
> Hackage.

That depends on what "acceptable" means. In the worst case you can have
separation between free and nonfree software by tag, and make it possible to
turn nonfree software on/off using a cabal-install commandline option.

This will allow people to upload first, and then think and understand the
licensing situation. Once they do, they can properly tag their project. Could
that work?

> > Actually the all-rights-reserved tag in Hackage [1] has only two packages
> > tagged by it - the dummy no-op project HNop, and another package whose
> COPYING
> > file contains a broken link and whose README says "BSD style license".
>
> This is a general problem on any site that offers downloads with a
> license type tag. What happens if the selected license tag and the
> included license have different rights? My suspicion is that if it
> went to court, you could justify using it under either license,
> meaning that such things are effectively dual licensed. We might make
> add a statement making that explicit.
>
> In particular, an "all-rights-reserved" tag implies that you may have
> to ask someone's permission to even download the package from Hackage,
> so it doesn't make a lot of sense. Given that - with the dual license
> interpretation - it effectively isn't used, removing it might make
> sense. Or renaming it to "other not listed" may be more appropriate.

That's what I thought too when I saw all-rights-reserved.

> <mike

[Mike Meyer]

On Sat, Feb 28, 2015 at 1:43 PM, fr33domlover <fr33do...@riseup.net> wrote:

On 2015-02-28

Mike Meyer <m...@mired.org> wrote:

> > Anything that excludes software that we could use, or otherwise

> > discourages people from making software available to the community, is

> > a bad idea. A restriction to OSF-approved licenses would exclude

> > anything released under a Creative Commons license, since the OSF

> > doesn't list those, which makes sense as they aren't "software

> > licences" per se. And your restriction of "released under a license"

> > would exclude public domain software - at least in countries that

> > recognize such a thing.

> 

> As to creative commons - indeed they aren't meant for software (maybe except

> for CC0, which is basically like public domain). But I also don't think people

> want to use them once they see the problem: If you want it permissive, you have

> Apache for example (also BSD/MIT), and if you want copyleft you have GPL (also

> AGPL, etc.).

And what if I want something like the CDDL or the EPL? Those are both

licenses that the OSI says are popular.

> As to public domain: It's actually just fine! It's true than most countries

> recognize lack of license as "all rights reserved", but I also think it's a

> very small and trivial task for a maintainer to add a few license lines to

> state that the software should be globally treated as public domain.

> 

> So public domain software is just fine, free software.

You're addressing the nits, not the core issue I tried to raise:

placing restrictions on what licenses (or lack thereof) are acceptable

will discourage people from making software available via Hackage.

> > Yes, these are nits, but these are nits that could cause someone to

> > decide not to put software that is otherwise perfectly acceptable on

> > Hackage.

> That depends on what "acceptable" means. In the worst case you can have

> separation between free and nonfree software by tag, and make it possible to

> turn nonfree software on/off using a cabal-install commandline option.

> 

> This will allow people to upload first, and then think and understand the

> licensing situation. Once they do, they can properly tag their project. Could

> that work?

I don't know. I suspect that if you do that, a lot of people would

never bother tagging their packages. Would that work for you?

You also talk like free/non-free was a binary decision, when it

isn't. The OSI lists licenses that aren't compatible with the GPL -

like the aforementioned EPL and CDDL. People releasing software under

one of those will want to avoid GPL licensed software, whereas people

releasing GPL licensed software will want to avoid those licenses, but

they are all free.

Or I may not care. If I build a binary that uses one package that's

GPL-licensed and one that uses an incompatible OSI-approved license, I

can distribute my source under whatever terms I want, because my

source doesn't include source from those packages. I can build and run

binaries myself with no problems, and that may be fine. But I can't

distribute binaries because I can't satisfy both licenses

simultaneously, and that may not be acceptable.

      <mike

[Francesco Ariis]

On Sat, Feb 28, 2015 at 01:15:28PM -0600, Mike Meyer wrote:
> Anything that excludes software that we could use, or otherwise
> discourages people from making software available to the community, is
> a bad idea. A restriction to OSF-approved licenses would exclude
> anything released under a Creative Commons license, since the OSF
> doesn't list those, which makes sense as they aren't "software
> licences" per se. And your restriction of "released under a license"
> would exclude public domain software - at least in countries that
> recognize such a thing.
>
> Yes, these are nits, but these are nits that could cause someone to
> decide not to put software that is otherwise perfectly acceptable on
> Hackage.

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.

Having to pick a licence from the bazillion ones [1] approved by the
FSF or the OSI streamlines the choice and avoids licence creep with a
minimal risk of scaring the uploader away.

I must admit, as fr33domlover notes, that this problem isn't present
in hackage as now (I yet have to meet a library not licenced as GPL/
MIT/BSD3), but after finding this gem on github

<Software> may be used in commercial projects and applications
with the one-time purchase of a commercial license.

For non-commercial, personal, or open source projects and
applications, you may use <Software> under the terms of the
GPL v3 License. You may use <Software> for free.

I say: "Better safe than sorry" ;)

[1] http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses#Approvals

[Mike Meyer]

On Sat, Feb 28, 2015 at 2:59 PM, Francesco Ariis <fa...@ariis.it> 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.

[ami...@gmail.com]

IIRC hackage doesnt accept AllRightsReserved packages (or at least sdist warns about it strongly)

Tom

[Gershom B]

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 (m...@mired.org) wrote:

[fr33domlover]

Hello Mike,

I think there's some confusion here. I wan't talking about GPL compatible
licenses, but about *any* free software license!

It looks like Creative Commons licenses may apply too, in particular the
version 4 ones. CC by 4 is even GPL-compatible.


The same for EPL and CDDL! Check out this:

http://www.gnu.org/licenses/license-list.html

Both are free sofware licenses. GPL compatibility isn't the issue here :)

On Sat, 28 Feb 2015 14:18:23 -0600
Mike Meyer <m...@mired.org> wrote:

>
> And what if I want something like the CDDL or the EPL? Those are both
> licenses that the OSI says are popular.
>

The FSF approves them as well, like I said.

>
> You're addressing the nits, not the core issue I tried to raise:
> placing restrictions on what licenses (or lack thereof) are acceptable
> will discourage people from making software available via Hackage.

I don't think it will, because people are already making free software. Look at
other existing hosting services - they're *full* of free software! This is what
people are making anyway. All I suggest is to make it official, providing a
guarantee so people know each `cabal install` indeed installs only free
software.

> >
> > This will allow people to upload first, and then think and understand the
> > licensing situation. Once they do, they can properly tag their project.
> Could
> > that work?
>
> I don't know. I suspect that if you do that, a lot of people would
> never bother tagging their packages. Would that work for you?

They probably will, actually: There is a huge number of packages - I don't know
how many - which have license tags. All the license tags on Hackage except for
the all-rights-reserved one are FOSS licenses, so all of these would instantly
become available as guaranteed free software packages.

How many free software packages on Haskell don't have license tags?

> You also talk like free/non-free was a binary decision, when it
> isn't. The OSI lists licenses that aren't compatible with the GPL -
> like the aforementioned EPL and CDDL. People releasing software under
> one of those will want to avoid GPL licensed software, whereas people
> releasing GPL licensed software will want to avoid those licenses, but
> they are all free.

Indeed they are all free, and the FSF approves them officially as well. MIT,
BSD, Apache, EPL, CDDL, GPL, AGPL, LGPL... all of these are free software
licenses.

> Or I may not care. If I build a binary that uses one package that's
> GPL-licensed and one that uses an incompatible OSI-approved license, I
> can distribute my source under whatever terms I want, because my
> source doesn't include source from those packages. I can build and run
> binaries myself with no problems, and that may be fine. But I can't
> distribute binaries because I can't satisfy both licenses
> simultaneously, and that may not be acceptable.
>
> <mike

That's true, but eventually you wouldn't want to do that. I mean, if you build
some program, you'd be happy to have it packaged for distros and make binary
releases for people who don't want to build from source.

This is essentially the question I'm asking the community: do you care about
the packages being free software, allowing legal distribution of binaries?
Specifically, would you make a step forward and make it official, build-in
into Hackage?

Note that it's also okay if some people - I would volunteer for this - go over
the new releases in Hackage periodically, and make sure the licenses are okay
and fix tags if needed. This is a parallel to GNU/Linux distrbutions make sure
the software is free, fix related problems, move nonfree software into separate
repos or remove them, and so on.


-- fr33domlover

[Mike Meyer]

On Sun, Mar 1, 2015 at 3:03 AM, fr33domlover <fr33do...@riseup.net> wrote:

> Hello Mike,

> I think there's some confusion here. I wan't talking about GPL compatible

> licenses, but about *any* free software license!

According to Gershom's letter, it already does that. Or at least

"cabal check" does.

> It looks like Creative Commons licenses may apply too, in particular the

> version 4 ones. CC by 4 is even GPL-compatible.

> The same for EPL and CDDL! Check out this:

> http://www.gnu.org/licenses/license-list.HTML

> Both are free sofware licenses. GPL compatibility isn't the issue here :)

That URL gets a 404 error. However, if you look at this page:

http://www.gnu.org/licenses/license-list.HTML you'll find that the EPL

and CDDL are listed as incompatible. The CC licenses are only

mentioned as non-software licenses, and not all of them are

listed. Nuts, it's even documented that the CC licenses aren't all

compatible with each other!

https://wiki.creativecommons.org/Wiki/cc_license_compatibility

> > And what if I want something like the CDDL or the EPL? Those are both

> > licenses that the OSI says are popular.

> The FSF approves them as well, like I said.

Well, I found them on a free license list. Of course, some of those

include things like "We urge you not to use the CDDL" in them, which

hardly sounds like approval to me.

5

> > You're addressing the nits, not the core issue I tried to raise:

> > placing restrictions on what licenses (or lack thereof) are acceptable

> > will discourage people from making software available via Hackage.

> I don't think it will, because people are already making free software. Look at

> other existing hosting services - they're *full* of free software! This is what

> people are making anyway. All I suggest is to make it official, providing a

> guarantee so people know each `cabal install` indeed installs only free

> software.

As long as you're willing to accept any license that the author thinks

of as free, then it won't. But that's such a broad scope as to make

this change effectively negligible, even from my nit-picking

standpoint.

> > Or I may not care. If I build a binary that uses one package that's

> > GPL-licensed and one that uses an incompatible OSI-approved license, I

> > can distribute my source under whatever terms I want, because my

> > source doesn't include source from those packages. I can build and run

> > binaries myself with no problems, and that may be fine. But I can't

> > distribute binaries because I can't satisfy both licenses

> > simultaneously, and that may not be acceptable.

> That's true, but eventually you wouldn't want to do that. I mean, if you build

> some program, you'd be happy to have it packaged for distros and make binary

> releases for people who don't want to build from source.

Sure, I may be happy to have the binaries build and packaged for all

distros. Then again, I know there are people building software using

Haskell - and hence hackage or stackage - that aren't planning on

distributing the software in any form, so don't care about this issue.

For me personally, the FreeBSD package system allows for adding things

that have to be built from source for some reason or another, and make

building them as easy as installing the binaries. I'm happy providing

FreeBSD ports, but making it possible for people building packages for

less flexible systems who actually check all the licenses involved

isn't something I'm going to spend a lot of effort on.

And you're proposed change - or possibly non-change, given what

Gershom reported - won't change that effort.  All the licenses

involved are free. However, some of them aren't compatible with each

other, so the only way to fix this is to use different packages. I

suppose I could try and get some of the authors to change their

license, but that's probably even more work.

> This is essentially the question I'm asking the community: do you care about

> the packages being free software, allowing legal distribution of binaries?

> Specifically, would you make a step forward and make it official, build-in

> into Hackage?

Except you can't answer the question "does it allow legal distribution

of binaries" by just looking at the license on the package. You also

have to consider the licenses on the transitive closure of the

libraries it uses, as they will be included in the binary, or at least

dynamically linked to it, and thus may be considered a derivative work

of the packages it includes. So your binary has to comply with the

terms of all those licenses, which may not be possible even if all the

licenses are approved by the OSI or on the FSF's list of free

licenses.

Which is also why even the relatively minor restriction "must allow

free redistribution of binaries" isn't one I'd be happy with. Sure, it

probably won't affect most people. But it equally won't help most

people who want to distribute binaries, because it only removes a

minor source of barriers to doing so.

Unless, of course, by "must allow free redistribution of binaries",

you mean "doesn't place any restrictions whatsoever on the

distribution of binaries", which would eliminate the not only many of

the CC licenses, but also the GPL and some of the BSD licenses.

    <mike

[fr33domlover]

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. But sure, a package with invalid license tagging should instantly
become unavailable.

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.

Who maintains the community hackage instance and the guidelines? Just to
make sure these people are aware of this discussion.

[Mike Meyer]

On Mon, Mar 2, 2015 at 3:36 PM, fr33domlover <fr33do...@riseup.net> 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. 

Until you've got an objective set of ethics - or a definition of "software freedom" - that everyone accepts, that's just a long-winded way of saying "arbitrary".

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.

Not quite. "OtherLicense" is an accepted license tag, and I take it to mean I can use any license I want. If you're going to place a restriction on the license types beyond "use one of our tags" (and if you disallow the otherLicense tag, then I'd say that's an arbitrary restriction), then you should either define the terms in it, or choose terms that are well defined. "free software" is so ill defined that gnu.org has to explain what they mean by "free software"  (https://www.gnu.org/philosophy/free-sw.html). They even point out that there are open source software licenses that don't meet their definition of free (https://www.gnu.org/philosophy/open-source-misses-the-point.html).  Their definition of proprietary as "not free" makes software licensed under such licenses proprietary, though that's certainly not common usage.

So just saying "only free software licenses" or "no proprietary software" would make matters worse, not better, because those terms have multiple meanings in common use. And that makes them not only arbitrary, but vague.

[fr33domlover]

On Mon, 2 Mar 2015 16:27:53 -0600
Mike Meyer <m...@mired.org> wrote:



> Until you've got an objective set of ethics - or a definition of "software
> freedom" - that everyone accepts, that's just a long-winded way of saying
> "arbitrary".

Indeed there is an objective clear definition:

http://www.gnu.org/philosophy/free-sw.html

>
> Not quite. "OtherLicense" is an accepted license tag, and I take it to mean
> I can use any license I want. If you're going to place a restriction on the
> license types beyond "use one of our tags" (and if you disallow the
> otherLicense tag, then I'd say that's an arbitrary restriction), then you
> should either define the terms in it, or choose terms that are well
> defined. "free software" is so ill defined that gnu.org has to explain what
> they mean by "free software" (https://www.gnu.org/philosophy/free-sw.html).
> They even point out that there are open source software licenses that don't
> meet their definition of free (
> https://www.gnu.org/philosophy/open-source-misses-the-point.html). Their
> definition of proprietary as "not free" makes software licensed under such
> licenses proprietary, though that's certainly not common usage.

"Open source misses the point" talks about the open source movement - it
doesn't say the BSD, MIT or Apache are not free software licenses. They are!
gnu.org provides a definition of free software, which makes it quite well
defined. There's even a list of licenses.

There is nothing arbitrary about it - in the same way the law that puts
murderers in prison isn't arbitrary. It's based on ethics: the value of human
life. Free software is similarly based on the value people's freedom to control
their computing, know what they run and be able to adapt and spread it.

> So just saying "only free software licenses" or "no proprietary software"
> would make matters worse, not better, because those terms have multiple
> meanings in common use. And that makes them not only arbitrary, but vague.

The FSF's definition is the only definition I know of. If people understand it
in a different way, this only strengthens my point: make it official and
explain the details and rules, so people do understand what free software is.
If hackage.haskell.org explains this, there will be nothing vague anymore.

[Mike Meyer]

On Tue, Mar 3, 2015 at 3:19 AM, fr33domlover <fr33do...@riseup.net> wrote:

> On Mon, 2 Mar 2015 16:27:53 -0600

> Mike Meyer <m...@mired.org> wrote:

> > Until you've got an objective set of ethics - or a definition of "software

> > freedom" - that everyone accepts, that's just a long-winded way of saying

> > "arbitrary".

> Indeed there is an objective clear definition:

> http://www.gnu.org/philosophy/free-sw.html

Applying that definition may be objective, but not everyone agrees

that it's a correct definition of free software, which makes it a

subjective definition.

> > Not quite. "OtherLicense" is an accepted license tag, and I take it to mean

> > I can use any license I want. If you're going to place a restriction on the

> > license types beyond "use one of our tags" (and if you disallow the

> > otherLicense tag, then I'd say that's an arbitrary restriction), then you

> > should either define the terms in it, or choose terms that are well

> > defined. "free software" is so ill defined that gnu.org has to explain what

> > they mean by "free software"  (https://www.gnu.org/philosophy/free-sw.html).

> > They even point out that there are open source software licenses that don't

> > meet their definition of free (

> > https://www.gnu.org/philosophy/open-source-misses-the-point.html).  Their

> > definition of proprietary as "not free" makes software licensed under such

> > licenses proprietary, though that's certainly not common usage.

> "Open source misses the point" talks about the open source movement - it

> doesn't say the BSD, MIT or Apache are not free software licenses. They are!

> gnu.org provides a definition of free software, which makes it quite well

> defined. There's even a list of licenses.

While the BSD, MIT and Apache licenses are free, the GNU license list

(https://www.gnu.org/philosophy/license-list.html#NonFreeSoftwareLicenses):

provides a long list of open source licenses that aren't free.

Some of them aren't free because they are truly noxious, some aren't

free because they are poorly written, and some aren't free because the

developers restrictions they feel are reasonable, but violate that

letter if not the spirit of that definition.

> There is nothing arbitrary about it - in the same way the law that puts

> murderers in prison isn't arbitrary. It's based on ethics: the value of human

> life. Free software is similarly based on the value people's freedom to control

> their computing, know what they run and be able to adapt and spread it.

Yes, but not everyone agrees to something you would think would be

clearcut, like the value of a human life. For instance, some cultures

feel that giving your own life for the good of your religion is the

best thing you can do with it, and think nothing of taking away some

non-believers life for that cause. And in other cultures, your life

isn't yours but the states, and you don't have the right to end it

yourself.

Since there's such broad disagreement on the value of a human life,

then it should be no surprise that people disagree on an idea as

recent as "free software". For instance, I find it a bit ironic that a

defintion of "free software" puts restrictions on derived works that

the original author doesn't have to abid by.

> > So just saying "only free software licenses" or "no proprietary software"

> > would make matters worse, not better, because those terms have multiple

> > meanings in common use. And that makes them not only arbitrary, but vague.

> The FSF's definition is the only definition I know of. If people understand it

> in a different way, this only strengthens my point: make it official and

> explain the details and rules, so people do understand what free software is.

> If hackage.haskell.org explains this, there will be nothing vague anymore.

Pointing to an external definition is certainly an acceptable way to

clear up the issue of the meaning of the phrase. However, I object to

any definition that excludes open source licenses that would otherwise

be useable under the otherLicnese tag for reasons I find capricious

(i.e - any license with a "no commercial use" clause is excluded, and

the lovely "must use for good" clause in the JSON license causes it to

be excluded).

The OSI's definition of open source doesn't have any of those

problems. How about using it: http://opensource.org/definition

   <mike

[Erik Hesselink]

On Mon, Mar 2, 2015 at 11:27 PM, Mike Meyer <m...@mired.org> wrote:
> Not quite. "OtherLicense" is an accepted license tag, and I take it to mean
> I can use any license I want.

That's not quite true, since AllRightsReserved is rejected. I think
the idea is that hackage only wants to accept licenses where people
can at least build and run that one package without any further
restrictions. It's true that this is not documented anywhere or fully
fleshed out, and it probably should be.

Erik

[Francesco Ariis]

On Sun, Mar 01, 2015 at 12:17:17AM -0500, Gershom B wrote:
> For the record, the current behaviour is as follows.
>

> [..]

>
> 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.

Thanks for the explanation Gershom. Hackage hacking is quite a mysterious
topic for me now, but I wrote a small cabal patch to encourage devs to
pick recognized free/open-source licenses.

[1] https://mail.haskell.org/pipermail/cabal-devel/2015-March/010019.html

[Marcin Mrotek]

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

[Mike Meyer]

On Tue, Mar 3, 2015 at 9:58 AM, Marcin Mrotek <marcin.j...@gmail.com> wrote:

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)

BTW, part of the tools are already available: the cabal-dependency-licenses package claims to report all your dependencies sorted by license type.

[Casey McCann]

On Tue, Mar 3, 2015 at 6:59 AM, Erik Hesselink <hess...@gmail.com> wrote:
>
> On Mon, Mar 2, 2015 at 11:27 PM, Mike Meyer <m...@mired.org> wrote:
> > Not quite. "OtherLicense" is an accepted license tag, and I take it to mean
> > I can use any license I want.
>
> That's not quite true, since AllRightsReserved is rejected. I think
> the idea is that hackage only wants to accept licenses where people
> can at least build and run that one package without any further
> restrictions. It's true that this is not documented anywhere or fully
> fleshed out, and it probably should be.

Yes, although that would require some decision or consensus on what we
expect to be able to do with code on Hackage...

My personal minimum expectation would be that anyone can always "cabal
install" anything and use it as-is without worrying about licensing.
Only when modifying code, writing code that pulls in multiple
dependencies, or uploading new code to hackage should licensing issues
really need to be considered.

For specific rules I suppose that would be something like requiring
that everything can be:
- Redistributed unmodified in source form
- Fetched and used locally with no restrictions
- Built without modification and distributed in binary form with no
restrictions beyond attribution and a link to Hackage
- Used and redistributed under the same license as any code it
contains FFI bindings to.

With all of the above taking into account the licenses of recursive
dependencies as well.

In particular, I'd personally be willing to accept code on Hackage
that restricts redistribution with modifications, but probably not any
other kind of significantly "non-free" license. I'd also be okay with
Hackage rejecting packages that can't be used/redistributed due to
conflicting licenses among its dependencies.

- C.

[Mike Meyer]

On Tue, Mar 3, 2015 at 10:31 AM, Casey McCann <c...@uptoisomorphism.net> wrote:

> Yes, although that would require some decision or consensus on what we

> expect to be able to do with code on Hackage...

> 

> My personal minimum expectation would be that anyone can always "cabal

> install" anything and use it as-is without worrying about licensing.

> Only when modifying code, writing code that pulls in multiple

> dependencies, or uploading new code to hackage should licensing issues

> really need to be considered.

I'd rather that people not have to worry about license issues when

uploading new code, either. They're trying to give the community code

to use. If they want to attach restrictions on that use, it should be

the users problem to comply with those restrictions, not the uploaders

problem. At least beyond the permissions implicit in uploading the

software in the first place, anyway.

> For specific rules I suppose that would be something like requiring

> that everything can be:

So let's go over your list and see how a few licenses stack up.

> - Redistributed unmodified in source form

Pretty much the definition of open source.

> - Fetched and used locally with no restrictions

Softare licensed under the AGPL doesn't meet this requirement.

> - Built without modification and distributed in binary form with no

> restrictions beyond attribution and a link to Hackage

Only if "without modification" means you don't use a library built

from the software in an application you are planning on

distributing. Because if you do so, then your binary is considered a

derived work, and is no different from any other modification.

If you want the ability to build a library without modification and

then distribute a binary that uses it, then all the GPL licenses but

the LGPL fail this requirement, and most licenses on the "not

compatible with the GPL" list will fail it as well because the usual

reason for incompatibility is adding restrictions to such a

distribution.

> - Used and redistributed under the same license as any code it

> contains FFI bindings to.

Well, this depends on the license that the FFI code, not the license

of the code on hackage. Those are usually the same license, but it's

not a requirement.

This touches on a problem I have with the current license

field. People may want to dual license something, or dual licensing

may be required by code they have used in it. But there's no way to

indicate dual licensing except to pick otherLicense and then document

it a such. For instance, if you incorporate MPL and GPL code, the

resulting code should be dual licensed. It'd be nice if the license

field in a cabal file could be a list for these cases.

>  In particular, I'd personally be willing to accept code on Hackage

> that restricts redistribution with modifications, but probably not any

> other kind of significantly "non-free" license. I'd also be okay with

> Hackage rejecting packages that can't be used/redistributed due to

> conflicting licenses among its dependencies.

The dependency licensing only kicks in on redistribution if you're

distributing binaries. Redistributing source doesn't include any form

of the dependencies, so their licenses don't matter. An inability to

redistribute binaries because of depencency licenses doesn't bother me

much, so long as I can still use them. If I want to redistribute such

binaries, then I have a number of options. But that should be my

problem, and not something that should impact people who don't want to

distribute binaries by, for instance, having the software not be

available on Hackage.

[Francesco Ariis]

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.

[Duncan Coutts]

All,

Hackage has of course always been for open source Haskell software (and
has always rejected "AllRightsReserved" packages).

Prompted by this recent discussion, Gershom, SPJ, and the hackage admins
have come up with a few changes to make our current implicit open source
policy a bit more explicit:

* The hackage homepage will say "Hackage is the Haskell
community's central package archive of open source software."
* The signup and upload pages will have a new blurb on open source
licenses. See below.
* We will accept a patch along the lines of
https://mail.haskell.org/pipermail/cabal-devel/2015-March/010019.html to continue to reject "AllRightsReserved" on hackage (though we may move the check from cabal into hackage).
* And on a somewhat related topic: we will finish the discussion
on hackage trustee guidelines (mostly about editing package
metadata) and post them.

https://github.com/haskell/hackage-server/commit/66a7acd125d486e55bb6674358959860efc3c3a5


Here's the new blurb:

Open source licenses

The code and other material you upload and distribute via this
site must be under an open source license. This is a service
operated for the benefit of the community and that is our
policy. It is also so that we can operate the service in
compliance with copyright laws.

The hackage operators do not want to be in the business of
making judgements on what is and is not a valid open source
license, but we retain the right to remove packages that are not
under licenses that are open source in spirit, or that conflict
with our ability to operate this service. (If you want advice,
see the ones Cabal recommends.)

The hackage operators do not need and are not asking for any
rights beyond those granted by the open source license you
choose to use. All normal open source licenses grant enough
rights to be able to operate this service.

In particular, we expect as a consequence of the license that:

1. we have the right to distribute what you have uploaded
to other people
2. we have the right to distribute certain derivatives and
format conversions, including but not limited to:
* documentation derived from the package
* alternative presentations and formats of code
(e.g. html markup)
* excerpts and presentation of package metadata
* modified versions of package metadata

Please make sure that you comply with the license of all code
and other material that you upload. For example, check that your
tarball includes the license files of any 3rd party code that
you include.

We hope this will be uncontroversial as it is just the status quo.

Note that the hackage admins are not getting involved in a license
debate, and we are not asking for any grant of rights (implicitly or
explicitly) when you upload stuff. The open source license you use
grants all the rights we need to be able to run the site.

Duncan

[Aaron Wolf]

I'd rather that people not have to worry about license issues when

uploading new code, either. They're trying to give the community code

to use. If they want to attach restrictions on that use, it should be

the users problem to comply with those restrictions, not the uploaders

problem. At least beyond the permissions implicit in uploading the

software in the first place, anyway.

If people can upload code under whatever license without hesitation and then users are left to worry about whether it is a free/open license, that presents a prohibitive burden and potential legal traps.
 .

> - Redistributed unmodified in source form

Pretty much the definition of open source.

No, the definition of Open Source is more specific http://opensource.org/osd

It requires not merely source-available but that the source is actually able to be used, modified, redistributed etc. — simply publishing source doesn't make it Open Source.
 

> - Fetched and used locally with no restrictions

Softare licensed under the AGPL doesn't meet this requirement.

AGPL doesn't restrict anyone from using the software locally. It does meet that requirement just fine.

 

If you want the ability to build a library without modification and

then distribute a binary that uses it, then all the GPL licenses but

the LGPL fail this requirement, and most licenses on the "not

compatible with the GPL" list will fail it as well because the usual

reason for incompatibility is adding restrictions to such a

distribution.

That reading isn't right. The incidental issue of license incompatibility is no more a restriction than "this software won't run on ARM processors" or any other sort of limitation that wasn't explicitly part of the license. The fact that two licenses are incompatible isn't itself the license imposing a restriction.

Anyway, software based on GPL libraries can be distributed without source, you just need to make source available under GPL upon request of anyone you distribute to.