A recap of OASIS position regarding WS-I material and their licensing

A recap of OASIS position regarding WS-I material and their licensing:

Licensing aspects, inheritance from WS-I

===========================================

WS-I materials: as assets they have two aspects:

-- As pieces of paper, OASIS owns them now. (As you said.)

-- As licenses, they are pre-existing rights that were granted in a body of

work before OASIS had anything to do with it. OASIS also is the new custodian

of most aspects of that old body of work, but did not acquire any new power to

bind those old members.

As a result:

1. OASIS took the work subject to the existing licenses. So whatever

rights an Adopter Agreement holder has before the transition, they still have.

2. WS-I.org gathered up and conveyed those license rights using rules and

membership arrangements (with its contributing members) that no longer exist.

3. So no-one has inherited the power to retroactively bind the

as-of-2009 WS-I.org members to a new license instrument in 2012.

That's an obstacle, if new users want new Adopter Agreements.

As we said in the transition meetings, we were happy to take on the material

as custodian, but a completed TC is a completed TC, wherever it is. The IPR

obligations of its members cannot be expanded after it's closed. So any new

licensing and any new work would have to come from a new OASIS TC.

That does give us some practical options for facilitating new implementers,

though.

a. A new OASIS TC, including WS-I Maintenance, could take in old WS-I

material as contributions from appropriate members, rev it (or just reapprove

it as is), and thereby make it an OASIS committee specification, which then is

available under OASIS open licenses.

b. The Adopter Agreements were sort of an unusual licensing method. If

users already have effective rights, either under the WS-I license terms or

those of the JTC1 mirror standards, to implement those specifications

*without* an Adopter Agreement, then perhaps there's not really a problem

here.

=====================================

At first glance:

-- On which license for test tools: it has to be something that majorities of the

community and our Board all will tolerate. BSD wouldn't bother me a bit, but

it's the community who has to decide this.

-- On "outsourcing" the code hosting. Certainly can be done. It's not like

we need to install house servers to do this. But every platform comes with

its own license issues (e.g., "if you post this thing to Sourceforge you are

hereby promising ..."), so it's not something we can do heedlessly.

-- On "recognizing/endorsing" some external OSS tool for use:

raises the same IPR / playing favorites issues.

Note, our TCs have plenty of GitHub nodes, Sourceforge projects and (I

hear) even Reddit forks. But they're all unofficial activity, generated by

members on their own, thus not triggering any "official recognition" issues.

ws-brsp message