gemini://geminiprotocol.net/news/2023_10

At long last, I have put copies up at geminiprotocol.net of the two separate specification documents, one for the network transport protocol and one for the "gemtext" hypertext format, which were created in the two gitlab.com repositories setup as part of Sean Connor's efforts to finalise the specification in 2021. They have been translated more fully into gemtext (e.g. they're no longer hard-wrapped) but in terms of content they are unmodified except for prominent notices at the top that they are non-binding works in progress with links to the binding combined specification. My plan is to now start work on bringing these two new documents and the existing combined document into a state of consistency and eventually we'll end up with two separate, formal, binding specifications which are the ultimate authority on fine details and corner cases, plus a single combined and informal document which does not describe Gemini exhaustively and unambiguously but is a much more casual read than the other two while still conveying almost everything that matters. The separation and formalisation is, for me, more motivated by the norms of internet standardisation processes than a serious functional deficiency in the existing document.

I am still hopeful that small changes to the specification will happen by the end of this year, but I don't want to announce any changes which would require updates to client or server implementations until I have my own two implementation projects in a state where I can quickly and confidently make the required changes to lead by example. So I'm now going to start spending time on closing long standing issues and pull requests on AV-98 and Molly Brown and maybe doing some releases, to get to that point. This does not necessarily mean that nothing is going to happen to the specification documents for a while. For example the network protocol specification can be updated to clarify details around the intended usage of query components in request URLs or the usage of Gemini proxies without requiring anybody to update implementations. And the gemtext specification is actually not much more than an excerpt of the relevant parts of the existing document and needs formalisation. So I will start tackling these things in parallel with software work.

The home page of the official capsule now includes a notice at the bottom that, unless stated otherwise, everything in the capsule is published under the terms of a CC BY-NC-ND license. This is the first time there has been an explicit license on any of the project's documentation, which is well overdue. It's a relatively restrictive license as far as CC goes, which is a little at odds with my usual perspective on copyright issues, but we are talking about writing here, not software. I certainly welcome and encourage people doing things like mirroring the official capsule as it is published. I don't really want things like the FAQ or the specification documents (though more on that shortly) being modified by third parties, though, I think it is entirely reasonable for me to want maintain control over official project publications. I don't want to discrouage translations of the official project publications, which strictly speaking constitute derivative works, but then with the established workflow for people submitting translations to be included in the official capsule, the translation ends up actually being published by the original copyright holder so I don't the license is problematic here. I guess I ought to update the translation instructions to make it clear that by submitting a translation you transfer copyright to me and agree to it being published BY-NC-ND. So in the end all that is "forbidden" is people distributing translations without contributing them to geminiprotocol.net, and that doesn't feel unreasonable. At any rate, this is largely academic because if push comes to shove I am not going to spend time and energy and money taking anybody to court. I am mostly just making a formal and public proclamation of what I consider perfectly fair things for people in the community to do and what I really rather they wouldn't.

The reason for the "unless stated otherwise" is the licensing for the formal network protocol that I've just published. Sean Conner applied CC0 public domain notices the two gitlab.com repositories, after DJ Chase very correctly pointed out, as Sean was stepping down from leading the finalisation, that leaving the licensing situation ambiguous could cause problems for whatever finalisation efforts came next (at a time when it was far from clear what the future direction of the project would be). This is probably not the license I would personally have chosen for reasons outlined above, but a public domain dedication is irreversible, and I actually quite like the network protocol specification document. I appreciate that other people did the work to produce it in my absence and I really don't want to discard it and start from scratch over a licensing quibble. So we'll just roll with that one exception. You might notice that the same CC0 license file was added to both the separate gitlab.com repositories: my take on this is that Sean wrote the network protocol specification from scratch as a substantively new document, and therefore was well within his rights to assign it a license, so the CC0 "sticks" to that repo, but, as mentioned, the gemtext specification is actually just a verbatim excerpt from the existing informal specification, which was written by me and can't be licensed by anybody else, so that CC0 "doesn't stick" and I am free to CC BY-NC-ND it along with everything else. I want to be clear that I'm genuinely not upset about any decisions which were made during my absence (how could I reasonably be?), and I'm not pointing out who-wrote-what-when to point fingers or anything like that, I'm just trying to make it clear that I'm not trying to relicense things willy nilly without any concern for how copyright law actually works.

2023-10-03 - Separated specifications and copyright updates