Re: [Haskell-cafe] Hackage and Free Software

On Mon, Mar 2, 2015 at 3:36 PM, fr33domlover
On 2015-02-28 Mike Meyer
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.

On Mon, 2 Mar 2015 16:27:53 -0600
Mike Meyer
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.

On Mon, Mar 2, 2015 at 11:27 PM, Mike Meyer
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

On Tue, Mar 3, 2015 at 6:59 AM, Erik Hesselink
On Mon, Mar 2, 2015 at 11:27 PM, Mike Meyer
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.

On Tue, Mar 3, 2015 at 10:31 AM, Casey McCann
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.
participants (4)
-
Casey McCann
-
Erik Hesselink
-
fr33domlover
-
Mike Meyer