STYLE-607: Copyright / Phonographic copyright dates

Right now, there seems to be no definition at all of what the dates mean on copyright / phonographic copyright rels, or at least it’s not in the relationship guidelines.

In a lot of cases I’ve seen, they seem to be used with the start date of whatever is printed and an open end date, I assume to represent that it’s not just they had the copyright for that one year. That kinda breaks for cases like “(P) 2000 - 2001” though, unless we should be doing "2000 - ". We should probably decide how this should be dealt with. For an example, see the rels for HNH International Ltd.

I’m not very familiar with the legal side of the music industry, so I don’t really know what’s a good way of dealing with this. I’d love some input on it!


Well I have only seen and set closed dates, so far.
I do set closed dates. Phonographic copyright gets distributed on all release recordings with date and copyright stays on the release with date.
Imo single closed date not only looks good but also sounds as the correct meaning as what is shown on those back cover small prints.

Just an example:

1 Like

It says on Wikipedia that

Before 1989, the use of a copyright notice – consisting of the copyright symbol (©, the letter C inside a circle), the abbreviation “Copr.”, or the word “Copyright”, followed by the year of the first publication of the work and the name of the copyright holder – was part of U. S. statutory requirements.

so, in my totally non expert opinion, it would make sense that the number next to the copyright symbol represent the first year that the release had copyrights held by said label… So it should not be left open, I guess.

As for phonographic copyrights, it should be moved at the recording level if it’s the same for the whole release. If it’s many different years specified after the § and we can’t figure out which recording is corresponding to which year, it should be entered at the release level. Using the same logic, it should be closed as well (the first year).


If I see © 2001 I will set that as “2001” start and end date, and understand it to mean “XXX held the copyright in the year 2001”.

I understand "2001 - " to mean “2001 to present”, which is often not true (copyrights are frequently transferred, and obviously any given publication cannot see into the future to know that.).

Reading back, I guess I’m basically saying I agree with Lotheric, though with slightly different logic in mind.

1 Like

@fmera posted this in the Jira ticket, copying it here to keep the discussion in the same place.

Right now, there seems to be no definition of what the dates mean on copyright / phonographic copyright rels.

actually, there is. the year next to ℗ & © symbols denotes the “date of first publication”* (see note below). ℗ pertains to the sound recordings while © pertains to all “visually perceptible” elements of copies of a phonorecord (which can be any medium, including digital releases, containing the sound recordings).

from that year, the sound recordings and phonorecord copies enjoy a certain term of copyright protection. the number of years sound recordings enjoy this protection varies. the determination of the period is a bit tedious to figure out though. (incidentally, since Mar 1, 1989, copyrights notices have been optional; even if no copyrights notices are printed on releases since that date, those releases still enjoy copyright protection nonetheless.)

The 1976 Copyright Act defines publication as “distribution of copies or phonorecords of a work to the public by sale or other transfer of ownership, or by rental, lease, or lending.” An offering to distribute copies or phonorecords to a group of persons for purposes of further distribution, public performance, or public display also constitutes publication.
as for whether one should add a closed or open date, it is a matter of interpretation. one could say that a particular release was first published in 2001, so ℗/© 2001 could denote the year an event took place, and a certain term of protection following that event is implicit. alternatively, one could also interpret the year as the start of that certain term of protection. what the latter approach does better though, is that sometimes you will encounter releases inadvertently giving different ℗ dates for the same recording(s), when a sound recording obviously cannot have more than one “date of first publication” event unless there are valid reasons*; otherwise, the clock starts ticking from the earliest date of publication. so reflecting copyrights as a span rather than as an event deals with this situation better when inconsistencies or ambiguities arise.

reasons for different “date of first publication” - remasters? different dates for different regions under different companies? copyright term extensions? i don’t know if these count as valid.
© copyrights, by their nature, can only be attached to releases, since they protect all the “visually perceptible” elements of copies of a phonorecord, everything from artwork & photography to literature, everything except for the sound recordings, which are protected ℗ copyrights. as packaging can evolve, so too can © copyrights “date of first publication” change, while still embodying the same sound recordings as earlier iterations of a phonorecord.

That kinda breaks for cases like “(P) 2000 - 2001” though

that does not make sense. perhaps the editor misinterpreted info presented by the release. eg, in the compilation some recordings may have been first published in 1990 and others only later in 1997, so the compilation might have reflected that as “℗1990,1997 HNH International Ltd.” (something you’ll see practiced fairly often) to indicate different “first publication” dates for unspecified sound recordings contained in the compilation.

sorry about the length; i did try to trim it down.

1 Like

I don’t mean a “real world” definition, I mean that the relationship pages have no info on how they’re supposed to be used. If we want to use open-ended relationships, that’s a deviation from the standard so we definitely should indicate that. Even if we want to use closed, same start and end date ones, the fact people are using different options right now suggests we should write something down.

