Ben Finney wrote: > Peter Saint-Andre <stpeter@stpeter.im> writes: > >> As Executive Director of the XSF, I am willing to push for a change >> to the licensing so that the XEP licensing is consistent with the >> DFSG. > > Thank you for actively pursuing this worthwhile change. > >> Although we need to complete some due diligence and come to >> consensus in our community before settling on a license, it appears >> to me that the MIT license would be appropriate. > > Yes, I'd agree with that. > >> (If it were up to me I would place the documents in the public >> domain, but that may not be consistent with the consensus of our >> community or the XSF's intended role as a neutral third party and >> intellectual property conservancy for Jabber/XMPP protocols.) > > It's a great shame that the debate is distorted by the term > "intellectual property", which is both nebulous in its application and > begs the question of how to treat ideas at all. I agree, but it's the framework within which I need to work regarding the XMPP Standards Foundation. I put all my personal creations into the public domain, but I don't have that leeway at the XSF. >> However, the MIT license talks about software, not documentation or, >> more precisely in our case, protocol specifications. > > Yes. Only under an unnecessarily narrow definition of "software" does > it equate to "programs"; and even then, it's notoriously difficult to > define when a collection of bits is a "program" but is not a "text > document". > > On the contrary, "software" is more sensibly contrasted with > "hardware", and covers any information in digital form — whether that > information happens to be interpreted as a program, an audio stream, a > text document, some other kind of digital data, or several kinds at > once. Within the context of our developer community, it is pretty clear what is a specification and what is software. Indeed, a XEP defines a wire protocol, which can be implemented in software, hardware, or a network-aware service. So as far as I can see, it is even more important for the XSF to clearly specify that the protocols it produces can be instantiated in software, hardware, or services. But the XSF itself does not produce software. >> Is it considered acceptable (for the purpose of DFSG compliance) to >> formulate a legal notice that is nearly identical to the MIT license >> but that talks about specifications instead of software? > > It should be even simpler to accept the fact that, as digitally > encoded information, a specification document *is* software and thus > can be covered by the MIT license terms with no modification. I am not convinced of that. Yet. Peter -- Peter Saint-Andre https://stpeter.im/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature