[Haskell-cafe] HDBC's future and request for help

[Chris Dornan]

John,

 

As far as I know it is the libraries that interface to O/S libraries that
have most value in the platform and, AFAIK, many HP libraries link to O/S
libraries (e.g., GLUT).

 

I had expected that at least the principle HDBC drivers would have to go
into the Haskell Platform with HDBC.

 

> And that is a useful point as well.  If there is a big package that
> people can use and understand once, without having to analyze licenses
> for dozens of component packages, there's value in that for sure.



> What I'm hoping the commercial people on this list could do (besides me,
> that is) is say something like "LGPL won't work for us because clause
> xxx requires us to do yyy."



I am such a commercial developer as well as soon (I hope) a Haskell Platform
maintainer. I am trying to explain my concerns. There are problematic
clauses in the LGPL (any clauses that set out conditions for making the
using system a derived work of the LGPL-licensed library) but the key point
is having, as far as possible, a single permissive license (like the BSD
license) for all of the libraries.

 

For mission-critical components all of the legal due diligence and necessary
educating of parties gets done. But it is not practical to do this for
non-essential libraries, so anything that isn't covered by a BSD or similar
license needs to be replaced for the production release.

 

> At the same time, if one of the HP maintainers says, "We want HDBC in
> the HP and all that's holding us back is the license" I think that would
> be compelling enough for me to switch it immediately.

 

It would be interesting to hear from the HP maintainers. I would expect them
to have a good handle on these issues.

 

Chris

 

 

From: John Goerzen [mailto:jgoerzen at complete.org] 
Sent: 23 February 2011 19:34
To: Chris Dornan
Cc: 'Haskell Cafe'; 'Gershom Bazerman'
Subject: Re: [Haskell-cafe] HDBC's future and request for help

 

On 02/23/2011 11:57 AM, Chris Dornan wrote:
> Thanks John,
>
> I think this is a valuable discussion.
>
> The compromise you propose wouldn't address the main point - the fear
> and aversion of using (L)GPL IP in proprietary IP.

Is that fear well-grounded or not?  If not, then people should be
educated.  If so, then let's see what we can do about it -- either add
exceptions or relicense.  I don't really think that this community
should choose licenses based upon whether or not third parties hold an
irrational fear of them.

> For me the key phrase in your email was the final one - 'if my reading
> is correct'. Everywhere I would take advantage of this modified license
> I will need to get the lawyers of the people owning the host IP to agree
> to this interpretation.

This is no different than with any other license, but could even be made
more explicit.  In the end, we are (mostly) a community of non-lawyers
here so such disclaimers

I also don't think that we ought to cater to people who are afraid to
read licenses.  Those are the people that tend to do things like pirate
busybox and the Linux kernel for proprietary purposes.

> I have checked all of the packages in the Haskell Platform and they are
> all BSD3. If it had been otherwise it would have destroyed a significant
> part of the value of the HP - clear and straightforward licensing
> implications for using it.

And that is a useful point as well.  If there is a big package that
people can use and understand once, without having to analyze licenses
for dozens of component packages, there's value in that for sure.

There are two ways to accomplish that.  One is to insist that everything
use the same license.  The other is to establish standards for what kind
of licensing terms are acceptable.  An example of the latter is the
Debian Free Software Guidelines,
http://www.debian.org/social_contract#guidelines

We could propose a guideline for things that go in the Haskell Platform,
and it could be such as this:

* All licenses must meet the terms of the Debian Free Software
Guidelines (DFSG), and must also meet the following terms:

* Proprietary applications may use and link with unmodified versions of
libraries without forcing the rest of the application to use a specific
license

* Licenses may require proprietary applications that use and link with
modified versions of libraries to make source code to the modifications
available to the community under the original library's license, but may
not require applications to do so for other code linked to the application

* Licenses may require copyright and/or warranty disclaimers to be
carried with applications that use the code.

Perhaps we could also list example copyright/license statements that
meet the requirements.

> I really don't want to plough work into a package that can't be bundled
> with the HP, the natural home for strategically-important high-quality
> libraries.

I'm not certain the HP is a good home for HDBC.  One could put HDBC
itself in there, but it's useless without a database backend.  All of
those, do date, require a C binding which probably makes them poor
candidates for the HP.  If the thing in the platform is useless without
the backend driver, is it sensible to put it in the HP?

At the same time, if one of the HP maintainers says, "We want HDBC in
the HP and all that's holding us back is the license" I think that would
be compelling enough for me to switch it immediately.

> Turning this around, it is going to be much easier to get people who are
> using Haskell in commercial contexts to contribute to HDBC if it has a
> license that meets their requirements.

Quite so.  I want to make sure we do that.  That's one reason I have
kept the door to the BSD license open.  As I've said, I've relicensed
other code under BSD in the past and may be convinced to do it again.
What I'm hoping the commercial people on this list could do (besides me,
that is) is say something like "LGPL won't work for us because clause
xxx requires us to do yyy."

Then we can have a good discussion here, revolving around:

  * Is the community/author prepared to say that we want to let people
do yyy with our software?
  * And if so, what is the best response?  Can we make small exceptions
to the LGPL to satisfy it, or do we have to go to the BSD or some other
such license?

> I do appreciate your concerns - I have regularly contributed code to the
> community and want to continue doing so - but I think there is little
> real prospect of HDBC being attacked by a proprietary derivative. I
> don't doubt there will be some free-loading, but this might be the
> inevitable price of attracting more investment.

That's an interesting point.  There is, of course, free-loading even
with GPL'd software.  The promise there is, though, that people get
their rights preserved regardless of who gives them the software.  I
like that, and think that in the long term it produces the greatest net
gain in software quality and freedom.  Yet I realize that it can cause
some people without that mindset to reject it, which is why I see the
LGPL, perhaps with the additional exception I've outlined, a good balance.

-- John 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1435/3463 - Release Date: 02/23/11

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110223/f8cf5fcb/attachment.htm>