Licensing terms for data in the Atmosphere

Discussion
1

I’d like to raise a fun and interesting topic, and that’s intellectual property and content licensing.

The data that flies around the Atmosphere is all visible and public. We’re at a stage within the Atmosphere where services are beginning to grow, and we’re beginning to see lexicons and data that express creative works that extend in length beyond microblogging. I think that the Standard.site lexicons are a great example.

But these creations lead to further questions. Who has permission to republish data that’s posted to the Atmosphere? Should we be making licenses to publish data clearer?

Should lexicons like Standard.site include licensing fields? Should we be recommending particular licenses for publishing to open social ecosystems?

Additionally, who in the Free Culture ecosystem should we be tagging into this conversation? :smiley:

15 Likes
2

There was a proposal regarding user intent flags a la robots.txt that could feasibly be extended to more granular permission sets. I’m not entirely sure what the current status of this proposal is, though.

2 Likes
3

Would be nice to have this incorporated:

RSL enables multiple publishers or content owners to reference a shared set of licensing terms, such as open source or Creative Commons license frameworks, through the <standard> element. By pointing to a common license URL, websites can declare that their content is governed by the same standard agreement. When a client application (e.g., an AI company) accepts the terms of a standard license, it gains access to all content covered by RSL licenses that reference that shared URL through their <standard>element.

In addition to supporting established frameworks, the ability to easily define and implement shared licensing terms gives content owners the ability to unify their voices and negotiate collective licensing agreements with AI companies and other applications that require access to large collections of digital content, including websites, books, videos, and proprietary datasets.

They don’t make it very clear but there’s an option to express ‘AI (training) prohibited’ which is what I’d want for my content. Would’ve liked to have a slightly more nuanced prohibition that makes an exception for Digital Commons usage in research and academia though.

6 Likes
4

I can’t remember if I’ve put something out publicly, but I think media objects (blobs) in particular should usually have license and attribution metadata attached when designing lexicons.

Two metadata fields:

  • licenseUri: string, format=uri, optional. standard/normalized URL(or short URI) for common licenses, or can point to more bespoke license/policy page
  • attribution: string, optional: more free-form field for listing a name or source of the media. can also be a URI that links back to the original source

These fields would go alongside things like alt-text. If there are multiple pieces of media in a record, it should be possible to attach different metadata to each (same as with alt-text).

7 Likes
5

I wrote that proposal and still think it is the best way forward for public atproto records/repos in the general case. Media files (blobs) maybe need more granular metadata (see my sibling post in this discussion).

I registered a domain and created a demo for this system a while back: https://demo.user-intents.org/

I’d love to collaborate with folks on getting that project shipped and adoption in the ecosystem. There have been a bunch of AI and monetization debates which have made it hard to get a more generic system out; focusing on the non-AI parts might help move it forward.

8 Likes
6

I have a lot of thoughts and very little time right now. But some quick bullet points:

  • All of this is on uncertain legal ground right now, which makes it hard to give legal advice and harder still to give creative, optimistic legal advice.
  • I have talked to @bnewbold.net and his “less is more” instincts are fundamentally sound here. May make sense for those two simple fields to be a recommended baseline for new lexicons—it is imperfect but hard to go wrong at least starting with those two fields.
  • To the extent lexicon fields can be typed (I don’t know the answer to this?) It may be helpful to specify that the license field prefers the SPDX license names, since “it’s just a URL” often results in unparseable messes as people slap slightly mangled copies of licenses on their own web pages.
  • I suspect for some lexicons, it may be worth having specificity about which fields are actually being licensed, as you might want (eg) identity to be tightly held but content to be broadly licensed.
  • RSL is interesting, but it is early and you probably don’t want to lock in a particular standard this early in the game. Flip side, though, I bet they’d see outreach from this community as an interesting and welcome test case.

Hope these are some helpful notes. Will try to check back in again soon.

[For those of you who don’t know me, I’m a Licensing Guy - former Open Source Initiative board, counsel to Mozilla and WMF, currently Creative Commons board]

12 Likes
7

AI-pref is still in limbo/derailment state at IETF best i can tell, so i would recommend to wait to see where that data model lands and don’t make something out of alignment with it. and yeah at the lexicon level probably makes sense.

i have been ruminating on how an iscc field in a lexicon would work, for content whose author(s) want its authorship, licensing, and/or ai-prefs to be “findable” (vector/perc hashing) across edits and metadata stripping… seems to be the same metadata pattern, and there too metadata at the lexicon/MASL level makes the most sense imho

1 Like
The community.lexicon.preference.ai lexicon
8

Conversely: AI Prefs is in limbo, which gives us the opportunity to lead?

User intents (non-ideal name but sound idea IMHO) with some tweaks as mentioned by @lu.is and taking into account some RSL ideas (without the XML — we know that it won’t be deployed in a conformant way and this’ll be RSS all over again) could be Good Enough™ to ship something and drive adoption I’d think?

1 Like
9

This is good. I don’t know how this could/should work, but a mutual license, kind of like copyleft, for atproto/decentralized data could be very interesting.

“I’ll license mine if you license yours”

1 Like
10

Useful framing of what we’re grappling with:

Broadly speaking, two distinct visions are emerging for how societies might respond to this moment.

Abundance and redistribution

In this scenario— outlined in Open Future’s Beyond AI and Copyright white paper— societies accept that digital information is fundamentally abundant and stop trying to recreate scarcity where none naturally exists.
(…)
Openness remains the default. Public-domain works stay public. Access is managed for sustainability, not weaponized to extract rents. AI becomes a layer that expands access to knowledge while reinforcing—rather than hollowing out—the institutions that produce, curate, and contextualize it.

