creativecommons / cc-legal-tools-app

Legal tool (licenses, public domain dedication, etc.) management application for Creative Commons

cc-legal-tools-app

Creative Commons (CC) Legal Tools Application. This repository contains the application that manages the license tools and public domain tools (static HTML, internationalization and localization files, etc.). It consumes and generates data in the creativecommons/cc-legal-tools-data repository.

Code of conduct

CODE_OF_CONDUCT.md:

The Creative Commons team is committed to fostering a welcoming community. This project and all other Creative Commons open source projects are governed by our Code of Conduct. Please report unacceptable behavior to [email protected] per our reporting guidelines.

Contributing

See CONTRIBUTING.md.

About

This application manages 639 legal tools (636 licenses and 3 public domain tools). The current version of the licenses is 4.0 and includes 6 licenses. They are international and are designed to operate globally, ensuring they are robust, enforceable and easily adopted worldwide. Prior versions were adapted to specific jurisdictions ("ported"). That is why there are 636 licenses.

Broadly speaking, each legal tool consists of three layers:

1. deed: a plain language summary of the legal tool
2. legalcode: the legal tool itself
3. rdf: metadata about the legal tool in RDF/XML format

With translations of the deed and translations of the legal code, this application manages over 30,000 documents.

Not the live site

This project is not intended to serve the legal tools directly. Instead, a command line tool can be used to save all the rendered HTML and RDF/XML pages as files. Then those files are used as part of the CreativeCommons.org site (served as static files).

Software Versions

• Python 3.11 specified in:
  • .github/workflows/django-app-coverage.yml
  • .github/workflows/static-analysis.yml
  • .pre-commit-config.yaml
  • Dockerfile
  • Pipfile
  • pyproject.toml
• Django 4.2 (LTS)
  • Pipfile

Setup and Usage

Once this project's required dependencies are enabled on your system, you will be able to run the legal-tools application and generate static files.

Prerequisites

This project depends on Docker and Git. It also requires this repository and the data repository (the codebases) be cloned next to each other.

MacOS

Mac users can install Git using these instructions: Git - Installing Git - Installing on macOS.

Docker Desktop can be installed using these instructions: Install Docker Desktop on Mac | Docker Docs.

Linux

Git is optimally installed using your distribution's package manager. See Git- Download for Linux and Unix for a wide range of popular distros.

Both Docker Desktop and Docker Engine are separately supported on Linux. Both include the required Compose command plugin, but Docker Engine is typically much easier to install:

• Recommended: See Install Docker Engine | Docker Docs for links to installation instructions for Docker Engine and Compose for various Linux distributions.
• See Install Docker Desktop on Linux | Docker Docs for links to instructions for the graphical desktop app that includes the commandline interface and Compose

Windows

You must use Windows 10 or 11 with Windows Subsystem for Linux (WSL2). For installation instructions: see Install WSL | Microsoft Learn.

Git should be installed within WSL2, using the appropriate Linux installation method. For WSL2 Ubuntu, the command is sudo apt-get install git.

Docker Desktop should be installed on Windows itself and integrated with WSL2 as explained in Docker Desktop WSL 2 backend on Windows | Docker Docs. Unlike Git, you should not install Docker within your WSL2 environment.

Codebases Setup

Both this repository and the creativecommons/cc-legal-tools-data project repository should be cloned side by side, resulting in a structure like the following:

creative-commons/
├── cc-legal-tools-app/     (git clone of this repository)
└── cc-legal-tools-data/    (git clone of the cc-legal-tools-data repository)

To achieve this, we recommend the following procedure:

1. Create and change to a container directory, such as creative-commons or cc.

   mkdir creative-commons
   cd creative-commons

2. Clone both repos using SSH or, if that does not work, HTTPS protocol.

   git clone [email protected]:creativecommons/cc-legal-tools-app.git
   git clone [email protected]:creativecommons/cc-legal-tools-data.git

   or

   git clone https://github.com/creativecommons/cc-legal-tools-app.git
   git clone https://github.com/creativecommons/cc-legal-tools-data.git

Visit Cloning a repository - GitHub Docs for more on how to clone a GitHub repository.

Docker Prep and Execution

Use the following instructions to prepare and run the project with Docker Compose.

1. Ensure all prerequisites and repositories are in place.
2. Ensure you are at the top level of the directory where you cloned this repository (where manage.py is).

   cd cc-legal-tools-app

3. Create Django local settings file from the example file.

   cp cc_legal_tools/settings/local.example.py cc_legal_tools/settings/local.py

   • Update variables in new file, if necessary.
   • This file is ignored by Git.
4. Build the containers.

   docker compose build

5. Run the containers.

   docker compose up

   1. app (127.0.0.1:8005): this Django application
      • Any changes made to Python will be detected and rebuilt transparently as long as the development server is running.
   2. static (127.0.0.1:8006): a static web server serving creativecommons/cc-legal-tools-data:docs/
6. Initialize data. Open a separate terminal tab, and in the same directory, run:

   ./dev/init_data.sh

   1. Deletes database (which may not yet exist)
   2. Initializes database
   3. Performs database migrations
   4. Creates supseruser (will prompt for password)
   5. Loads data

Note: Once this full setup is performed, running Step 5 above will execute the application on any subsequent occasion.

Manual Setup

⚠️ This section may be helpful for maintaining the project, but should NOT be used for development. Please use the Docker Compose Setup, above.

1. Complete Docker Compose Setup, above
2. Development Environment
   1. Install dependencies
      • Linux:

        sudo apt-get install python3.11 python3.11-dev python3-pip

        pip3 install pipenv

      • macOS: via Homebrew:

        brew install pipenv [email protected]

      • Windows: install Python and then use pip to install pipenv:

        pip install pipenv

   2. Install Python environment and modules via pipenv to create a virtualenv
      • Linux:

        pipenv install --dev --python /usr/bin/python3.11

      • macOS: via Homebrew:

        pipenv install --dev --python /usr/local/opt/[email protected]/libexec/bin/python

      • Windows:

        pipenv install --dev --python \User\Appdata\programs\python

   3. Install pre-commit hooks

   pipenv run pre-commit install

3. Run development server (127.0.0.1:8005)

   pipenv run ./manage.py runserver

   • Any changes made to Python will be detected and rebuilt transparently as long as the development server is running.

Manual Commands

ℹ️ The rest of the documentation assumes Docker. If you are using a manual setup, use pipenv run instead of docker compose exec app for the commands below.

Tooling

• Python Guidelines — Creative Commons Open Source
• Black: the uncompromising Python code formatter
• Coverage.py: Code coverage measurement for Python
• Docker
  • Dockerfile reference | Docker Documentation
  • Compose file version 3 reference | Docker Documentation
• flake8: a python tool that glues together pep8, pyflakes, mccabe, and third-party plugins to check the style and quality of some python code.
• isort: A Python utility / library to sort imports.
• pre-commit: A framework for managing and maintaining multi-language pre-commit hooks.

