Consider adding `Album#rights` for copyright/license details
Opened this issue Β· 8 comments
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
...?
(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...?
ππ»
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...:
- 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? Licenses
have a text description, code and url attributes
Thecode
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 onAlbum
data for their web api: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. π€·ββοΈ"copyrights": [ { "text": "(P) 2012 RCA Records, a division of Sony Music Entertainment", "type": "P" }
- 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? - 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. - 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.
@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 andcode
for a symbol are good attributes. I might makecode
anenum
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 thetext
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.
@chrislo thanks for the feedback. Following up on a couple points:
- 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). - 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.