Why is the MIT License unpopular in chess programming?

[Tony P.]

So if you plan to integrate a library into you project, my advice is to stay away from anything *GPL. LGPL is more permissive but requires dynamic linking.

Right, that's the exact reason why this thread has appeared, though, as I've mentioned in the depths of the first post, a GPL program can still be legally accessed from a non-GPL program (i.e. one that the author doesn't want to be bound by the GPL) by means of 'unintimate' (e.g. following some common protocol like UCI) communication through a command line or a pipe, which means that one can write a GPL wrapper (also acting as a meaningful separate program, e.g. a command-line tool that gets a FEN string and replies with an eval and the PV) around a GPL program and connect it to the non-GPL part of the distribution this way. It's a dirty trick, of course, and I'll be avoiding *GPL engine sources anyway, but this example shows how little legal power GNU has.

On a side note, I'm pleased to see Jon, Alexandru and Martin, whose engines (Arasan, Zurichess and Cheng) all carry permissive licenses and are all strong, check into the thread so fast

[Ras]

However, the GPL as opposed to the MIT makes it more difficult and longer for more motivated (profit-driven) developers to write premium quality products

They are welcome to be bright enough to develop their own code on their own time. Or asking the actual authors for a dual licence release, though that would probably cost money.

Personal statement why I have chosen GPL3 not only for the chess SW part, but also for the self-developed toolchain around it, as well as for the detailed construction documents for the dedicated hardware.

I really couldn't care less about whether some hypothetical company might be upset about additional aspects in ripping off profit from my unpaid leisure work. They don't pay me, so I owe them exactly nothing.

What I care about is that I leave the same possibilities to fellow programmers coming after me as my predecessor left to me. And to make sure that the programmers after the programmers after me also have these possibilities. This is a way of sustainability. If that should be in the way of some cheap buck not to be made somewhere, so what.

[Tony P.]

Or asking the actual authors for a dual licence release, though that would probably cost money.

I guess that's a pretty common way for SW authors to monetize their side projects without spending a lot on marketing, haha.

To clarify, I don't mean to pressurize anyone into relicensing their code, and actually, I don't think that publishing the whole program under a permissive license is optimal.

The main advantage of a permissive license is that it allows to split a distribution into two parts with different degrees of freedom, unlike the GPL that requires the whole distribution to carry it. These two parts might as well be GPL main code and an MIT-Expat / Modified (3-clause) BSD / zlib / LGPL library used by it, the program as a whole being necessarily GPL.

For example, imagine that I'm working on an engine and have coded the board representation and the search algorithm but the static eval (which is very critical to the engine's Elo) isn't ready yet. Still, I want to have the search beta-tested publicly with a stub static eval.

What I can do is write an Expat-licensed wrapper library around the static eval function of an engine whose license is Expat-compatible, putting it in a separate folder copyrighted to the author of that engine. My main code (calling this library when it needs to eval a position) would be copyrighted to myself. Thus a clear distinction would be made between my contribution and the one of the other author.

As a whole, this early version of the engine would be Expat-licensed and fit for beta-testing. Its Elo would be much less than the expected Elo of the final version of the engine (the one with my own static eval), so the opening of the beta code wouldn't harm the expected final version of the engine, whereas the former's testing would help debug the search early on.

The same argument applies if a Modified BSD licensed stub static eval is used, except that my part and the beta engine as a whole would of course carry the MBSD then.

This opening of the code would be a step towards satisfying the curiosity of clone hunters. They'd get more evidence of the engine's originality than if all my code were closed.

And don't forget that if someone suddenly started making huge money out of my Expatted code, I'd still be able to start patent treachery against them - Expat is not as permissive as Apache 2.0, after all

[jdart]

I think very few people are ever going to make any significant income from chess software. I think unless you have a business plan and the software is a key part of it, then licensing to protect your future revenue is probably unnecessary. You won't have any to protect.

--Jon

[Peperoni]

Is there an up-to-date list of engines and their license?

[Dann Corbit]

You could get a start looking at github.
Most chess engines are GPL, I think.

[Tony P.]

Solid bump

I can't guarantee the completeness of my lists anyway. Here's some notable open-source non-GPL code that I've learned about (or missed in 2017):

Scorpio: a custom BSD-like license*, C++
FabChess: 3-clause BSD, Rust
Roc: CC0, C++, a successor to Gull in TCEC with few changes
Dumb: MIT, D, a didactic weakened version of (GPLed) Amoeba
A0lite: MIT, Python
BBC v1.0-1.2**: WTFPL, C
Chess.jl: MIT, Julia, a library by Tord Romstad himself
Pyrrhic: MIT, C, a Syzygy TB probing library rivaling the good old Fathom

Out of the old list, the 2nd strongest (behind ScorpioNN) permissively licensed engine, Arasan (MIT, C++), is still in active development.

Among these, the only ones at the TCEC strength level are ScorpioNN, Arasan, FabChess, and Roc. A0lite has appeared in QL but did poorly there

GPL 3.0 is still the most popular among new engines. I'm omitting those using it, as it's easy to look up the list of orange engines on CCRL.

* I haven't asked Daniel to clarify his intentions behind the modification of the 3rd BSD clause, it looks like any commercial reuse requires his written permission (because selling is hard without any promotion or endorsement ), but the license is certainly more permissive than GPL. Note that Daniel's nncpu-probe repo is under GPL 3.0 due to the use of SF's NNUE code.

** Versions 1.3 and later are under GPL 3.0 due to the use of SF's NNUE.

[AndrewGrant]

Historically, I cannot say the answer. However, going forward, there is great motivation to use something like the GPL. In a more naive time, one could assume that others would not steal your work and pass it off as your own. Now, that is more true than ever. Fire and Houdini, but many more, and even more shameful examples exist among us today.

Why would you make it even easier for someone to steal your work without giving any credit?

[Tony P.]

Open-source code is easy to steal, no matter which license it's under, because thieves don't care about compliance anyway There are differences for those who wish to reuse the code legally, and there are many licenses that require attribution (the MIT one actually does too, the authors just tend to care less about enforcing it).

As for the history, I guess Fruit set the fashion. (Back then, clouds weren't as prominent, so AGPL seemed an overkill.)

Note that Daniel's nncpu-probe repo is under GPL 3.0 due to the use of SF's NNUE code.

Ouch, that was a misprint: nnue-probe is under GPL 3.0, while Daniel's own new probing code (nncpu-probe) is under the same license as Scorpio.

Also, I forgot to mention:

Tinman: MPL 2.0, Rust
chess-alpha-zero: MIT, Jupiter/Python - that was the project that Gary Linscott combined with SF's movegen to give birth to Leela. I thought it's a ton slower than Leela's later backends and so rather useless, but who knows?