4.0/Attribution and marking

Attribution

The current 3.0 licenses require users of a work to implement the following in any reasonable manner: ^[1]

• keep copyright notices intact; and
• reasonable to the medium or means used by the licensee,
  • provide the name the original author (or her pseudonym, or other attribution party, when provided);
  • provide the title of the work if supplied;
  • include the URI associated with the work (if it refers to the copyright notice or licensing information); and
  • where an adaptation is created (when permitted by the license), include a credit stating that the work has been used in the adaptation ^[2]

All 3.0 licenses allow licensors to request removal of the credit when their works are reproduced in a collection, as well as when their works are adapted (where permitted by the licenses). Specifically, all six version 3.0 licenses provide: ^[3]

If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(__), as requested.

And in BY, BY-SA, BY-NC-SA, and BY-NC, additionally:

If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(__), as requested. ^[4]

The attribution requirement is reflected on the CC deeds as:

Attribution – You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

A few legal decisions have successfully enforced the attribution requirement.

The attribution requirements have drawn some criticism:

1. General difficulty understanding what is required on the part of licensees, in part due to the “reasonable to the medium or means” language but also because the language is difficult to parse.
2. Are too onerous and do not align with community practices.
3. The requirements insufficiently anticipate or account for analog distributions and performances, making it challenging to comply (same criticism is equally applicable to other marking requirements, below).
4. Absence of a mechanism for requesting or permitting removal of a credit for reproductions of an unmodified work when not reproduced as part of a collection.^[5]

Note: For criticisms, issues and proposals relating to attribution requirements for adaptations, please see the 4.0/Treatment of adaptations page.

Proposals for attribution in 4.0

For ease of reference on discussion lists, please do not alter proposal numbers.

[Note: these proposals are not necessarily mutually exclusive]

BY Proposal No. 1: Consolidate the attribution requirements into a single location within the licenses (e.g., Section 4) and simplify language, including all other marking requirements (see below), such as providing the URI for the license.

• Pros: Users of licensed works would understand requirements more easily, which fosters reuse.
• Cons:
• Other comments:
• Treatment in 4.0 d.1: Consolidated, reorganized and simplified for greater understandability and to facilitate compliance.

BY Proposal No. 2: Introduce further flexibility into the requirements, to bring them closer into alignment with community practices.

• Pros: This would reduce unintentional violations of the licenses, which is especially important because a violation of the license results in automatic termination.
• Cons:
• Other comments: For example, one proposal from license-discuss is to remove the provision requiring that a credit for an adaptation or collection must be as prominent as the other contributing authors. This requirement might be excessive in some circumstances.
• Treatment in 4.0 d.1: To increase license compliance, attempted to introduce more flexibility by providing that all requirements may be implemented in a reasonable manner.

BY Proposal No. 3: Expand the existing mechanism for requesting removal of the attribution credit so licensors can request removal for any reuse.

• Pros: There may be situations where licensors would prefer not to be associated with a particular website, and this would enable them to avoid association by removing attribution credit.
• Cons: Allows people to require removal of author's name even where credit is accurate and factual.
• Other comments:
• Treatment in 4.0 d.1: Incorporated change. Note that this revision may also have relevance where the moral right of withdrawal exists, arguably giving the licensor a functional equivalent when using a perpetual, irrevocable public license.

BY Proposal No. 4: Create a mechanism in the license allowing licensors to waive attribution completely.

• Pros: Potentially useful for keeping alive CC BY-SA but waiving BY aspect without needing a separate and incompatible copyleft (CC SA, which existed and has been deprecated for some time)
• Cons: Reduces need for and potential adoption of CC0.
• Other comments: Couldn't a licensor waive attribution requirements outside of the license with an additional statement and without needing to add anything to the legalcode?
• Treatment in 4.0 d.1: Not addressed in this draft, although draft does permit licensors to seek removal of attribution elements for any reuse, including reuse in unmodified form. May be possible to address as technical solution rather than within legal code.

BY Proposal No. 5: Relax the requirement to "keep intact" copyright notice, notice referring to the license, and notice referring to disclaimers of warranty; and allow translation, contextualization, and possibly other modification of those notices.

