Re: Safe harbo(u)rs: A structural proposal for interop

Thanks, Vittorio!

I agree that you raise a good point here.

I want to raise a counterpoint and an argument.

I don't think it's true that there is only one platform per application. In the example you give - chat - the DMA and ACCESS Act are likely to encompass products from Apple, at least two Google products, and at least three different Facebook products. Certainly nothing in the ACCESS Act would require them all to adopt the same standard (and given the need to integrate with other platform components, that seems unlikely).

That said, I agree that any game-playing with the API - whether SDO-defined or unilateral - could really punish smaller interoperators.

I think that militates for strong oversight, whether of an SDO *or* a unilateral, requirements-satisfying API. I think most of us have experienced standards capture, even in "good" SDOs; I'm not convinced that designing a role for a referee would fight standards capture is harder than designing a role for a referee who would police both standards capture and unilateral API development (and, practically speaking, the standards implementation is as important as the standard itself, so the referee is going to have to police the actual operations, not just the specs).

And I do think that while standardization's benefits are substantial, it also exacts a cost. The value of unilateral action is that engineers do sometimes have good ideas that can benefit users, but which are hard to shoehorn into a standard (how many standards wrangles have ended with a good idea being dismissed as "out of scope" or some other synonym for "too much work to get consensus on"?).

Again, in the spirit of disaggregating the tech/policy questions into bite-sized standalone pieces, I think we can add "design a referee role" to the list of separate, vital questions, which (in my formulation, at least) now stands at:

1. A safe harbour regime that allows adoption of a standard API or compliance with the standard's requirements;

2. A capture-resistant process for setting those requirements;

3. A capture-resistant process for policing both standards compliance and requirements compliance.

What do you think?

Cory

On 2/11/22 07:01, Vittorio Bertola wrote:
> Hello Cory,
> 
> thanks for the reply. I just have a clarification on a specific point:
> 
>> Il 10/02/2022 16:09 Cory Doctorow <cory@eff.org> ha scritto:
>>
>> In both cases, there is no suggestion that all dominant firms will adopt the *same* standard. Rather, they contemplate that each platform will have its own interop standard because each does something different - Google is not Facebook, Facebook is not iOS. That means that any interoperator seeking to take advantage of these bills' new regimes will already have to implement a separate function, with separate libraries and API calls, for each platform they wish to interoperate with.
> 
> In practice, there are either zero or one gatekeeper(s) per each core platform service covered by the DMA. So if you are not a competing platform, but (as it happens much more frequently) a competitor only for that specific platform service, you only have to implement one API/standard. You want to create an IM app, you only implement Whatsapp's interface - etc.
> 
> All in all, my argument is that having that interface defined by an "open SDO + policy oversight" process, while still open to capture, will be more likely to produce fair results than having that interface defined and changed unilaterally by the gatekeeper within a broadly defined set of requirements. Even just reversing the order of the arguments in an API call can create significant havoc for third party implementers, especially small ones, especially if the gatekeeper does that every two months. That is not something you can address by setting functional requirements on the interface, but only by taking change control away from the hands of the gatekeeper.
> 
> Moreover, there is also the issue of whether the gatekeeper could copyright their APIs and exert control that way, for example by preventing other parties from offering the same interface so that those who manage to interoperate with the gatekeeper can also interoperate with them (incidentally, this would be the kind of beneficial network effect that we'd hope to get with the "open standard" solution). As I understand, the current Supreme Court ruling in the US is that APIs can be copyrighted, but can be copied as a form of fair use. I don't know about other countries, though. We'd just remove this risk altogether if we used an open standard owned by an independent party.
>

Received on Monday, 14 February 2022 19:27:25 UTC