Re: [XBoard-devel] Installer

[Eric Mullins]

h.g. muller wrote:
> > 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).

I think a link to a relevant page instead of a download.  But yes, 
provided it comes with the disclaimer that the winboard project doesn't 
endorse any particular add-ons or tools.

> I see it more as a mutually benificial arrangement. [...]

Beneficial to some, a select few who for no particular reason got the 
boon when others are equally deserving.  Now don't take this the wrong 
way, I'm not actually accusing anyone of anything-- it's just 
hypothetical.   But how do we know that nobody gets a kickback (monetary 
or otherwise) from inclusion in a bundle or from causing the winboard 
project to plug some specific software.  Far fetched?  Maybe, but 
weirder things have happened in this world.  It's easily avoided too.  I 
think that's one reason among many for sticking with freely 
distributable software or not bundling at all.

If a 3rd party wants to deal with attaining relevant permissions, it's 
of no concern to this project.

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

Microsoft is criticized for a lot of things.  But there are versions of 
windows that don't include IE  because of bundling.  Not because of 
interface specs.
> It was not my idea to provide WinBoard and engines in one bundle.
I'm sure it wasn't.  This whole issue never entered my mind until you 
mentioned possible licensing issues hosting the install files on git.  
Since then, I've done lots of thinking about it.  I'm convinced that 
bundling hurts some people, and could lead to licensing problems down 
the road.  Permission can be revoked, unless it's in writing and labeled 
as permanent.  And really, we should be able to do what we need to with 
files in the project at any time.  Inability to do so because of 
permission issues means to me that we are dealing with files that 
shouldn't be in a GNU project at all.

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

Rather than bundle, I would prefer to see some solid howtos that are 
maintained.  They could contain links and precise setup instructions-- 
even scripts to set up software so the user wouldn't have to do anything 
complex.  Of course with disclaimers that the winboard project doesn't 
endorse any particular external software.  Along those lines, we might 
consider making it easy for other software to determine the winboard 
install location.

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

Is that really your goal, dictating protocol?  If so, it really flies in 
the face of the previous sentence.


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

I'm not sure what the point is here.  None of that has anything to do 
with the legal and ethical implications of the winboard project 
advocating select external software.

I certainly applaud your efforts in the winboard project.  I probably 
never made that clear.  I simply do not have the time to do the amount 
of work you have on the project.  So please don't take my criticism here 
as a jab at your obvious enthusiasm for the project, nor at the vast 
amount of hard work you have contributed.

Perhaps I'm just being pedantic about this issue.  Nobody else seems to 
care-- at least I haven't seen anyone else who's concerned about it.