Feature #2105
closedNew file license system
Description
Update
In the end we didn't change the license system itself but done a lot of work related to it, e.g. implemented file attributes, references for types and a lot more, see related issues.
Important change is that for a file to be available via the API it now has to have a linked license and the public flag activated.
Original description
Because of the increasing requirements (e.g. URL for licenses in IIIF) we decided to implement a new license system for files.
- New license system (de-coupled from types)
- Configurable at
admin/files
- Option to add an URL and/or text
Updated by Bernhard Koschiček-Krombholz about 1 year ago
- Precedes Feature #2066: IIIF: Access restriction added
Updated by Bernhard Koschiček-Krombholz 12 months ago
- Description updated (diff)
Updated by Alexander Watzinger 10 months ago
- Status changed from Acknowledged to Assigned
- Assignee set to Alexander Watzinger
- Target version changed from 8.3.0 to 8.2.0
Updated by Alexander Watzinger 10 months ago
- Status changed from Assigned to In Progress
I looked around but didn't find a good authoritative list/vocabulary for licenses so we will just provide a few examples, e.g.
- Open
- Public domain (https://wiki.creativecommons.org/wiki/Public_domain)
- CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
- CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/)
- Restricted
- Needs clarification
- Top items are not editable (Open/Restricted/Needs clarification) and used to decide e.g. that only open licenses are visible in presentation site, can get archived and so on
- One has to be chosen and no default is set to "guarantee" conscious decision making when adding files. Top item Open can't be selected (because not clear enough), only subs of it.
- Managers can add/edit sub types (not sure if needed for restricted and needs clarification)
Feedback is welcome.
Updated by Alexander Watzinger 10 months ago
- Description updated (diff)
Christoph just raised a good point. If a public license is chosen in most cases the license holder has to be defined too.
Updated by Alexander Watzinger 10 months ago
I got some feedback from my nice collegauges at the ACDH-CH (thanks Vera).
There is a Vocabs instance about licenses. I don't think we will use them all because it also contains a lot of software licenses, but there is one that looks especially interesting:
Copyright Not Evaluated which is also used by ARCHE and could replace the Needs clarification item.
I also asked about CIDOC mapping and was provided with an example from CLS INFRA:
<https://clscor.io/entity/f8ca3e64-1> a crm:E13_Attribute_Assignment ; crm:P134_continued <https://clscor.io/entity/6f473447-3> ; <-- that's our corpus description activity crm:P140_assigned_attribute_to <https://clscor.io/entity/bf849ab519> ; <-- entity, the license is assigned to crm:P141_assigned <https://clscor.io/entity/type/license/cc0-1-0> ; <-- our license vocab (mapped to ARCHE-licenses vocab) crm:P177_assigned_property_of_type crm:P2_has_type .So next questions will be:
- Do we want to use Vocabs license definitions (which) and link to them via external reference (I would like that)
- Do we change/adapt the mapping? Currently it's just a P2 -> E55 (e.g. we could put the license text in the description but how/where to map the URL, ...)
Updated by Alexander Watzinger 10 months ago
Now that it looks like we are going to create links to Vocabs for already provided licenses in the default installation, I'm thinking about how to add Vocabs to our default external reference systems.
Some clarification for this will be necessary:- How sustainable will the usage of Vocabs be: how are the long term plans there?
- Do we add one external reference system for all of Vocabs or one for each vocabulary, e.g. ARCHE Licenses
- Can we make use of the Vocabs API like we do e.g. with Wikidata and GeoNames?
- What adaptions would be needed for the existing Vocabs import functionality?
I try to clarify these topics in the next days. In case we decide to integrate Vocabs I will make an own issue for this.
Updated by Alexander Watzinger 10 months ago
To answer my own questions from before with a lot of feedback from Christoph:
- Vocabs is planned to stay there for a long time
- We will use one external reference system for each vocabulary (like in INDIGO), so for licenses we will add ARCHE Licenses
- There is a Vocabs API via Skosmos which we can use for e.g. search functionality in the OpenAtlas user interface
We still will have to look into adaptions for existing Vocabs and INDIGO import scripts.
Also I decided to not split this issue because license changes and Vocabs integration will have to be done in one upgrade together anyway.
Updated by Alexander Watzinger 9 months ago
- Precedes deleted (Feature #2066: IIIF: Access restriction)
Updated by Alexander Watzinger 9 months ago
- #2128: Option to mark files for public viewing
- #2129: Attributions for files
We still will do them one after another but they will be released together to not make users have to go through and update file licenses multiple times.
Updated by Alexander Watzinger 9 months ago
- Start date changed from 2023-11-03 to 2024-02-16
- Follows Feature #2186: Move file item from admin area to menu added
Updated by Alexander Watzinger 9 months ago
- Target version changed from 8.2.0 to 8.3.0
Updated by Alexander Watzinger 8 months ago
- Target version changed from 8.3.0 to 8.4.0
Updated by Alexander Watzinger 7 months ago
- Start date changed from 2024-02-16 to 2024-04-26
- Follows Feature #2261: Option to prevent selection of a type added
Updated by Alexander Watzinger 7 months ago
After some input from Christoph I'm afraid we have to re-open the discussion about licenses.
He made some good points why using the categories public, restricted, ... don't really make sense.
- a defined license
- a flag if it is meant to be shown/shared public
We will also implement the possibility to add creator and/or rights holder but because it's not possible to (automatically) cross check with the licenses if this is mandatory (e.g. not needed if public domain) it's the responsibility of the person who sets the public flag if this is legitimate. So in short creator/rights holder can be set (and of course shown) but won't be a criteria to show something publicly.
Anyway, I added this to the agenda of the next developers meeting.
Updated by Alexander Watzinger 7 months ago
- Target version changed from 8.4.0 to 8.5.0
Updated by Alexander Watzinger 6 months ago
- Start date changed from 2024-04-26 to 2024-05-14
- Follows Feature #2277: References for types added
Updated by Alexander Watzinger 6 months ago
- Related to Feature #2129: Attributions for files added
Updated by Alexander Watzinger 6 months ago
- Description updated (diff)
- Status changed from In Progress to Closed
Updated by Bernhard Koschiček-Krombholz 6 months ago
- Related to Feature #2294: API: Adapt public sharing of files added