FEP-c118: Content licensing support

Standards Fediverse Enhancement Proposals
, ,
41

[this got lost in the either but was cached, Im pushing… maybe the conversation has moved on or I should have checked this draft]
A practical suggestion, which looks like a good start.
https://spdx.org/rdf/terms/

Its of course worth pointing out that the definitions are in RDF, thereby permitting a user/team to create their own definitions and linking.

Id posit that this is a useful thing in the domain of licensing and the fediverse, especially when bespoke expectations can be interrogated using things like Sparql.

From what I see SPDX usually is operating within a file (as opposed to a dedicated field in support of a document/content). As such there are subtleties regarding how to chain components (and the conclusion in terms of licensing) as well as explicit/implicit representations.

For instance, Ive been thinking about ‘injecting hashes’, whereby content is hashed excluding annotations or notation (if not breaking down the content into smaller chunks). If such a hash is identified elsewhere then (casually) such inferences can be added (with all the carnets of provinence and context).

1 Like
42

I like that idea @indieterminacy Pinging @TimBray on this one as author of the FEP.

43

@indieterminacy, Why do you propose reliance on SPDX rather than W3C ORDL? What about SPDX makes it superior to ODRL?

See:

44

Meh. The notion of using something that already exists is attractive, but the failure-to-success ratio of everything involving RDF is terrible.

ODRL doesn’t look terrible.

45

Yeah, and as externality railroading full-blown DRM into the Fediverse, establishing it as “commercial space” :scream:

(PS: To me that looks terrible. But maybe I’m seeing this wrong, or a subset of ODRL may avoid this)

When talking “Social Web” we’d until now like to expand that to “Open Social Web” and public data being open data. With “content licensing” that would boil down to “This is the open license I publish this under”.

It may be that ODRL is optimal for expressing “digital rights”, but that goes much further than “content licensing”. And in that light other suggestions, like SPDX or whatever, gain an advantage imho if they avoid the externality.

1 Like
46

Arnold wrote:

It may be that ODRL is optimal for expressing “digital rights”, but that goes much further than “content licensing”. And in that light other suggestions, like SPDX or whatever, gain an advantage imho if they avoid the externality.

I may be missing something subtle in the distinction you make between “digital rights” and “content licensing.” I don’t understand how the two are different. What am I missing? What externality is avoided by using SPDX rather than ODRL?

I can’t see how the use of SPDX prevents, or even discourages, the use of any license terms that might be expressed via ODRL. However, I believe that the use of ODRL is more likely to result in users’ intent being respected because ODRL provides a machine-readable expression language for individual granted rights, while SPDX usually just links to licenses that must be read and interpreted by humans. My sense is that if SPDX is used, many implementers would simply declare that it is unreasonable to expect them to read and translate into code the terms of dozens of license documents written in impenetrable legalese.

Another issue is that SPDX, since it typically just references existing non-machine-readable licenses, makes it hard to express exceptions. As we all know, one of the reasons motivating this discussion is the desire of some to prevent search engine indexing of their content. But, as far as I know, there aren’t any existing licenses that explicitly address search engine indexing as something distinct from other uses. Thus, we might find that an SPDX solution would lead to people choosing licenses that prohibit more than they really want to prohibit. (Note: ODRL has vocabulary for controlling indexing.) There are dozens of licenses in use today because there are a wide variety of needs. Instead of proliferating the number of licenses as new needs are discovered, why not support a level of expression granularity that affords users an ability to compose machine-readable grants that address their unique needs?

In any case, any use of ODRL should probably be defined via a profile document which could remove anything in the default ODRL that was considered inherently bad. That profile would also define SocialWeb vocabulary that isn’t already in the default ODRL Vocabulary. And, it should make it very clear that a SocialWeb Rights Expression Language should only be used to grant rights which are otherwise withheld or reserved by law. Use of the SocialWeb Rights Expression Language would only be supported when it makes data more “open” than it otherwise would be by default.

bob wyman

47

Thank you for this response, which offers good handholds. I am not for or against any particular format, just don’t want so see full-blown DRM and its horrors enter the Fediverse. A “content license” is a subset of things that constitute “digital rights”. DRM horror scenario’s involving digital rights might be instance admins receiving threatening emails from a lawyer firm with a list “illegally boosted copyrighted content” and demands to immediately unboost and provide stern warning to users, or else… (just saying, idk what copyright/patent trolls can dream up).

I agree the intent is important. Something that specifically doesn’t have scope into DRM realms, and only allows the culture of openness we love on the Fediverse, is also communicating intent. Even safeguarding it.

If such a profile could do the trick, then it may be okay. But I do feel that the barrier to DRM has been lowered. After all implementations will support ODRL. Now you only need to bring in a different Profile.

48

