Re: [XBoard-devel] Installer

[h.g. muller]

> 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.