• Pros: Reduces the risk for users to overlook copyright notice, notice referring to the license, or notice referring to disclaimers of warranty. This risk is higher in at least 2 situations: 1) When those notices are written in languages that a user do not understand well; and 2) When the work under a CC license is long or complex. For example, a notice referring to disclaimers of warranty might not be easily detectable in a given photo gallery web site with multiple pages with many different sections. (And you are required to keep intact "all" such notices.)
  • Allowing contextualization of the notices would reduce the risk of bearing non-sensical or even ineffective notices. For example, if you use a text from web page to create a book, to "keep intact" a notice saying "content of this web page is under CC-BY 3.0 Unported" does not make good sense for readers of a book. (And in practice, many license notices are written in this kind of context-specific way.)
  • In some cases, to "keep intact" a notice is impossible. For example, a notice may be given as an audio, as a part of radio program. A user cannot "keep intact" the audio notice if he wants to use the content of the audio for a photo or a book. More importantly, notice seems to be given visually in many cases, by using a CC license logo. To keep intact a logo may be challenge if a user wants to create a non-visual work, or use the work in an environment where only text-data is usable.
  • In theory, this requirement to keep intact "all" notices could be used to intentionally block further reuse even when license and technology would allow reuse. Imagine a user of a licensed CC-BY-SA work adds a few hundred notices to an Adaptation. Those who wishes to use such work would find it very difficult to comply with the requirement to keep intact "all" such notices. Allowing more flexible attribution and marking would prevent such effort. Another theoretical example would be to embed notices in easy-to-overlook places within a movie, a video game, or a long book. A user may need to first find all the notices to comply with the requirement to keep intact "all" notices.
  • Note also that reuse (creation of adaptations/ derivatives) under BY-SA licenses would end up accumulating license notices. "This work is licensed under Creative Commons 2.0 Generic" may appear "This work is licensed under Creative Commons 3.0 US." That would look like the work is dual-licensed, while it is not. It is simply that an original work was under 2.0, and a derivative is under 3.0.
  • As far as I can tell, in practice, very few people comply with (or even understand) this requirement, so relaxing it would have the effect of bringing the license into alignment with common usage. If common usage has been ignorning, at least to some extent, this requirement for the past 5 or 6 years, then that is probably a pretty good argument against the con that unwanted exploitation might arise, as I'm not aware of any court battles over this point.
• Cons: Like many relaxation of requirements, it could serve as an opening for unwanted exploitation.
• Other comments: I think there is some room for interpretation what exactly is to "keep intact."
• Treatment in 4.0 d.1: Incorporated some changes in the spirit of this proposal.

BY Proposal No. 6: Make clearer what is meant by "credit" by stopping the use of the word in two different ways. - "a credit identifying the use of the Work in the Adaptation" is one place where the word appears, and "remove ... any credit as required by Section 4(b), as requested" is another place where the same word is used but to mean a wider set of information.

• Pros: Increase the ease of complying the license terms, and reduce unintended failure to comply with the requirements.
• Cons:
• Other comments:
• Treatment in 4.0 d.1: Incorporated change by avoiding use of the term credit in this draft.

BY Proposal No. 7: Explicitly allow attribution via a provision of a URI, when a web page with that URI provides attribution

• Pros: This would solve the problem sometimes referred to as attribution stack-up - when there are too many authors to attribute to, that would restrict the scope of reuse. Allowing the use of a web page to provide attribution, and requiring just a display of its URL for attribution would make reuse possible in those cases. A typical example - copying some text from Wikipedia's heavily edited article to a blog. If you need to copy the whole list of the authors, it could be difficult and time-consuming. If you could simply show a URL of the page on Wikipedia where you can see a list of people edited the page, that would be a lot easier and quicker.
• Cons:
• Other comments:
• Treatment in 4.0 d.1: Incorporated change, but we have retained requirement that the licensee must provide the URI only if it references copyright notice or licensing information. Further input needed, including suggestions for other alternative means for allowing attribution.

BY Proposal No. 8: Consider giving the right to request credit removal to actual people receiving credits. - The current license allows only licensor to make such a request. Note that a CC licensed work may not carry information about licensor's name or contact at all. Credits may tell licensee about authors and other entities the credits are given to. When a CC-BY-SA work is adapted a few times by a few different parties, a licensee may not be able to tell who the licensors are.

• Pros: When removal request has to come from a licensor, there are two consequences: 1) A licensee cannot tell a removal request coming from authentic licensor from fake one, and 2) authors and other entities receiving credits may or may not necessarily know how to contact a licensor when they want to request a removal.
• Cons: A complication could still arise if this proposal is implemented because authentification of authors and other entities receiving credits are not easy, either. It is perhaps easier than telling who is a licensor for a given set of credit.
• Other comments: In general, it is not easy to understand the distinction between an author and a licensor.
• Treatment in 4.0 d.1: Not included. Granting rights to third parties who are not a party to the license presents challenges on multiple levels.

BY Proposal No. 9: Consider limiting the "keep intact" and other crediting & marking obligations to only those pieces of information that are clearly present and easily identifiable. Make a licensee's failure to comply with properly crediting not a trigger for terminating the license. - For example, it is often difficult to tell if a URI accompanying a work is "specified" by the licensor. The same can be said even about the name of an author, when there are more than one name displayed for the same account. Flickr accounts may have an account name and a name of a person. It may be difficult to tell if a file name is meant to be a title for a photo or the photo is untitled. Many blog posts are accompanied by poster's account names, separate from their full names (typically linked from those nick names), which is different from name of the organization (typically found at the copyright notice) the blog is for. Which name is "supplied" as the name of the Original Author in this case?

