Hi, Simon,
If the trust uses a software license for code that doesn't meet the
requirements in, say, the DFSG, would you consider that a failure? If
that happens, Debian cannot include such code.
Using the NPOSL3.0 as the software license, which I read Ray's message
to imply was being considered, would be one way to prevent Debian from
using the code.
OK so far...
I would agree that the references should be for a specific version of
the documents, if that is your point.
OK, I unsubscribed to IPR two or three years ago (or maybe it was two or
three PR-actions ago, I can't remember which), so maybe I'm really confused,
but
- I would disagree with referring to a specific version of these documents,
because tellng the trust "it has to be X-1.0-compatible" will just frustrate
all of us when there's an X-1.1 version, so then we get to have this
conversation all over again - or else, we just trust the trust to do the
right thing (which is what we're discussing now) - or am I misunderstanding?
- please, please, please do not try to craft precise guidance on
ietf(_at_)ietf(_dot_)org(_dot_) We can't even get our own process BCPs right.
If there is a
new uber-software license developed thirty minutes after this draft is
published as an RFC, I bet we would want the trust to look seriously at it,
and maybe even do the right thing ("and please ignore our guidance if that
helps you do the right thing").
I don't understand how we can have a trust that we can't trust to do the
right thing at some level. The draft is pretty clear about our intentions.
Simon has said "there are land mines all over the place". I don't disagree.
If it helps to add text that says "it's easy to make mistakes; if you make
mistakes, please fix them as we find them", fine, but if we have to tell the
trust that, we probably need a smarter trust more than we need specific
guidance.
IMO.
Spencer
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf