That they give permission for git use isn't the point (and they haven't
yet anyway. BTW, do we have anything in writing from these sources, and
what about the new images that are part of the program for variants,
etc.). It's that we even need to obtain permission at all. These files
are not freely distributable. Why is it hard to understand the inherent
problem with that for this project?
I am not sure what images you are talking about. You mean the Xiangqi
pieces? These are from a font that allows any non-commercial use in its
license. For me it s no problem to obtain permission if obtaining
permission is required. This seems much less of a hassle than the usual
copyright transfer to FSF that is always required for the sources. If
permission is required, and cannot be obtained, then we will of course not
include it.
I don't see the problem with simply having the bundling occur by a 3rd
party. In this case, you, but in a capacity outside of the winboard
project. Or anyone else. I think it's something to be encouraged,
actually. But again, not as part of the project.
Well, this is a perfectly viable solution, as long as there is a link on
the poject homepage to a download
(e.g. the one on WB forum) that prospective users would not percieve as
unusably raw.
The GNU website can then host a zip file with only the files produced in
the project (winboard.exe, .chm,
.hlp).
In fact most of the stuff we do include is GPL's or has even less
restrictions (open-source freeware). Much of what is
closed source is actually my own. [...]
You don't see a conflict of interest there? I do. Again, I bring up my
point which you ignored about bundling being analogous to Microsoft
bundling IE.
I see it more as a mutually benificial arrangement. MicroSoft is criticised
for not revealing the interface specs, (to make competition impossible)
and commercial anti-trust violations (pricing some products at a loss,
funding them by profits on other, unrelated products, to bankrupt competition).
We don't do any of that.
It was not my idea to provide WinBoard and engines in one bundle. That
decision was taken here before I had even heard of WinBoard.
But I see nothing against that in principle. (It is just the choice of
engines I criticized. And not even because they were nearly all GNU products,
but mainly because they are (by todays standards) mediocre and extremely bulky.
WinBoard protocol is fully open, and everything we deliver is freeware. IMO
adding features to a protocol is very difficult,
because GUI writers will wait for engines, and engines will wait for GUIs
to implement them.
Unfortunately, we have let our market share slip away, so that we are in
fact very un-MicroSoft like.
WinBoard's importance has dwindled to the point where it will even be
difficult to dictate the protocol.
So I think it is important to break the dead-lock of GUIs and engines
waiting for each other to implement
new stuff by providing products on both sides of the fence. If I add
Xiangqi support to WinBoard, I make
sure there are Xiangqi engines, so that it can actually be used. I don't
see anything wrong with that,
it might open an important market that would never get of the ground
without this two-pronged approach.
It invites competition rather than exclude it.
That leaves only Pulsar. Perhaps Sjeng would have been a better choice.
(Except
that it doesn't play Atomic, and I really like Atomic most of all ICC
variants.) But Mike Adams (Pulsar author) was very
helpful in debugging WB in combination with all the weird variants Pulsar
plays, and is actually eager to see it
optionally distributed with WB. Pulsar is not very big, it is just a tiny
add-on that provides a lot of FUNctionality for
the more casual board-game enthusiast.
