Cascading permissions?

[Klortho]

Questions / concerns about Open Book Publishers permissions example

1. In many places, there are two elements side-by-side, which is ambiguous (not machine-readable). It would not clear to a machine whether it indicates a dual license, or two ways of calling out the same license. After looking it over, it's clear what it means: that the content is generally under the CC license, but that the document at the second URL has qualifications and caveats.
2. In that elements' xlink:href attribute, the URL "http://www.openbookpublishers.com/isbn/9781783740178#copyrighttab" appears. This is not the canonical URI identifier of any license, but rather a URL link to a page that has the license documentation. The link is broken, too: it seems that it has changed to this: http://www.openbookpublishers.com/product/233#copyright. This is a good illustration of why only canonical, published, persistent URIs should be used in that attribute.

3. So, for the first element in that example, I would retag it something like this:

    <license license-type="open-access"
             xlink:href="http://creativecommons.org/licenses/by-nc-nd/4.0/"/>
      <license-p>This entire volume is published under a Creative Commons
        Attribution-NonCommercial-NoDerivatives 4.0 ...
        See permissions relating to individual images. Detailed information 
        is available at 
        <ext-link ext-link-type="uri" 
          xlink:href="http://www.openbookpublishers.com/product/233#copyright"
            >http://www.openbookpublishers.com/product/233#copyright</ext-link>.</license-p>
    </license>

4. Inside , there is this: "The National Portrait Gallery, London. All rights reserved". Here, the element, that has the same URL as the others. In order to have this machine-readable, do we need a canonical persistent URI that means "all rights reserved"?

[Klortho]

[Please note that I appreciate that this is a really tough example, and I hope it doesn't sound like I'm being too critical.]

Regarding the fact that there are differing licenses for different parts, I think that this is a great example. One thing I think the recommendations need to make explicitly clear is that the permissions are inherited, much like the @xml:lang attribute. I.e. the permissions applies to all child elements unless it is explicitly overridden.

[ostephens]

I agree with the suggested markup in (3) above - the book isn't being licensed in multiple ways (which multiple elements would suggest).

I'm not sure about the idea of a URI for 'All Rights Reserved'. In the example, the figure is not licensed - I'm not sure it is a good idea to have a element contain information that is not a license. It also begs the question how to interpret the lack of a license element.

[Klortho]

The reason to want to put a element in there is to override the cascade -- the default inheritance of license from parents to their children. It's interesting that it's really not a license, but there is a precedent: public domain isn't a license either -- it's really a statement that there is no copyright. But it is being tagged in the element by many groups, and probably should be.

[ostephens]

I can see the issue of wanting/needing to assert that the rights/licensing on a child element are different. I'm not completely convinced this is the right way to do it, but I haven't got any better ideas at the moment :)

[biancagualandi]

Critics and comments are most welcome! I'm not convinced this is the best way to go either, and the example was meant, above all, to open a discussion on 'multi-level' licensing.