Scarcity as a market strategy

The second scenario also starts from the recognition that the traffic-based web economy is breaking down as search gives way to AI-mediated access. But it is being advanced primarily by a different set of actors—large infrastructure providers, content delivery networks, and publisher coalitions—whose response is to re-engineer scarcity at the point of access. This vision has been articulated most explicitly by Cloudflare CEO Matthew Prince in a Stratechery interview.

In this vision, the collapse of the old bargain is treated not as a reason to rethink how value is redistributed across the information ecosystem, but as an opportunity to turn information into a tradable input once again.

2 Likes
11

On the ATProto Touchers’ discord there was a conversation I started by asking about the legal issues of reusing another project’s lexicons. This is important because a lot of atproto projects share and reuse lexicons and this is a strength of the ecosystem (ex: standard.site). The consensus was that it will probably never matter because most projects are small and if someone does try to sue then there’s an argument for fair use. Note, fair use isn’t automatic, it has to be argued in court. Getting sued isn’t usually the immediate worry but potential legal harassment (ex: scary legal letter from lawyer).

Most importantly: people should license their lexicons in a way to promote this sharing/remixing. Otherwise it breaks the mental model and ethos of atproto and the Atmosphere.

5 Likes
12

From @ngerakines.me

Add community.lexicon.preference.ai lexicon by ngerakines · Pull Request #72 · lexicon-community/lexicon · GitHub

I’d like a way to say ‘can only be used in training for non-commercial purposes’. Maybe the above supports it, but that’s unclear to me.

What @blaine.bsky.social has proposed makes that affordance and many others explicit by way of a descriptive rather than prescriptive approach:

1 Like
13

Given that the new gallery embed type lexicon is being designed, could those metadata fields please be included in that?

1 Like
14

Discussion here too

15

Having a npm package.json license spec allows programatic license identification, and able to utilise the existing parses and standard around this:

One of the nice features in combined licenses. Naturally, it is isn’t a license enforcement, no way to censor nor monetise the relationship with the consumer re the license; if such did exist, we’d might be able to properly monetise indie open-source, with pay-per-install/dev/team/company/project/* terms.

Besides licenses, and as mentioned:

There is robots.txt, which Cloudflare has done a lot of work on regarding AI crawling:

And interestingly, work to enable Pay Per Crawl and Pay Per Use, etc etc

One of the issues I’ve been researching is strategies to avoid surveillance capitalism and data aggregation and its eventual soul harvesting. Intranet Atmosphere projects are vulnerable by one actor pilfering the data into aggregates.

Combating this could be copyfarleft licenses, that forbid or discourage such:

Future Outlook and Innovations

The evolution of ACSL 1.4 points toward exciting future trends in ethical software licensing:

Enhanced Blockchain Integration

  • Immutable Compensation Records: Future versions of ACSL 1.4 may fully integrate blockchain technology to automate revenue tracking and distribution, ensuring immutability and auditability.

  • Tokenized Revenue Sharing: Models similar to the Open Compensation Token License (OCTL) demonstrate that tokenization can further streamline developer compensation in open source projects.

Decentralized Governance and Community Empowerment

  • Community-Driven Updates: Decentralized platforms such as Arbitrum can foster new voting and governance models that allow developers to make iterative improvements to the license, ensuring fairness evolves with industry needs.

  • Layer 3 Solutions and Scalability: Innovations in open source scaling—exemplified by projects like Arbitrum and Layer 3 Solutions—could transform how revenue sharing and licensing compliance are managed.

Integration with Broader Ecosystems

  • Cross-Project Collaboration: By establishing a common framework for ethical licensing across platforms, ACSL 1.4 could become the benchmark for sustaining open source innovation. This vision is echoed by developers and industry experts featured on platforms like GitHub’s Licensing Landscape.

  • New Funding Models: As open source communities continue to explore sustainable funding best practices (see Funding for Open Source), ACSL 1.4 may pave the way for hybrid revenue models that combine grants, tokenized rewards, and fair code compensation.

Selected External Perspectives

Several insightful posts further enrich this discussion:

However, we’ve also seen the failure of licenses in the 21st century. Monetised youtube videos and presentations commonly use content with CC-NC licenses, violating the terms. The Western Empire and Venture Capital consistently violate copyright for their privileged takes on national interest and national security while punishing others - RIAA suing independent pirates, Spotify origins in piracy, Anthropic/OpenAI/etc origins and continued piracy, Aaron Swartz penalised for democratising public-domain access.

This license/trust vulnerability is actively exploited and perceived as a weakness by empire grifters. To some extent, it is. Combating this weakness at its heart focuses on edification and erudition in the civics and humanities - making it so people move completely from isolated wisdom to competitive wisdom to collaborative wisdom - so they can have technology that can be used as a weapon, and use it as medicine instead. It is humanists everywhere and the humanities in general marching in tandem to equitise this front. My work at Bevry is a few small steps in this march.

I’ve also been thinking about how technology itself can fight back against its over-dependence on faulty trust in that licenses, commons, fair use, and reciprocity will be respected, enforced, and reprimanded/restituted. That perhaps we can use technology to make pilfering of data increasingly impractical, hopefully enough to be impratical enough to no longer be viable.

Initially, I started with exploring the idea of handling requests for content with a firewall that erects a paywall if the request is from a for-profit and/or anti-democratic network/device/ontology. This is a good enough stop-gap, and is a good option for monetising content resources surrounding open-source projects, blogs, etc - but still has the pilfering option available.

To use technology to move pilfering towards impossibility, I’ve been thinking about leveraging secure enclaves, drm, and protected outputs, which seems tedious but somewhat viable:

1 Like