[Members] XEP-0001: Remove impossible guarantee from XSF Objectives
jonas at wielicki.name
Thu Jan 16 15:27:21 UTC 2020
On Mittwoch, 15. Januar 2020 23:30:03 CET Marvin W wrote:
> 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).
I understand your argument now and it does make sense to me. However, I’d like
to second what Dave said in reply to your mail w.r.t. "If a XEP looks too bad,
we should reject early."
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Members