[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: licensing of XMPP specifications

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



> 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 Saint-Andre

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply to: