[Koha] RFC: relicense wiki.koha.org

Thomas Dukleth kohalist at agogme.com
Thu Oct 8 12:54:24 NZDT 2009


[I had intended to write about this issue earlier but I had thought that
addressing the issue had been postponed until after settling some other
issues.  The originally proposed date for a vote passed as community
attention became devoted to other issues.]

I think that the basic wiki content relicensing proposal is good but there
are some mistaken presumptions and the ambiguity of the ballot question
needs fixing,  http://wiki.koha.org/doku.php?id=relicensing .

I have a very brief examination of the history of the difficulty and a
proposed remedy for the ambiguity of the ballot question.

I also introduce other possibilities than relying upon the supposition of
a favourable reading of the GPL to cover wiki content.  I reject those
other possibilities which I introduce and offer licensing under GPL 2 with
the or later clause as the least worst option at the present time.


1.  DIFFERENCE BETWEEK THE KOHA WIKI AND WIKIPEDIA.

Wikipedia used a similar process but also had the benefit of invoking the
GFDL with an or a later version clause.  FSF made a specific modification
to GFDL 1.3 allowing Wikipedia to switch to the CC-BY SA license.  There
is no similar provision in any CC-BY NC SA license allowing relicensing
under the GPL.  However, Wikiipedia had a specific problem about
relicensing because the number of contributors are too many to have a vote
which would have approached significant agreement even with the unanimous
ascent of the most devoted contributors.

The Koha community does not have the same problem with the Koha wiki
because Koha is a relatively small community where it is much easier to
obtain ascent and agreement.  Obviously the Koha community was too small
for people to pay enough attention to the default DokuWiki content license
to recognise it as a problem at an earlier point.

