Francesco Poli wrote: > On Sat, 20 Oct 2007 23:33:14 +1000 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. > > I would also like to thank Peter for that. > >>> 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. > > So would I. > > [...] >>> 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. > > 100 % agreement here, I even wrote an essay on this subject. > http://frx.netsons.org/essays/softfrdm/whatissoftware.html Does a wire protocol count as "software"? How about documentation of such a wire protocol? I'm not convinced yet, but I'll think about it. >>> 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. > > That would be the simplest and best solution. > Especially if we take into account that license proliferation is bad and > should be avoided whenever possible (hint: it is almost always > possible!). I agree, which is why I initiated deprecation of the Jabber Open Source License: http://www.opensource.org/licenses/jabberpl.php http://mailman.jabber.org/pipermail/members/2005-August/003322.html > Moreover, it should be considered that a license that talks about a > "specification" becomes pretty confusing and problematic, as soon as the > work it applies to is modified into something that is no longer a > "specification" (e.g.: a manual, a poem, ...). No different from what happens when I put software onto a T-shirt. > I would encourage the adoption of the unmodified Expat/MIT license: > http://www.jclark.com/xml/copying.txt License proliferation! How is that different from the MIT license? Peter -- Peter Saint-Andre https://stpeter.im/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature