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

[John Goerzen]

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