This is a case where it is fortunate that if the wiki is a work of joint
authorship and not merely a collection of separate works then at least US
legal practise would allow significant contributors to relicense the work
as a whole without needing the agreement of all contributors.  [I have
written about the joint versus collective works issue in the absence of
copyright assignment when it might go against free software interests in a
thread on the koha-devel list from 2007
http://www.nabble.com/copyright-holder-ts10219512.html .]


2.  AMBIGUITY OF LICENSING QUESTION.

There is no precise question on the wiki relicensing ballot.  Do we mean
GPL 2 invoked with the or later clause as with the Koha code itself?

"This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version."

I suppose that we could rearrange the words to something like following in
which program and software have been substituted in a way which reads well
in English.

"You can redistribute Koha Wiki content and/or modify the content under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version."

The ambiguity issue needs addressing.  Once addressed, I think that this
would be the best we can reasonably do for now.

This really leaves us with supposing that the GPL software license would
be read correctly for covering non-software works when it would not
necessarily be read in such a manner.  I suspect that this supposition of
favourable license reading will work in the Koha community and that there
will be no real problems about it.

What legal advise has been given to the Debian community about how to at
least try to invoke the license well for documentation under the GPL? 
Documentation licensing has certainly been an inflammatory issue in the
Debian community.


3.  INCOMPATIBILITY BETWEEN SOFTWARE AND DOCUMENTATION LICENSES.

The GPL itself is a software license with terms covering software.  The
language of the GPL is not compatible with other types works which are not
software perhaps because the language is more carefully constructed for
its copyleft purpose covering software than licenses written specifically
for other types of works.  There really is no clearly good available
remedy because FSF have not thought the problem of creating a GPL
compatible documentation license to be vexing enough in the universe of
problems relating to free software to devote enough of their limited
resources to addressing it.  A solution for documentation licensing for
people using the GPL needs an FSF solution which is one reason why
invoking the license with the or later clause is a good idea.

The GNU Free Documentation License (GFDL) was introduced for documentation
but had neglected the issue of compatibility with the software license
because of a need to preserve the integrity of opinions on free software
in essays bound into software manuals published by FSF.  Unfortunately,
FSF did not consult the software development community well enough when
writing the GFDL and relied to heavily on input from other publishers. 
FSF really recognises what a mistake that was and has fixed there
processes.  The process of drafting an alternative GNU Simple Free
Documentation License (GSFDL) is not obtaining enough attention at FSF and
may be focused on fixing the invariant sections and cover texts issue
without addressing compatibility with the GPL.  Anyone can make comments
on the drafts for the next versions of GFDL and the proposed GSFDL and
help create better versions of the licenses,
http://gplv3.fsf.org/doclic-dd1-guide.html .  When the GSFDL is issued,
there will likely be an upgrade path for works under GFDL which lack
invariant sections and cover texts.

[The free software community and FSF members can certainly influence FSF
but members do not control FSF or the terms of future license versions by
popular vote to prevent the open membership of FSF from being subverted by
opposing interests such as Microsoft had used in subverting the ISO
standards process over OOXML.]


4.  DISJUNCTIVE DUAL LICENSING.

I consider and reject the idea of two following possibilities for
disjunctive dual licensing as a remedy for the problem of licensing the
wiki content.  Bradley Kuhn likes the use of 'disjunctive' for authors
choosing multiple licenses and users having their choice of any or all of
the multiple licenses used by authors.  Perl uses disjuntive dual
licensing under both the Artistic License and the GPL.

[Bradley distinguishes disjunctive from what he supposes that most people
refer to simply as a dual licensing in a 'core source' business model
disfavouring free software.  In the 'core source' business model, a
company controlling all the copyright to a significant base of code may
produce a community version under a free software license and a version
with additional features under a proprietary license.]


Disjunctive dual licensing wiki content under both GPL 2 or later and
CC-BY SA unported 3.0 or later might address the problem.


4.1.  GLOBAL DISJUNCTIVE DUAL LICENSING.

I will refer to user choice of license for outside of the wiki where the
content inside the wiki is automatically under multiple licenses applying
to every wiki page as global disjunctive dual licensing.

Some people such as Bradley Kuhn encourage software projects to take such
an approach for documentation but he also knows that it is not really an
adequate remedy.  The idea in such a case would be that you would allow
the user to use the content outside the wiki in a choice any or all
specified licenses.  There would then be both the software license for any
code and a non-software license for any other content.

Such a remedy may be fine for code originating in the wiki.  However we
should not assume that the authorship of wiki content will originate with
people contributing directly to the wiki.  Code including help file texts
embodied as code could not be copied from the Koha code into the wiki if
the wiki allowed the CC-BY SA license which is not as strong or as precise
a copyleft license as the GPL and therefore incompatible with the GPL. 
Pierrick Le Gall had a proposal from 2006 to have special pages in the
wiki used to contribute contextual help and better translations which
would have help text copied between the wiki and Koha in ways where no one
had noticed the license incompatibility problem.

The GPL licenses are fairly inclusive in allowing the incorporation of
works under other more permissive licenses.  However, even any possibility
of including CC-BY SA works as part of a work as a whole under the GPL
would be a one way possibility if the CC-BY SA parts would be modified
under the terms of the GPL for the work as a whole.


4.1.  MARKED DISJUNCTIVE DUAL LICENSING.

Providing GPL 2 or later and CC-BY SA or later as a default unless marked
otherwise as only GPL X or later is a possibility with much appeal for me.
 However, it may be too easy for people to forget to mark appropriately
even in the minority of cases where needed without strong support in the
wiki code itself for assisting with the process.  I think that such
marking would overly complicate contribution to the wiki.  If we ever need
such a feature as with any possible license upgrade in even some
alternative builds of Koha under GPL 3 or AGPL 3, we could create a
parallel wiki with a different default license invoked.


5.  CONCLUSION.

Perhaps question on relicensing the wiki should read as follows.

Should we relicense the wiki content as follows?

"You can redistribute Koha Wiki content and/or modify the content under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version."

We ought to seek legal advise about such matters.  The FSF would advise
against it as advocates for appropriate use of the license that is their
position.  The Software Freedom Law Center might have a similar answer but
at least the Software Freedom Law Center may be inclined to give a more
nuanced answer to the extent that it would not be a conflict of interest
given that they are council to FSF.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783


On Thu, May 7, 2009 12:25, Galen Charlton wrote:
> Hi,
>
> On Wed, May 6, 2009 at 10:42 AM, Ben Finney <ben+koha at benfinney.id.au>
> wrote:
>> But it also doesn't solve the incompatibility between the Koha manual,
>> licensed under GPL, and the Wiki content.
>>
>> Why not license the wiki content also under GPL? Then the same license
>> terms apply to all the software: programs, documentation, and wiki.
>
> Good idea - the GPL seems to have worked OK for the manual.  MJ and I
> discussed this a bit more on #koha yesterday, and MJ also suggested
> either the GPL or a free-for-all.  For the sake of completeness, the
> other licenses that came up in the discussion include:
>
> CC-BY - http://creativecommons.org/licenses/by/3.0/
> CC0 - http://creativecommons.org/license/zero/
>
> I now think that the GPL is the way to go.  I've updated the
> relicensing page on the wiki
> (http://wiki.koha.org/doku.php?id=relicensing); are there any other
> comments about the license or the voting process?
>
> Regards,
>
> Galen
> --
> Galen Charlton
> VP, Research & Development, LibLime
> galen.charlton at liblime.com
> p: 1-888-564-2457 x709
> skype: gmcharlt
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>



More information about the Koha mailing list