FEP-c118: Content licensing support

Standards Fediverse Enhancement Proposals
, ,
1

Hello!

This is a discussion thread for the proposed FEP-c118: Content licensing support. Please use this thread to discuss the proposed FEP and any potential problems or improvements that can be addressed.

Summary

Currently, popular Fediverse software does very little to establish the legal status of posts. Controversy over indexing and scraping the Fediverse is common. The hope is that providing a legal framework to express the desires of users as to how their content may be re-used might bring order to this debate.

4 Likes
2

Hello, Tim here, just to say that the purpose of this FEP is obviously to start a discussion rather than argue for one particular option. But I’m pretty convinced that a licensing framework would benefit many Fediverse users, including those who would prefer to avoid thinking about this sort of thing.

2 Likes
3

Thank you Tim, and welcome to SocialHub :wave:

I think this is a valuable FEP that warrants a good elaboration. Wrt the resources you already added at the bottom, and the mention of common fedi reaction to someone running an indexer, there was this related HN Discussion yesterday, on the Searchtodon maintainer apologizing with a good retrospective and thoughts.

1 Like
4

This is a (quite) question of #openweb vs #closedweb

The Fediverse worked/s because it is #4opens at a protocol and #UX implementation, it’s a #openweb project, this is a good thing. Yes, the is a history of well worded “white lies” about privacy and safety that have helped to change social behavers. A kinda not bad thing.

One of the #4opens is #opendata, every post has a URL, the is no encryption at all, in this all “privacy” is based on trust, a good thing.

I agree with the need for #openlicence for content, it’s one of the #4opens, a good thing.

Where I worry, a little, is some people seeing this (often unthinkingly) as an opertunerty to push #closedweb thinking into a #openweb project. This is a small problem that is good to keep an eye on :slight_smile:

My though is to set a permissive CC content licence as default (the power of default) and let users change this to completely open or a more restricted licence, then “trust” coders/people to respect this.

2 Likes
5

Consent mechanism

Instead of a focus on the licensing itself, which as @TimBray states is a “somewhat-technical” perspective, the FEP might be reworked into a mechanism whereby fedizens can clearly express their consent wrt what happens with their content. That also expresses a freedom: “I provide this information to you all, but on these terms”. E.g. not for commercial use, for instance (I had a discussion on that yesterday).

1 Like
6

Given the topic I thought it would be worth knocking this crayon license your way again

https://git.sr.ht/~indieterminacy/iq-nq_qiuy-knowledge-management/tree/main/item/iq-nq_qiuy-knowledge-management.gmi

The logic of the approach is that there would be more of a graph orientated approach regarding licensing - with (version defined) software interpretation setting the criteria for which line/block/doc should have which license.

Ive considered this not only with regards to the articulation of repo centric permissiveness/restrictions from licenses but also for services

2 Likes
7

Thanks. This gave me the idea that if licensing information will be somehow part of the AP messages, then there’s the SPDX that offers an ontology. Though SPDX is more for software artifacts, it supports consistent definition of many licenses.

1 Like
8

CC-BY-NC might deter some commercial uses, but I think the existing commons licenses are really inadequate for social network posts, and that probably a new license needs to be invented which explicitly regulates scraping for academic or commercial or ML uses. Licenses won’t stop bad actors, but they may deter the worst abuses by mainstream organizations who need to at least appear to be legitimate.

In Epicyon I am now displaying a license icon on each post, linking back to the full license text. In ActivityPub it’s another attachment on a Note.

"attachment": [{
  "name": "license",
  "type": "PropertyValue",
  "value": "CC-BY-NC"
}]

or

"attachment": [{
  "name": "license",
  "type": "PropertyValue",
  "href": "https://creativecommons.org/licenses/by-nc/4.0"
}]
4 Likes
9

We should try to use existing work and avoid reinventing wheels.

Open Digital Rights Language (ODRL)

3 Likes
10

Hi

I think it is very weird to frame scrapping (an old thing btw, december 2022 is pretty much “born yesterday” for the fediverse) under licensing.
GnuSocial allowed default licences like CC-BY-SA 2.5 for post content (similarly to say wikipedia) and so far effectivelly no one copied that over to more recent fediverse software.

