[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] Installer

From: Eric Mullins
Subject: Re: [XBoard-devel] Installer
Date: Mon, 24 Aug 2009 19:42:02 -0600
User-agent: Thunderbird (X11/20090817)

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,

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]