4.0/Attribution and marking

From Creative Commons
Jump to: navigation, search

This page presented an issue for consideration in the CC license suite 4.0 versioning process. The discussions have now concluded with the publication of the 4.0 licenses, and the information on this page is now kept as an archive of previous discussions. The primary forum for issues relating to the 4.0 versioning process was the CC license discuss email list. You may subscribe to contribute to any continuing post-launch discussions, such as those surrounding compatibility and license translation. The wiki has been populated with links to relevant email threads from the mailing list where applicable, and other topics for discussion were raised in the 4.0/Sandbox. See the 4.0 page for more about the process.

Summary

This page aggregates discussion topics involving attribution and marking requirements, as the two are closely related and have never been clearly or uniformly differentiated. Attribution has been a standard feature of all CC licenses since the version 2.0 suite. Currently, attribution requirements are primarily contained in Section 4 of the 3.0 licenses. Marking requirements are interspersed throughout the license, including (in version 3.0) in Section 3(b), 4(a) and 4(b) of the licenses permitting adaptations, and in Section 4(a) of the two ND licenses (BY-ND and BY-NC-ND).

Treatment in drafts

(expand to read Draft 1 treatment)

Draft 1

In light of our goal to make CC licenses simpler and more user-friendly, we have considerably revamped the manner in which the attribution and marking requirements are conveyed in the license. Most importantly, we have consolidated all of the attribution and marking requirements into one section of the license, outlined them in list form and have labeled that section accordingly. To increase license compliance, we have provided that all attribution requirements may be fulfilled in any reasonable manner depending on the means and medium used. Last, we have added a shortcut, which allows licensees to include the URI associated with the licensed work (or a hyperlink) to satisfy several of the attribution requirements. We look forward to your input on these changes and others, including other suggestions for adjusting this provision to facilitate large collaborations such as Wikipedia. Our goal is to best ensure a proper balance between the author’s attribution rights and the need for flexibility given that any license violation results in automatic termination (at least as currently drafted). See also the discussion regarding relaxing the termination provision.

Note we have also added a bullet point addressing our treatment of each attribution and marking proposal below.

(expand to read Draft 2 treatment)

Draft 2

We continue our effort to make attribution and marking easy for licensees without undue burden (thus promoting greater compliance), while at the same time respecting the desire of licensors to have relevant information they provide included when the work is further shared. We have retained nearly all of the requirements from the first draft with a few variations intended for clarity and ease of application.

See this attribution and marking comparison chart to easily view differences between 3.0, 4.0d1 and 4.0d2.

One change is that the URI requirement is now simpler. The licensee must provide the URI or hyperlink to the source where the work can be accessed. Another change relates to the requirement to retain notices of disclaimers or warranties supplied by licensor. The difference in draft 2 is that licensees must retain any such notices when supplied by the licensor, rather than only those referring to the CC license. This change also supports a corresponding addition found in Section 6(b), which allows licensors to supplement the license to disclaim warranties or limit liabilities differently than the license does in Section 4, or to offer warranties. We have also expanded the URI shortcut, so that licensees may satisfy some or all of the requirements by linking to a particular webpage containing some or all of the necessary information.

We have eliminated the requirement to provide the title of the work and retain copyright notices, though ideally licensees will provide both when supplied by the licensor. In this spirit, we specifically encourage their retention by explicitly permitting licensees to use those notices to comply with any or all attribution requirements when they contain any or all of the required information. We hope this encourages licensors to consolidate attribution and marking information in a central location. Finally, in order to support many communities who have well-accepted practices for how attribution is given (e.g., in scientific and scholarly communities), we now make clear that attribution and marking requirements may be fulfilled in any reasonable manner based on the means, medium and context (the term “context” being new) in which the work is shared.

Finally, we recognize that these revisions may ease the problem of attribution stacking, but that the stacking problem and the challenges associated with attribution in the context of text-mining persist. We will be looking at these two problems more concertedly in the d2 discussion period.


(expand to read Draft 3 treatment)

Draft 3

This draft features only a few refinements to the attribution requirements as they appeared in 4.0d2. First, we have provided a bit more detail in connection with the requirement to identify the creator and other attribution parties. Licensees must do so in any manner reasonably requested by the licensor, including by pseudonym or trademark if designated. Note the shift in language away from “author” to the more inclusive term, “creator,” which is intended to better account for those licensing non-creative databases.

Second, we have reinserted the requirement to retain a copyright notice if supplied with the licensed material by the licensor. This puts v.4 back in line with v.3 on this particular point, and helps to encourage retention of this important information wherever it is reasonable. As with all of the attribution requirements, the obligation to retain copyright notices may be fulfilled in any reasonable manner based on the medium, means, and context in which the material is shared.

Another change involves the requirement to retain notices of disclaimers or warranties. This requirement now extends only to customized notices of disclaimers or limitations on liability, or an affirmative undertaking of warranties by licensors. Our reasoning is that the license itself is abundantly clear on the non existence of a warranty, and that the requirement should be imposed only when the disclaimer or warranty has been modified in some respect, as 4.0 now makes possible.

Last, we have consolidated and changed the requirements relating to modifications and the location of the original licensed material. Now, rather than indicating only where Adapted Material is created, licensees must indicate anytime they have modified the licensed material. (Not every modification results in the creation of an adaptation under copyright; some modifications are permitted even under the -ND licenses.) We want to be sure that whenever modifications are made, downstream licensees are aware of that and can get access to the unmodified original. We felt this change better served the interests of provenance and integrity of the original, but we seek further input on this and the other attribution and marking requirements during the public discussion period.

Draft 4

The attribution and marking requirements in draft 4 align closely with those in Version 3.0. For a detailed comparison against version 3, see this chart.

Comparison to d3: The requirement to retain a URI to the licensed material if it is supplied by the licensor now applies even where the material is used without modifications. We heard from many current and potential adopters that this requirement, which now mirrors Version 3.0, is important for provenance, branding, and other reasons. The requirement to indicate if you modify the material remains, but it is no longer tied to the URI requirement. We also added a requirement to retain an indication of prior modifications, so that important information about the source of a work (e.g., that a film is based on a novel) is retained. For inter-version compatibility purposes, we reverted to the Version 3.0 requirement to retain a notice about the disclaimer of warranties, but removed an obligation to retain a customized disclaimer (since those are no longer considered part of the license when offered -- see the explanation on the Disclaimers and warranties wiki page). One other substantive change is to make it clear that supplying the name of the author and attribution parties is only required if they are supplied by the licensor. We made a few other language and formatting changes to make the requirements as simple to understand as possible. We also altered the numbering scheme to ensure that the attribution provisions that are in all six licenses would have the same section numbers throughout the license suite.


Attribution

The current 3.0 licenses require users of a work to implement the following in any reasonable manner: See the Marking Page for further information.

  • keep copyright notices intact; and
  • reasonable to the medium or means used by the Certificate license,
    • providing the name is the original author's name (or her name, 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 and 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 [1]

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: See Section 4(a) of the licenses.

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(__), all requested.
And in 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. [2]