• Pros: Increased ease of use of licensed works.
• Cons: In theory, unwanted crediting, or omission thereof may increase.
• Other comments:
• Treatment in 4.0 d.1: Incorporated change by specifying that only information supplied (such as name and title) must be provided and subjecting all requirements to reasonableness standard.

BY Proposal No.10: Consider increasing machine-readability of credits and marks.

• Pros: If a simple script can identify all or most of the information needed for giving a credit, it would improve license compliance for a wider range of works and licensees.
• Cons: If done in legalcode(?) this could result in massive incompliance with licenses, as machine-readability is hard to get right
• Other comments: It seems like this should be done regardless, but in external tooling work by the tech team and the rest of the CC-using ecosystem?
  • It's not clear what this proposal means to say. For example, the HTML provided by the CC license chooser does contain attribution metadata, as long as the copyright holder provided that information when the filled out the chooser form. As far as downstream reuse, this proposal would imply that reusers would need to likely manually enter that metadata, which isn't going to happen. At the moment, the main way in which this attribution metadata is revealed to reusers is if they follow the license mark to the license deed, in which case attribution HTML will be provided on the deed, which itself contains metadata. However, not everyone will click through to the deed.
• Treatment in 4.0 d.1: Not addressed in draft because this is a technical rather than legal proposal.

BY Proposal No. 11: Clarify the language about URI specified by the licensor - currently it says, in part, "unless such URI does not refer to the copyright notice or licensing information for the Work," and what it means seems to be "as long as resource identified by such URI includes the copyright notice or licensing information for the Work."

• Pros: In a Web environment, many people may like to be attributed via some URL, such as a personal site or web page. Limiting the requirement of attributing wih a URL to only when the URL contains copyright information probably isn't what most people have in mind.
  • Allowing a copyright holder to require attribution to a URL (any URL, regardless of what is behind it), may make it easier for downstream reusers to actually know who the copyright holder is, and how to contact them for additional permissions. For example, if I find an image on some web site and all the data I have is some user name and the CC license mark, then it may be nigh impossible to contact the copyright holder. On the other hand, if a licensor can require attribution to some certain URL, then finding that person suddenly becomes much more feasible.
• Cons:
• Other comments:
• Treatment in 4.0 d.1: Incorporated change.

BY Proposal No. 12: Remove provision that allows licensors to request removal of attribution or amend it to cover only requests for removal of misleading or inaccurate attribution.

• Pros: This provision arguably does not meet the Debian Free Software Guidelines because it requires removal of attribution upon request, even where attribution is accurate and not misleading.
• Cons:
• Other comments: More information about this proposal is included in this email thread from license-discuss.
• Treatment in 4.0 d.1: Not incorporated. The purpose of this clause is to allow those receiving credit to distance themselves from reuses they may find objectionable. This encourages use of public licenses by those wishing to share but who are concerned about being associated with those uses. In all events, in this draft as in 3.0, removal is required only when reasonably practical.

Please add other BY proposals here, and number them sequentially.

Marking requirements

Beyond the marking requirements related to attribution described above, the CC licenses contain additional requirements for properly marking a CC-licensed work:

• in those licenses that permit adaptations (BY, BY-NC, BY-SA, BY-NC-SA), if an adaptation is made (including any translation in any medium), the licensee must take reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work"; ^[6]
• for every copy of the work distributed or publicly performed, the licensee must: ^[7]
  • include a copy of, or the Uniform Resource Identifier (URI) for the license;
  • keep intact all notices that refer to the license and to the disclaimer of warranties;
• for every adaptation of the work that is distributed or publicly performed (where adaptations are permitted), the licensee must: ^[8]:
  • include a copy of, or the URI for, the license (for the original work); ^[9]
  • keep intact all notices that refer to the license (for the original work) and to the disclaimer of warranties.

These marking requirements have attracted some criticism:

1. For adaptations, lack of clarity or uniformity as to placement of the mark or label indicating that changes were made to the original work.
2. Absence of flexibility (such as through a reasonableness requirement) for inclusion of the URI.

Note: For proposals relating to marking requirements for adaptations, please see the 4.0/Treatment of adaptations page.

Proposals for marking requirements in 4.0

For ease of reference on discussion lists, please do not alter proposal numbers.

Marking Proposal No. 1: Making the inclusion of the URI subject to a "reasonable to the medium or means" requirement

• Pros
• Cons
• Other comments
• Treatment in 4.0 d.1: Incorporated change, though only required if the URI references a resource containing attribution or licensing information.

Please add other marking proposals here, and number them sequentially.

Related debate

We encourage you to sign up for the license discussion mailing list, where we will be debating this and other 4.0 proposals. HQ will provide links to related email threads from the license discussion mailing list here.

Relevant references

Please add citations that ought inform this 4.0 issue here.

• ePSIplatform guest blog post dated February 11th, 2011: "CC tools and PSI: Supporting attribution, protecting reputation, and preserving integrity"
• Best Practices for Marking Content with CC Licenses: Users

Notes