Shouldn’t the semantics be:
What I am saying is that any Object type can have a license. This covers the case of attachments implicitly, as attachments have the Object type.
So the only thing necessary to do would be to specify the vocabulary to talk about a license. One should probably add a date to what I’ve suggested, and make a possibility to attach a list of licenses.
Yes, in schema.org the concept CreativeWork has a license property for that (as well as other copyright-related properties, and contributor property), and has a whole bunch of sub-types where it applies (like Article). I use this on fedi.foundation so guest authors can choose a different open license than the default one. But Object is a very generic type to have a license for.
First, I think it’s a good idea to reuse something that is already there.
My understanding of this is that you propose, we use a pattern such as shown in the following json-ld snippet.
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{"schema": "https://schema.org#"},
],
"type": "Image",
"name": "Cat Jumping on Wagon",
"url": [
{ "type": "Link", "href": "http://example.org/image.jpeg", "mediaType": "image/jpeg" }
],
"schema:license": "https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document",
"schema:creator": "James M Snell, IBM; Evan Prodromou, Fuzzy.ai",
"schema:isBasedOnUrl": "https://www.w3.org/TR/activitystreams-vocabulary/#dfn-image",
}
I’m not completely sure if “isBasedOnUrl” is the best choice for the original url, where an image, I post, can be found. As most ActivityPub implementations do a bunch of conversions of images, it’s probably accurate.
This type of additional information attached to objects would solve the point “1. Encouraging good behavior”, I made in an earlier comment.
Remaining question
Before one can implement this to add a license to every ActivityPub object, one needs to decide what a good license would be. I guess something like CC BY-NC 4.0 Attribution-NonCommercial 4.0 International as mentioned before might be appropriate.
SA option would cause too many problems with how ActivityPub consumers, e.g. Mastodon, are implemented. They would ignore the license, and thus potentially violate it.BY is satisfied due to web frontends usually displaying the username.NC just seems safe to be what most people intend to doI’m no expert so my interpretation might be off.
Thank you. I was not really proposing, just following up with one way it is done in web pages, and I used to make license explicit.
So, I’ve thought about this some more and realized that Creative Commons is a bad choice for license for me.
The problem is as follows:
So what I would expect of a FediVerse license is to have this ephemeral aspect to it. Does something like this exist? DuckDuckGoing “ephemeral content license” and similar terms yielded nothing useful.
Note: I’m not sure of the exact conditions, I would want in this license. I’m also not sure how something like this would
Similar to mentioned previously, I think none of the existing licenses are ideal for fediverse posts, and something like a fediverse license needs to be created. Anyone who knows the legal ins and outs of copyright could start working on this.
There seems to be a lot of confusing discussion here. If an instance wants to discourage scraping and index-building, then they probably should NOT put a NC-ND CC license on content. That only prevents commercial activity, and search can be done for reasons other than commercial. Note that socialhub.activitypub.rocks has search, but isn’t commercial. archive.org has search on billions of pages, but it isn’t commercial.
Let’s not confuse people who have different intents. I can think of several reasons why people don’t want content indexed.
I can also think of reasons why people DO want their content indexed.
These are all social constructions, and in my opinion it’s not the job of a standard to say which is “correct”. It’s only useful to describe a mechanism for people to express their intents, and we should guard against limited imagination when it comes to recognizing the intents of others.
There are a variety of problems which any prospective license should address:
I have a meta-comment. This discourse is about “FEP-c118: Content licensing support”. In my opinion concrete licenses are or should be off topic.
I am currently only interested in technical “support” for licenses by standards (#activitypub) and do not have bandwidth/cycles for licenses. Maybe concrete licenses can be discussed separately?
Something I’m not seeing discussed, and would like to raise is the idea that certain forums may not be the right place for users to post certain types of content.
(I appreciate that this is slightly orthogonal to the question of “Once the user has chosen a license, how is that license metadata attached to their content?”, but I also feel like the FEP is discussing Fediverse content licensing but is really focused on Matsodon (and similar) content licensing)
For example:
In those cases, perhaps a Mastodon (or similar) instance is just not somewhere the user should be posting content that has those requirements, and the user should instead use a platform (which can still be part of the Fediverse, e.g., write.as) to host the content.
Then they can post a link to the content from their instance.
So instead of trying to craft or choose a license that is usable by everything that participates in the Fediverse, users would be better served by clearly directing them to specific Fediverse platforms that can provide the controls they want around their content.
I agree, but there are some early users of the fediverse who were used to living in obscurity. The current trend seems to be for servers to be defederated when they feel that this expectation is being violated. Maybe it’s ok that we end up with two or three distinct fediverses based on their shared values - sort of like Fox News and NPR in the USA. That kind of defeats the purpose of federation. Personally I think it would be better for users on search-enabled platforms to read content from search-blocked platforms and vice versa. That interoperability probably requires servers to express the intent of their users.
I think the proposal for users to express their desires on their content makes a lot of sense, though I also fear it could quickly escalate to look like the privacy settings on Facebook, which few people understand or look at.
Would like to add crosses instance toots licencing, this is opaque at mo.
Although I am no ODRL expert, it seems to me that ODRL could easily handle the various constraints listed in your comment. I’ve tried below to create a rule set that includes some of the things you gave as examples. (Note: There are probably errors here.)
I think the rule set below says that @username@example.com prohibits non-commercial use or indexing of the target post, “132342342342,” but otherwise allows users to ShareAlike, distribute, or Extract that post no later than 10 October, 2023. Additionally, those who use the granted permission must attribute @username@example.com.
{
"@context": "https://www.w3.org/ns/odrl.jsonld",
"@type": "Set",
"conflict": "prohibit",
"permission": [
{
"target": "https://example.com/132342342342",
"assigner": "https://example.com/@username",
"action": ["ShareAlike", "distribute", "Extract"],
"constraint": [
{
"leftOperand": "dateTime",
"operator": "lt",
"rightOperand": { "@value": "2023-10-10", "@type": "xsd:date" }
}
],
"duty": [
{
"action": "attribute",
"attributedParty": "https://example.com/@username"
}
]
}
],
"prohibition": [
{
"target": "https://example.com/132342342342",
"assigner": "https://example.com/@username",
"action": ["CommercialUse", "index"]
}
]
}
While some might argue that a simpler “language” for specifying rights might be more appropriate, I think it is best to adopt (not invent) a language like ODRL that is highly expressive and has had the benefit of review by legal professionals. Given that it comes from the W3C, one can hope that library support will be provided for ORDL. In any case, it is unlikely that once people are able to express rights in this fashion that they will be happy with an overly constrained syntax.
Content creators should be free to be as complex or detailed as they wish in providing grants to use rights provided by law to those creators. Those who aren’t able to, or won’t bother to, parse a detailed and complex statement should simply assume the default situation which is “All Rights Reserved.”
bob wyman
I agree that the ODRL spec looks pretty close to what is required. I’m just a little skeptical about the legal side, since when I looked over it I saw lots of ambiguities. In your example
I haven’t looked at the digital signatures on activities, but presumably the signature should also cover the rights.
I think ODRL is by far the closest thing I have seen to what fits ActivityPub, but even with its verbosity there are potential problems. In the grand scheme of things it’s better to move on with something imperfect than to have nothing at all (which is the current state).
Kevin,
Thanks for your comments. And, thanks for pointing out the inevitable mistakes I made in writing my first chunk of ODRL!
Yes. It will be important to consult with actual lawyers to clarify a great many issues – and there are many. I learned this the hard way back in the 1980’s when I was designing, and patenting, one of the first “Rights Expression Languages,” for use on DEC’s VMS, ULTRIX, and other operating systems: The “Digital Distributed Software Licensing Architecture.” (Note: Those patents are long expired.)
While users should be free to concoct their own licenses, I think it would be best to develop a set of standard licensing policies, vetted by legal experts, that cover the most common cases. ODRL supports references to such boilerplate, standard policies.
Current law vests all rights with the content creator. While there are all sorts of fascinating arguments about which implicit rights grants may be assumed when a digital object makes no formal attempt to control rights, I think it is reasonable to assume that, at least in the case of an object which carries license terms, that we should assume that all rights not explicitly granted are withheld.
As I suggest above, once a grant expires, we should return to the assumption that no grant exists. Creative Commons is wise to clarify that a right, once granted, can’t be revoked. If this wasn’t the case, we’d have all kinds of confusion when different copies of the same object were found to have different licenses. But, the expiration of a grant is very different from a revocation since the expiration is part of the initial grant while a revocation is a modification to some earlier grant.
I suggest that an author who needs to modify licenses should be required to republish a new version of the underlying object. (For instance, in Mastodon, different edits of a toot might carry different licenses…)
ODRL provides an ability to establish “Duties” or “Obligations” which are requirements imposed in exchange for using permissions. One could craft a policy that requires deletion upon expiration, or within some time after expiration.
The ODRL Vocabulary defines “index” as:
“Definition: To record the Asset in an index. …
Note: For example, to include a link to the Asset in a search engine database.”
If this definition is ambiguous, there exists a process by which new actions can be defined. We should engage with the ODRL community to ensure that rights needed by the SocialWeb users are clearly expressed in the ODRL Vocabulary.
We should do a detailed analysis of common SocialWeb actions and define standard terms that describe them.
It makes a great deal of sense to include the license within the scope of an object’s signature. Doing so ensures that the signature can’t be verified in the absence of the license.
bob wyman
I mentioned my concerns above. And I want to restate my worries now. Though it makes sense to consider full-blown standards, it will also mean that full-blown Digital Rights Management is introduced to the Fediverse. And I am firmly opposed to seeing this flawed mechanism become part of our daily reality. As corporate entries become more commonplace, the DRM will only serve commercial interests that erode the openness of the current environment. Before we know it DCMA Takedown requests will be flying all over the place. It will erode the Commons and that what the Fediverse stands for: Freedom of information exchange and global public access.
Hence a much more limited model that only allows to specify degrees of further openness, rather than a whole range of degrees leading to further restriction has my preference. A simple mechanism maybe, that only allows choosing from a set of open licenses.
Yes, been fallowing this thread, it has a lot of #geekproblem pushing, only a few #openweb voices.
As @aschrijver says the #Fediverse is #4opens out of the box, this is why is works, and why we are here and not a more #closedweb project. Rights language - the desire to control - is not native to this space. And yes, you would be right to point at the white lie mastodon sold on this subject, but maybe we can forgive them this as it was needed to sprout the seed.
For background to understand this http://hamishcampbell.com/2023/02/18/they-knew-that-their-work-was-just-the-start-they-were-determined-to-keep-pushing-forward-to-keep-building-a-better-world-one-link-one-line-of-code-at-a-time/ you need to click through the SSL error.
Let’s think #KISS and #openweb native, please:
My thought an instance wide drop down for a default licence, can start this list with basic CC licences and have it config file updatable. Then the individual users on the instance can change this default for their account if they want to. This licence is then added to the toot in short form, to make cross instance licencing issues workable.
Humm Wikipedia links are getting worse so What is Keep It Simple, Stupid (KISS)? | IxDF
I consider myself a supporter of the #openweb and I believe that a Rights Expression Language could afford us a more open SocialWeb that what we have now. Today, within realm of Mastodon and some other ActivityPub systems, we’ve seen a significant retreat from the idea of “open data” in order to respect the insistence by many users that their posts must not be made available via search engines – whether or not those search engines are commercial. The result is that data that flows through the SocialWeb is less open than similar data found elsewhere on the Web. This lack of openness serves some people’s legitimate purposes and needs, but not the legitimate needs of others.
Almost every attempt to build a Mastodon/ActivityPub search engine has been strongly attacked. As a result, several developers have publicly withdrawn proposals to build systems and some have even withdrawn operational systems from service – in order to avoid debilitating criticism. One exception is the TootFinder service that relies on explicit permissions being granted to TootFinder by Mastodon users who wish their content made available by the system. However, it is quite likely that those who wish TootFinder to index their data would be quite happy if at least some others were to do so. These “search-friendly” users will be unnecessarily inconvenienced if they are required to explicitly authorize each and every individual search engine and if they need to use a different mechanism for each authorization. It would make a great deal more sense to provide a general mechanism which allows content producers to authorize search engines, with some set of appropriate constraints (i.e. commercial/non-commercial use, length of content retention, search-engine or not, etc.) If we can provide a general means for those who wish their content to be indexed, the result will be a more #openweb than what exists today – while preserving the rights of those who, for whatever reason, wish that their data should not be indexed.
The “control” that is provided by a Rights Expression Language (REL) is control over granting rights, not removing them. Today, the law reserves all rights to the content creator. What a REL does is allow the creator to efficiently and effectively grant rights otherwise reserved. A REL can’t restrict rights that are already held by a reader (i.e. It can’t stop you from reading some data you’ve found on the web) and it can’t impose an ex post facto obligation. (i.e. I can’t say that “If you’ve read this, you owe me money.”) The primary thing a REL does is grant to others rights that they otherwise do not already enjoy. The REL would be a tool for giving up control, not for increasing it.*
(Note: I recognize that ODRL can be used to make “offers” of data access/use rights, in exchange for compensation or some other obligation. But, discussion of that use case isn’t the subject of this note.)
While Creative Commons (CC) licenses are probably adequate for most needs, they don’t currently offer enough granularity to say “Do what you want – except, do not provide this content via a search engine.” Thus, while it would make sense to ensure that the simplest and most common use for a REL would be to refer to one of the existing CC Licenses, we need to be able to do a more. For instance, bashrc suggests “time limited posts,” and an ability to grant rights for “academic use for research.” But, CC licenses can’t express either of these ideas. Both seem to me to be reasonable requirements. Why shouldn’t we allow content owners to grant (give up) their rights in these ways?
I agree with your suggestion that default licenses should probably be CC licenses and also that we should allow users to override the defaults to be either more open, or more restrictive, than the default licenses. Of course, we have little choice but to “trust” coders/people to respect these licenses. A REL only allows one to express grants of rights. It doesn’t provide a means to enforce them.
My fear is that if we don’t provide a robust Rights Expression Language, we’re going to end up with people doing what lanodan suggests: “Make your software require authentication to view posts.” If the base systems don’t provide enough expressiveness, then people are going to feel compelled to pull data behind walls and implement their own means for rights-expression and enforcement. That would hurt, not help, the #openweb
Yes, this path is simply not #openweb native, and we should talk to people about this unthinking #geekproblem pushing, it is damage. “Trust” is built from open, this is always flow/ conversation and bridge building.
http://hamishcampbell.com/2023/02/18/composting-the-last-40-years-of-social-sht-understanding-political-motivations-and-embracing-openness-and-trust/ (need to click past SSL error)
The is nothing wrong with REL, but there are problems with the motivation and social understanding behind the technology, in that it is feeding the need/desire for CONTROL more than it is feeding our social “trust”, on balance we need MUCH more of the second and MUCH less of the first.
Yes, we can play semantic games and pretend that we need more control before we can trust - but this is obviously not true if you think… Our tech/society is broken because we don’t trust each other, building more control is not fixing this problem, so on balance this is obviously the path of the (geek) problem not the solution.
Messy is good, basic CC licences keep the mess in place, they keep our need for CONTROL in check, #KISS empowers us to pick up simple shovels and compost #techshit for growing humane social outcomes. Let’s plant seeds of hope, you are holding the watering can 
On this subject So about permissions, huh? - #3 by silverpill "you can’t infer “interact” permissions at all. anyone who has the id of an object can refer to it.
more generally, activitypub doesn’t even have a concept of “permissions” at al"
While Tim Bray’s proposal is narrowly focused on providing “a legal framework to express the desires of users as to how their content may be re-used”, I think we should recognize that that problem is a subset of a larger set of problems involving the expression and delegation of users’ rights. Just as it is useful to describe how content may be used or re-used, it would also be useful to allow users to grant or delegate the capability to do various things that the user would otherwise be exclusively authorized to do – including the creation of content on behalf of the user.
Example: If others rely on using ActivityPub to engage with me concerning some project that I’m working on, I will be faced with a problem if I decide to go on a two-week long “screen-free” vacation. Ideally, while soaking up the sun on one of New York City’s many resplendent beaches, I would be confident that someone I trust is monitoring my Inbox and responding on my behalf, when appropriate, to others’ questions, needs, etc.
Using today’s “technology,” the general solution to this problem of capability delegation is for me to reveal my passwords to someone I trust and then change my password when I return from vacation. (I think I shouldn’t need to detail all the problems with that solution…) However, a much more satisfactory solution would allow me to generate a chunk of signed JSON-LD that describes a time-limited delegation of one or more of my rights. I might, for instance, delegate the capability to Post and Reply, but not to “Like” others’ posts or to Delete any of my previous posts. Ideally, the holder of that delegation could then present it to my ActivityPub service and exercise the rights and capabilities delegated to them. Also, it would be ideal if anything published “on my behalf,” using a delegation, were tagged as such in order to distinguish between my own actions and those performed on my behalf.
Any geeks reading this will recognize that what I’m describing could be considered an instance of a simple object-capability model or OCAP system. (See this GitHub project for a list of some existing capability-based systems) While formal OCAP systems can be very complex, much of their basic function can be achieved by using the same Rights Expression Language for both granting content-usage rights and rights to “do” things (i.e. capabilities). My guess is that a properly extended W3C ODRL Vocabulary would be sufficient to address both use cases.