How does the EU General Data Protection Regulation (GDPR) affect MusicBrainz data

musicbrainz
gdpr
Tags: #<Tag:0x00007f98ce681fc8> #<Tag:0x00007f98ce681e38>

#1

I finished entering my music collection into MusicBrainz two of months ago and in the process learned the fantastic capabilities of this database beyond just tagging music. The historical information possibilities of this database are limitless (at this time). The present schema gives the ability to link all forms of data together and allows the user to decide what data they want to search.

With relationships filled in the research capabilities are limitless, we could search the history of music. We could trace music by type and location, we could find all the groups a person played with (as a member or featured artist).

For academics it could make a fantastic starting point for research and allows the researchers to provide feedback with more data and error corrections.

What happens if a artist asks to have information removed? If MB is asked to remove a birthday, can you still keep the birth year? Time is a universal search tool both as research and verification. When does public information no longer become public? When does a public figure no longer become public? Could this “regulation” lead to pay walls. Could artists and their labels band to gather to squeeze the last infinitesimal monetary value out of this information?

I ask this because I have just begun to enter relationships and works for composers/lyrists (songwriters) and as I research the ones I am entering it has become common for me to add new songwriters who were a part of the work. As I do this the “spider web” gets larger and larger, I am not content to leave a artist or songwriter “hanging” out there with little attached to them.

This is days of work and if it is going to be removed then why enter it in the first place.

I am not trying to be an alarmist, I have read through some of the regulation and do not totally understand it. I believe in the right to privacy for all individuals (even politicians), but a compromise needs to be made in these regulation and laws on “some” of the information that is already publicly available.

I asked about the date of birth earlier because that is one of those questions that get asked of you for verification (at least here in the US). Personally I have heartburn with the full date for a living person being stored and believe to some degrees it is an evasion of privacy even if the data has been made public. In research the granularity of timelines in days can be important so I am not sure where I stand on the subject.

An interesting question is to ask where do Google, Wikipedia, and others fall into this? I guess MusicBrainz is asking itself the same question.


#2

It’s an interesting topic, and a few things have been said about it already relating to MusicBrainz, including by @rob here.

I don’t think it will have a large effect on the data in MusicBrainz, because the GDPR makes a specific exception for “archiving purposes in the public interest”, which MusicBrainz, Wikipedia et. al clearly are (not sure about Google though).

By the way, you may want to add “gdpr” as a tag to your topic for future reference. :slight_smile:


#3

Thanks, I asked a question in that thread, and I am watching the “gdpr” tag now.


#4

I’m just someone that has been reading meeting notes etc and have not been involved in anything.
I believe to support GDPR there have been a few minor changes:

  • The site no longer uses google analytics
  • There now needs to be a delete account button on all sites so this is being added to listenbrainz and critiquebrainz etc

#5

Hello!

I’m planning on posting a blog post on May 25th outlining all of the actions we’ve taken towards GDPR compliance. We’ve been discussing this topic for months now and have had a number of people advise us on how to comply. The good news? Our standards for data privacy were good to start with; I would summarize our efforts towards GDPR compliance as “a couple of minor fixes and improving verbiage to be more GDPRy”.

Google Analytics and LIstenBrainz “processing” acknowledgement are the two biggest changes that we’re making towards this effort. Completely automatic removal of user accounts when a user removes their MusicBrainz account is another one, but that will not be complete in time for GDPR day. In the meantime someone can remove their account by mailing us, which is not ideal, but GDPR compliant.

What happens if a artist asks to have information removed?

We remove birth day and birth month information if an artist requests it. Other information in MusicBrainz is not Personally Identifying Information, but public record. We clearly stand as an organization that is archiving public (non-personally identifying) information and people wishing to remove data from MusicBrainz need to have a compelling reason to do so. We get these requests periodically, but very few are granted.

