[foundation-board] Openness and licences...

Wed Jan 18 10:20:25 UTC 2012

On Wed, Jan 18, 2012 at 7:52 AM, Jordan S Hatcher
<jordan at opencontentlawyer.com> wrote:
> I agree with Rufus's summary -- thanks for pulling this together.  One small expansion:
>
> On 15 Jan 2012, at 11:11, Rufus Pollock wrote:
>
>> On 3 January 2012 12:00, Ben Laurie <ben at links.org> wrote:
>>> It seems the Panton Principles give me an opportunity to summarise my
>>> concerns in a nutshell.
>>>
>>> The Panton Principles define "open" as  “A piece of content or data is
>>> open if anyone is free to use, reuse, and redistribute it — subject
>>> only, at most, to the requirement to attribute and share-alike.”.
>>
>> Panton Principles aren't really the relevant thing here as they are
>> just quoting the Open Definition:
>>
>> http://opendefinition.org/
>
> Just to expand, the Open Definition is the overarching definition of openness for our work at the OKFN.  Within the scope of that work, we have a project called the Panton Principles, which are specifically looking at one type of material, data, in one specific field, science.  Within that scope and given a variety of factors (public policy, legal rights, ease of use, etc) the creators of the Principles all felt that copyleft was inappropriate for open data in science.

Jolly good ... I feel the same about software.

> I wholeheartedly agree with this assessment, in spite of. or even because of, my work with Open Data Commons.
>
> How we license our software is a different matter.  In the spectrum of "openness" within the OSD you have AGPL at one end (the most restrictive open license) and something like BSD, MIT, and WTFPL on the other end (the least restrictive open license), with public domain dedications being one step further off the scale.

Hah. I had not come across the WTFPL - awesome.

>
> The questions seem to be:
>
> 1) Do we seek to move the OKFN's licenses across several existing software projects (but most specifically the CKAN) from AGPL to a more "liberal" open license, and if so, why?
>
> 2) Can we even change the licenses for the projects in (1), and if so, how?
>
> 3) What default license should we use for new software projects, and why?

Indeed. 3 seems like the important question - if the answer is
something other than AGPL, then we need to consider 1 & 2.

So ... why something other than AGPL? There are two angles to this
question, from my POV:

a) Principle. "Open" means, to me, at least, that it should be
possible for anyone to use the software for any purpose whatsoever,
commercial or otherwise. If people think that data is somehow
different from software with respect to "open" then I would very much
like to understand why - I don't get it, myself. AGPL clearly
restricts those who, for whatever reason (e.g. licence agreements or
competition) cannot publish all their software.

b) Allowing wide contribution. One of the reasons the ASF rejected the
GPL was that we wanted to allow contributions from as wide a range of
developers as possible. We felt that the GPL (and even more so the
AGPL, but it did not exist at the time) prevented those who had
existing software that they could (or would) not make available from
participating. It also discouraged experimental participation - people
who wanted to try it out, see how it worked, and make their own
private modifications while they are experimenting are effectively
prevented from doing so by the GPL (and even more so by the AGPL).

Although the widely held view is that the GPL somehow benefits the
community by forcing those who take to also give back, and that
licences like the AL somehow fail to do this, experience clearly shows
this is not true - look at the ASF and the huge developer resource it
has, almost _all_ supplied by companies who _would not participate_ in
a GPL-based ecosystem (for example, IBM, Google and Microsoft). Why do
they give back when they don't need to? Because the drivers for
participation are nothing to do with licensing - they are principally
the advantage of sharing development costs for common infrastructure
and what I call "fork pain". "Fork pain" is what happens when you fork
an active open source project in order to maintain a private branch -
rapidly, you find yourself spending a substantial fraction of your
development budget on simply merging upstream changes and adapting
your private patches to architecture changes. If you, instead,
contribute those changes, then they are, of course, maintained by the
community at substantially reduced cost to you - and a net gain for
all, of course.

So, in short, the GPL is damaging to community and participation, and
the AGPL even more so. More liberal licences encourage participation
by those who have resources, especially when they are initially
skeptical.

>
> Thanks
>
> Jordan
>
>
>>
>>> This seems perfectly reasonable to me, but why "content or data" and
>>> not everything?
>>
>> See http://opendefinition.org/okd/ which states at the start:
>>
>> "Software is excluded despite its obvious centrality because it is
>> already adequately addressed by previous work."
>>
>>> Simple: because the "open source" definition is _not_ open by this
>>> standard, since it admits licences that are more restrictive. In
>>> particular, the GPL family of licences. This is obviously a matter of
>>> political expediency, but it seems to me these politics should not
>>> concern us, we should stick to the principles.
>>
>> Could you explain why you see GPL as non-compliant (if it were taken
>> to include software) with the Open Definition. The Open Definition is
>> directly based on the OSD and hence if the GPL were OSD compliant it
>> should be OD compliant (and hence compliant with the OD sections of
>> the Panton Principles -- I note the principles go on to make a
>> stronger requirement than OD-compliance in its last section).
>>
>>> So, this is my core concern: if we believe in "open", why are we using
>>> a licence that fails the test?
>>
>> Because we define open for software as the OSD :-)
>>
>>> I would like to separate that question from the question of which
>>> licence we should be using: first we should agree that GPL does not
>>> meet our standards.
>>
>> Can you give a brief precis (or link to such a precis by others) of
>> why the GPL is a) not open b) or if open still unsatisfactory, or not
>> recommended (I also presume these comments would apply to the AGPL
>> which is what we use most along with the MIT/BSD). If this is already
>> in a previous thread I apologize (I believe I have read all your
>> previous emails but if I have missed one where you already do this
>> please do point me to it).
>>
>> Rufus
>>
>> _______________________________________________
>> foundation-board mailing list
>> foundation-board at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/foundation-board
>
> ____
> Mr. Jordan S Hatcher, JD, LLM
>
> More at: <http://www.jordanhatcher.com>
> Co-founder:  <http://www.opendatacommons.org>
> Open Knowledge: <http://www.okfn.org/>
>
>
> _______________________________________________
> foundation-board mailing list
> foundation-board at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/foundation-board