I agree that the double URI is ambiguous and I see why it should be avoided. I think the solution that Klortho suggests in (3) works really well because it allows to give both URIs (quite important from our point of view) but, at the same time, distinguishes between the machine readable, canonical one (in the element), and the human readable, publisher-maintained URI (in the element). [see also issue #2 ]

I really think we need a machine readable URI that means "all rights reserved". Otherwise, the image in our example could be mistakenly regarded as CC BY-NC-ND, with the possibility of unpleasant legal implications.

Also, as Klortho points out, it needs to be absolutely clear that the permissions apply to all child elements unless explicitly overridden.

[Melissa37]

From our meeting notes 6th August:

Multiple licenses in a document Cascade effect – parent license applies to the child parts unless explicit in the child element and then that overrides the parent for that section. Existence of license tag at child level indicates that child has own license statement and parent cannot be applied. That way license information does not need to be redefined for each child component, unless it is different to the parent. Copyright can change for each section of a document and if license is same as parent no need to redefine the license in the child.

Overwrite tag? Parent license statement applies to child elements unless this tag is present?

all rights reserved Do we need a URI for all rights reserved? JATS4R could create this and it be part of the recommendations/JATS4R validation process

[ostephens]

I think from the discussion on the 6th August there were four possible options:

1. Assume that all aspects of a element cascade unless explicitly overwritten This would mean the Open Book markup is correct as the copyright statement is different in each case. In this case the 'override' for a license could simply be to have a element without a element so no need for an 'all rights reserved' URI
2. Assume that the elements within a element cascade unless explicitly overwritten This would mean that the repeated elements in the Open Book markup were no longer needed, but that an override for the license would need to be made explicit through the use of an 'all rights reserved' license
3. Assume that only the element cascades unless explicitly overwritten Included as it is referenced above as a possibility, but I think this is a subset of (2) and I can't see the sense in the cascading, but not cascading.
4. Assume that element is always needed and must be fully stated. This would mean that if the element is lacking a element then the relevant element in the JATS is assumed not to be licensed

My only concern about the cascading aspects is that the cascade is logically not through the XML hierarchy - would we need rules that defined how the cascade worked that were machine processable?

[biancagualandi]

Option 1 seems the best to me. But if implementing the cascading aspect proved to be too difficult, I suppose we could go with option 4?

[Klortho]

I prefer option 1 as well. I think it's the cleanest, and closest to what most people would naively expect. So, to phrase it another way, to make sure we're all in agreement, we're saying that "permissions" is atomic, and that all aspects of a element apply to that part and all of its children, unless a child has a . If the child has a , then that must be complete, and won't inherit any part (copyright or license) from the parent.

If that's right, then, @biancagualandi, you could do away with the in the "all rights reserved" image.

[Klortho]

@biancagualandi , I took the liberty of updating your example, removing the element from that image. I also added some newlines for readability, so the diff looks much worse than it actually is.

[biancagualandi]

@Klortho This sounds perfect. And thank you very much for updating the example!

[ostephens]

@Klortho +1 to this approach. Do we need to discuss on this weeks call to 'agree' or can we close this based on agreement on this issue in these comments?

[Daniel-Mietchen]

I still find it problematic to have the book under CC BY-NC and then an image therein that is more restrictively licensed. Suppose I am building an online library that brings CC-licensed books together - I then just want to look at the license of the book as a whole, and if that is CC BY-NC, I will put it into the -NC corner of my library. But if that image is "All rights reserved", I am not allowed to put it into that library, so in order to be sure whether I am allowed to put it in there, your current example would require me to go through the entire book and look for something that lacks an explicit license statement.

I thus think the book as a whole should be tagged as "All rights reserved", and everything available under other conditions should be tagged accordingly. For whole-book scenarios as sketched out above, this would work properly, and anyone interested in sub-book level stuff, they can then dive into "All rights reserved" books and try to find some more liberally licensed stuff in there.

[biancagualandi]

You raise a really interesting and important issue - how should multi-licence works be licenced?

We have raised this with Creative Commons - and their advice was that we exclude third party rights when declaring our own licence. So, for example, the bottom of CCs own homepage has the following disclaimer below the CC BY logo "Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution 4.0 International license." http://creativecommons.org/

The world bank CC BY publications similarly have "third party" disclaimer on their copyright pages, eg http://issuu.com/world.bank.publications/docs/9781464801907

Of course the difficulty with your proposal is that if a complex document such as a book needs to be licenced under the most restrictive third party licence - it would effectively lock down open content. (Search bots would see the "all rights reserved" label and move on - not checking that open content is available within that.)

An example: Last week we published "Denis Diderot's 'Rameau's Nephew': A Multi-Media Edition" - this consists of a wonderful new translation of the original text, has embedded within it 18 rare 18C musical pieces especially recorded for the volume by the Conservatoire of Music and Dance in Paris, it has extensive bibliographic notes (over 250) and lots of images (over 100). The translation, all the recordings, the text of all the bibliographic notes and the vast majority of the images are CC BY (many of the images from wikimedia actually!) - but there are about 6 images that the contributors feel strongly should be included, for which the library holding the copyright has imposed "all rights reserved" restriction. The images can be distributed as part of the complete work - but not otherwise. It would be a crying shame to list this title as "all rights reserved" and miss all that wonderful, re-usable, original material.

Following the CC lead - the approach that we have taken is that we have listed the complete work under the most restrictive licence of any specific contribution - ignoring third party rights. Thus - for example - a collected edition will have contributions from many different authors. Some will choose CC BY for their licences and one author may insist on CC BY-NC-ND. In this case we would list the entire work as CC BY-NC-ND, and note that some chapters are available under a less restrictive licence - but we would ignore any third party rights.

Would a solution be to include a 'multi-licence' tag somehow - that would flag early on that some content is included under a different licence to the 'parent'?

[hubgit]

The JATS schema lists the elements in which the permissions element can be found.

Given that the purpose of allowing the permissions element in these places is presumably to allow permissions to be specified for a sub-element separately from the main article, it would be useful to have a table that specifies which element of the article is covered by a permissions element in a certain location:

permissions container	Element to which permissions apply	Notes
array	array	Self
article-meta	article	Closest parent article element
boxed-text	boxed-text	Self
chem-struct-wrap	chem-struct-wrap	Self
disp-quote	disp-quote	Self
fig	?	The whole figure, and any associated files?
front-stub	response or sub-article	The closest response or sub-article parent
graphic	graphic	The image file (@xlink:href) - and its description?
media	media	The media file (@xlink:href) - and its description?
preformat	preformat	Probably intended for code blocks?
sec-meta	sec	Closest parent sec element
statement	statement	Self
supplementary-material	supplementary-material	The supplemental file (@xlink:href) - and its description? What about inline-supplementary-material?
table-wrap	table-wrap	The table, caption etc
table-wrap-foot	table-wrap	Closest parent table-wrap element
verse-group	verse-group	Self

[hubgit]

It seems that nested permissions can't work if the nested permission is more restrictive (if you have permission to redistribute the whole article, you can't not have permission to redistribute a part of it), but some sections/files could be given less restrictive permissions?