So, really we anticipate no real changes to how we operate – please keep adding data to MB! And yes, we’ve been having a lot of discussions around this and informal discussions with Wikipedia and Google suggest that they are also aware and working very hard at addressing this. I can’t imagine what sort of hell must be happening in the EU offices of Facebook. (serves them right, methinks :slight_smile: ).

I hope this answers your immediate questions – if you have burning follow up questions, please ask them. Otherwise I ask that you wait for the GDPR blog post to appear, which should hopefully address the bulk of questions for people.

How does that sound?


"Remove my info for privacy"
#6

Even an artist’s legal name?


#7

Yes, even an artist’s legal name.


#8

If that is what is required, but it may make some research much harder. The ISWC database and even ASCAP have creator IPI codes listed under legal name, some form of legal name, “stage” name, nick name, or other, I have been filling in Artist IPI codes where they do not exist. Comparing the Artist IPI on a Work with other information has allowed me to verify who the Work belong to, sometimes these searches are cryptic in nature.

Is the removing of the legal name for living artist or for the deceased as well? If only the living can it be reentered after the Artist is deceased and if so is there a waiting period. The legal name is historical and needed by research, it sometimes links things together.

I am wondering if the country rights organizations like ASCAP and CISAC are going to remove the nonmember interfaces into their databases since these may have some form of the legal name.

Linking music history together may get impossible, I foresee “creative” people like Gracenote and others providing research capabilities at a “price”.

As I said in my first post it is the Relationships that make this DB futuristic. No one and I repeat no one has this kind of capability. It is amazing how you can research just through the Works. A Work without the Artist relationships is meaningless.


#9

How about birth year? I edit a lot of Japanese artists, and it’s fairly common for artists (or rather the agencies that represent them) to list their birth month and day publicly but not the year.


#10

Just an idea for if MB would like to remove information from the living…

Maybe there can be a way to make the information not appear on the site (therefore not repeated by places like google) unless someone is dead. But if I open the edit tab, the information is already populated; which would then prevent me from re-adding it.


#11

That is not an option. With the GDPR, such information should be deleted, not just hidden.


#12

But then we would need to delete those fields from their edit page to prevent someone from re-adding information in the future.


#13

Getting back to the legal name issue. What is to stop someone from adding it back as a “search hint”, will MB have to remove Artist alias’s also.

Sorry, just thinking out loud as I digest all this. It makes me want to grab all my Artist data and relationships, but I will not. I believe in adhering to the intent of the law and if law needs to be changed or modified then support that effort. I am sure the community will be monitoring requests and actions here and elsewhere to make sure there is no effort (organized or otherwise) to place data behind paywalls.


#14

I though @rob was saying that the legal name was public record - so no issue.


#15

It is still available in the edit history. Does that have to be deleted too?


#16

What about valid removal requests that come through this forum, does the forum thread need to be removed once the request has been satisfied?


#17

I was not asking if I could hide the legal name, I was asking about others that may try to hide the legal name. I was asking if Artists aliases would be removed in order for that not to happen, or at least require a mandatory vote/review process for Artist alias’s.

The more I think about this from the point of linking the same artist to their different artist names, maybe their needs to be a “current name used”, “last name used”, or “non legal name used” MBID to tie them together since it appears the “performed as” refers to the “legal name”. Or does the appearance of linking the same artist names together cause a “de facto” “legal name”, does that make since.


#18

How about birth year?

Fun! I suppose we need to comply with the requests – but I see a problem here in that we do not support partial dates with no year… If this an actual problem we need to address, please open a ticket for MBS so we can discuss this in greater detail.


#19

Sure we do:


→ has birth month and day, but no year.

→ only has a start day, not even a month!


#20

I know we are very early into this but I figure the more we talk about possible issues the more work Rob has. :grinning:
Is it possible that the spouse/parent/sibling relationships could be considered private data. They could be used to figure out the legal name. And if that is the case there are a number of disambiguation’s that reference or may reference father/son/daughter/mother/brother/sister/husband/wife that may need to be changed.