W3C home > Mailing lists > Public > www-tag@w3.org > July 2012

RE: Governance and Web Architecture ...

From: Larry Masinter <masinter@adobe.com>
Date: Tue, 24 Jul 2012 17:32:52 -0700
To: Wendy Seltzer <wseltzer@w3.org>
CC: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D1E2D869AD5@nambxv01a.corp.adobe.com>
> When I read your draft, it appeared to me that your "governance" and
> their "tussles" described the same or similar class of issues. Either
> way, since that's a widely referenced paper, it would be handy to make
> the connection or distinction.


Can you help me with this? Which connections were particularly compelling? Which descriptions in "tussles" are better than what we have?


>> Piracy is the practice of obtaining and redisstributing works without regard to limitations placed on such distribution by the copyright owner.

> "Piracy" is a contested term; "copyright infringement" is bounded by
> legal limitations on the scope of the copyright right (fair use, first
> sale, eventual expiration, etc.).

With regard to "piracy vs "copyright infringement":  I think there is some sense in which governance distinguishes between different kinds of copyright infringement, and that distinction has architectural implications. The SOPA/PIPA proposals seemed to be oriented toward take-down of services whose main business model related to wholesale infringement ... and that this kind of copyright infringement rose to the level of a more strongly pejorative term like "piracy".  But I agree the framework document overemphasizes "piracy".

>> The primary tradeoff that is involved in legislating copyright and piracy, then, is between restricting access to content and making content widely available.

> at least a secondary piece of the tradeoff, as described earlier in the
> paragraph, is innovation in the systems permitted to interface with
> copyrighted material. DRM locks-down not only "content," but also
> who/what can create and play it.

DRM is an example of a couple of things: (a) governance which isn't particularly government mandated, but rather instigated by those owning the business of one of the workflows that the technology allows. (b) governance where the typical implementation restricts not only behavior intended, but also other, likely legitimate, uses. 


>> Thanks, I've had conversations with Jeni and Dan on earlier versions; I'll look again.

Yes, please look again at publishingAndLinkingOnTheWeb to see if your comments have been addressed.

> What I want to see more of in this document is what we expect to learn
> from the consideration of this cross-cutting set of "governance" issues.
> It could be that we won't learn it until after the deeper examination of
> each, but then a bit more fleshing out of the intro: what unifies these
> problem areas? what defines them as "governance" and leaves others outside?

At this point, if the framework merely serves as an introduction to "publishing and linking", it will have proved its utility.
If this becomes also useful in explaining why we have a "privacy by design in JavaScript APIs" document, it might also introduce some of the privacy topics.

If we're able to help with the examination of other related topics.

Those are some of the things that I expect to learn.

For me, the "governance" areas are ones where requirements are not determinable by interoperability, performance, utility, but that there is some social value.  
So what is left outside are those requirements that are externally determined.

Larry
--
http://larry.masinter.net
Received on Wednesday, 25 July 2012 00:33:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 July 2012 00:33:19 GMT