Attribution can simply be a reference to the original post — whatever helps the reader to link the content to its origin. On the web we call it a hyperlink. :wink:
Share Alike is more difficult, as it should convey the conditions, so the licensing terms should be passed on.

Having an SPDX reference seems to be shorter and more compact than a full ORDL policy. However, it should be interesting to describe each SPDX license in ORDL terms. This would provide a number of advantages:

  1. SPDX licenses would be machine-readable
  2. Licensing terms would become explicit (e.g., the difference between GPL-3.0-or-later and AGPL-1.3-or-later would be shown to cover distribution over the network, making the AGPL a very straightforward and simple license to understand)
  3. A license category of so-called permissive and restrictive licenses would become obvious and enable people to understand what is permitted and what is restricted, encouraging further reciprocal sharing and fading out extraction (e.g., DRM).

One thing we certainly want to avoid is to have a one-liner becoming burdened with licensing terms, and a grotesque inflation of bandwidth usage to satisfy lawyers and paranoid or repressive data regimes.

Indeed, under copyright law, if the license expires, then copyright is enforced (until the ever-growing limit of author death + n years – n = 75 at this point, but Disney might want to bribe some Congressmen into extending it again, although Mickey Mouse® might be superseded with iconoclast superheroes® who can joyfully save the world by destroying it.)

That said, I think a common charter is better than individual licenses, and so expressing conditions and policies consistently for what politics the Fediverse wants to achieve seems superior to me that any tinfoil hat legalese that may be conveyed by overly cautious corporate lawyers to protect the self-interest of their, hmm, assets. If fedizens want to enable federation while removing extractive powers of corporations or derivative use by AI, data extractivists, marketing ploys and abusive government agencies, then it’s important to be able to describe “licensing terms” in terms of machine-readable policies — but of course, no machine will respect that, since they’re operated by humans working for corporations. You know you’ve seen this before.

I would be curious about what Ted Nelson would do :slight_smile: And also how @cwebber’s goblins handle permissions, since Spritely includes object capabilities, and content licensing terms might be part of it.

Maybe what we need is a Commons Data Profile that removes all market incentives over the social data generated by the Fediverse.

49

ODRL looks pretty decent.

In the end such distinctions (such as from @TimBray regarding RDF being terrible) end up falling into differences of philosophy rather than technical or economic concerns.

As an analogy, the pervasive use of plastics is practical and allows people to produce, distribute and consume but is abhorrent to those who want to ‘do the right thing’ and dont mind doing things slower, at greater cost and with more convenience.

As a practical concern, trying to remember why I had originally wanted to suggest SPDX, it has capabilities for checksums and a reference for the checksum algorithm
(which a scan for ‘checksum’ and ‘hash’ in the ODRL documentation you provided didnt show up).

I believe that just as one has functional package management for domains such as building coding for toolkits, one should be doing this for content.

For example, Guix is excellent for reproducible research, with the inputs chained and verified not only with respect to inputs but the hashes of the coding and scripts.
We should be mindful about the need to have content assets as well as coding assets provided with such objective terms - it should not only be confined to the rigours of scientific enquiry but capable of modelling content or more practically for being mindful of edits, updates or blocking content from a hashing.

I guess this is not the most common type of concern but I consider hashes an important thing for a wide range of uses.

I could of course have overlooked ODRL’s approach for this, similarly there are other important facets concerning SPDX for or against.

I should feel that the complexity for addressing any potential added complexity for SPDX could be mitigated by hashing such impressions and then using it for an individual entity to whitelist/blacklist things according to economic and legal criteria.

I can expand further and can attempt to be clearer, just thought Id express this anyway.

50

I think time sensitive rights is an imporant area, though I wouldnt say that such things are ‘giving them up’, so long as they are within the purview of somebody rationally making choices and them being fulfilled.

When it comes to rights, Im mindful of conflicts.

I recall that Fred Astaire put in his will that he must not have a biopic about his life, which the bounty of his wealth was no doubt sufficient to make his estate oblige.

The problem here is that complying meant that his dance partner, Ginger Rogers in effect received a veto, as its impossible to tell her tale without Fred Astaire featuring.

When it comes to rights its often that peoples rights and community rights are taken away because of inequality within systems.

51

ODRL can be just as terse as SPDX if one uses the odrl:hasPolicy tag to point to an external file containing ODRL. For instance, all you need is:

“odrl:hasPolicy”: “http://example.com/policy.odrl”

To make things easy for people, what we could do is define a SocialWeb profile (like the Creative Commons ODRL Profile) that includes the definition of those policies most commonly expected to be used for SocialWeb content. These policies would differ from existing ones in that they would address SocialWeb specific concerns like search-engine-index rights, etc. The ODRL-encoded policy files would be hosted at some well-known location in much the same way that namespaces, etc. are commonly hosted. Ideally, most people would select from those consensus policies, but those who had unusual requirements would be free to define them either in their entirety or as exceptions (Constraints) amending the standard policies. Over time, if patterns or trends were found in the use of Constraints, then we could add new policies to the profile and to the shared repository.