The vast majority of the concerns when it comes to scrapping are privacy-based, and harvesting personal data without consent is illegal under data privacy laws like the GDPR.
I would also say that Creative Commons is horribly inapropriate, there is no opt-out from (re)distribution. While I’m at it, CC-*-ND would pretty much mean no federation.

And I don’t think copyright is the appropriate law to base yourself on when it comes to data privacy, even with considering moral rights. Please consider asking a lawyer.

Now on actual solutions, technical-side:

  • Make your software require authentication to view posts. Pleroma and Mastodon got that years ago
  • Force ActivityPub-fetching of posts to have HTTP Signatures, Mastodon got that years ago, IIRC Pleroma also has it (Note: it will likely create some federation problems)
  • Maybe consider accept-list based federation, Pleroma got that years ago, there is some Mastodon forks with that feature in the wild

I wish this FEP would have been about fixing the lack of SPDX or a similar system in PeerTube and equivalent fediverse software… not proposal-less drama.

4 Likes
11

@lanodan with regards to your referral to “proposal-less drama” I kindly request you to (re)read the FEP procedure which explicitly states that:

  • Proposals are not limited to technical topics and may focus on social and cultural aspects.
  • Proposals may be entertaining and humorous.
  • Authors are responsible for initiating community discussion and collecting feedback.
  • Authors may submit updates to the proposal which will be checked in to the repository by an editor.

@TimBray as author of the FEP and new member of this community followed correct procedure, and your feedback and background above is much appreciated. Licensing is always a hot topic, and apparently there’s enough food for discussion :slight_smile:

2 Likes
12

On your “actual solutions, technical-side”: I was totally shocked when I found out that most Mastodon instances (and apparently all the large ones) freely expose all the non-followres-only posts to any HTTP GET without any requirement for knowing who is GETting and whether they have acknowledged the interests of the posts’ authors. So I think the first of your bullet points would be a huge step forward.

Obviously this kind of thing is not going to deter the really malicious actors. But forcing people fetching Fediverse data to accept some sort of conditions-of-service would definitely be useful in deterring unwanted commercial activity.

1 Like
13

There is also Creative Commons Rights Expression Language (ccREL) which is adopted by the GNU Project. Creative commons have this guide: CC REL by Example.

@TimBray you may ping Neil Brown on the fedi about legislation concerns mentioned by @lanodan. I have seen people mention the license of their toots in their profile, curious for instance if that carries any legal meaning.

3 Likes
14

per activitypub: ActivityPub

Activities may additionally be addressed to the special “public” collection, with the identifier https://www.w3.org/ns/activitystreams#Public […] Activities addressed to this special URI shall be accessible to all users, without authentication.

in other words, Public is public. even so, softwares such as mastodon and pleroma have features like AUTHORIZED_FETCH to require authorization as an actor, using a valid http signature on the GET request, or else the GET will fail. i don’t think this is something you can enforce network-wide unless you proposed another pseudo-scope other than Public, which has also been done before in as:Authenticated proposal · Issue #339 · w3c/activitypub · GitHub and similar discussions. the problem, of course, is that creating your own activitypub actor and keypair to perform http signatures is not actually a significant barrier to scraping, unless you also implement an allow-list on who can fetch. a deny-list alone will not be sufficient, as objects and resources may be fetched on behalf of some other unknown actor via a “trusted” actor.

alternatively, you can use audience to refer to some (pseudo-)collection and rely on inbox forwarding (assuming support for both the audience property and for inbox forwarding). such posts will probably appear to be “private” on remote sites; this would be fine if you didn’t care to have remote sites understand additional semantics beyond the explicitly delivered-to actors as Public implies, or as a hypothetical Authenticated collection might imply, or even as the followers collection implies in current fediverse interpretations – these are considered “magic collections” for the purposes of federation, and current implementations are expected to “know” who is following without being explicitly told who is following. (personally i think such “magic collections” are a big mistake, but that’s a different discussion.)

it’s important to consider that the vast majority of documents are actually delivered and not fetched – if you want to stop people from doing things you don’t want with them, then you need to vet your followers and not just impose access controls on fetch.