The attribution requirement was 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.[3]

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: Title is needed to help with tracking.
  • Other comments:
  • Treatment in 4.0 d.1: Consolidated, reorganized and simplified for greater understandability and to facilitate compliance.
  • Treatment in 4.0 d.2: Same.
  • Treatment in 4.0 d.3: Same.
  • Treatment in 4.0 d.4: Same.


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.
  • Treatment in 4.0 d.2: Same.
  • Treatment in 4.0 d.3: Same.
  • Treatment in 4.0 d.4: Same.


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.
  • Treatment in 4.0 d.2: Same.
  • Treatment in 4.0 d.3: Same.
  • Treatment in 4.0 d.4: Same.


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.
  • Treatment in 4.0 d.2: Same.
  • Treatment in 4.0 d.3: Same.
  • Treatment in 4.0 d.4: Clarified that author and attribution parties only required where supplied by the licensor.


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 ignoring, 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. See the 3.0/4.0 comparison chart on the 4.0 Drafts page for more details.
  • Treatment in 4.0 d.2: Incorporated some changes in this spirit by suggesting keeping intact existing copyright notices as a a way to comply with the other attribution requirements. See the d1/d2 comparison chart on the 4.0 Drafts page for more details.
  • Treatment in 4.0 d.3: Incorporated some changes in the spirit of this proposal. For example, all requirements now subject to reasonableness standard and requirement to include notices of disclaimers or warranties only applies when they have been customized by the licensor. See the comparison charts on the 4.0 Drafts page for more details.
  • Treatment in 4.0 d.4: Reverted to 3.0 requirement to retain notice of disclaimer of warranties, but still subject to reasonableness standard.


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.
  • Treatment in 4.0 d.2: Same.
  • Treatment in 4.0 d.3: Same.
  • Treatment in 4.0 d.4: Same.


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: Providing only a URI will result in works winding up as ARR in the future when the page to which that URI is directed is dead.(license discuss list )
  • Other comments:
  • Treatment in 4.0 d.1:Not incorporated in this draft.
  • Treatment in 4.0 d.2: Expressly allowed in this draft.
  • Treatment in 4.0 d.3: Same as d2.
  • Treatment in 4.0 d.4: Same.


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.
  • Treatment in 4.0 d.2: Same.
  • Treatment in 4.0 d.3: Same.
  • Treatment in 4.0 d.4: Same.


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. See also discussion regarding Relaxation of Termination Provision.
  • Treatment in 4.0 d.2: Further modified to no longer require title.
  • Treatment in 4.0 d.3: Further modified to relax termination criteria. See more detail about changes to the termination provision on the 4.0 Drafts page.
  • Treatment in 4.0 d.4: Same.


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.
  • Treatment in 4.0 d.2: Same.
  • Treatment in 4.0 d.3: Same.
  • Treatment in 4.0 d.4: Same.


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 with 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.
  • Treatment in 4.0 d.2: Changed so that licensees must indicate URI where the work can be accessed.
  • Treatment in 4.0 d.3: Changed so that licensees who make modifications must include URI to unmodified original.
  • Treatment in 4.0 d.4: Changed to require URI specified by the licensor.


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: The provision, in its 3.0 form, reassures licensors who are concerned their reputations will be irreparably damaged by a remix of the works which they license under Creative Commons.
  • Other comments: More information about this proposal is included in this email thread and 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.
  • Treatment in 4.0 d.2: Same.
  • Treatment in 4.0 d.3: Same.
  • Treatment in 4.0 d.4: Same.


BY Proposal No. 13: Change "reasonable manner" qualifier in attribution requirements to "any reasonably prominent manner" or "a reasonable manner consistent with, to the extent feasible, any customary attribution for the medium or means You are using.

  • Pros: Helps ensure that attribution is made as prominent as is reasonably possible.
  • Cons: May not add much because "reasonable" inherently means reasonably prominent.
  • Other comments:
  • Treatment in 4.0 d.1: Proposed after 4.0 d.1 publication.
  • Treatment in 4.0 d.2: Incorporated to some extent by including the concept of "context."
  • Treatment in 4.0 d.3: Same.
  • Treatment in 4.0 d.4: Same.


BY Proposal No. 14: Resolve the source of conflict between "in the manner designated by Licensor" (3.(a)(1)(A)) and "in any reasonable manner" (3.(a)(3)) in the public draft 2. One way is to add a language to 3.(a)(3) "For the avoidance of doubt, if you cannot strictly give attribution in the manner designated by the Licensor, it is okay as long as your manner of giving attribution is reasonable based on the medium, means and context in which the Work or Adaptation is used." A Licensor may well designate that the author should be attributed on the opening page of any Adaptation in color, with the author's name hyperlinked to a certain web page.

  • Pros: Resolve a (seeming) source of conflict that may stifle reuse of licensed works.
  • Cons: Additional words mean a lay person has to spend additional unpleasant time to read the license.
  • Other comments:
  • Treatment in 4.0 d.1: Proposed after 4.0 d.1 publication.
  • Treatment in 4.0 d.2: Proposed after 4.0 d.2 publication.
  • Treatment in 4.0 d.3: Added reasonable qualifier to "in the manner designated by the Licensor."
  • Treatment in 4.0 d.4: Same.


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"; [4]
  • for every copy of the work distributed or publicly performed, the licensee must: [5]
    • 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: [6]:
    • include a copy of, or the URI for, the license (for the original work); [7]
    • 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.
  • Treatment in 4.0 d.2: Incorporated change, though URI to work required in all cases.
  • Treatment in 4.0 d.3: Incorporated change, though URI to original work only required where licensee made modifications.
  • Treatment in 4.0 d.4: Incorporated change, though URI to work required in all cases.


Marking Proposal No. 2: Require description of changes made to original work in adaptations.

  • Pros: Makes it easier to identify the original work within an adaptation
  • Cons: Requires a lot of extra text that could get very detailed; increases burden on reusers
  • Treatment in 4.0 d.1: Proposal made after d.1 published.
  • Treatment in 4.0 d.2: Proposal made after d.2 published.
  • Treatment in 4.0 d.3: Not incorporated, but link to original work required when work is modified.
  • Treatment in 4.0 d.4: No description required, but licensees must retain indication of previous modifications and must indicate if they themselves modify the work.


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

