Why is the MIT License unpopular in chess programming?

[brtzsnr]

I'm a programmer myself and get paid for my work. I made zurichess under BSD and currently it's used in a commercial project [1]. Do I mind? Absolutely, not! I'm really happy that non-programmers get to use my engine for entertaining.

Some software, e.g. compilers, chess engines, shells, OSes, is commodity and should be free to use, modify, appropriate, etc. Being open leads to lots of advances since the bar of innovation is lowered.

Now, why GPL vs BSD (or more permissive licenses)? GPL doesn't prevent cloning and appropriation, but it prevents legitimate businesses from using the software because they don't want to share their intellectual property.

However, the market forces business to contribute back eventually to the used software to maintain and improve the projects. Some examples: Google has summer of code to support many open source project, Linux & LLVM have tons of contributions from big companies, PHP is supported by Facebook. Some of the reasons are: it's hard to maintain internal patches better contribute them upstream, you want special functionality or bug fixes but don't have the full expertise and need help / code reviews.

So... I encourage you to clone and sell Zurichess.


[1] http://www.digitalgametechnology.com/in ... t-e-boards

[Tony P.]

Well, the only kind of charity is giving yourself, not asking others to give or to give more permissively...

That's very true! I wish I had anything substantial to give ATM

[Dann Corbit]

There are different kinds of benefits to every kind of license.
I am grateful for all of them, including commercial license types.

I think that GPL is the license of choice for many chess engines for obvious reasons.


Gull and Ivanhoe are super strong. So these can be used as a base for commercial engines (and clearly have been).

I think that GPL for Stockfish has proven to be extremely successful for that particular project and the nature of the license probably stimulated some of the innovation (people know that their efforts won't simply be taken without compensation of some sort, though the ideas are still free).

Crafty, for instance, is ordinary copyright by the author. Yet many programmers have benefited by examination of the code. I guess that most programmers who wrote bitboard engines in the 90's gave it a look to see how it is done.

The level of programming needed to write a high end chess engine is worth about a thousand dollars a day. I guess that Stockfish is worth more than a million dollars, when you examine the effort that has gone into it.

So I won't cry about it being GPL. I use SF for my primary analysis engine, chiefly because of the open source nature. It allows me to bolt on my own modules that write the analysis to disk so that I can collect secure analysis (GUI connections to the engines are almost always unreliable, with Arena being especially susceptible to decoupling from the engine).

So my conclusion is:
1. If you want to grab a strong engine, make some tweaks and call it your new project you can do that legally with the strong engines that are available. I advise against this, because someone else's code is not native to your brain since it was written by someone else. These projects usually fizzle out, though I can think of at least two exceptions, where the people who started the projects were pretty good at maintenance and innovation for a foreign body of code.
2. You can study the code of many open source projects, including the strongest engine in the world currently (Stockfish). Then you can use your new found knowledge to build your own engine from the bottom up. It won't beat the world in the first few months, but this is the best real path to a truly great engine that you can really be proud of.
3. You can avoid all the code bases and write an engine based strictly on chess programming articles (I know at least one programmer who has done this).
4. You can start with a flimsy engine and build it up. I think that Sungorus is a good place to start for that path. I think that is a really good way to come up to strength. I guess that after this path, you will revert to one of the other choices, having gained a huge body of knowledge.
5. Some other path of your own choosing.

The programmers here are all incredibly helpful. Even the commercial programmers have been known to explain some of their techniques to the raw beginners.

Anyway, I see nothing but good choices and open road before the beginning chess programmer, with an army of helpful experts ready to lend a hand. What could be better than that?

On the other hand, writing a good chess engine is a very arduous task. If you plan to do it, you had better love the job, or you will tire out.

5.

[Tony P.]

So my conclusion is:
1. If you want to grab a strong engine, make some tweaks and call it your new project you can do that legally with the strong engines that are available. I advise against this, because someone else's code is not native to your brain since it was written by someone else. These projects usually fizzle out, though I can think of at least two exceptions, where the people who started the projects were pretty good at maintenance and innovation for a foreign body of code.
2. You can study the code of many open source projects, including the strongest engine in the world currently (Stockfish). Then you can use your new found knowledge to build your own engine from the bottom up. It won't beat the world in the first few months, but this is the best real path to a truly great engine that you can really be proud of.
3. You can avoid all the code bases and write an engine based strictly on chess programming articles (I know at least one programmer who has done this).
4. You can start with a flimsy engine and build it up. I think that Sungorus is a good place to start for that path. I think that is a really good way to come up to strength. I guess that after this path, you will revert to one of the other choices, having gained a huge body of knowledge.
5. Some other path of your own choosing.

That's all great advice! I had had similar thoughts. Moreover, I believe that the only way to beat the current top 3 engines is to come up with a total novelty. That's of course a big gamble because most of the crazy ideas generated during the brainstorm will turn out useless.

On the other hand, writing a good chess engine is a very arduous task. If you plan to do it, you had better love the job, or you will tire out.

That's very true too - there are few things in life that are more frustrating than an elusive bug.

My personal issue, though, is that I don't know what I'll do in early retirement should it come true, and I'll possibly have decades of free time available that I'll need to fill with some meaning. That said, programming indeed has a very low priority on my list of possible hobbies, partly because it seems easier to rise from the club level to the CM title in wooden chess than to write an engine of TCEC strength.

Thank you all for the guidance!

[mar]

This MIT clause

Code: Select all

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Means you have to include the license with binary distribution (substantial portions), even though the formulation is tricky.

The same applies to BSD which explicitly states that:

Code: Select all

Redistributions in binary form must reproduce the above copyright notice

or (older version)

Code: Select all

Redistribution and use in source and binary forms are permitted provided that the above copyright notice and this paragraph...

Some variants also require you to acknowledge the author (always nice).

So in my opinion MIT and BSD licenses are very similar and (relatively) liberal.

Why people prefer GPL? Maybe because GPL mandates the changes to remain open source, I personally don't like GPL at all.

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.

If you plan to release a library under a very permissive license, you may consider Boost public/zlib or even public domain
(but some say public domain is not a good idea because "public domain" is not acknowledged by law in some countries)

[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