Helper Scripts

Best run before every commit:

• ./dev/coverage.sh - Run coverage tests and report
• ./dev/tools.sh - Run Python code tools (isort, black, flake8)

Run as needed:

• ./dev/copy_theme.sh - Copy the portions of creativecommons/vocabulary-theme needed for local development
  • Run after each new release of creativecommons/vocabulary-theme

Data management:

• ./dev/dump_data.sh - Dump Django application data
• ./dev/init_data.sh - ⚠️ Initialize Django application data
• ./dev/load_data.sh - Load Django application data

Esoteric and dangerous:

• ./dev/updatemessages.sh - ⚠️ Run Django Management nofuzzy_makemessages with helpful options (including excluding legalcode) and compilemessages

Coverage Tests and Report

The coverage tests and report are run as part of pre-commit and as a GitHub Action. To run it manually:

1. Ensure the Data Repository, above, is in place
2. Ensure Docker Compose Setup, above, is complete
3. Coverage test

   docker compose exec app coverage run manage.py test --noinput --keepdb

4. Coverage report

   docker compose exec app coverage report

Commit Errors

Error building trees

If you encounter an error: Error building trees error from pre-commit when you commit, try adding your files (git add <FILES>) before committing them.

Frontend Dependencies

The following CC projects are used to achieve a consistent look and feel:

• creativecommons/vocabulary-theme: WordPress Theme implementation of the Vocabulary design system

Data

The legal tools metadata is in a database. The metadata tracks which legal tools exist, their translations, their ports, and their characteristics like what they permit, require, and prohibit.

The metadata can be downloaded by visiting the URL path: 127.0.0.1:8005/licenses/metadata.yaml (currently disabled)

There are two main models (Django terminology for tables) in legal_tools/models.py:

1. LegalCode
2. Tool

A Tool can be identified by a unit (ex. by, by-nc-sa, devnations) which is a proxy for the complete set of permissions, requirements, and prohibitions; a version (ex. 4.0, 3.0), and an optional jurisdiction for ports. So we might refer to the tool by its identifier "BY 3.0 AM" which would be the 3.0 version of the BY license terms as ported to the Armenia jurisdiction. For additional information see: Legal Tools Namespace - creativecommons/cc-legal-tools-data: CC Legal Tools Data (static HTML, language files, etc.).

There are three places legal code text could be:

1. Gettext files (.po and .mo) in the creativecommons/cc-legal-tools-data repository (legal tools with full translation support):
   • 4.0 Licenses
   • CC0
2. Django template (legalcode_licenses_3.0_unported.html):
   • Unported 3.0 Licenses (English-only)
3. html field (in the LegalCode model):
   • Everything else

The text that's in gettext files can be translated via Transifex at Creative Commons localization. For additional information on the Django translation domains / Transifex resources, see How the license translation is implemented, below.

Documentation:

• Models | Django documentation | Django
• Templates | Django documentation | Django

Translation

See docs/translation.md

Generate Static Files

Generating static files updates the static files in the docs/ directory of the creativecommons/cc-legal-tools-data repository (the Data Repository, above).

Static Files Process

This process will write the HTML files in the cc-legal-tools-data clone directory under docs/. It will not commit the changes (--nogit) and will not push any commits (--nopush is implied by --nogit).

1. Ensure the Data Repository, above, is in place
2. Ensure Docker Compose Setup, above, is complete
3. Delete the contents of the docs/ directory and then recreate/copy the static files it should contain:

   docker compose exec app ./manage.py publish -v2

Publishing changes to git repo

When the site is deployed, to enable pushing and pulling the licenses data repo with GitHub, create an SSH deploy key for the cc-legal-tools-data repo with write permissions, and put the private key file (not password protected) somewhere safe (owned by www-data if on a server), and readable only by its owner (0o400). Then in settings, make TRANSLATION_REPOSITORY_DEPLOY_KEY be the full path to that deploy key file.

Publishing Dependency Documentation

• Beautiful Soup Documentation — Beautiful Soup 4 documentation
  • lxml - Processing XML and HTML with Python
• GitPython Documentation — GitPython documentation

Machine/metadata layer: RDF/XML

For details and history, see docs/rdf.md.

Licenses

Code

LICENSE: the code within this repository is licensed under the Expat/MIT license.

Legal Code text

The text of the Creative Commons public licenses (legal code) is dedicated to the public domain under the CC0 1.0 Universal (CC0 1.0) Public Domain Dedication.

vocabulary-theme

COPYING: All the code within Vocabulary is dedicated to the public domain under the CC0 1.0 Universal (CC0 1.0) Public Domain Dedication.

Normalize.css

normalize.css is licensed under the Expat/MIT License.

Fonts

Accidenz Commons

Accidenz Commons by Archetypo is licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) License.

JetBrains Mono

JetBrains Mono is licensed under the OFL-1.1 License.

Roboto Condensed

Roboto Condensed by Christian Robertson is licensed under the Apache License, Version 2.0.

Source Sans Pro

Source Sans Pro by Paul D. Hunt is licensed under the Open Font License.

Vocabulary Icons

Vocabulary Icons use icons from Font Awesome which are licensed under the Creative Commons Attribution 4.0 International (CC BY 4.0) License.

cc-legal-tools-app's Issues

DJANGO_SETTINGS_MODULE doesn't point to a settings file

Description

In manage.py, line 10, the environment variable DJANGO_SETTINGS_MODULE doesn't point to a settings file.

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cc_licenses.settings")

Reproduction

1. Check if you don't have a DATABASE_URL key in the virtual environment.
2. Run any management command, such as manage.py runserver
3. See error.
   django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.

Expectation

It is expected that it should point to the local settings file.

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cc_licenses.settings.local")

Environment

• Device: Laptop
• OS: Ubuntu 20.04 LTS

Resolution

• I would be interested in resolving this bug.

[Bug] A previous PR broke Deeds & UX translations

Description

PR #166 Broke Deeds & UX translations. This also exposes a lack of test coverage.

Reproduction

Run docker environment and visit http://127.0.0.1:8000/publicdomain/zero/1.0/deed.es

Expectation

Translated text should be displayed. Basic translation functionality should be covered by unit tests.

Additional context

• PR #166 changed the Deeds & UX gettext domain from django (the default) to deeds_ux.
• Django does not have robust support for custom gettext domains (#6376 (Allow using custom gettext domains) – Django has been open for 14 years and untouched for 2 years).

Custom currency icons for deeds

(This is not a launch blockerlocker)

Problem

We have a few designs for custom currencies in non-commercial deeds (ex) that aren't used anywhere. It would be nice to have the correct license icon used when available.

See the Icons section on this page.

Ensure links do not downgrade security or break continuity (use path-only or https://)

Problem

CC should want to protect its users when possible, HTTPS is a means to do that. Even though the website that links to already redirect http to https, it is good stewardship.

Description

Some links in the repo refer to external websites using http, this needs to change to https where possible.

Alternatives

We could also make these links protocol agnostic.

Implementation

• create branch
• Search repo on 'http://'
• replace with 'https://' , after check if external site has https
• create Pull request
• ????
• profit

@TimidRobot indicated that they wanted to leave links to / within RDF alone. Could you elaborate @TimidRobot?

Plaintext legal code URL doesn't work

Description

Visiting any legal code page results in a a server error

Reproduction

1. Visit https://cclicdev.creativecommons.org/licenses/by-sa/4.0/legalcode/index.txt
2. See error.

Screenshots

Environment

cclicdev.creativecommons.org

Resolution

• I would be interested in resolving this bug.

[Bug] Aranese dialect is misidentified and mislabeled

Description

The Aranese dialect is an Occitan variant not Occitan itself. Additionally, it should use a Django lowercase RFC5646 language tag instead of a POSIX locale.

Reproduction

cc-legal-tools-app/cc_licenses/settings/base.py

Lines 166 to 171 in 2f6c6af

	LANG_INFO["oci"] = { # Occitan? https://iso639-3.sil.org/code/oci
	"bidi": False,
	"code": "oci",
	"name": "Occitan",
	"name_local": "Occitan",
	}

Expectation

The Aranese dialect should be properly identified and labeled. Per [Bug] Clearly handle the variety of language code formats and cases · Issue #157, the correct language code should be used and legacy codes should redirect to the correct language code.

Correct language code: oc-aranes (as listed in the IANA Language Subtag Registry):

• oc is the ISO 639-1 language for Occitan
• aranes is the IANA registered variant subtag

Additional context

The legacy ccEngine uses the POSIX locale oci_ES (cc-archive/cc.i18n:cc/i18n/mappers.py:Line 131)

The legacy legal code uses oci (with a jurisdiction of Spain (es):

• by_3.0_es_oci.html
• by-nc_3.0_es_oci.html
• by-nc-nd_3.0_es_oci.html
• by-nc-sa_3.0_es_oci.html
• by-nd_3.0_es_oci.html
• by-sa_3.0_es_oci.html
• cc-archive/legalcode-pre-2014-06-26@79aa9a6:

  rename 'oc' (Aranes) to 'oci', since it's oci_ES in i18n module

• The Aranese dialect is an Occitan variant not Occitan itself. However, the Aranese variant subtag did not exist when these files were named (nor when they were renamed). The aranes variant subtag was added 2018-04-22 (IANA Language Subtag Registry).
• The Aranese dialect was added to Transifex (Languages on Transifex) on 2021-08-31.

References

• Aranese dialect - Wikipedia
• IANA Language Subtag Registry
• IANA Registration form for 'aranes'
• ISO 639-1 - Wikipedia
• ISO 639-2 - Wikipedia
• ISO 3166-1 alpha-2- Wikipedia
• POSIX platforms - Locale (computer software) - Wikipedia (POSIX Locale)
• RFC5646 Tags for Identifying Languages
  • 2.2.5. Variant Subtags
• Languages on Transifex

[Bug] Need to support category (licenses or publicdomain)

Description

This application is unaware of legal tool category (licenses or publicdomain).

Expectation

CC0 should have publicdomain instead of licenses. For example:
https://github.com/creativecommons/cc-licenses-data/blob/main/docs/publicdomain/zero/1.0/deed.en.html#L120

Screenshots

[Feature] Dedicate the rest of the legal tools’ text to the public domain

Problem

I would like to use CC0 to help me dedicate some of my software to the public domain. I would like to include a copy of CC0 with my software since that’s recommended. Parts of CC0 are legal code, so parts of CC0 were dedicated to the public domain under CC0. Parts of CC0 aren’t legal code, so parts of CC0 are licensed under CC BY 4.0.

Other than the Creative Commons trademarks (licensed subject to the Trademark Policy below) and the text of Creative Commons legal tools and human-readable Commons deeds (dedicated to the public domain as specified below), all content on this site is licensed under the Creative Commons Attribution 4.0 International license unless otherwise marked.

Creative Commons makes the legal code of its licenses and the CC0 Public Domain Dedication available under the CC0 Public Domain Dedication.

Quotes from “CC’s Licensing Statement for Content and Software Code” by Creative Commons (CC BY 4.0)

Elements of the license page that are not part of the legal code

Anything not specifically named as legal code above, including:

• “CC is not a law firm” disclaimer at top
• […]

Quote from “Legal Code Defined” by Creative Commons (CC BY 4.0)

I’m perfectly fine with adding some attribution information whenever I distribute a copy of one of the legal tool’s text. The problem is that most software developers who included a copy of CC0 with their code (or a CC license on their assets) probably didn’t know that they needed to provide attribution. I sure didn’t when I started using it.

Another problem is that this partial licensing situation is overly complicated.

Description

Dedicate the entirety of each legal tools' text to the public domain. This would remove the requirement for attribution and make the situation less confusing. It would also cure the accidental violations that have already happened.

Alternatives

We could add documentation that explains this and gives attribution instructions for the legal tools' text. This would make it more of a hassle to use the plain text versions of the licenses.

Another possible solution is to include attribution information in the legal tools' text.

Neither of these alternatives would do much to address the accidental violations in the past. Neither would make the copyright situation less complicated.

Additional context

It seems like CC intended to dedicate all of the legal tools’ text to the public domain anyway.

[…]the text of Creative Commons legal tools and human-readable Commons deeds (dedicated to the public domain as specified below)[…]

Legal text (we call this legal code) and Commons deeds: Creative Commons makes the legal code of its licenses and the CC0 Public Domain Dedication available under the CC0 Public Domain Dedication.

To me, legal text would be the entire text of a legal tool and legal code would be something different. Those quotes from “CC’s Licensing Statement for Content and Software Code” imply that they’re the same thing.

Implementation

• I would be interested in implementing this feature.

[Bug] Deed/UX translations and Legalcode translations must be distinct and fully represented

Description

The Deed & UX translations are separate from the legalcode translations, but the application currently only exposes translations based on legalcode.

Both the deeds view and the legalcode view use the same function (get_languages_and_links_for_legalcodes):
https://github.com/creativecommons/cc-licenses/blob/f42b78db9c89d52924714340f3952dc792dac7bc/licenses/views.py#L136-L167

Translation strings in cc-licenses-data:

• legalcode/
  • .po and .mo internationalization and localization files for legalcodes
• locale/
  • .po and .mo internationalization and localization files for deeds, contextual information, and user interfaces

Expectation

The interface (and generated files) should expose all of the deed translations

Additional context

• Translation | Django documentation | Django

i18n.utils.active_translation uses a private Django value and may duplicate Django code

Description

The active_translation function in i18n/utils.py uses a private Django value (see Lines 95-128).

Expectation

I wonder if the function duplicates the override function in django.utils.translation:

A Python context manager that uses django.utils.translation.activate() to fetch the translation object for a given language, activates it as the translation object for the current thread and reactivates the previous active language on exit. Optionally, it can simply deactivate the temporary translation on exit with django.utils.translation.deactivate() if the deactivate argument is True. If you pass None as the language argument, a NullTranslations() instance is activated within the context.

override is also usable as a function decorator.

Additional context

• Translation | Django documentation | Django

[Bug] Code does manage Deeds & UX translations (only Legal Code translations)

Description

Code does manage Deeds & UX translations (only Legal Code translations)

Reproduction

licenses/transifex.py:

• check_for_translation_updates() and check_for_translation_updates_with_repo_and_legal_codes() only check legal code resource slugs. The Deed & UX resource slug and related translations are never referenced or managed.

Expectation

Deeds & UX translations should also be managed.

Additional context

• Related: #146

Adding documentation for setting up a developement environment on linux based systems using a python virtual environment

Problem

Right now, the README file only has specific instructions for mac OS systems. For new contributors, who are working on some of their first open source projects on their linux systems, it might be a little difficult finding their way through setting up the project environment with postgresql and other dependencies

Description

Add simple step by step instructions to clone and set up the project on linux based systems like Ubuntu. As these systems are widely used by developers and students, this will make it easier for new developers to start contributing to the project.

Implementation

• I have already set up a development environment on my pc and have written easy instructions to do the same. I would like to add these instructions to the README file or create a new .txt file containing them.

Complete translation status page

The repository does not contain a CC metadata file

Description

Each repo in the CC organisation should have a .cc-metadata.yml file. This one does not.

Expectation

The .cc-metadata.yml file should be present.

Resolution

• I would be interested in resolving this bug.

Mark License Javascript as Free Software

The JS we supply in the Python section of the site (under /licenses/ ) is Free Software (this is an observation not a declaration), so it would be nice to mark it as such:

https://www.gnu.org/software/librejs/free-your-javascript.html

[Bug] Remove specific pipenv version restriction

Description

PR #201 added a specific version of pipenv (2021.5.29). This was required as the current version of pipenv (2021.11.5.post0) does not work well on Ubuntu 20.04, which is the current default for GitHub Actions.

Reproduction

See pypa/pipenv#4833 and PR #201 GitHub Action logs.

Expectation

We should be able to use the latest version of pipenv (once it is not broken).

Once pipenv has been fixed, the specific version should be removed:

--- .github/workflows/pre-commit.yml
+++ .github/workflows/pre-commit.yml
@@ -61,12 +61,9 @@ jobs:
         python-version: "3.7"
 
     - name: Install pipenv
-      # Use pipenv 2021.5.29 to circumvent errors with 2021.11.5.post0 on
-      # Ubuntu 20.04
-      # https://github.com/pypa/pipenv/issues/4833
       run: |
         python -m pip install --upgrade pip
-        python -m pip install pipenv==2021.5.29
+        python -m pip install pipenv
 
     - name: Install Python dependencies
       run: |

Environment

• Ubuntu 20.04.3 LTS (Focal Fossa)
• actions/runner-images#1816

Additional context

• #201
• pypa/pipenv#4833

Translation metadata needs to be publicly visible

Translation metadata needs to be publicly visible

[Bug] Deeds & UX: Clarify gettext translation domain and Transifex resource slug

Description

Deeds & UX:

• gettext translation domain: django
• Transifex resource slug: django-po

Potential Issues:

• The gettext translation domain and the Transifex resource slug do not match (for the legal code, they do match).
• The Transifex resource slug is too generic (we already have multiple Django applications)

Reproduction

See file names (gettext translation domain) and Transifex resources.

Expectation

• Unless there is a compelling reason otherwise, the getttext translation domain and the Transifex resource slug should match
• The Transifex resource slug should be unique (ex. deeds_ux)

Additional context

We must keep the Deeds & UX translations distinct from the Legal Codes translations. The latter are legal documents and require much stricter change control.

[Feature] Coverage of i18n/utils.py is incomplete

Description

Coverage of i18n/utils.py is incomplete (97.50%)

Reproduction

1. Coverage Tests

   docker-compose run app coverage run manage.py test --noinput
   

2. Coverage REport

   docker-compose run app coverage report

   Name                    Stmts   Miss Branch BrPart     Cover   Missing
   ----------------------------------------------------------------------
   i18n/utils.py              72      1      8      1    97.50%   126
   licenses/git_utils.py      83      0     36      3    97.48%   70->exit, 124->126, 140->145
   licenses/models.py        241      0     50      1    99.66%   534->542
   licenses/transifex.py     201      0     42      1    99.59%   285->293
   licenses/utils.py         172      3     78      2    98.00%   60, 154-155
   ----------------------------------------------------------------------
   TOTAL                    1000      4    282      8    99.06%
   
   15 files skipped due to complete coverage.
   

Expectation

Complete test coverage

Must not publish to cc-legal-tools-data main (default branch)

Description

This application must not publish to creativecommons/cc-legal-tools-data main (default branch). Updates to creativecommons/cc-legal-tools-data main must only be done via approved pull request. This application should continue to publish to creativecommons/cc-legal-tools-data translation branches.

Reproduction

docker-compose exec app ./manage.py publish -b main

Implement translation preview sites

Improve support of CC Licensed GitHub repositories

Problem

Creative Commons does not currently provide easy to use LICENSE / attribution guidelines and snippets for GitHub repositories.

Description

This project's documentation should be organized so that project maintainers can easily find LICENSE / attribution guidelines (ideally in multiple languages). For example, see santisoler/cc-licenses.

Additionally, we may be able to leverage Transifex to manage translations of the documentation in addition to the content.

Blockers

1. Jinja2 Templates · Issue #102
2. Plaintext format generation

Make translated license texts available in plain text files

Problem

Currently, only the English version of the CC licenses are available in plain text:
https://github.com/creativecommons/creativecommons.org/tree/master/docroot/legalcode

Description

Would be nice to have all legal codes formatted in plain text along with their HTML versions.

Additional context

I've created a personal repository to make easier to add CC licenses to GitHub repositories which doesn't host software: https://github.com/santisoler/cc-licenses

Recently, the repository got attention and started to being used by other people all over the world.
This week, we had some Pull Requests for adding translations of the license texts in plain text.
The contributors had reformatted the HTML version of the license texts and storing those plain text files on my own repository.
I think it would be much better if those files can live inside this repository, and mine can only link to the files stored here.
Although my repository is having attention, I don't do proper maintenance, don't check for possible typos or changes on the legal codes, so I may host old-dated versions of the license texts in the future without noticing.

Implementation

• I would be interested in implementing this feature.

Jinja2 Templates

Problem

Django templates offer very little control over whitespace. While this has little-to-no impact on end users, it creates the following issues:

1. Inadequate Formatting: It will be very difficult or impossible to output consistent and well formatted data that is whitespace sensitive (ex plaintext, markdown)
2. Big Deltas: Unnecessary output churn from comments (with Django templates comments result in lots of blank lines). This results in many unnecessary changes in creativecommons/cc-legal-tools-data.
3. Identification: Tools like the following rely on fingerprints of the plaintext files for identification:
   • licensee/licensee: A Ruby Gem to detect under what license a project is distributed.

Description

Best practice appears to be to add Jinja2 support in addition to Django templates. This can be done for new work and then existing templates can be migrated as time allows.

Existing templates seem to use a lot of Django template features. I am not yet familiar enough with them to reproduce them with Jinja templates.

Django / Jinja2 Documentation

• Templates | Django documentation | Django
• Jinja templates in Django (chapter 4 in Beginning Django by Daniel Rubio)
• Translation
  • makemessages doesn’t understand the syntax of Jinja2 templates. To extract strings from a project containing Jinja2 templates, use Message Extracting from Babel instead. (Translation | Django documentation | Django)
    • Message Extraction - Working with Message Catalogs — Babel 2.7.0 documentation
    • Babel — Babel 2.7.0 documentation
    • Translation | Django documentation | Django
  • python - How to enable {% trans %} tag for jinja templates? - Stack Overflow
  • django - Switch language in jinja template - Stack Overflow

Alternatives

• Use Django templating
  • denizdogan/django-whiteless: Django template tags which deal with pesky whitespaces!
  • Only impacts whitespace between its tags (not before or after tags like Jinja2)--still impossible to remove whitespace from Django template directives
• Jinja2 Integrations
  • niwinz/django-jinja: Simple and nonobstructive jinja2 integration with Django.
    • Looks like it's been broken for since 2019-07-17: Django 2.2.3, custom handler500 broken · Issue #234 · niwinz/django-jinja

How to Contribute

• Pull Requests: I will accept PRs for this, but they should be as small or self-contained as possible. Please coordinate with me on Slack if your interested.
• Submit Django / Jinja2 Documentation links

[Feature] Custom legal code gettext translation domains may overly complicate Django code

Problem

Currently, this Django application uses many custom gettext translation domains:

1. by-nc-nd_40
2. by-nc-sa_40
3. by-nc_40
4. by-nd_40
5. by-sa_40
6. by_40
7. zero_10

In order to support these custom gettext translation domains, private Django objects must be referenced and manipulated. This introduces complexity and fragility.

Description

If the following were implemented, all the translation data could use the default django gettext domain while preserving legal code cohesion:

1. Decouple Django gettext translation domain and Transifex resource slug
2. Reorganize legal code files hierarchy (.mo & .po files)

Current directory structure

• legalcode
  • language code
    • LC_MESSAGES
      • by-nc-nd_40.mo (resource slug.mo)
      • by-nc-nd_40.po (resource slug.po)
      • ...
      • by_40.mo (resource slug.mo)
      • by_40.po(resource slug.po)
      • zero_10.mo (resource slug.mo)
      • zero_10.po (resource slug.po)

Potential locale hierarchy

• locale
  • deeds_ux (resource slug)
    • locale name
      • LC_MESSAGES
        • django.mo
        • django.po
  • by-nc-nd_40 (resource slug)
    • locale name
      • LC_MESSAGES
        • django.mo
        • django.po
  • resource slug
    • locale name
      • LC_MESSAGES
        • django.mo
        • django.po
  • by_40 (resource slug)
    • locale name
      • LC_MESSAGES
        • django.mo
        • django.po
  • zero_10 (resource slug)
    • locale name
      • LC_MESSAGES
        • django.mo
        • django.po

Each of the resource slug directories would need to be added to LOCALE_PATHS settings variable.

Alternatives

Leave as-is?

Additional context

• Django uses two gettext translation domains: django and djangojs (Translation | Django documentation | Django)
• Django does not have robust support for custom gettext domains (as of 2021-10-06, #6376 (Allow using custom gettext domains) – Django has been open for 14 years and untouched for 2 years).
• GNU gettext - GNU Project - Free Software Foundation

Terms

• language code: Django language codes are lowercase IETF language tags
  • language code | Terms | Internationalization and localization | Django documentation | Django
  • IETF language tag - Wikipedia
• locale name:
  • locale name | Terms | Internationalization and localization | Django documentation | Django
  • POSIX platforms - Locale (computer software) - Wikipedia (POSIX Locale)
• resource slug: Transifex resource slug
  • API 2.0 (deprecated): Resources | Transifex Documentation
  • API 2.5 (deprecated): Resources | Transifex Documentation
  • API 3.0: Resources | Introduction to API 3.0 | Transifex Documentation

[Bug] Transifex integration uses deprecated APIs (v2.0 and v2.5)

Description

The Transifex integration uses deprecated APIs (v2.0 and v2.5).

Reproduction

Introduction to the Transifex API 2.0 | Transifex Documentation:

We are deprecating the API versions namely API v2 and v2.5, to make way for the more usable and maintainable API v3.

As of April 7th, 2022 the API versions 2 and 2.5 will no longer be operational and relevant requests will begin to fail.

Introduction to API 2.5 | Transifex Documentation:

We are deprecating the API versions namely API v2 and v2.5, to make way for the more usable and maintainable API v3.

As of April 7th, 2022 the API versions 2 and 2.5 will no longer be operational and relevant requests will begin to fail.

Expectation

1. Application should use the best supported API.
2. This work should be done ASAP so that more time is not invested in code to interact with v2.0 and v2.35 API

Additional context

• Transifex API 3.0
  • Introduction to API 3.0 | Transifex Documentation
  • Transifex API v3
  • Python SDK: transifex-python/transifex/api at devel · transifex/transifex-python

Keep same language across pages

Email from user:

If i go to https://creativecommons.org/choose/ i see the license in
danish. I guess according to the browser language preferences.

Then if i click the "Kreditering 4.0 International" to go to
https://creativecommons.org/licenses/by/4.0/ that page is in english.

I would be nice if the first page in danish would keep the language to
the next page.

To change the link:
https://creativecommons.org/licenses/by/4.0/
To:
https://creativecommons.org/licenses/by/4.0/deed.da

Or whatever way is the best to keep the language across pages.

Perhaps good idea to have the same kind og language selection box across
pages instead of different ways to select language depending on what
page you are on.

[Bug] licenses.utils has unused functions

Description

licenses.utils has unused functions

evaluation command:

for f in $(grep '^def' licenses/utils.py | sed -e's/^def //' -e's/(.*$//'); do echo $f; echo; ag $f; echo; echo; echo; done

functions that are defined in utils and only referenced in tests:

• get_code_from_jurisdiction_url
• save_dict_to_pofile
• strip_list_whitespace
• cleanup_current_branch_output (may be useful for future development of branch status)

Expectation

Unused code should be verified and either documented as potentially useful for the future or removed.

[Bug] Clearly handle the variety of language code formats and cases

Description

This application must clearly and cleaning handle four different language code contexts:

1. Older Creative Commons URLs currently use POSIX locales
   • Examples:
     • pt_BR (language_REGION: ISO 639-1 _ ISO 3166-1 alpha-2)
       • https://creativecommons.org/licenses/by/2.5/pt/deed.pt_BR
       • https://creativecommons.org/licenses/by/4.0/deed.pt_BR (Deeds are shared across versions)
     • sr@latin (language@script: ISO 639-1 @ ISO 15924)
       • https://creativecommons.org/licenses/by/2.0/deed.sr@latin (404s, but there are enough log entries to indicate it should be a redirect)
     • zh_TW (language_REGION: ISO 639-1 _ ISO 3166-1 alpha-2)
       • https://creativecommons.org/licenses/sampling/1.0/deed.zh_TW
       • https://creativecommons.org/licenses/by/1.0/deed.zh_TW
       • https://creativecommons.org/licenses/by/4.0/deed.zh_TW (Deeds are shared across versions)
2. Newer Creative Commons URLs currently use conventional IETF language tags
   • RFC5646 (references replaced with Wikipedia links, code emphasis added):

     the tag "mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" or "mN-cYrL-Mn" (or any other combination), and each of these variations conveys the same meaning: Mongolian written in the Cyrillic script as used in Mongolia.

     [...]

     Although case distinctions do not carry meaning in language tags, consistent formatting and presentation of language tags will aid users. The format of subtags in the registry is RECOMMENDED as the form to use in language tags. This format generally corresponds to the common conventions for the various ISO standards from which the subtags are derived.

     These conventions include:

     o [ISO 639-1] recommends that language codes be written in lowercase ('mn' Mongolian).

     o [ISO 15924] recommends that script codes use lowercase with the initial letter capitalized ('Cyrl' Cyrillic).

     o [ISO 3166-1 alpha-2] recommends that country codes be capitalized ('MN' Mongolia).

   • Examples:
     • sr-Cyrl (language-Script: ISO 639-1 - ISO 15924)
       • https://creativecommons.org/licenses/by/3.0/rs/legalcode.sr-Cyrl
     • sr-Latn (language-Script: ISO 639-1 - ISO 15924)
       • https://creativecommons.org/licenses/by/3.0/rs/legalcode.sr-Latn
     • zh-Hans (language-Script: ISO 639-1 - ISO 15924)
       • https://creativecommons.org/licenses/by/4.0/legalcode.zh-Hans
     • zh-Hant (language-Script: ISO 639-1 - ISO 15924)
       • https://creativecommons.org/publicdomain/zero/1.0/legalcode.zh-Hant
3. Transifex uses POSIX locales
   • Examples:
     • pt_BR (language_REGION: ISO 639-1 _ ISO 3166-1 alpha-2)
     • sr@latin (language@script: ISO 639-1 @ ISO 15924)
     • zh_TW (language_REGION: ISO 639-1 _ ISO 3166-1 alpha-2)
     • For a complete list, see: Languages on Transifex
4. Django uses lowercase IETF language tags
   • Examples:
     • ar-dz (language-region: ISO 639-1 - ISO 3166-1 alpha-2)
     • dsb (language: ISO 639-2)
     • sr-latn (language-script: ISO 639-1 - ISO 15924)
     • zh-hans (language-script: ISO 639-1 - ISO 15924)
     • For a complete list, see: django/django:django/conf/global_settings.p:Lines 50-148

Each of the above contexts are the same when it comes to simple languages (no locale/region or script):

• is (language: ISO 639-1)
  • https://creativecommons.org/licenses/by/1.0/nl/deed.is
  • https://creativecommons.org/licenses/by/4.0/deed.is
• nl (language: ISO 639-1)
  • https://creativecommons.org/licenses/by/1.0/nl/deed.nl
  • https://creativecommons.org/licenses/by/4.0/deed.nl

Expectation

1. Internally, this application should use Django lowercase IETF language tags
2. Mappings should be maintained so that:
   • the application can easily interface with Transifex
   • the application can create redirects from the variety of contexts to the canonical URL

References

• Django Language Codes:
  • django/django:django/conf/global_settings.p:
    Lines 50-148
• Transifex Language Codes: Languages on Transifex
• References:
  • IETF language tag - Wikipedia
    • RFC5646 Tags for Identifying Languages
      • ISO 639-1 - Wikipedia Codes for the representation of names of languages—Part 1: Alpha-2 code
        • List of ISO 639-1 codes - Wikipedia
      • ISO 639-2 - Wikipedia Codes for the representation of names of languages — Part 2: Alpha-3 code
        • List of ISO 639-2 codes - Wikipedia
      • ISO 3166-1 - Wikipedia Codes for the representation of names of countries and their subdivisions – Part 1: Country codes
        • ISO 3166-1 alpha-2 - Wikipedia
      • ISO 15924 - Wikipedia Codes for the representation of names of scripts
  • POSIX platforms - Locale (computer software) - Wikipedia (POSIX Locale)

Plaintext in multiple languages on the licenses

Description

Plain text formats for the 4.0 licenses and the CC0 public domain dedication were created using a manual process. Only the English versions of the legal tools were formatted as plain text. Additionally, that manual creation process was not without errors and is not sustainable.

Expectation

Extend the CC Legal Tools App to generate deterministic plain text versions of the 4.0 licenses and the CC0 public domain dedication (including all translations):

@CreativeCommons Suggestion: I often encounter a frustrating issue: the plaintext version of licenses is only available in English.
What I would like: just like you append .txt to get https://t.co/xj09QHxa8o, get https://t.co/7BinrQoJXI to work too.
Cleaning myself is long 😉

— Matti Schneider (@matti_sg) January 5, 2018

Requirements

Updated requirements given cc-legal-tools-app:

• Plaintext format should be generated from "source" like the HTML is (not using Pandoc)
• Plaintext format generation should be idempotent--the output should be the same each time
• Plaintext output should exactly match existing plaintext files (except where those files are in error)
  • Plaintext versions of Creative Commons licenses and CC0 - Creative Commons
  • Plaintext versions of Creative Commons 4.0 licenses - Creative Commons
  • #286

RDF/XML generation

(This is not a launch blocker)

Problem

We are hoping to tightly couple RDF/XML generation with the new legal tools infrastructure. The new data models used in the Django app should be a good step forward towards simplifying the generation of RDF/XML.

Currently, as a stopgap measure, this application simply reuses the legacy RDF/XML (with known gaps and faults).

Description

This application should be extended to generate RDF/XML files from "source" just like it does for the HTML documents.
The generated RDF/XML files must be deterministic and well organized and based on current RDF specifications. Application updates must include test coverage.

Related Links

• RDF (Resource Description Framework)
  • RDF/XML - Wikipedia
  • RDFa 1.1 Primer - Third Edition
• ccREL
  • Describing Copyright in RDF - Creative Commons Rights Expression Language
  • CC REL - Creative Commons (CC Public Wiki)
  • creativecommons/ccrel
    • ccREL: The Creative Commons Rights Expression Language
  • creativecommons/ccrel-guide
    • CC REL by Example

[Bug] Documentation is wrong about Django translation domain

Description

Documentation is wrong about Django translation domain

Reproduction

There are only two Django translation domains:

1. django
2. djangojs

Specialties of Django translation:

The string domain is django or djangojs. This string domain is used to differentiate between different programs that store their data in a common message-file library (usually /usr/share/locale/). The django domain is used for Python and template translation strings and is loaded into the global translation catalogs. The djangojs domain is only used for JavaScript translation catalogs to make sure that those are as small as possible.

However, our README.md incorrectly states:

The Django translation domain and corresponding Transifex resource is different for each tool.

The previous wording of README.md was also incorrect:

Also note: What Transifex calls a resource is what Django calls a domain. I'll probably use the terms interchangeably.

and

For the license legal code, for each combination of license code, version, and jurisdiction code, there's another separate domain. These are all in cc-licenses-data under legalcode.

I expect this confusion arose because Django translations utilize Gnu gettext, which bases its translation domain on the PO file name.

Expectation

The Django domain for all of our translations is always django. Only the PO file name (Gnu gettext translation domain) and the Transifex resource slug are varied. The documentation should be accurate.

Additional context

We must keep the Deeds & UX translations distinct from the Legal Codes translations. The latter are legal documents and require much stricter change control.

Documentation

• Translation | Django documentation | Django
• Resources | API 2.0 (Deprecated) | Transifex Documentation
• Resources | API 2.5 (Deprecated) | Transifex Documentation
• Resources | Transifex API v3
• gettext — Multilingual internationalization services — Python 3.9.6 documentation
• GNU gettext utilities

[Feature] Consider using "Notice" instead of "Disclaimer"

Problem

Consider using "Notice" instead of "Disclaimer".

Description

"Notice" may offer better clarity when translated. Per #145 (comment):

Thank you for working on this. Great that you are using Dutch as a translation example. I noticed that disclaimer is being translated to 'vrijwaring'. Which is in a legal sense a good translation, but not for notices that have no legal significance. I wonder if other translation will have the same issue with translating disclaimer.

Can I suggest that we rethink the word 'disclaimer' as a heading? Should we change that heading to 'notice'?

Additional context

Unless we already have "Notice" as a translation key, it is probably best to leave this until after the initial launch.

Adding Docker and Docker Compose Support

Problem

Currently, to set up the development environment, having python 3.7 and starting a separate Postgres server is required.

Description

This process can be automated by creating a docker image for the Django server based on python 3.7 and using Postgres docker image. Then these images can be managed by docker-compose, hence requiring only a docker-compose up to start the server.

Implementation

• I would be interested in implementing this feature.

The Public Domain Mark (PDM) is available at two URLs (no canonical URL)

Description

The Public Domain Mark (PDM) is available at two URLs (no canonical URL):

Reproduction

1. https://creativecommons.org/publicdomain/mark/1.0/
   • ✅ Correct
2. https://creativecommons.org/licenses/mark/1.0/
   • ❌ Incorrect: it is not a license and there is no legalcode for it.

Expectation

There should be a single canonical URL for the PDM. Other URLs should redirect to it.

Additional context

• PDM FAQ - Creative Commons

[Feature] Coverage of licenses/views.py is incomplete

Description

Coverage of licenses/views.py is incomplete (91.61%)

Reproduction

1. Coverage Tests

   docker-compose run app coverage run manage.py test --noinput
   

2. Coverage REport

   docker-compose run app coverage report

   Name                    Stmts   Miss Branch BrPart     Cover   Missing
   ----------------------------------------------------------------------
   i18n/utils.py              72      1      8      1    97.50%   126
   licenses/git_utils.py      83      0     36      3    97.48%   70->exit, 124->126, 140->145
   licenses/models.py        241      0     50      1    99.66%   534->542
   licenses/transifex.py     201      0     42      1    99.59%   285->293
   licenses/utils.py         172      3     78      2    98.00%   60, 154-155
   licenses/views.py         115      7     40      4    91.61%   52-55, 163, 167, 184, 390
   ----------------------------------------------------------------------
   TOTAL                    1002     11    284     12    98.06%
   
   14 files skipped due to complete coverage.
   

Expectation

Complete test coverage

[Bug] Translation normalization falsely detects translations on Transifex

Description

Translation normalization falsely detects translations on Transifex

Reproduction

1. Run normalization command:

   docker-compose exec app ./manage.py normalize_translations -v3 -n
   

2. Output excerpt:

   DEBU 23:58:59 <NOP> Deeds & UX (deeds_ux) af: Transifex already contains translation.
   

3. However, there isno Afrikaans (af) translation on Transifex:
   

Expectation

Normalization command should properly detect state and take appropriate action.

Additional context

It is currently detecting language instead of translation.

Add plaintext license link to XHTML versions

What

I continually want to download the plaintext versions of the licenses, so that I can bundle them with my software repositories. However, there are no easy links to the plaintext versions in the XHTML pages for the licenses. Adding a link would be very useful in cutting down on search time.

Links

Here are the plaintext files I am thinking of: https://creativecommons.org/2014/01/07/plaintext-versions-of-creative-commons-4-0-licenses/

Here is an example of an XHTML page without a license file that is downloadable: https://creativecommons.org/licenses/by-sa/4.0/legalcode

How

There are a few possible solutions:

• I can PR a link for you to the XHTML pages;
• We could make a link to a single GitHub repository where all of the plaintext licenses are kept
  • I could make this repo, and then move it to Creative Commons organization, or just have it on my profile, I guess.
• We could make an exportable license package for software; npm i cc-by-sa-4.0, for instance.

Finally

Thank you! Great work, creative commons. :)

Missing .txt legalcode version of CC BY 3.0 IGO

From info@:

Hi,

Looking for the text version of the CC BY IGO (3.0).
In theory, it should be here:
https://creativecommons.org/licenses/by/3.0/igo/legalcode.txt

As is the case (for example) with CC BY 4.0:
https://creativecommons.org/licenses/by/4.0/legalcode.txt

However that just bounces to a HTML version of the document,
which isn't useful for our purposes.

Any chance of getting that fixed in the very near future?

Rename TRANSLATION_REPOSITORY_DIRECTORY to DATA_REPOSITORY_DIR

Description

Rename TRANSLATION_REPOSITORY_DIRECTORY to DATA_REPOSITORY_DIR.

Additional context

TRANSLATION_REPOSITORY_DIRECTORY is a misnomer. The translations directories are subdirectories of that directory (the data repository directory).

[Bug] Translation normalization uses resource_stats revision_date instead of translation_stats last_translation_update

Description

Translation normalization uses resource_stats revision_date instead of translations_stats last_translation_update. This results in all languages having the same (inaccurate) date instead of a date for each language.

Reproduction

https://github.com/creativecommons/cc-licenses/blob/fcd042242ddaa940ee1e8e208c6871116d728e49/licenses/transifex.py#L739-L741

Expectation

Instead it should be:

        transifex_revision = dateutil.parser.parse(
            self.translation_stats[resource_slug][transifex_code]["last_translation_update"]
        )

Additional context

• Translation - README.md - creativecommons/cc-licenses
• Definitions - README.md - creativecommons/cc-licenses-data

[Feature] Move transstats gen_statistics to i18n.utils and include in publish

Problem

Too much code is in management command which prevents it from being effectively referenced from multiple places.

Description

Move transstats command's gen_statistics function to i18n.utils and include in publish command.

Additional context

The transstats command generates a CSV file with translation statistics

Legalcode translation process proposal

Description

Write initial legalcode translation process proposal and discuss with Caktus (technical) and Creative Commons Legal.

Goals:

• improve existing translation process
• minimize barriers for community involvement
• better leverage technology to increase feedback and visibility

[Bug] Translation directories should use locale name instead of language code

Description

Translation directories should use locale name instead of language code.

Terms

• language code: Django language codes are lowercase IETF language tags
  • language code | Terms | Internationalization and localization | Django documentation | Django
  • IETF language tag - Wikipedia
• locale name:
  • locale name | Terms | Internationalization and localization | Django documentation | Django
  • POSIX platforms - Locale (computer software) - Wikipedia (POSIX Locale)

Reproduction

creativecommons/cc-licenses-data:locale/sr-latn: sr-latn is a language code, not a locale name

Expectation

How Django discovers translations | Translation | Django documentation | Django:

In all cases the name of the directory containing the translation is expected to be named using locale name notation. E.g. de, pt_BR, es_AR, etc. Untranslated strings for territorial language variants use the translations of the generic language. For example, untranslated pt_BR strings use pt translations.

Additional Information

Django offers a function to help with this: to_locale | django.utils.translation | Django Utils | Django documentation | Django:

• to_locale(language)
  • Turns a language name (en-us) into a locale name (en_US).

3.0 jurisdiction-variants confusing

I found it confusing that https://creativecommons.org/licenses/by/3.0/us/legalcode and https://creativecommons.org/licenses/by/3.0/legalcode are different licenses. Maybe links between these different variants would help others avoid the same confusion?

CC 4.0 plain text licenses: third level numbering in lower case but referencing in upper case

Description

The CC 4.0 plain text licenses use lower characters (a, b, ...) in the third level of the numbering, e.g. Section 2(a)(1) or 2(a)(5), but the internal references use upper case letters (A, B, ...), e.g. Section 2(a)(6) or Section 3(a)(3). This is inconsistent and potentially misleading.

The HTML versions of the license text does consistently use upper cases across all third level enumerations and references.

Expectation

Consistent naming equal to the HTML version.

Resolution

• I would be interested in resolving this bug.

I would be willing to capitalise those ~30 letters if I get a go ahead.

Need a real "errata" page on deeds and legalcode

Problem

Currently, the legalcode errata link at the top of the deeds doesn't do anything.

Use of 'language turnstile' icon for translation switching inappropriate for a Creative Commons site, replacement needed

Description

A resource used on the Creative Commons site should not violate CC best practices; however as I will show below, the 'language turnstile' icon currently in use on the site does violate them.

Reproduction

1. Visit a CC legal instrument summary page, for example https://creativecommons.org/publicdomain/zero/1.0 (my favourite).
2. Observe text at the top of the page: "This page is available in the following languages: " followed by an icon.
3. Confirm that the icon is the same as described at https://en.wikipedia.org/wiki/Language_Icon, complete with problematic license.
4. See error.

Expectation

The Creative Commons website would have a translation-switching interface that either eschewed use of an icon altogether, or used one released using a CC legal instrument (ideally one of the more permissive ones to better align with the rest of the content on the site), rather than a non-CC license that uses CC branding against best practices.

Screenshots

https://creativecommons.org/images/language_icon_x2.png

Environment

I am certain the problem is not environment-specific.

• Device: laptop
• OS: PureOS
• Browser: Firefox
• Version: 78.5.0
• Other info: N/a

Additional context

• https://wikidata.org/wiki/Q101001302 refers to the offending license in question.
• https://wiki.creativecommons.org/wiki/Modifying_the_CC_licenses point 1 is the best practice the license (and therefore the licensed content) violates.
• coreinfrastructure/best-practices-badge#1052 is another discussion about the suitability of this icon.
• https://framagit.org/peppercarrot/website/-/commit/aa520b285598c56daced5ceb2f747a68d109a8ae is a case of the icon being replaced with an alternative.
• mdn/mdn-dinocons@553a49d#diff-5e7e32f89e4d18de5bc99997e13b9c99b885c575128228da760b952f0caa64bf is another replacement.

Resolution

• I would be interested in resolving this bug; however I am only mildly familiar with using Git.

Followup

2021-01-11: added example of someone switching from the icon to the 'additional context' section.

I don't know much about agile, what do the tags/projects the bot attached mean?

2021-02-10: changed 'additional context' section from paragraph to bulleted list form

make canonical URIs more visible on the website

It seems that the idea of using CC license URIs to refer to them is gaining ground as a (good) idea. See for instance the rights statements of IIIF Presentation API 3.0.

My concern is that because canonical URIs are not very explicit on the website and the RDF versions are not very obvious to find (which is normal), users might start to refer to licenses with some non-canonical URIs such as the https version, or the version ending in /deed, which seems like a bad idea...

I think canonical URIs of the various licenses should appear explicitly on the website, with an indication like "URI to use to refer to this license: XXX". One possible source of inspiration is https://rightsstatements.org/page/1.0/?language=en which makes the canonical URIs very explicit.

see IIIF/api#1874

[Bug] Project does not support Docker with Pre-commit

Description

The docker environment is the primary supported development environment. It offers better parity with production and testing than a purely local pipenv and related services. However, the pre-commit hooks (as currently documented in README.md) act against the local repository, not the docker environment.

Expectation

If pre-commit cannot be configured to work with the Docker environment, it should be dropped.

Regardless of wether pre-commit is dropped or its configuration is updated, the GitHub action should be updated to better minimize the delta between what is done in developer's environments and what is done via GitHub Actions.

Configurations

• Docker
  1. Dockerfile
  2. docker-compose.yml
• pre-commit
  • main/.pre-commit-config.yaml
• GitHub Action
  • .github/workflows/pre-commit.yml

Additional context

• Docker
  • Dockerfile reference | Docker Documentation
  • Compose file version 3 reference | Docker Documentation
• pre-commit: A framework for managing and maintaining
  multi-language pre-commit hooks.