Absolutely! Of course those who want anything other than minor departures from existing, pre-defined policies should be strongly encouraged to create them in ODRL files that are referenced using by using odrl:hasPolicy, rather than embedding them in each piece of content published. One might implement instance-specific rules that say things like: “Your post will be delayed or rejected if your policy statement is larger than your message content…”

I believe ODRL covers what you’re looking for. An ODRL Asset is any resource or a collection of resources that are the subject of a Rule. Assets can either be stand-alone, or “partOf” an AssetCollection. But, since Assets can be just about anything, ODRL doesn’t define any type-specific attributes for describing or naming Assets. So, if we wanted to use hashes to identify parts of an object as individual assets, or as partOf some AssetCollection, we could define those Asset attributes in a SocialWeb profile.

Such horror stories are more likely to occur if we remain stuck with today’s human readable and often incomprehensible licences. If we can move to a requirement that grants must be machine-readable, then it will be much harder to trap or trick people. The rule for admins should be: “Don’t do anything not clearly allowed under copyright law with any object that has policies or rules that you don’t understand.” Admins might even decide to handle content with opaque policies. So, if some lawyer links to a non-machine readable license, or uses a machine-readable policy that includes non-standard vocabulary, they should expect that their content simply won’t get distribution. We can use ODRL, as a machine-readable syntax, to force people to be explicit and open about the rights they are withholding.

Remember also that, in the absence of a contract between publisher and consumer, the use of any Rights Expression Language is inherently limited to granting rights which would otherwise be withheld. Thus, the Rights Expression Language can only be used to make content more open and more freely used. Without a contractual relationship, nothing anyone inserts in their content allows them to restrict rights that are not already reserved to them by law.

52

Thanks for articulating these reassurances.

I suppose given your emphasis on machine-readable as a criteria then there would be a benefit of crowd-sourcing opinions regarding how the addition or removal of conditions inside license components should impact criteria for being able to use (or not use) an asset.

I expect there is a natural cost of investigation and risk regarding using ambiguous licensing arrangements - which means that people gravitate towards the opinion of larger organisations/cooperatives .

For example, Ive seen discussions in the Guix-Devel mailinglist about being risk adverse about certain licenses being ambiguous, as well as potential incompatabilites wrt using multiple licenses together.

I recall something about OpenZFS once.

Here is an example about mixing licenses as a quick concern:
https://mail.gnu.org/archive/html/guix-devel/2016-08/msg00308.html

Is there a possibility that we could check in with specialist communities such as Guix with very specific questions to ensure that any adoption is in line with pro libresoft best practices and likely to encourage better reproducability and interoperability of content?

Any suggestions as to what this would look like?

53

Soliciting input and expertise from a broad range of sources is always a good idea!

There are sometimes issues with license compatibility. This is one of the very important reasons that it is necessary to provide mechanisms to allow exceptions to standard policies. As you pointed out, there is an issue when using OpenSSL in systems licensed under GPLv3. A similar issue arises when you try to combine code licensed under GPLv2 with GPLv3 code. (The GNU site states clearly: “there is no legal way to combine code under even GPLv2 with code under GPLv3 in a single program.”) So, in order to avoid such conflicts, exceptions are often used (e.g. “I invoke GPLv3 for this system, excluding the [x, y, …] components which are separately licensed”).

The conflict between OpenSSL and GLPv3 arises whenever OpenSSL is used as a component of a system licensed under GPLv3, or whenever OpenSSL is a component of a system that also uses some GPLv3 component(s). This is because GPLv3 is a “strong copyleft” license and applies to the entire software system, not just to one or more of its components. Without a stated exception, GPLv3 must apply to all of the components of a system, and thus must also apply to OpenSSL – but it can’t. So, those who use OpenSSL as a component, but would like to use GLPv3 licenses for their own work, will often invoke GPLv3 with an exception that specifically excludes coverage of the OpenSSL component. This need to do this is common enough that “GPL linking exception” has its own Wikipedia page.

Fortunately, the strong v. weak copyleft issues appear much most frequently in the context of building software from components (linking, compiling, etc.). The idea of “copyleft” does have parallels in the “content” or “data” world, but they are less common.

Yes. I’d like to see a SocialWeb ODRL profile that describes, in detail, the meaning of each machine-readable permission, constraint, obligation, etc. and that also includes a definition of the “non-standard” term. In general, those using non-standard terms should expect that systems that don’t have some out-of-band method for determining granted rights would refuse to process objects with non-standard terms.

54

The maintainers of a Calckey fork (Blajkey) are implementing AP extenders to accommodate personal content licensing and are soliciting feedback: Kaity A (@supakaity) | Blåhaj Zone

2 Likes