Skip to content
This repository has been archived by the owner on Jul 5, 2022. It is now read-only.

Separate license for design assets? #1850

Open
shiffman opened this issue Oct 28, 2019 · 3 comments
Open

Separate license for design assets? #1850

shiffman opened this issue Oct 28, 2019 · 3 comments

Comments

@shiffman
Copy link
Member

I am going to shortly merge #1839. I see this as a license for all of the code examples and website source code itself. The Coding Train design assets I would prefer to live under a different license likely a creative commons one (non-commercial?). Should any other elements be licensed separately? Not sure the best way to handle this.

@duskvirkus
Copy link
Member

Not entirely sure on the legality of how this would work but you could change the LICENCE file to have two sections with two licences and say above each which file types or folders they apply to. Not sure if it would be lawyer proof but I think it would make it clear to most people what the intentions are.

@duskvirkus
Copy link
Member

Had a thought on how to go about this problem. We could move all images in to a separate repository which has the community commons licence. Then it could be nested in the assets folder on this repository. Could also add a npm post install script to clone the images repository because chances are most people wouldn't use --recursive when cloning the main website repository. The advantage is a clear distinction between images and code. The disadvantage is it could easily confuse those unfamiliar with nested repositories on github. Also would require those with post install scripts turned off to either use --recursive or manually run the script. I could work on it if you (@shiffman) think it's a good idea.

@shiffman
Copy link
Member Author

shiffman commented Nov 21, 2019

I love the thinking behind this, but I think this is a low priority issue for me (at the moment) and I'm unlikely to run into any significant issues for how the media assets are used. In the end, I think a friendly notice in the README is "good enough" for now and if we reach the point where it's important to more meaningfully separate them out we can move forward with a plan like this!

For now, I would prioritize ease and simplicity of maintenance and bringing in new contributors!

Let's merge the license and add a note about licensing in the main README!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants