Consider adding `Album#rights` for copyright/license details

[floehopper]

I notice that we've already got Album#credits and it looks as if some people have included copyright details in there. I don't really know much about this stuff, but I wonder if it might be useful to store this information separately...?

I thought about this when I was working on the Atom feed for a single artist and I was thinking about populating the entry.rights attribute for each album. However, I'm now less sure that's appropriate because the entry really corresponds to the album page on jam.coop; not the album audio itself.

If we decide that adding Album#credits is useful, we might want to think about having a default in Artist#credits and/or allowing overriding in Track#credits...?

[chrislo]

Sounds good to me - we've been asked a couple of times if we support that. Here's a screengrab of the licenses that bandcamp supports (at the track level, interestingly):

[floehopper]

(at the track level, interestingly)

Do you imagine ever having individual track pages? It looks as if Bandcamp do...

https://jogginghouse.bandcamp.com/track/something

They also seem to display the rights for an album - I'm guessing they store that separately rather than somehow "merging" the rights for all the tracks...?

[chrislo]

Certainly purchasing individual tracks would be great at some point (it's very useful for DJs in certain electronic genres).

I think rights at the album level make sense to me!

On Thu, 11 Jan 2024, 20:03 James Mead, @.***> wrote:

(at the track level, interestingly)

Do you imagine ever having individual track pages? It looks as if Bandcamp do...

https://jogginghouse.bandcamp.com/track/something

They also seem to display the rights for an album - I'm guessing they store that separately rather than somehow "merging" the rights for all the tracks...?

— Reply to this email directly, view it on GitHub https://github.com/freerange/music-coop/issues/134#issuecomment-1887878619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAECQ57AXI3JVIRVRHGC6TYOBAQLAVCNFSM6AAAAABBQMPCLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBXHA3TQNRRHE . You are receiving this because you commented.Message ID: @.***>

[rosschapman]

👋🏻 ☺️ I've been chatting with Chris about this task. Going to take a look this week and see if I can't send up a code spike.

[rosschapman]

Well, I ended up just going for it today 😅. Here's a draft comparison diff on my own fork as a gut check before I polish some things and open a PR: https://github.com/freerange/jam-coop/compare/main...rosschapman:jam-coop:adds-album-rights?expand=1&w=1

And here are some of my operating assumptions, open for discussion. I want to make sure my theory of the code ends up being consistent with your established practice, vision, understanding, etc...:

1. The new domain object is a "License"
   Although I don't love this name because a copyrighted work with "all rights reserved" isn't technically a "license" per se? I don't know enough about licensing yet. Is there an alternative?
2. Licenses have a text description, code and url attributes The code attr is intended as a machine-readable string for various usages on the platform. url is useful for hyperlinking to source documents for CC licenses; perhaps other usages. The data structure is influenced by how Spotify handles the "copyright" attribute on Album data for their web api:

   "copyrights": [
       {
         "text": "(P) 2012 RCA Records, a division of Sony Music Entertainment",
         "type": "P"
       }

   I researched some other music apis -- Soundcloud, Last.fm, Apple Music -- but they don't seem to include copyright or licensing data anywhere (although I could have missed it). Sadly there doesn't seem to be a strong data standard for music? I also didn't notice pertinent guidance in the Open Music Initiative documentation related to copyright or similar. 🤷‍♀️

3. I've made the License relationship optional But perhaps it should be required? Or maybe "all rights reserved" as a default? What do artists want?
4. Licenses are intended as static data in the database I added a dev seed assuming we might want to lock down a particular set. We could eventually slap an admin screen somewhere to manage these.
5. I tend to like writing system tests, since they conform to behavior and real usage. How are y'all generally thinking about coverage?

Thanks in advance for any feedback. ☺️

[chrislo]

@rosschapman - this looks good so far, I like your modelling approach.

• I think License is an appropriate name for the model.
• I think text for the human-readable text and code for a symbol are good attributes. I might make code an enum type for the different licenses we have (maybe adopting those used in bandcamp in the first instance).
• I think the license relationship should be required and all rights reserved used as the default, since I think almost everywhere an artist would own the copyright of their own work by default unless they signed it over.
• static data for the licenses sounds fine to me. I think you could potentially store the code in the database and have the text in a view helper or similar.
• system tests testing the "happy path" and controller/model tests providing coverage of edge cases tends to be what we try to do, but we don't have any hard rules about it. Some test coverage would be good if you can, but shout if you need help.

[rosschapman]

@chrislo thanks for the feedback. Following up on a couple points:

1. I'll look into enum implementations for Rails (ActiveRecord::Enum), although I'm not too familiar yet. I'm glad Rails has some convention for this because IME declaring the values at the application level vs creating an enum type in postgres allows a more adaptable approach (ie, app code is easier to change than DDL).
2. Actually, I think like the idea of a view helper for the license text better. That's less developer/ment overhead up front. If eventually it makes sense for that data to be encoded at the db level, it's easier to make that change later than move back to strings in code.

[chrislo]

Great! We use an enum elsewhere (for the publication state of an album) if an example would be helpful.

I think you're right about storing the text in a helper for now, and when you said that I realised also that it want to localise those strings into another language it would be easier if we just store a symbol in the DB and not the whole string.

On Sun, 4 Feb 2024, 20:49 Ross Chapman, @.***> wrote:

@chrislo https://github.com/chrislo thanks for the feedback. Following up on a couple points:

1. I'll look into enum implementations for Rails (ActiveRecord::Enum), although I'm not too familiar yet. I'm glad Rails has some convention for this because IME declaring the values at the application level vs creating an enum type in postgres allows a more adaptable approach (ie, app code is easier to change than DDL).
2. Actually, I think like the idea of a view helper for the license text better. That's less developer/ment overhead up front. If eventually it makes sense for that data to be encoded at the db level, it's easier to make that change later than move back to strings in code.

— Reply to this email directly, view it on GitHub https://github.com/freerange/jam-coop/issues/134#issuecomment-1925910003, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAECQ7GOPYQIP4ODEGONRTYR7X4LAVCNFSM6AAAAABBQMPCLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVHEYTAMBQGM . You are receiving this because you were mentioned.Message ID: @.***>