I don't understand why perforce would be worried about this issue. The hard part
of perforce is implemented in the server side code, not in the protocol. Let's
say perforce did open up the protocol, what could their competitors do with it?

Well, they could then implement their own clients, their own servers, and/or
copy the protocol's design for their own products.

Other people making perforce clients actually helps perforce, since they make
their money selling licenses which are enforced on the server side. If perforce
wanted to control all clients for their server, they wouldn't have released the
p4api at all. No issue there.

Emulate perforce on the server side? Even assuming that someone could afford to
put enough effort into emulating the server side of perforce (a herculean task),
what would it get them? The ability to reuse existing perforce clients?
Perforce's clients (command line and p4win) are both perfectly good as far as
they go, but they certainly aren't significantly better than their competitors,
and it would be much cheaper to put those resources into making a better client
for their own protocol.

That leaves us with copying the protocol itself. Even without the source code, I
think it is fairly clear from looking at p4api as distributed by perforce to see
that the protocol is a fairly straightforward RPC mechanism. I suspect that
anyone who wanted to put in the time could reverse-engineer the protocol using
the API specs as documented by perforce and tcpwatch. Of course, doing so would
violate your perforce license agreement, but a dedicated open-source type or one
of perforce's competitors could easily work their way out of that issue. (No,
I'm not willing or able to do it myself.)

Summing up, it is difficult to see how opening the protocol could possibly leave
perforce vulnerable to their competitors.

So why are they reluctant? One can only assume that the real issue is that
perforce would be losing some level of control over the protocol's future if
they made it public. This is a valid concern, but one that could probably be
worked out in some manner satisfactory to perforce (e.g., using a Mozilla style
process where perforce still maintained control over the changes allowed into
the p4api module (if not the whole p4win kit and kaboodle).

Personally, I think the advantages of having a community developed client would
be worth it, and I'd like to hear perforce's real concerns about the issue
discussed.