Wrap: Improve handling of copyright notices

[skreutzer]

Many source portions come with a copyright notice of their own so they can work on their own, standalone. When generating target formats, they end up being duplicated in the yearly and all-time spines. There might be no semantic markup for the copyright notices to identify them, less processing steps that handle these sections properly. For all material, there's the CC0 text and CC BY-SA images to cover. For the Tufte-LaTeX variants, there's also the Apache 2.0 for the layout and font.

[danoff]

That is a lot of copyright concerns!

So, we can only use Tufte font if it has an Apache license?

I think I should try to only use CC0 images and keep the text CC0.

[skreutzer]

As briefly discussed in an earlier call, for the sake of clarification, this particular issue here covers what to do about the copyright notices that are in the source material, typically on each Wikitext article for most of the months, because in a Mediawiki (Wikiversity) and on the GitHub wiki (Peeragogy GitHub organization), these are stand-alone materials. For the concatenated all-time or yearly spine/run of the Wraps, these texts would repeat every month (given that the copyright demands/disclaimers remain the same for every month). So the question is if they could somehow be semantically marked up and subsequently stripped out for having just a single copyright/licensing page in the front or back matter, this way reducing duplicates and overall length. The individual results for each month could still include the original notices.

CC0, CC BY-SA, Apache 2.0 are mentioned because these licenses currently apply to parts of the results, so for result files separate for every month, license notices for them likely need (or should) to be included, as well as for the yearly/all-time spine/run (but only once, not duplicated in this latter case). Some licensing is specific to a particular generated result, and may not be part of the content source, so no need to strip it away during processing, and instead more a question of how to organize it's inclusion during the production of the generated results.

Licensing questions regarding the layout, font, images and text as well as the combined results as wholes are a separate topic we still need to discuss in more detail eventually, be it as a new GitHub issue or in conversation as part of the Monthly Wrap Working Group.

[danoff]

I may not be remembering correctly, but I believe you said this in one of our meetings, how editors in control their contributions @skreutzer

I wasn't sure, but it looks like you are right based on this page

It is not unreasonable to put your content in the public domain, but we advise you to also license it under a CC BY license or a free-use license if you desire a "softer" fallback than the GNU FDL. Note that all text is licensed by the uploader or editor under a CC BY-SA license (both on the edit form and on the upload submission form) if they have the rights to do so.

As a result, all of the text for old wraps is available to dedicate to the public domain it seems? What do you think?

I found that link in this discussion.

[skreutzer]

This GitHub issue is primarily for the problem about how to handle the copyright notices (regardless of what they are in particular) and doesn't discuss under what license the content should be released under. For the original publication on Wikiversity and/or on the GitHub wiki, a license notice/disclaimer is included in the text in order to indicate the license(s) that apply. Mostly because on Wikiversity, CC0 diverts from the standard CC BY-SA of Wikiversity/MediaWiki, and because GitHub wiki doesn't come with default licensing in the software for the content that's published in it (rendering it likely proprietary, "all rights reserved"). This is the case for every individual Wrap article page. As we produce individual files for each month, we want to include this notification for each of them, in order to educate the reader/user of what can and can't be done with the individual wrap. Then, there are the yearly + all-time compilations based on the same source article page, and if each page contains another duplicate of the notification, maybe paper space is wasted unnecessarily, nor does the reader need to have them repeated, in a compilation anyway. So the question is of how to technically manage these notifications separately or mark them up, so they get included for the individual month files and for the yearly/all-time compilations used only once (even if different licenses apply to different articles, a little icon or reference might point to the license notification in the back matter or something). Don't have a clean, simple solution for this yet, just workarounds/hacks, ideally some sort of decent document management system with metadata would handle this well, but we don't have one of these yet.

Effects, problems, solutions, approaches, intentions of the many different licenses as legal instruments are an important and huge topic, maybe to be discussed elsewhere (as another GitHub Issue or a introduction/overview piece), especially considering the general confusion when it comes to how this relates to digital, OER, peerness, our past and future.