- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 05 Mar 2009 12:15:00 -0800
- To: Philippe Le Hegaret <plh@w3.org>
- Cc: Sam Ruby <rubys@intertwingly.net>, "Dailey, David P." <david.dailey@sru.edu>, Karl Dubost <karl+w3c@la-grange.net>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, Ian Hickson <ian@hixie.ch>, public-html@w3.org, site-policy@w3.org
On Mar 5, 2009, at 11:35 AM, Philippe Le Hegaret wrote: > On Thu, 2009-03-05 at 14:03 -0500, Sam Ruby wrote: >> Dailey, David P. wrote: >>> I am not sure if Philippe's intention was to have this discussion >>> here at public-html as well >> >> I'm not certain what plh's intentions were, but given that we were >> asked >> to provide use cases as a group, I would like to gather together a >> response as a group. I am planning on attending the AC meeting later >> this month, and would like to be able to represent the working >> group's >> position on this matter. > > Having the response from the HTML Working Group prior to the AC > meeting > is going to be useful indeed, and discussion on public-html is > perfectly > appropriate. site-policy isn't a public list so it can't be used for > useful discussion. W3C, as a SDO, isn't used to the concept of > allowing > a fork. I can understand the concerns with forking of standards, and that this could lead to a failure of interoperability. However, I think it may be impossible to prevent forking while also satisfying the use case of usability in LGPL/GPL-licensed code, since these licenses require granting permission to fork for any purpose whatsoever. I think that in practice, W3C specifications will remain canonical and authoritative, not because of licensing, but because the W3C is respected as an organization, and is seen as the definitive source of Web standards. So long as W3C remains a good steward, forks will not happen or at least will not go anywhere. If it fails to be a good steward, forks will happen no matter what the license says. Let's look at history. For the vast majority of W3C specifications, no one has chosen to make a competing spec, even though it would certainly be possible to express the same technical content in different form (perhaps by clean-room reverse engineering). But when the W3C abandoned maintenance of HTML for many years, a fork arose even though it was legally impossible to copy any of the HTML4.01 specification. When the W3C decided to resume work on HTML, the fork has essentially merged back in. This history tells me a few things: 1) Preventing specification forks is not achievable through license terms; a sufficiently motivated party can create a new spec from scratch. 2) Preventing specification forks is probably not necessary; the one time it happened, the outcome was good and the effort merged back into a realigned W3C. 3) Due to 1 and 2, we should give more consideration to LGPL/GPL compatibility than prevention of forks via licensing terms. Regards, Maciej
Received on Thursday, 5 March 2009 20:15:45 UTC