[Members] XEP-0001: Remove impossible guarantee from XSF Objectives
xmpp at larma.de
Wed Jan 15 22:30:03 UTC 2020
I'd like to explain why my understanding of this does make more sense to
me than yours.
First XEP-0001 defines 5 parts of the standardization process:
Submission, Publication, Discussion, Proposal and Approval
The IPR policy has exactly two sections of relevance (all the others are
terminology and other bla):
- § 3.1 deals explicitly with the submission process, mainly that the
author of the Extension shall assign any ownership rights or other
Claims asserted over the Extension to the XSF. It explicitly only deals
with IPR of the XEP or specification (the text) and excludes any
- § 3.2 says that extensions cannot be approved by the XSF if there are
any Claims that would prevent perpetual, unrestricted, royalty-free use
of the Extension. If XSF discovers such claims it shall immediately seek
to *replace* (not reject without replacement) it.
In XEP-0001 it is written twice (in § 5 and § 8.1) that acceptance as
experimental XEP does not imply any level of approval.
I also think that the bare nature of the Experimental status conflicts
with your understanding of IPR policy. If an Experimental XEP is
underspecified (which happens a lot) the underspecified part can contain
references to protocols with IP Claims, but it is impossible to verify
this, because of underspecification. Due to its nature of rapid
updating, it may also easily happen that an intermediary state of an
Experimental XEP has IP Claims on it and as long as this is not intended
I wouldn't see a problem with that, as production systems are not
supposed to be created from Experimental XEPs (and if you only implement
something for testing, you usually don't have issues with IP anyway).
As the PR #878 suggests, replacing "Signal" with "TODO" in XEP-0384 may
make it less useful for anything but experimental implementations, but
obviously also means that noone can argue there are any Claims that
would prevent its implementation.
The IPR policy does apply for Experimental XEP because the *text* of the
XEP is assigned to the XSF and the author must guarantee that they have
the right to do so (under § 3.1). This is required so that others can
work on this XEP (i.e. suggest changes, create derivatives etc.) This
however does not extend to any IP Claims on actual implementations
derived from an Experimental XEP. Of course XEPs should only be
submitted if the plan is to get them approved at some point, but if
preparing the XEP for proposing it to approval takes longer than
expected, I wouldn't see a general issue with that. (And yes, this is
something that was and is happening with XEP-0384).
As a more general remark: I think us putting efforts into having high
quality Experimental XEPs is just another sign of failure for getting
our standardization process right. If it was generally accepted that
Experimental XEPs are not intended for production use (as this is
written in ever Experimental XEP), we probably wouldn't have this
discussion. By not advancing XEPs in the standardization process, all
the rules that made sense once do not work that well anymore. If
companies request they get Experimental XEPs implemented for a
production system, we should consider this a problem of our process,
because apparently it means nothing anymore if a XEP is Experimental,
Deferred, Draft, Final or even Deprecated (I am looking at you XEP-0071).
On 1/15/20 9:49 PM, Jonas Schäfer wrote:
> I think this is wrong. The IPR policy is in effect starting from the very
> moment the XEP is under Experimental and must be accepted by anyone submitting
> a ProtoXEP. That is, from my understanding, one of the reasons we have the
> Experimental phase: To ensure that the IP questions on the Extension itself
> are cleared up from the point where the Community starts to work on it.
> Everyone contributing to a published (Experimental onwards) XEP is aware of
> the IPR policy and agrees that their contributions are under those terms.
More information about the Members