Questions about attribution/marking in 4.0

In draft 1 of v.4, we tried to simplify the attribution and marking requirements by putting them all into one section of the license in list form. This is designed to make it easier for licensees to understand and comply with their obligations.

Specifically, when sharing the work, licensees must provide the following information when it is supplied by licensor:

  • Name of the author
  • Name of parties designed by licensor for attribution
  • Title of the work
  • Copyright notice
  • URI associated with the work
  • URI associated with the CC license
  • Notices, disclaimers, warranties referring to the CC license


(1) Is there any other information we should require licensees to provide when fulfilling the attribution and marking requirements under CC licenses? Alternatively, is there anything in this list that is unnecessary for licensees to provide even when it is supplied by the licensor? Our goal is to make the requirements extensive enough to satisfy licensors’ desire to be attributed and recognized for their work without making the obligations impractical.

  • Comments:
  • Is it necessary to require attribution? [1]
  • Can licensors select their desired attribution elements in the Chooser, rather than mandating a specific set? [2]
  • Should there be an element for related data sets? [3]
  • "Attribution Parties" should be dropped entirely. [4]
    • But: some works made possible/assisted by parties who are not the author; there should be space to credit them. [5]
  • Requiring removal of attribution may not be in line with DFSG. [6]
    • Benefit does not exceed cost if this is true, unless required by moral rights (which should be clarified). [7]
  • Publish a standard for correct attribution, but allow experimentation in community-developed standards, which licensors may follow but are not bound to. [8]
  • There are going to be scaling issues with requiring licensees to provide the name of the author - this could go all GFDL very quickly, with big bulky booklets or attribution pages required for the smallest amount of derivation. In particular, I'm worried about places like Wikipedia - you get articles with hundreds or thousands or tens of thousands of unique contributors. Listing all of them seems like the sort of overkill that undermined the GFDL, and is likely to cause implementation problems for licensors - if you come up to well-trafficked wikis and tell them that, in order to use 4.0 and not seriously vex anyone using their content, they're going to have to provide a method of getting an incredibly barebones list of all contributors to a specific page that people can copy and paste...that could take time and effort that are better spent on other things. Oliver Keyes (talk) 21:41, 26 June 2012 (UTC)
  • An additional concern is that "name of the author" is unnecessarily vague; I'd change it to "the author's chosen name or pseudonym" (which is basically how it works in the UK anyway - the author gets to choose). My issue is that when I see "name of the author", I think "real name", and again, I don't think this is likely to scale or apply to online works nicely. It reads as if contributors will have to out themselves to use the licenses without messing with licensees, and while I know this isn't what's meant, some clarity would be helpful. Oliver Keyes (talk) 21:41, 26 June 2012 (UTC)

(2) All of these requirements may be fulfilled in any reasonable manner based on the medium the licensee is using to share the licensed work. This flexibility is intended to help ease compliance with the license conditions. Does the current language grant licensees too much flexibility? Not enough? Is there anything else we should change to make it easier on licensees that are remixing content from multiple sources – the so-called “attribution stacking” problem?

  • Comments:
  • For many elements, licensees don't know how to comply and may be confused by leaving it open-ended; we should provide guidance and/or verbatim statements for unfamiliar elements such as "copyright notice". [9]
  • Many reusers are unfamiliar with the "URI" acronym and need explanation, examples, or replacement with amore common term. [10]
  • Amount of flexibility OK, but if adjusted should be in the direction of more flexibility. [11]
  • Allow experimentation in community-developed standards. [12]