[Melissa37]

I have a really tricky one, which I have only just been made aware of. We have parts of composite figures that are under separate copyright. In one figure I have 4 separate copyrights to account for, 2 all rights reserved, one CC-BY and one reprinted with permission only. I am guessing my only option is to make the whole figure all rights reserved and in the license-p add the separate details? The editorial department is reluctant to do this as some is CC-BY, but I can see no alternative. Any thoughts? I appreciate this whole thread is not complete and resolved, but I'd like to ensure I am at least partway right for now rather than completely wrong!

[Melissa37]

Sorry, just tried this a bit more and I can validate the xml file with multiple permission statements...

[vincentml]

Melissa: Could you tag the composite figure using fig-group with nested fig elements, and tag each fig with it's own permissions element?

[Melissa37]

But think that would be confusing as it is loaded as one figure file?

[Melissa37]

23 closed as too similar to this issue, but referenced here

[Daniel-Mietchen]

@Melissa37 Having a figure or subfigure non-compliant with CC BY is technically possible, but a CC BY journal doing so would cease to be one.

On a sidenote, composite figures in non-editable formats are a reuse barrier in and of themselves, even if openly licensed, because adapting them to different reuse scenarios (e.g. translation into another language) can be difficult and sometimes impossible, and there is always a quality loss when downscaling original images or adding label text or arrows in bitmap layers.

[Melissa37]

"Subject to a Creative Commons Attribution license, except where otherwise noted." We've had 5 instances of non-compliant figures. One option would be to not allow them at all - but that will detract from the scientific message and hinder the reader. They are pretty rare and it is always clear to the human reader that they are non-CC-BY - I am just sorting out the xml so it's tagged up. We do need to resume this topic discussion and get more input from the publishers who have joined the group since Christmas.

Am in agreement about composite figures, but there is a lot of work for authors to do this, and also for publishers and their online hosting platforms to accommodate it, so I don't think it will be a quick thing to change.

[hubgit]

If a publisher adds a separate <permissions> element to a figure that has more restricted copyright than the rest of the article (but which is allowed to be used in articles that are CC-BY licensed), will any tools recognise that permissions notice?

If so, what should they do with the information?

[Melissa37]

Can anyone think of examples of where this content might not be figures? Figures are discrete elements of an article/chapter that could be treated as separate from the rest of the article, theoretically.

[Melissa37]

See: http://publishingresearchconsortium.com/index.php/prc-guides-main-menu/166-open-access-licensing-0215

See page 28 of this document: Permissions typically not included or reserved in Open Access Licences Permissions typically not included or reserved in Open Access Licences a) Third-party content Nobody can validly license content to which they have no rights. Thus, Open Access Licences inherently do not cover any third-party content embedded in OPC, third-party illustrations, photographs, chunks of text that the author-researcher proposes to use as part of his unpublished manuscript, or supplementary content such as data sets, videos, sounds, etc. Third party content may be so embodied in OPC because sometimes the authors may in fact not need a licence to do so under local copyright laws, as the inclusion would be covered under an exception, such as making a quotation. However, more often uses are proposed or licensable to the public that would go beyond those permitted in national exceptions. The authors should thus seek permission in order to include this third party material. Where the third-party content is itself subject to an Open Access Licence, the authors would incorporate the content based on that licence and consistent with its requirements, e.g. attribution, link back to the rightsholder’s version, uses free from DRM, and any other requirements, e.g. statement of non-modification or modification of the content depending on permissions available. Where the third-party content is proprietary, then it would be misleading to embed the content into OPC without clearly marking it as another licence. This author would recommend a prominent demarcation of such content so that users are aware that they might need additional copyright licences if they wish to make a copyright use of the content in question.

Unfortunately the xml tagging is still not covered.

[Klortho]

Owen wrote,

My [only] concern about the cascading aspects is that the cascade is logically not through the XML hierarchy - would we need rules that defined how the cascade worked that were machine processable?"

I think Alf's table addresses this concern. I have added it to the recommendations.

Daniel wrote,

Suppose I am building an online library that brings CC-licensed books together .... your current example would require me to go through the entire book and look for something that lacks an explicit license statement. I thus think the book as a whole should be tagged as "All rights reserved", and everything available under other conditions should be tagged accordingly.

I think that Bianca's example, and also the document, Open Access Licensing, that Melissa linked to suggest that the idea that OA material can have some more restrictively licensed content is a valid one.

Note that with the tagging recommendations we have right now, it's possible to do either:

• Put the OA license on the container, and override that for all restrictively-licensed content, or
• Put an "all right reserved" permissions element on the container, and override that for all OA-licensed content.

The question is, do we want to add anything to the recommendations regarding this discussion? I think maybe a summary gleaned from a couple of the above comments would be good.

Bianca wrote,

Would a solution be to include a 'multi-licence' tag somehow - that would flag early on that some content is included under a different licence to the 'parent'?

I don't think so. It should be enough to put that into the human-readable , and have the machine-readable scheme that we're proposing here. It's (relatively) easy for a machine to find all the elements in a document, and see if they agree.

Melissa wrote,

We have parts of composite figures that are under separate copyright....

I don't see any way to handle this for machine-readability, within JATS, if the composite parts are not exposed. The whole figure would have to be tagged as "all rights reserved", and not available to any bots. But, of course, the element could explain the situation to humans.

....Unfortunately the xml tagging is still not covered.

I think we've got it covered in our example.

[hubgit]

The simplest recommendation for a machine that's processing the XML could be to take the permissions element in the article-meta element as applying to the whole article, but if there's a permissions element anywhere else in the article then it should flag the whole article for manual processing, as the current rules are too vague to be able to know what might be covered by the separate permissions statement.

[biancagualandi]

Melissa asked:

Can anyone think of examples of where this content might not be figures?

At least one of OBP titles has third-parties recordings embedded in the text which are not under the same license as the rest. More specifically, the text is under a CC BY-NC-ND license, while some of the recordings are in the public domain, and some are all rights reserved.

In all the cases I can think of, the different license applies to elements that are separate from the rest of the article/book.

[Klortho]

When/if we get this resolved, we could add this back into the JATS-Con paper:

We have further established rigorous guidelines for the scope of the element, depending on where in the document it appears.

[Melissa37]

In response to Alf's comment:

but if there's a permissions element anywhere else in the article then it should flag the whole article for manual processing

As the permission is contained within a container (the containers it could be listed in are in the table above), could the bot just regard that complete container?

[hubgit]

As the permission is contained within a container (the containers it could be listed in are in the table above), could the bot just regard that complete container?

It could, but my table was just a rough guess at what the containers should be, and in many cases it wasn't clear. The safest recommendation would be just "if there are multiple permissions elements, the processor is going to have to do extra work, possibly manual, to work out what they apply to".

[Melissa37]

All agreed. Need to write up the notes more - which elements it can be used in. Can close this issue once done. Jeff to provide info in the Schematron - not right/wrong rules. See meeting minutes 2nd April.

[Melissa37]

Agreed on call - 16th April. Close case.

[Klortho]

FYI, in response to a comment @hubgit wrote in the table, I added this comment on the NISO site about adding permissions to