I identified what is a potential problem with texture images and the requirements of the CC BY license: there is no current mechanism to track authors and modifications to these images. While we haven't had an image recycled to the library for a fix, I feel it is only a matter of time before this happens. The PT tracks these events internally and this data is saved between releases but there is no method for someone who downloads the library to know who has authored an image and what its license is. A solution needs to be found.
I have a few options I can think of:
1. A "Texture Attribution" document included with the library that lists the filename, author, modification authors (if there are any), and license for each image.
Pros: Does not require any modifications to the PT software.
Cons: Labor intensive for the Parts Admin.
Note: I have made such a document and will be including it with the library starting the May release.
2. Add this information to the PNG meta data
Pros: info lives in the files
Cons: Very technically challenging, data not available in an intuitive way, not sure if this meets the intent of CC BY, would have to research.
3. Have a parallel dat file for each png file or, conversely, include texture mod HISTORY in the parent file
Pros: Easy to implement, uses the standard header.
Cons: Adds complexity to the library.
Thoughts?
I have a few options I can think of:
1. A "Texture Attribution" document included with the library that lists the filename, author, modification authors (if there are any), and license for each image.
Pros: Does not require any modifications to the PT software.
Cons: Labor intensive for the Parts Admin.
Note: I have made such a document and will be including it with the library starting the May release.
2. Add this information to the PNG meta data
Pros: info lives in the files
Cons: Very technically challenging, data not available in an intuitive way, not sure if this meets the intent of CC BY, would have to research.
3. Have a parallel dat file for each png file or, conversely, include texture mod HISTORY in the parent file
Pros: Easy to implement, uses the standard header.
Cons: Adds complexity to the library.
Thoughts?