joystream icon indicating copy to clipboard operation
joystream copied to clipboard

Runtime level content terms

Open bedeho opened this issue 2 years ago • 0 comments

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

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, 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<T::LicenseID>, 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.

bedeho avatar Sep 22 '22 20:09 bedeho