(3) If the URI associated with the work refers to a resource that specifies the name of the author (or attribution parties, if applicable) and title of the work, licensees may include only the URI rather than specifying that information separately. This is another attempt to make compliance with the license conditions easier and more flexible without compromising the needs and expectations of licensors. Is this shortcut appropriate and/or helpful? If the URI points to a resource that includes the other required information (e.g., the copyright notice), would it be preferable to allow the URI shortcut to satisfy those other requirements as well?

  • Comments:
  • It is probably better to allow not just "a URI" but "one or more URIs." For example, it is common for MediaWiki-based Wikis (including this CC Wiki) to have multiple pages that list contributors. Such list of contributors for this page could be viewed by clicking "History" near the top of the page. And it is currently spanning two pages, having two different URIs.
    • Given that URL shortener is currently rather popular, it is better to allow "a resource referenced by the URI that is contained in the resource referenced by the URI" to also benefit from this clause. The current language may be interpreted that the resource containing (i)-(iii) above should be at the URI specified, as opposed to URI redirected from the URI specified.
    • Better yet, it should perhaps be allowed to use a URI for attribution to point to the resource referred to by that URI and other resources easily identifiable from that resource.
  • Allow a licensee to create a resource (such as a web page listing all attribution information), and use its URI, when that resource contains (i)-(iii).
  • In some cases, the resource at a URI contains only (i) and not (ii) and (iii). I think it is okay still to allow replacing the list of names of authors with a URI and supply (ii) and (iii) separately.
  • Copyright notices, disclaimers of warranty, etc., should be readable even offline, so URI alone is insufficient. [13]
  • Allow experimentation in community-developed standards. [14]


(4) Some licensors have more detailed expectations for attribution of their work. Should we make allowances for licensors who want to include specific attribution requirements (e.g., a particular attribution statement), or would this unnecessarily complicate license compliance? Note that any particular requirements would need to be subject to the reasonableness standard to be consistent with the explicit terms of the license.

  • Comments:
  • The complication could come from four sources that I can imagine: a) language and font that is not readily available for medium or means licensee wants to use; b) visual, audio, text, and other media-specific requirements that does not fit with licensee's medium or means; c) how a licensee (or even his lawyer) can know that some specific attribution is required when he is not fluent in the language, and/ or the work is voluminous; d) one may not know if an attribution element provided by a performer (in a video or audio work, say) or author, means "licensor" "supplied" that element for attribution, because the licensor's relation with the author /performer is not necessarily known to the potential licensees. (Is licensor the same person or not? is a question not necessarily easy to answer, for example.)
    • See also, this edit for some concrete examples of some of the difficulties surrounding attribution compliance.
    • These complications could result in failure to comply, and/ or decision not to use the work because of the high cost of compliance/ risk of failing to comply. But this is not really limited to "specific attribution requirements" discussed here.
    • One possible way to deal with this (or a part of this) issue is to tolerate failure to attribute when the attribution elements are supplied in a manner neither prominent, conventional, nor consolidated with other element that is supplied in a prominent or conventional manner.
    • A question arises when one uses URI (i.e. an external resource) to give attribution. Is
  • No, compliance with attribution is already difficult enough. [15]
    • Agreed with difficulty, and we don't want to make it harder to distinguish libre/non-libre content. [16]
  • Nonstandard requirements increase transaction costs. Community standards for additional requirements could enable automation to reduce these costs. [17]


(5) Another possibility is to change the language to a more general requirement to acknowledge the author and cite the original work. We could then include the current list of attribution and marking requirements as an example of best practices rather than as a specific legal requirement. This would potentially give licensees more freedom to adapt attribution to their particular circumstances, while maintaining the spirit and purpose of the requirements. Is this a proposal we should pursue? Why or why not?

  • Comments:
  • Pro: It is in general difficult to determine what is "supplied" by "licensor." It is not necessarily easy to determine what is title, author's name, notice referring to the license, etc. (See this edit for some concrete examples of some of these difficulties.)
  • Con: Citation may not enable the recipient of the work to find the original. Current level of requirement allow licensors to make sure that a recipient, if interested, can reach the original, and its author/ licensor.
  • Perhaps prominently and explicitly placed specific attribution requirements should be followed to the extent reasonably practicable with the medium or means to the licensee, but in other cases the attribution could be left to flexible interpretation of the licensee.
  • Yes, it gives more freedoms to users & encourages growth of free content community. [18]
  • No, insufficient for many licensors, especially some OER projects. [19]
  • Enable licensors to require a standard for attribution, let licensors figure out appropriate standard? [20]

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.

Notes

  1. Per Section 4(b) of the license, in the case of an adaptation or collection, where a credit for all contributing authors appears, the credit required must be at least as prominent as the credits for contributing authors.
  2. See Section 4(a) of the licenses that permit adaptations.
  3. Although, a licensor may always enter into a separate agreement with licensees to have attribution waived.
  4. See Section 3(b) of the licenses that permit adaptations.
  5. See Section 4(a) of the licenses.
  6. See Section 4(b) of the licenses that permit adaptations
  7. The international (unported) BY-SA and BY-NC-SA incorrectly refer to "Applicable License" in Section 4(b). This is a known error.