[tei-council] Fwd: TEI licensing issues

[Piotr Bański]

On 13/09/11 18:27, Martin Holmes wrote:
> On 11-09-13 05:45 AM, Piotr Bański wrote:
>> On 13/09/11 14:26, Laurent Romary wrote:
>>> OK. What I meant is that, if I have understood the situation
>>> correctly, it was not necessarily planned to have this GPL
>>> constraints on some of our TEI productions.
>>
>> The description of what you call GPL constraints as "viral" comes, as
>> far as I barely recall, from some Microsoft spokesman. He was very
>> successful -- this is a strong meme, people catch it unawares. It's very
>> cunning: it reverses the imagery, from a means to keep stuff free to a
>> picture where that strategy acquires evil/dangerous connotations, and of
>> course the meme cleverly plays on the right to possess and to draw
>> income, although the license actually doesn't prevent either.
> 
> I don't think I'd quite agree with that. I've been involved in
> commercial software development for many years, and I've come to dislike
> the GPL; it's generally very difficult to use GPL code in a commercial
> project without having to make your own commercial source code public as
> well, and that acts as a serious deterrent to commercial software
> development. The LGPL is slightly better, but even that involves lots of
> compromises and can often force you to restructure your application so
> that compiled libraries are kept separate and linked at run-time rather
> than compile-time.

I can't resist remarking that, understandably, this sounds very much
like it's written from the perspective of someone involved in the
commercial software side of things :-) One fragment I'd like to pick on
is that GPL, directly or indirectly, is a "serious deterrent to
commercial software development". How can that be? If you develop
commercial software, you are not forced to use GPL-ed software -- you
can develop your own closed equivalent, can't you. If you decide to use
the shortcut provided by the existence of good free GPL-ed software,
well, there is a price associated with that, because the people who have
put their time and skills into that software have certain expectations
with regard to its future fate: it was developed in the open, and it
shall remain in the open, so that everyone can benefit. "Benefit" also
monetarily, because open source software need not mean software that
doesn't provide a way to get revenue, you just need a different business
model to start benefiting from that.

> The GPL encodes an ideological stance which is strongly opposed to
> anyone keeping source code secret. Most commercial software developers
> feel that they must keep at least some of their source code secret,
> otherwise their software will be recompiled and released for free by
> hackers or competitors.

One very ideological reply could be that if both the said developers and
their competition decided to compete in the open, their energy and
skills would find more efficient use. But of course such opening of
software happens rarely nowadays, and hasn't happened often in the past,
for many reasons, not the least important of which is that it may be
very difficult to ensure that all sides of such a competition would
behave ethically.

Still, no one requires that creators of secret code release their code,
because no one requires them to use GPL-ed code. And the 'release'
clause only becomes relevant when you decide to distribute. So for
projects that offer APIs in-situ, for example, without software
distribution, GPL does nothing -- they are free to use GPL-ed code.

> I understand the motivation behind the GPL, but I think on balance its
> effects on innovation and openness are actually negative. I much prefer
> licenses like MPL and BSD which don't really attempt to control what
> people do with the source code.

In Computational Linguistic circles, this article[1] by Ted Pedersen has
resounded pretty strongly. Pedersen gives arguments for why the open
source development model guarantees innovation.

[1]: http://www.aclweb.org/anthology/J/J08/J08-3010.pdf

In the end, I think the distinction between BSD and GPL flavours may be
(brutally) reduced to the distinction between the attitudes of creators
and the status of the project. For BSD, it is "here, I've created
something cool, go and use it for your benefit, all I need is a
copyright statement on your help screen". This is extreme generosity,
very laudable. A bit like "here, have my kidney, I'll be ok". Super
cool, if you can afford it. A friend has also remarked that in some
cases, it may allow software companies to choose stuff under BSD, and
many of them may be willing to give back. Possibly a kind of law of
large numbers effect if it's true and measurable.

In GPL, it is "here, I've created something cool, go and use it for your
benefit, but since I have sweated over it, I would like it to maintain
its open status (share-alike)". This is a guarantee that if someone put
their time into an open project, the offspring of this project will
remain open for others, including the original creator. This is, I
believe, rather essential in the work on "minor", "under-financed",
"non-central", "lower-density" languages, to make them open their data
sheds and contribute towards a common goal, part of which is
preservation of the given language.

This guarantee is not, in my view, essential for the TEI, which, as
Martin has remarked, can stand on its own, at least among the Humanities
enterprises. In other words, I believe that the TEI is capable of
donating a kidney, and maybe even growing a new one to donate it again.
Not in all areas, but surely in its main areas of application.

My point regarding CC-BY was only: if they say it's incompatible with
the license we have used so far (and "they" appear to be serious about
this, whatever the legalese nitty-gritty is), let us rather use
something that is compatible with it, not to hit the GPL world that we
are still, until the change of the licence, part of, and that we still
want to be able to incorporate the TEI (it's not a small world).

Best,

  Piotr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4054 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20110913/e0627c7d/attachment.bin