From: Adam C. Engst (ace@xns.org)
Date: Thu Sep 28 2000 - 08:07:17 PDT
At 11:18 PM -0400 9/26/00, Robert S. Thau wrote:
>Adam Engst writes [forwarded by Keith Dawson]:
>
> > Although there's no doubt that the loss of OneName would be blow to
> > the system, especially early on, we at XNSORG have worked hard to
> > make sure they're not actually required. Several large firms have
> > already expressed interest in running backup root servers, and once
> > there are other agencies out there to take up the slack if OneName
> > fails, I think XNS could survive that.
>
>But that's not the scenario that worries me. What worries me is the
>possibility that OneName (or its buyer or designees) succeeds and
>misbehaves --- for example, by providing information to people
>claiming to represent law enforcement without an actual warrant, a la
>AOL. The same applies to any other root server, of course; if other
>agencies are potentially "taking up the slack", I'm afraid that means
>that there are *more* folks that I have to trust not to screw up.
>
>The root operator agreement says that OneName can be terminated as
>root operator if XNSORG finds "a pattern or practice of abusive trade
>practices that are commercially unreasonable and result in unfair
>economic advantage to the ROOT OPERATOR or detriment to others" (in
>sec. 7.5). Now, IANAL, but I'm not sure that everything that worries
>me could be considered a "trade practice", and I'm not sure I see how
>other forms of root operator misbehavior are covered by the agreement.
Wow, getting right to the heart of our most difficult negotiating
point. This was a major issue for the Negotiating Committee
(basically, the entire board, minus Drummond Reed, who recused
himself from the entire process on both sides because of conflict of
interest).
We can up with the language you quoted for exactly the reason you
suggested, what happens if everything succeeds and the power goes to
OneName's head. However, there are two important checks that may not
be quite as clear because they're not called out explicitly.
1) The Root Operator is subject to the XNS Global Terms just like
everyone else. So anything that runs afoul of the Global Terms,
either as they stand now or are amended to stand in the future, could
be sufficient cause to start investigations into OneName's power, and
failing the dispute resolution process, into arbitration that could
remove them from the position.
2) In the initial proposal from OneName, if they were kicked out of
being Root Operator, they were to be compensated in several different
ways (perfectly reasonable from their lawyers' points of view). I
probably shouldn't get into the details here, since they're
essentially moot, but one aspect of that recompensation was that
OneName was to receive royalties for their patent license in the
event they weren't Root Operator.
In large part to help prevent abuses of any sort in the future,
during the negotiations I managed to get them to eliminate _ALL_
repayments and royalties in the event they were kicked out of the
Root Operator position. What this means from a business standpoint is
that if they misbehave, they could stand to lose, permanently, a
large percentage of the possible revenues the company could earn into
the future.
It gives XNSORG a lot of power over OneName, and although we have to
be scrupulous about how we wield that power, it's a bit akin to a
company having one customer who makes up 80% of revenues. It's not
necessarily a problematic business model, but that company had sure
better keep that customer happy.
>WRT the other stuff:
>
> > We had an open source license ready, but some private feedback
> > convinced us that it would just be stupid to release something
> > without significant feedback and input from the open source
> > community. So we explicitly punted on that entire issue, and I
> > pored over the various legal documents to try and make sure that
> > none of them required anything in particular of the open source
> > license. I don't think they do, and the lawyers we had working on
> > it agree, but I'm certainly not an open source expert.
>
>Well, you may be trying to do the right thing here, but I'm not sure I
>understand how you're trying to do it. If you want feedback and input
>from the open source community, why not post your draft (labelled as
>such)? If you've set up a mailing list, the text must be available...
The draft was drafted by lawyers who weren't specifically familiar
with open source principles or the community, and the more I looked
at it, the more I felt that it wasn't even necessarily a relevant
starting point. The main thing that's weird about XNS is that we have
the concept of a Core Technology Area that is essentially the
foundation of the system. We want to make sure that changes to the
open source of the Core Technology Area come back to the community
without restriction to prevent a powerful large company from
"embracing and extending." But at the same time, we want to make sure
that the opportunity to create supplemental software on TOP of the
foundation is open to people who wish to give their changes away and
those who wish to charge for them.
> > >What kills it for me, though, is that the license covers the client
> > >side only; OneName is explicitly retaining all rights to the patent
> > >claims which cover operation of the central directory. Which means
> > >that, as Strata has pointed out, if you want to use their tech, you're
> > >stuck with them or their licensees, even if they screw up or sell out.
> > >This is not the sort of thing I like to see in a privacy guard.
> >
> > Drummond will have to respond to this. My distinct belief is that
> > nothing in the so-called "Reserved Technology Area" is required for
> > the operation of XNS.
>
>Well, here's what I was going on, from the patent license agreement:
>
> Without limitation, RESERVED TECHNOLOGY AREA includes Directory
> Service Objects described in column 102, line 27 to column 105,
> line 51 of the '325 Patent; Payment Service Objects described
> U.S. Patent No. 5,862,325 (the "'325 Patent") in column 119, line
> 13 to column 123, line 15 of the '325 Patent; Feedback Service
> Objects described in column 124, line 21 to column 128, line 30
> of the '325 Patent; and Schedule Control described in column 136,
> line 28 to column 141, line 46 of the '325 Patent; and any
> service, method or system which does not rely upon and use the
> XNS PROTOCOL.
>
>I'll admit I was assuming that the Directory Service Objects claims
>covered the operation of a root server --- I really should have
>examined the patent itself, but I have real trouble reading patentese.
>Still, if that's not the point of the RTA, I'm a bit perplexed at what
>is.
>
>At any rate, clarification from Mr. Drummond would certainly be
>helpful.
Drummond?
> > >(BTW, the privacy policy on their web site covers retrieval of
> > >pages from the web site, and their mailing lists and discussion
> > >forums, but is so far strangely silent on the use and
> > >redistirbution of XNS ID information. The best discussion I've
> > >found on that is on a separate page,
> > >
> > > http://www.xns.org/governance/legaldocs/globaltermssummary.html
> > >but while that document says a great deal about who is required to
> > >uphold the privacy policies, it doesn't yet say much at all about what
> > >those policies *are*.
> >
> > Does this answer your question?
> >
> > http://www.xns.org/governance/legaldocs/privacyterms.html
>
>Well, 3.4.4-3.4.8 are helpful, but they don't cover everything;
>it would be good to see more about cooperation with court orders,
>for instance. I'm not sure how 3.4.8 stands up against a subpoena,
>for instance.
As I understand it, the point of 3.4.8 was to prevent the kinds of
things that DoubleClick has apparently done. If you have enough
disassociated information about someone, you can apparently
reassociate it using statistical methods. We definitely wanted to
prevent that kind of behavior.
However, as to a subpoena, I have no idea if it stands up or not. I
think it would likely depend on the agency being subpoenaed (how
serious they wanted to be about cooperating in the particular case
versus how worried they were about violating the Global Terms). It's
also possible that the raw data could be subpoenaed, but that the law
enforcement agency would have to do the reassociation (since they're
not bound by the Global Terms).
>Some of the other paragraphs are still a bit wishy-washy; for
>instance, it starts off with:
If things are wishy-washy, consider it a starting point for improvements. :-)
> 3.4.1. Fair Information Practices. REGISTRANT agrees that a
> principal purpose of XNS technology is to provide an
> infrastructure for protecting the privacy and security of each
> MEMBER'S information. REGISTRANT agrees to abide by such Fair
> Information Practices as XNSORG shall adopt and promulgate with
> respect to the information of all MEMBERS. REGISTRANT understands
> that, as part of the XNS OPERATIONAL SPECIFICATION, XNSORG may
> issue and from time to time amend its own specification of such
> Fair Information Practices for the purpose of establishing a
> baseline for the XNS COMMUNITY as a whole and increasing the
> trustworthiness of the XNS TRUST MARK. REGISTRANT agrees to
> conform its conduct to such specification.
>
>Again, that says that the REGISTRANT is bound by the policies, but
>doesn't say what the policies are, just that whatever they are, they
>are promulgated by XNSORG (and that if XNSORG changes them, REGISTRANT
>is bound by the changes; likewise for the privacy policies).
Yes, this clause bugged me too. Here's what I was told. Apparently
Fair Information Practices is a term that's come out of the privacy
work in the EU. The goal here was to integrate in some fashion with
that philosophy, and the result is that XNSORG will have to come up
with a Fair Information Practices document. Like most of our
supporting documents, that's not done yet (we're only human!).
>(The requirement for change compliance is actually itself a bit
>worrisome; I can imagine XNSORG might change its regulations in a
>manner which some users of the system don't like --- requiring some
>forms of recordkeeping, for instance. Privacy-sensitive folks often
>prefer records not be kept).
I'm absolutely sure that when XNSORG changes the Global Terms, there
will be some people who don't like the changes. No one likes
everything, but that's why we feel it's paramount that XNSORG be
representative of and composed from the XNS community. Changes to the
Global Terms should not seem as though they were handed down from on
high by this elite group, they should seem as though they were agreed
upon and adopted by the entire community.
There was some concern about this fact in the early discussions, but
the advantage of being able to evolve the Global Terms to meet the
needs of the community was considered far more valuable than the
feeling of stability from a locked-down document. And worse, a
locked-down document would also anger a lot of people who feel,
justifiably, that this version of the Global Terms isn't perfect. But
unlike credit card agreements, which the credit card company change
how they like, when they like, for whatever reason they like, we're
talking about a representative and participatory situation with XNS.
cheers... -Adam
______________________________________________________________________
Adam C. Engst, XNSORG President XNS Name: =Adam Engst
Email: <ace@xns.org> Web: <http://www.xns.org/>
This archive was generated by hypermail 2b29 : Thu Sep 28 2000 - 08:21:38 PDT