惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Hacker News - Newest:
Hacker News - Newest: "LLM"
Webroot Blog
Webroot Blog
S
Security @ Cisco Blogs
H
Heimdal Security Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
www.infosecurity-magazine.com
www.infosecurity-magazine.com
N
News and Events Feed by Topic
H
Hacker News: Front Page
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Application and Cybersecurity Blog
Application and Cybersecurity Blog
SecWiki News
SecWiki News
N
News | PayPal Newsroom
T
Tor Project blog
W
WeLiveSecurity
A
Arctic Wolf
Security Archives - TechRepublic
Security Archives - TechRepublic
S
Secure Thoughts
月光博客
月光博客
AWS News Blog
AWS News Blog
D
Docker
C
CERT Recently Published Vulnerability Notes
MyScale Blog
MyScale Blog
Google Online Security Blog
Google Online Security Blog
大猫的无限游戏
大猫的无限游戏
T
The Blog of Author Tim Ferriss
I
InfoQ
人人都是产品经理
人人都是产品经理
Recent Announcements
Recent Announcements
Google DeepMind News
Google DeepMind News
Hacker News: Ask HN
Hacker News: Ask HN
Blog — PlanetScale
Blog — PlanetScale
博客园 - 【当耐特】
Engineering at Meta
Engineering at Meta
Stack Overflow Blog
Stack Overflow Blog
Recorded Future
Recorded Future
罗磊的独立博客
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
T
The Exploit Database - CXSecurity.com
D
DataBreaches.Net
S
Security Affairs
WordPress大学
WordPress大学
T
Threatpost
Microsoft Security Blog
Microsoft Security Blog
V
Vulnerabilities – Threatpost
The Hacker News
The Hacker News
S
SegmentFault 最新的问题
B
Blog RSS Feed
Project Zero
Project Zero
P
Proofpoint News Feed

David Baron's Weblog

Software engineering, responsibility, and ownership Software engineering, responsibility, and ownership David Baron's weblog: Security and Inequality Running animations on the compositor thread David Baron's weblog: Tying ecosystems through browsers David Baron's weblog: Payments on the Web Thoughts on migrating to a secure Web David Baron's weblog: The need for government David Baron's weblog: Priority of constituencies How browser developers should seek feedback from Web developers A possible approach to shorter release cycles David Baron's weblog: Fifteen years Why debug builds (and assertions) are important Ten years of the Mozilla Foundation Why adding compositing and blending to CSS is harder than it looks How you can help with removing -moz- prefixes Moving bug history out of the primary display of a bug report Beware of locale-specific behavior in the C library Eating dogfood and shipping software Specification style and the future of the Web The bug system I wish I had CSS border-image changes and unprefixing Improving font size readability on Firefox for Android David Baron's weblog: CSS Animations, part 2 Hue-preserving color inversion with SVG filters Changes to handling of @-moz-keyframes David Baron's weblog: window.matchMedia() David Baron's weblog: CSS Animations What does a blur radius mean? Crash analysis in the future David Baron's weblog: calc() David Baron's weblog: colorDepth David Baron's weblog: Hidden complexity in specifications The most important field in a bug report: the summary WOFF font format submitted to W3C David Baron's weblog: :-moz-any() selector grouping setTimeout with a shorter delay Faster repainting in SVG foreignObject David Baron's weblog: Distributed Extensibility David Baron's weblog: Broadening crash analysis Correlating crashes with binary extensions or plugins David Baron's weblog: ex-HTML Downloadable font formats for the Web Web Accessibility as a Political Movement David Baron's weblog: CSS priorities David Baron's weblog: Bug priorities David Baron's weblog: Semi-vacation Some new CSS features in Firefox 3 David Baron's weblog: New selectors David Baron's weblog: The age of bugs Seeking a good Linux distribution David Baron's weblog: Teaching to the test David Baron's weblog: March 2008 David Baron's weblog: February 2008 David Baron's weblog: January 2008 David Baron's weblog: October 2007 David Baron's weblog: September 2007 David Baron's weblog: August 2007 David Baron's weblog: June 2007 David Baron's weblog: April 2007 David Baron's weblog: March 2007 David Baron's weblog: January 2007 David Baron's weblog: September 2006 David Baron's weblog: August 2006 David Baron's weblog: July 2006 David Baron's weblog: May 2006 David Baron's weblog: February 2006 David Baron's weblog: January 2006 David Baron's weblog: December 2005 David Baron's weblog: October 2005 David Baron's weblog: September 2005 David Baron's weblog: June 2005 David Baron's weblog: May 2005 David Baron's weblog: April 2005 David Baron's weblog: March 2005 David Baron's weblog: February 2005 David Baron's weblog: October 2004 David Baron's weblog: September 2004 David Baron's weblog: August 2004 David Baron's weblog: June 2004 David Baron's weblog: May 2004 David Baron's weblog: April 2004 David Baron's weblog: March 2004 David Baron's weblog: February 2004 David Baron's weblog: January 2004 David Baron's weblog: November 2003 David Baron's weblog: October 2003 David Baron's weblog: September 2003 David Baron's weblog: August 2003 David Baron's weblog: July 2003 David Baron's weblog: June 2003 David Baron's weblog: May 2003 David Baron's weblog: April 2003 David Baron's weblog: March 2003 David Baron's weblog: February 2003 David Baron's weblog: January 2003 David Baron's weblog: December 2002 David Baron's weblog: November 2002 David Baron's weblog: September 2002
Open licensing at the W3C
David Baron · 2013-05-22 · via David Baron's Weblog

