View source for AB/trademark-license

The [[AB]] is working on a combination trademark / license policy to permit more permissive copyright licenses on W3C drafts and specifications.

This is the current state of that work / project.

AB project page:
* [[AB/2014-2015_Priorities/w3c_work_trademark]]

[[AB]] Trademark License task force members:
* [[Tantek|Tantek Çelik]] 
* [[Michael Champion]] 

= Trademark License Taskforce Summary =

Goal: build broad consensus on a combination trademark / license policy that permits more permissive copyright licenses.

== Problem Statement ==
How did we get here? Why is this a problem?

The current W3C Copyright license is presenting the following problems:
* '''Restrictiveness has pushed specs outside W3C''' Some highly productive editors of key web platform specifications have chosen to do their work outside of W3C, due to, among other things, the ability to use more open (liberal) and more standard (not W3C-specific) licenses such as CC0 and OWFa ([https://wiki.mozilla.org/Standards/license#Example_Specifications Web Platform Specs with CC0+OWFa]).
* '''Blocks some spec implementation in Open Source.''' Recently W3C specifications are becoming more and more procedural in style (rather than declarative), in many cases providing (pseudo-)code for implementer incorporation. The W3C Copyright license's restrictions prevent incorporation of such code and/or strings (like error messages) into much open source, e.g. licensed with GPL.

== Current W3C Licensing Work ==
What changes to W3C Licensing is actively occurring in W3C specs right now?

* '''HTMLWG experiment: optional CC-BY for HTML5 extension specs.''' Several HTML5 extension specifications are being developed with the CC-BY license, with the following result:
** Spec development is proceeding (but nothing "finished" to report)
** No bad results (the sky didn't fall).
* '''WebApps WG proposal: URL spec dual license with CC-BY'''
** Actively being proposed / discussed in AC.

== Broader Trademark License Work ==
What is being done to fix licensing W3C-wide?

* '''AB is working on using trademark to supplement copyright'''. Mike and Tantek on the AB, having familiarity with concerns along a broad spectrum of this subject, are working on finding points of consensus on how W3C could use a Trademark License with a liberal copyright license instead of the current W3C Copyright license. The rest of this document show current state of work. This work is being done in the open as part of the [[AB#Open_AB|Open AB efforts]] begun in 2013.
Recommendations:
* '''Use 'W3C' prefix on W3C spec names'''. Based on experience with other open groups like Apache, Creative Commons, Mozilla, and experience to date with the [http://www.w3.org/2013/09/html-charter.html#documentlicense CC-BY HTML5 Extension Spec Experiment].
* '''Encourage WGs to pick unique names'''. This will help searchability/discoverability for specifications.
* '''Specific liberal license still under discussion.''' Whether to use CC-BY, CC0, or some other standard liberal copyright license is still under iterative discussion, and taking into consideration experience gained from the above experiments.
* '''Continue Investigating Experience of Other Groups'''. We are continuing to examine how other open source/licensing groups like Apache, Creative Commons, Mozilla use copyright and trademark licensing.

== Expected Positive Results ==
The adoption of a trademark License with a liberal copyright license is expected to have the following positive outcomes:
* '''Re-attract editors and specs.''' Using a liberal copyright license is expected to remove one of the motivations for editors to develop specifications outside W3C. This is a necessary (but expected not to be sufficient) action to bring more web platform work (back) into W3C. The AB is working on understanding what would be sufficient and working on those issues as well.
* '''More Open Source Implementation of W3C Specs'''. GPL open source implementations will be able to implement from W3C specifications in addition to WHATWG specs.
* '''Allow bi-directional spec changes'''. When a spec is being developed both outside W3C (e.g. a living WHATWG spec), and inside W3C (a feature-frozen W3C spec), small edits, changes, bug fixes will be able to go back and forth between the specs, which will hopefully enable and encourage more cooperation across SDOs, setting a good example to help with re-attracting editors as well.

While maintaining:
* '''Identifying which specs have W3C consensus and IP commitments'''. Many of us believe it is  important for  implementers be able to identify which published specifications have benefited from W3C's open, consensus-based processes and patent licensing commitments. A trademark based licensing approach will allow such identification by looking for "W3C®" as a prefix on names of W3C specs.


----


= Trademark License Taskforce Working Area =

== Consensus Recommendations ==
* '''Require consistent identification of W3C Recommendations.''' The simplest change to current W3C trademark practice would be to require consistent identification of W3C Recommendations using the W3C name, e.g., "W3C DOM" rather than just "DOM".  To effectively minimize confusion about which flavors of a spec such as DOM benefit from the W3C process and patent commitments, such a minimalist trademark policy would need to be supplemented with a content update of W3C's website to educate people on the distinction between "DOM" and "W3C DOM", as well as general update to W3C's announcements about specs to use the full name of the spec e.g. "W3C DOM" upon first mention in any particular communication.

== Consensus Items ==
Items on which there is consensus within the task force.

* Create a public wiki page to track the project (this page [[AB/trademark-license]])

* Historical note: last time there was a survey on more permissive licensing in HTMLWG there was a lack of consensus, and progress has been made since with the HTML licensing experiment.

* Using trademark license may provide an alternative to solving the underlying problem that the document license revision tried to address. From AC and AB discussions there may be a broad consensus possible on much of the underlying problem that the document license revision tried to address even if we disagree on using copyright to achieve those goals.

* It should be clear to the developer community which features in which specs are covered by the broad RF patent commitments that W3C Recommendations carry.

* There should be some sort of norm strongly encouraging attribution of ideas in derivative works back to their source.  This helps maintain a culture of collaboration. The more we can make this simple and easy to do, the better.

* We need to foster a culture that respects the contributors of specific ideas and texts while recognizing that it they are refined and implemented via an evolutionary process in a larger community.  We need to do this within a legally sound but minimally legalistic framework.

* Several prominent organizations developing and promoting open source software (OSS) use *trademark* policies to define and defend shared norms about  how to use and re-use text and code.  The Apache Foundation, Mozilla Foundation, Linux Foundation, Creative Commons, and others appear to have established trademark policies and executed them at a reasonable cost.

* To date, copyright protection (and the associated patent licensing commitments) have been the core elements in creating that identity and stability. A third element, trademark, has perhaps been underutilized in distinguishing W3C Recommendations from other Internet-related specifications.

* W3C currently has a strong copyright policy (consistent with most established SDOs but inconsistent with some other groups) and a relatively weak trademark policy.

* A combination of changes to copyright and trademark protection could be a better way to let implementers and the public know which Web specifications are products of the W3C process (and benefit from the associated patent commitments).  This  should be feasible without undue complications or expenses.

* Copyright: more and more web platform features are being defined outside of W3C with a CC0 Copyright Declaration: https://wiki.mozilla.org/Standards/license#Example_Specifications Thus it is proposed that to stay competitive as a venue for web platform standards development, W3C consider adopting a CC0 Copyright Declaration as its Copyright policy.

* Several prominent organizations developing and promoting open source software (OSS) use *trademark* policies to define and defend shared norms about how to use and re-use text and code. The Apache Foundation, Mozilla Foundation, Linux Foundation, Creative Commons, and others appear to have established trademark policies and executed them at a reasonable cost.

* The existing W3C trademark policy is fairly minimal. http://www.w3.org/Consortium/Legal/2002/ipr-notice-20021231#W3C_Trademarks is very short, mainly linking to http://www.w3.org/Consortium/Legal/2002/trademarks-20021231 and http://www.w3.org/Consortium/Legal/2002/trademark-license-20021231. In the simplest terms, W3C trademarks and protects the mark "W3C"  and some logos.


See also the [[AB/trademark-license#FAQ|FAQ]] for additional points of consensus.

== Discussion Items ==
Items requiring further discussion. We are capturing these in an attempt to have a specific list to go through and hopefully resolve.

* Public mailing list for trademark license discussions: an open-to-all mailing list on the subject of licensing will likely be counter-productive (per above previous experience).

* Create a public-ab mailing list: (if it already exists, we can document our intent to use it), where only members of the AB can post to it, but the discussions are publicly archived
** This would also provide a forum for discussing AB projects which we decide are "open by default" and thus further the "Open AB" effort in general.
** Over time we can hopefully move more AB project discussion traffic from the private AB list to a public-readable AB list.

* Differences in copyright license approach: Some members including Microsoft have expressed the view that a copyright license that explicitly enables new use cases for W3C documents *except* creating derivative normative specifications is a good way forward, others including Mozilla have expressed the view that W3C specs should be put in the public domain, e.g. with the CC0 copyright waiver.

* Identifying a spec as from W3C to some identifies it as well-developed and stable enough count on for the long run. In practice, this tends not to be the case due to:
** TR specs quickly getting out of date (in contrast to "living spec" documents outside of W3C, or even W3C Editor drafts, often in [[GitHub]].
** Errata quickly getting out date (issues queue up in email or other issue trackers)
** In practice implementers often don't see/read separate errata documents.

* Differences in copyright license approach: Some members including Microsoft have expressed the view that a copyright license that explicitly enables new use cases for W3C documents *except* creating derivative normative specifications is a good way forward, others including Mozilla have expressed the view that W3C specs should be put in the public domain, e.g. with the CC0 copyright waiver.

== Plan ==
* Work through remaining points of discussion and incrementally increase points of consensus in the process. Document any unresolvable differences.

* Document publicly known points of agreement and disagreement (being done on [[AB/trademark-license]]), and report that to the AC directly. At that point, assuming we can easily iterate based on AC feedback, we may be able to directly scope work for PSIG.

* Draft a joint message to the AC explaining the rationale for trying to build broad consensus on a combination trademark / license policy that transcends the recent disputes.

* Schedule a discussion / consensus building session at an AC meeting to try to get signoff on a way forward.

== FAQ ==
=== Community Group ===
Q: Should we create a community group to have the license scoping discussion?

A: No. It is likely that a Community Group (CG) would be counterproductive based on historical experience with public email threads in various working groups etc. on document licensing. In addition, joining a CG entails agreeing to a Contributor License Agreement.  This is unnecessary overhead for this discussion that does not plausibly create or infringe intellectual property.

=== ... add more questions here ... ===
Please add more questions here with a brief summary as === subheading === before this subsection.