Desire for freedom is practical self-interest [LWN.net]

Desire for freedom is practical self-interest

Posted May 5, 2005 15:42 UTC (Thu) by rickmoen (subscriber, #6943)
In reply to: Desire for freedom is practical self-interest by dlang
Parent article: Linus Torvalds' BitKeeper blunder

dlang wrote:

and note that the metadata people are complaining about is the stuff that bitkeeper uses to track the patches, not the patches themselves

It was my understanding that information available via other means such as the BK-CVS gateway was never a full equivalent of what one got directly with the BK client, though I might have been misinformed. In any event, ask yourself what this "stuff that BitKeeper uses to track the patches" turned out to be: SCCS files! So, BitMover claims to have proprietary rights to SCCS? That will come as a heck of a shock to the Bell Labs guys!

In effect, however, what BitMover was really claiming to "own" was a monopoly right to require everyone to use nothing but its proprietary client to talk to its repositories, obliging those who declined its licence to have second-class access to hosted data, or none at all. And it never had that right.

Rick Moen
rick@linuxmafia.com

to post comments

Desire for freedom is practical self-interest

Posted May 6, 2005 0:22 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

just shortly before this fiasco there was an update to the CVS info and I saw at least one of the die-hard opponents fo bk who had been screaming about the missing info agree that the info was now complete enough.

What exactly was risked by the telnet and netcat trick?

Posted May 6, 2005 1:01 UTC (Fri) by rickmoen (subscriber, #6943) [Link] (1 responses)

dlang, thanks for clarifying that. It's one of the aspects of the former situation that had been left hanging for a long time. (Just for completeness, I note in passing a potentially importance difference in kind between direct open-source access to a repository's contents and access through a gateway that exists courtesy of a third party's goodwill and willingness to fund it.)

Many long ago clearly wearied of this entire subject, but I remain interested in seeing whether some key factual questions can resolved with a reasonable degree of objectivity. For example: What was BitMover's real concern with Tridgell's activity? The legal basis for their complaint was at best thin (attempting to control what a licensee's contractor did in his spare time), but that's not the point: What actual proprietary interest was threatened?

(I pose that as a real, not rhetorical, question. One might well have existed and been at risk, but what specifically was it?)

You say the metadata in question was the repository's internal data structures (how I'm interpreting your phrase "the stuff that bitkeeper uses to track the patches", anyway -- correct me if I'm wrong). And it would seem reasonable to assert that those BK repository data structures were and remain a trade secret -- like BK's advanced merge algorithm, etc. But, unless I'm missing something vital, Tridgell's activity would seem to have given him no discernable access to repository data structures, SCM merge algorithms, etc. Those remained squirreled away in, variously, the BitMover-hosted repositories and the proprietary, binary-only client software. What Tridgell's perfunctory telnet-and-netcat "client" fetches is... SCCS files.

Given that distinction, if "BitMover-proprietary metadata" denotes, as you say, something much more sensitive than a pile of SCCS files -- which sensitive information would logically exist in the hosted repository and proprietary client but not the SCCS files -- then what company-proprietary information was McVoy upset over?

I have no objection to how you construe the term "metadata" in this context -- but then that's not what Tridgell retrieved, is it?

Rick Moen
rick@linuxmafia.com

What exactly was risked by the telnet and netcat trick?

Posted May 6, 2005 16:38 UTC (Fri) by ksmathers (guest, #2353) [Link]

Larry sells licenses on a per-developer-seat basis. Add a competing client, and Larry loses money. Improve a competing client to the point where it can emulate most or all of the standard client functionality (not by really doing local version control, but by passing all of the hard work on merging and branching to the 'real' BK 'server', and you end up with all of the BK
functionality at a fraction of the cost. One server, lots of clients -- totally destroys Larry's business model.

I'm guessing that what gave Larry the scare was realizing how easy it would be to make a dumb client instead of a smart peer.