Specify license for documentation

[eloquence]

There is currently no LICENSE file in this repository. Is the intention for the docs to be MIT-licensed or under a similarly open license? If so, it would be good to state that clearly.

[aschrijver]

Yes, it is very weird that this license is missing. Given the professional approach to AT proto development this seems deliberate. It may be that Bluesky wants to keep tight control over the ecosystem until specs have significantly matured, and I read somewhere in Docs that the intention is to eventually go open standard at W3C or IETF.

Without license to the specs / this repo, FOSS development for AT protocol is in limbo land I think. It woulld hold me back from any experimentation. Please provide clarity on your intentions and strategy in this regard.

Note too that there exists a general distrust about the intentions of Bluesky wrt their positioning within the ecosystem, and being a Social Benefit Organization alone isn't enough to get rid of the impression of facing a Silicon Valley growth-hacking club with Big Tech aspirations. Any additional openness to the ecosystem might help mitigate that impression.

[bnewbold]

Thanks for pointing this out! This has simply been overlooked until now, not an intentional decision that I know of.

Will need to consult with the team, which will take time, but something like a CC license or GFDL would probably work. We do want folks to be able to reproduce (verbatim) and implement the specifications without restrictions. Translations should also be fine.

Standards and specifications often end up with restrictions around derivative works and branding. It would be good to avoid a situation where there is a standards-body-governed version of "AT Protocol", and then a random party promotes "AT Protocol Next Gen" or "The Real Official AT Protocol", which is an incompatible fork. For example, I believe the GPL license has restrictions on reuse of the license text itself.

This repository contains blog posts, other documents, and images/logos/marks which may end up with different licenses.

For reference, some IETF docs on licensing of specification text:

• RFC-5378: Rights Contributors Provide to the IETF Trust
• RFC-5377: Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents

And the W3C:

• W3C Document License (2023 version)

[eloquence]

Thanks @bnewbold! I understand this may take some time to resolve, but your commitment to doing so is much appreciated.

Standards and specifications often end up with restrictions around derivative works and branding.

For sure. I completely understand the concern about any derivatives of the protocol using the term "ATProto". I do think it would be in the spirit of open source to permit derivatives/forks, so long as they are not confusingly labeled. A permissive license also protects the people working on ATProto today -- e.g., it makes it easier for you to continue ATProto's evolution through a fork, should the PBLLC go defunct in future and the IP situation be ambiguous.

FWIW, from what I can tell, ActivityPub uses an older W3C license which explicitly permits derivative works (https://www.w3.org/TR/activitypub/ references https://www.w3.org/copyright/software-license-2015/).

[bnewbold]

We added a CC-BY license for the specs, with an explicit CC-0 carve-out for code snippets and things like test data/fixtures in the specs.

PR: https://github.com/bluesky-social/atproto-website/pull/243

Going to close this issue, feel free to re-open or start a new one if there is more to discuss.

Thanks again for noting this!

[bnewbold]

Oh, also to note: an un-mentioned thing here is software patents, which I think are actually often more of a concern for protocols than copyright on the specification (somebody could just re-write the specs pretty easily).

We don't try to resolve patents on the specs directly. Going through a formal SDO (standards dev org, like IETF or W3C) will be the best guarantee that the protocol is not patent-encumbered and can't be infringed on by any party. In the meanwhile, we updated the license on our reference implementation of the protocol (atproto for typescript, indigo for golang) to be dual-licensed MIT/Apache2 ("MIT or Apache 2.0"), with the Apache license providing a patent grant. "I'm not a lawyer" but hope that this gives the ecosystem and third parties more confidence until an SDO process happens (which can/will be a long process).

[aschrijver]

Thanks much for this information and effort!