In response to the objection I made on behalf of Mozilla to the previous proposed charter of the HTML Working Group, the W3C has proposed a new charter that allows the group to experiment with an open document license for extension specifications to HTML. If you work for a member company of W3C, I'd encourage you to encourage your AC representative to support the open licensing experiment. Here's why:

W3C publishes specifications, generally written by members of the W3C's working groups, under W3C's copyright ownership [1] and licensed under the W3C Document License, which does not allow other parties to modify the documents. This means that if, for some reason, W3C is no longer the right place to standardize something, those who want to work on that standard elsewhere have to start over rather than starting from the W3C document.

I'm one of several people who would prefer that the W3C license its specifications in a way that allows others to modify and republish the documents (a license that allows forking). I want this to be possible so that if the W3C stops being the right venue for standardizing something, the work can continue elsewhere. I don't want this to be a regular occurrence, nor do I want those who do it to do it without appropriate credit to the specification's original authors. But I want it to be possible to do when it's necessary, so I don't want legal restrictions that prevent forking, only social ones.

I also want it to be possible so that the W3C can collaborate effectively with other venues (such as the WHATWG) that do publish documents under a forking license. Currently this sort of collaboration isn't possible because the W3C can and does take documents from elsewhere that allow modification (often with little credit), but the movement can't happen in the other direction.

For example, when Ian Hickson set out to write what has become HTML5, he had to start over from scratch because previous HTML specifications were not licensed in a way that they can be modified. Ian wrote a new HTML specification at the WHATWG under a license that does allow modifications, and the W3C is using this specification as the bulk of their HTML5 specification (often with little credit to its original author).

Having licenses that allow modification and forking is also a useful governance mechanism. Without such licenses, once W3C has become the place for a particular specification, it is under relatively little pressure to continue to be a good forum. Allowing modification puts a little more competitive pressure on W3C to remain a good forum for standardization. This will reduce the chance of the history of HTML standardization from around 1999-2006 repeating itself.

Some might counter that this lessens the point of standards. I disagree. Standards are useful where there is benefit from a common agreement on how things work. If that agreement still has more value than changing it, then the party modifying the specification won't change it. When the value of sharing a common standard isn't large enough to motivate people to make and keep an agreement, that probably means it isn't worthwhile to do so.

For these reasons, I (as Mozilla's representative to the W3C's Advisory Committee) objected to the previous draft charter of the HTML Working Group. While we'd like to see all the documents of the group published under a liberal license, our objection didn't ask for this. We asked only that the charter allow the group to experiment with liberal licensing on extension specifications. We hope this experiment will give other members of the W3C more experience in working in an environment with liberal licensing and make them more comfortable with extending the experiment to other documents in the future.

The new proposed charter is under review by the W3C's Advisory Committee (the committee consisting of one representative per W3C member company) through May 29. If you are a member of the Advisory Committee or know your company's representative on the Advisory Committee, I'd encourage you to support liberal licensing.