Joystream / Joystream/joystream

Runtime level content terms

Open
#4,305 0 comments 0 reactions 0 assignees View on GitHub
content-pallet idea post-mainnet urgent-post-mainnet
Dominant language
Rust
Stars
1.4k
Forks
116
PR merge metrics
No merged PRs in 30d

Description

# Background

At the moment there is no runtime level clarity or commitment around what exactly the creator is authorizing people to do with their creative work. Obviously, the gateway, if one is used (which need not be the case), may possibly have some terms, but those

1. are not visible to the DAO,
2. may not fully address all areas which are relevant to the goals and activities of the DAO,
3. may conflict with the goals of the DAO.

In particular what is important to address, so as to facilitate scaleable republishing, remixing or other utilizations of some content is to standardize a set of global terms which provide clarity for all parties involved. Currently, each video can be subject to arbitrary terms

```graphql
type License implements BaseGraphQLObject
{
id: ID!
createdAt: DateTime!
createdById: ID!
updatedAt: DateTime
updatedById: ID
deletedAt: DateTime
deletedById: ID
version: Int!
code: Int
attribution: String
customText: String
videolicense: [Video!]
}
```

or no terms at all, since `Video::license` is nullable. In this scenario, it leaves the platform open to disputes around creator expectations being violated, and it also deters gateways from repurposing existing content in all the ways they may want to due to a lack of clarity.

The way this would work would be as follows: A creator triggers a signup flow on some Gateway. As part of this flow, they sign some terms of service through, a clickwrap, which must clearly present the runtime level terms, either exclusively or at least clearly. As long as both the gateway and DAO terms are [reasonable](https://law.stackexchange.com/questions/13549/are-terms-of-service-legal-contracts), then it seems the legal side of things should be fine. The DAO must inspect all applications through which people are creating channels, something which will be possible through #4307, and make sure terms are being presented. **It's critical to understand that what we are solving for here is to align expectations by being explicit about what commitments are being made and to provide a solid footing for honest application developers and the DAO. We are not intending to solve adversarial applications that are intending to deceive systematically.**

# Proposal

For all channels make the _runtime_ , specifically content pallet, enforce (so below metaprotocol) that a signal from the author that they are opting into one among a set of existing valid licenses. The set of licenses valid at any point in time is set by the council through a proposal. So literally it would be `create_channel(..., license_id: T::LicenseID)`, where `license_id` has to live in some small `BTreeSet`, and there is a `Root` origin gated `add_license(URL, hash)` which adds to this set. Probably also need `retire_license(license_id: T::LicenseId)` and `update_license(URL)`. Alternatively, there could be an integration with the council storage bag to store natively, but that would be more work.

**What exactly should be described in these license texts is outside of the scope of this specific proposal.**

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.