Copyrights Guard

Copyrights Guard is a Drupal module that enforces copyright restrictions at the level of individual fields. For any entity type an administrator marks as managed, it decides field by field whether the current viewer may see a protected value, and hides anything restricted or unrecorded from everyone except the site owner.

It is the enforcement half of a two-part system: a separate family of modules, field_copyright, copyrights and copyrights_ext, records who holds what rights over a piece of content, and Copyrights Guard acts only on what those records say. It is built and in use in development on MADDev's own research platform, where it protects scripture passages and translations as its first wired content; it is not yet running on a public site.

Modules

copyrights_guard, the only module; no submodules

Drupal core

10 or 11

Requires

No hard dependencies beyond Drupal core

Entity types

None of its own; it is a policy layer over fields on entity types provided by other modules

Works with

Any entity type configured with a licence field and one or more fields to protect

Fair-use excerpt

A short public excerpt allowed on restricted content, 30 words by default

Status

Built and in use in development on MADDev's own research platform, protecting scripture passages and translations as its first wired content. Not yet running on a public site.

Field-level access gate

The module's whole enforcement surface is one hook, hook_entity_field_access(). It acts on the view operation only: on a managed entity, the fields configured as content fields are forbidden to any viewer other than user 1, the site owner's account, while every other field, such as title, citation, provenance or other metadata, stays untouched and public. Editing and deletion are left entirely to the host entity's own access handler. The hook governs Drupal's Field API render path; a render path that reads a field's value directly, bypassing that layer, is not covered and needs its own check.

Service

The service copyrights_guard.guard (class CopyrightGuard) is the module's API for other code:

• whether an entity type is managed, and which of its fields are protected
• whether a given entity is restricted, or has no recorded licence at all
• an entity's licence, rights holder and contact
• a fair-use excerpt of a piece of text

Settings

An administration form at /admin/config/content/copyrights-guard, behind the administer site configuration permission, lets an administrator choose which entity types are managed, add extra restricted licence identifiers, and set the fair-use excerpt length. The rest of copyrights_guard.settings, the map from each managed type to its licence, holder, contact and content fields, is set directly in configuration rather than through the form.

Drush command

copyrights-guard:incomplete (alias cg:incomplete) lists every managed entity with no recorded licence, the module's fail-safe worklist.

• Gate the content, not the catalogue. Enforcement acts field by field rather than on the whole entity, so a restricted work's title, existence, authorship and citation stay public, and only the content field or fields configured for that type are hidden.
• Only the site owner sees restricted content. The exception is the site owner's account (user 1), deliberately not a permission, so no role can be given access by accident.
• Default deny. A managed entity with no recorded licence is treated as restricted automatically: wrongly publishing something is treated as the more serious failure, and hiding something that could legally have been shown is treated as the lesser one.
• Free-licence markers are checked before restriction markers. A genuine Creative Commons or public domain statement often still carries a copyright line, because Creative Commons licensing is itself built on copyright, so the module looks for free-licence wording first, to avoid wrongly gating a freely licensed work.
• The fair-use excerpt is capped at half the source text's length, not a flat word count, so a short protected text cannot be turned into an excerpt that is effectively the whole work.
• Field mapping is entirely config-driven. A new managed entity type is wired up through settings, not code, so the module never hardcodes a particular entity type or field name.