[Haskell-cafe] GPL License of H-Matrix and prelude numeric
ketil at malde.org
Thu Jan 27 09:23:37 CET 2011
Chris Smith <cdsmith at gmail.com> writes:
>> I disagree, I've always interpreted the license to cover the text in
>> that particular package.
> There seems to be a difference in focus here that's confusing to me.
> When I write a library, my primary concern is generally with helping
> others use that library
I'm not saying it's a bad idea to echo the licensing of dependencies,
say for a library that wraps an underlying C-library. But there could
be valid reasons for not doing it.
> As a result, if I were to write a package that depends on
> someone else's GPLed library, I don't see it being anywhere near worth
> the conceptual weight to apply a different license to the source code in
> the current package; since ultimately, the terms of the GPL are going to
> apply to anyone who builds a program with the library anyway.
What if the library depends on proprietary code? Maybe you want to make
the code available for educational purposes, or porting to
non-proprietary alternatives? What if you write a database access
library which links against various backends - just because one of the
backends has restriction (GPL, say), you may want to use a liberal
license so that people can still use it in their proprietary project
with (say) BSD-licensed back ends.
>> At any rate we need a different way to deal with this, since the
>> license for the resulting binary can vary depending on build flags,
>> different binaries from the same package can end up having different
> The other (somewhat obvious, in my mind) possibility is to consider this
> a poor use of build flags
Well, I disagree - it's nice to be able to ./configure --without-readline
(or whatever) precisely to avoid licensing conditions that are
unacceptable to your project. The alternative is more duplication of
> I suppose this is another reason to specify upper bounds on
> dependencies. :) In this case, it's a matter of legal compatibility
> rather than technical compatibility, but it amounts to the same thing.
For most of us, technical compatibility is what's relevant, since we
typically download from Hackage and build everything from scratch, we
don't often redistribute binaries.
Linux distributions will have to audit packages a bit more carefully.
> That certainly seems like overkill. First of all, as mentioned above,
> it's confusing and unnecessary to package things in such a way that
> different licenses will apply to different pieces or build options.
We have lots of itty bitty packages with a variety of licenses, so I'm
not sure this is so easy for non-trivial projects.
> Furthermore, the example above could be greatly shortened by just saying
I'd be wary of automatically interpreting licensing issues for users.
Better to just provide the information, and let them decide whether they
have redistribution rights or not.
If I haven't seen further, it is by standing in the footprints of giants
More information about the Haskell-Cafe