insofar as these conditions are made known and are understood ahead-of-time, then… maybe? i doubt an “i agree to the terms and conditions” for machine parsers would be particularly useful, but some indication of what you expect might help. consider a hypothetical “origin only” flag or scope that indicates that the author doesn’t want their posts to be redistributed. in such cases, perhaps you could respect that flag by not rendering their posts in threaded contexts. the post would instead be shown only as a link or URL (which must be fetched or loaded like a web page). but to extend this to an entire framework of expectations and behaviors, it would be necessary to first define those expectations and behaviors.

1 Like
15

I think this topic can be split into two parts:

  1. Encouraging good behavior
  2. Enforcing good behavior

I would like to have a good idea how to do 1. As I pointed out on Mastodon (helge: "@timbray@hachyderm.io @david_megginson@mstdn.ca @…" - mas.to), I’m thinking worried about a simple and frequent use case.

Use Case: A picture

I want to post the status “Dandelions are the best!” as this is a bit bland, I want to add an image and Wikipedia to the rescue, I find one: File:Dandelion (3509409143).jpg - Wikimedia Commons

There I find the information

This file is licensed under the Creative Commons Attribution-Share Alike 2.0 Generic license.

    You are free:

        to share – to copy, distribute and transmit the work
        to remix – to adapt the work

    Under the following conditions:

        attribution – You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
        share alike – If you remix, transform, or build upon the material, you must distribute your contributions under the same or compatible license as the original.

So how do I include this in my status?

Proposal

We already have plenty of Metadata in the attachment list in the ActivityPub Activity, e.g.

        {
            'type': 'Document',
            'mediaType': 'image/png',
            'url': 'image.png',
            'name': 'A lovely dandelion
            'blurhash': 'xxxxx,
            'focalPoint': [0,0],
            'width': 800,
            'height': 600
        }

We can now add another to it containing something like

"license": {
     "type": "License",
    "name": "CC-BY-2.0",
    "href": "https://creativecommons.org/licenses/by/2.0/",
    "creator": "wikipedia contributor",
    "original": "https://wiki"
}

I know that I probably reinvented the wheel here, I just couldn’t figure out how to do it with the linked vocabularies.

The interface to add this would be similar to the one adding alt texts. This can be done with a dropdown + two text fields (creator, original) where applicable. Thus it would not impose too much work on the user.

1 Like
16

ccREL was submitted to the W3C in 2008 as a Member Submission. ODRL 2.2 became a W3C Recommendation in 2018. Therefore one can assume that ccREL was carefully looked at when ODRL was developed.

17

Given speculation about this FEP I want to firmly note that my only interest wrt this proposal is the ability to state that my content adheres to open licenses e.g. public domain, creative commons or what-have-you, and that if this goes into direction of native DRM impl, I am HIGHLY opposed to going in that direction (because that will only serve hypercapitalist parties). I know that this FEP can’t hold back abuse by bad actors, same as the license we put under our personal website, or on assets uploaded to Wikimedia. Also agree that software and open data licensing based on copyright law is far from perfect, yet we still use this feeble tool throughout the FOSS movement. I can imagine that an outcome is that there is no practical way to implement things, given the complexities that would bring to federation.

3 Likes
18

Yes, the #Fediverse is an example of an #openweb project, which means that the protocols and user experience are open and accessible to anyone. One of the key features of the Fediverse is that it is based on #opendata, with every post having a unique URL and no encryption. This means that privacy is based on trust, which can be seen as both a good and a bad thing.

In terms of content licensing, it is important to promote open licences that allow for the free sharing and reuse of content. One approach to this is to set a permissive Creative Commons licence as the default, and allow users to choose a more restrictive licence or a completely open licence if they prefer. This approach empowers users to make their own choices about how their content is shared and used, while also trusting developers and other users to respect those choices.

#openweb vs #closedweb open licenses for content and opposed to the implementation of DRM within the Fediverse, and as @aschrijver says this is a complex issue that may not have a practical solution.

1 Like
19

It could be added as another attachment, although this would not cover the case of having multiple attached images with different licenses.

20

it is important to promote open licences that allow for the free sharing and reuse of content.

A lot of Fediverse instance admins want to discourage scraping and index-building, for reasons that seem good to them (and me). The issue is rather fully discussed here: ongoing by Tim Bray · Private and Public Mastodon

So in their case they would probably want to use -NC-ND- CC licenses by default.

But at the moment few if any Fediverse instances bother with any licensing at all.

2 Likes