Proposal: Clarifying Copyright for mixed content in feeds via <podcast:copyright>

[fritz-fritz]

Clarifying Copyright for mixed content in feeds

Motivation

It seems the RSS 2.0 <copyright> tag is rarely adopted by clients and is not standardized very well. It also is only available at the channel level whereas feeds consist of multiple works that might fall under different copyrights (e.g. Images, Videos, Audio, Content, Music).

1. There are various types of copyright and multiple parties might have a claim (eg Sound Recording, Work of the Performing Arts, Musical Composition)
2. Items may need to support the copyright tag separately from the channel.
3. Individual copyright entries might use dates that differ from the publication date of the latest feed or item publication.

While the US Copyright Act leaves copyright notices as optional there are legal benefits for including them whether or not you register with the US Copyright Office.

Up until now I have been primarily appending copyright notice to the bottom of each episode description which works but is less than ideal.

Proposal

I propose adopting a new optional tag that would enable an easy to parse structure for revealing legal notice of copyright (which is different from the intention behind a license).

I would propose the following where type and year are optional free form fields and copyright can be specified more than once:

  <xs:element name="copyright">
    <xs:annotation>
      <xs:documentation>
        The person or organization claiming copyright.
      </xs:documentation>
    </xs:annotation>
    <xs:complexType mixed="true">
      <xs:attribute name="type" type="xs:string" use="optional">
        <xs:annotation>
          <xs:documentation>
            What they are claiming copyright.
          </xs:documentation>
        </xs:annotation>
      </xs:attribute>
      <xs:attribute name="year" type="xs:string" use="optional">
        <xs:annotation>
          <xs:documentation>
            The year or year range of the claim.
          </xs:documentation>
        </xs:annotation>
      </xs:attribute>
    </xs:complexType>
  </xs:element>

• A <podcast:copyright> would supersede a <copyright> tag in supporting clients.
• A <podcast:copyright> without a year should default to the publication date of the item or channel.
• A <podcast:copyright> with a specified type should be associated with the value.
• An item without a <podcast:copyright> should inherit the channel <podcast:copyright> value if present but use the item pubdate.

Example:

<channel>
    <copyright>Organization Name</copyright>
    <podcast:copyright year="2020-2025">Organization Name</podcast:copyright>
    <item>
        <title>Example 1</title>
        <podcast:copyright type="Sound Recording">Organization Name</podcast:copyright>
        <podcast:copyright type="Music" year="1995">Artist Name</podcast:copyright>
        <podcast:copyright type="Content" year="2024">Speaker Name</podcast:copyright>
    </item>
    <item>
        <title>Example 2</title>
    </item>
</channel>

This style would be quite easy for clients to iterate and parse:

Channel:
> Copyright 2020-2025 Organization Name

Example 1:
> Sound Recording Copyright 2025 Organization Name
> Music Copyright 1995 Artist Name
> Content Copyright 2025 Speaker Name

Example 2:
> Copyright 2025 Organization Name

I believe that podcasts would generally fall under Collective Works and the episodes themselves would qualify as a Sound Recording.
If you wanted to codify the types we might be able to reference the Works of the Performing Arts Compendium from the US Copyright Office or their registration portal but I think generally speaking leaving this a free form field might be sufficient.

Benefits

1. Legal clarity for creators and listeners
   Including structured copyright metadata offers clear attribution and ownership, which benefits creators and contributors.
2. Granular support for multi-party content
   Podcasts frequently contain layered IP — music, sound design, speeches, interviews. This proposal enables clear, structured ownership declarations for each, at both channel and item levels.
3. Improved client behavior and UI presentation
   By providing a machine-readable structure, apps and players can optionally display proper legal notices or attributions.
4. Alignment with legal best practices
   While not legally required, including copyright notices has tangible legal advantages, such as rebutting “innocent infringement” defenses and asserting your rights proactively.
5. Backwards-compatible with RSS 2.0 and
   This proposal is additive. Clients not supporting the podcast: namespace will gracefully ignore the tag, while newer clients can use the structured data.

I see this particularly useful for audiobook series published as a podcast, episodic speakers giving talks/lectures, and music podcasts amongst others.

[samsethi]

Hey @fritz-fritz

TrueFans already supports the original RSS 2.0 copyright tag and the Podcasting 2.0 license tag.

I agree that often there is no Copyright declared in RSS feeds, so we automatically complete this field if it is blank with a Copyright statement - Year, Podcast Name etc.

Equally, if there is no license, we automatically add All Rights Reserved. Of course, if these fields are pre-populated in the RSS feed we respect that.

If I read you correctly you want to add Item Level Copyright and License options as the current spec only support the Channel level? And the other change is to provide multiple copyright options. This is very easily done but do you have an RSS feed or Podcast with this requirement.

[fritz-fritz]

If I read you correctly you want to add Item Level Copyright and License options as the current spec only support the Channel level? And the other change is to provide multiple copyright options. This is very easily done but do you have an RSS feed or Podcast with this requirement.

This proposal concerns specifically the copyright and not license.
Yes I believe we should support both channel and item level declarations.
Yes both channel and item level should support multiple declarations.

The way I see it is all podcasts are already publishing mixed media via image, audio, and feed itself. Each of these might need separate copyright notices. Now that video enclosures are supported that only adds to the potential. Each deliverable might also be comprised of different elements of which copyright notice should be provided.

Personally, I'm hosting a feed for a group which is comprised of recorded talks. The group claims copyright to the podcast, images, and the sound recording but not to the content of the recording. The content copyright remains the IP of the speaker.

Example

Let's presume a theoretical feed with the subject of video games that includes a video enclosure. An episode of this feed would presumably discuss and show footage from a video game.

• The feed itself would be copyright by the podcast publisher
• Each episode would have a sound recording copyright by the podcast publisher
• The video game footage, branding, and logo would be copyright by the video game publisher
• The episode might include music which would be copyright by the music publisher

While providing notice of these copyrights might be considered optional by the US Copyright Office, brands such as Nintendo, Sony, and Disney are known to be quite litigious and usage of their IP (even under fair use) without providing notice of their copyright could be a problem.