That editor was me, and I didn’t misinterpret anything :slight_smile: The credit is “℗1990-1997 HNH International Ltd.”, which obviously means different recordings have different ℗ years. Given ℗1990-1997 at the release level is all we have, though, the only reasonable choice is to decide how that range value should be entered at the release level (if someone finds enough info to apply the specific ℗ to each recording later, that’s great). After all, that’s the whole point of having release-level rels for any recording-related stuff: they can be used when we don’t know which recordings they apply to.

1 Like

It is also not well-defined, since the length of protection and sometimes other details vary between countries. E.g., it is quite common for certain works to be out of copyright in Canada already, while most other countries still consider them copyrighted.

That is a purely U.S. point of view. Most other countries have never required copyright notices.

About that begin=end approach.
I think

  • It looks good in MB
  • It is easy to not mistake (ignoring specific time span for each country’s law at that time) as we just read what’s printed
  • It still is meaningful in a way (The ℗ or © was registered on that year/date. That registration action is ended, however long the recording or release status remains)

I don’t know if I neglected to include it in the original RFC/V to add this in the first place, but the intent was not to have open-ended years. Often, releases are manufactured to include specific years (e.g., it may say “©1997, 2004, 2009 Company”) so it doesn’t make sense to me to erase those facts from our release relationships.

“℗” of course can exist at the release level. There is certainly the concept of release-level copyrights on packaging, artwork, the music/compilation as a whole. Is it any different from having a single release artist credit and many track artist credits co-existing?


Thanks for this! :slight_smile: I think knowing the intention behind the original request was for closed dates, and also given what @jesus2099 said above (which I pretty much agree with), it’s reasonable to specify that the date should be what’s printed in both begin and end (unless a range is given). I’ll keep this around for a bit longer to see if someone thinks that’s a terrible idea and why, but if not I’ll make that change after some days :slight_smile:


I’ve been entering ©’s and ℗’s “open-endedly” as I don’t subscribe to the “no end date = still current” thought, but rather “no end date = we don’t know if it’s ended or not”, and I feel it’s wrong to enter “© 2000 Fooizzle” as “copyright Fooizzle (2000-2000)” if they still retain copyright post-2000. “Copyright Fooizzle (2000-)” to me indicates that they held the copyright since 2000 and until an unknown time - possibly still current.

I don’t think presentation issues (ie., whether it “looks good”) should be used as basis for a decision on how to store data. MBS is “just” an interface to the data, and presentational issues should be fixed in code, not in data… IMO.

(I would have replied sooner, but I’ve been otherwise engaged for the last week.)


That’s how it is for birth/death dates, at least. I would assume AR dates to work similarly.

Maybe there’s some conflict between our AR “held copyright” and what the copyright notice is trying to show, and/or the intent of various editors.

If we’re trying to strictly record information about a release, i.e. what the release says then closed dates are more appropriate. If we’re trying to record the history of the holder of copyright then open dates are more appropriate, though much harder to back up with facts; Also if we’re trying to record information about the audio rather than a release’s cover art, we should be completely ignoring © in favor of ℗.

1 Like

Not really. If an artist end date isn’t specified, it doesn’t mean that the artist has not ended - just that we don’t know about it. If I hadn’t marked that Rovers Ahead has officially disbanded, they wouldn’t have an entered end date (and would not have the “ended” flag either) in the database, but they would still have disbanded.

How so? The release tells us when ©/℗ starts, not when it ends. A “close-ended” relationship adds more information (ie., an end date) than what is provided by the release.

No, but it means that MB believes that the artist has not ended. Obviously the database is not infallible but that doesn’t change the meaning of the field.

Incorrect: The release tells us the date on which the copyrighted work was first published. “First published” is a definite point in time (at least within the resolution of one year), and it ends immediately once publishing is completed.

That’s not quite the same thing as what the AR says though, which is “held [phonographic] copyright”; it is true that we are assuming the copyright holder continued to hold the copyright even after the release was first published, but that’s not what the release actually says with a © date.


Well, let me repeat myself then :slight_smile:

IMO the back covers say that this has been published or copyrighted on this year. This action of registering the stuff was made by filling some administrative form out, at some point in time in the specified year.
It is an instantaneous action that started and ended, like when the recording is recorded or like when a wedding takes place.

As we cannot seriously pretend that we would be able to deduce the end date for a single instance, we may rename this relationship if necessary so that its meaning is the one described above, the registration act is the only thing we can know without enrolling some Sherlock Holmes. :slight_smile:


Given the feedback here plus my own view on this, I’ve added the following guideline to the relationships:

When a year is specified (as in “℗ 2015 Artist”), use that year as both the begin and end date.

If someone feels that the relationships should be renamed or tweaked to adapt to this, please add a second STYLE ticket and I’ll open a discussion on the matter ASAP :slight_smile: