The specification committee should be where an alternative patent license type is proposed

[starksm64]

Red Hat does not believe that specification projects, who are mostly composed of technical contributors, should have a simple bar for proposing a patent license type that differs from the working group default. We would suggest that such a decision require a super-majority vote of the committers to adopt an exception to the working group default patent license type.

[waynebeaton]

It seems to me that we already have a pretty high bar and I'd be hard-pressed to describe it as "simple".

1. Committers vote with their feet. The proposer of the project stipulates which license they want, and the committers and interested parties can decide to join in on that basis. It is up to whomever is proposing the project to decide on the patent option and build the necessary consensus to get enough committers and interested parties to join in.
2. In an exceptional state, approval from the steering committee is required.
3. In any case, a super-majority ballot of the specification committee is required as a final gate.

Note that the steering committee can decide for themselves what is required for approval. Simple majority is the default.

[starksm64]

This simply is not true. Committers care about the technical aspects of a specification. They are joining to influence the spec, API and TCK. The patent license is only a concern of vendors with a patent portfolio. The more I think about it, the more I believe that the patent choice, if anything other than the default needs to be brought up in the specification committee vote by whatever vendor who is requesting the non-default option.

[waynebeaton]

We can split hairs. Whether it is the committers themselves or their employers, committers absolutely have the choice regarding whether or not they will participate in a particular specification.

The choice to use patent license that is different from the working group's default needs to be approved by both the steering committee and the specification committee. The process purposefully makes no mention of how the request for approval is brought to the committees; while it seems natural that the responsibility to do so fall on the vendor who feels strongly that an exception is required, codifying this responsibility feels potentially restrictive and unnecessary.

In any case, both committees have -- through voting processes that they defined and control -- the ability to stop an exceptional patent license state from proceeding. Note that it's also the case that the committees can decide when and under what circumstances they will call a vote.

IMHO showing up to the specification committee out of the blue and saying "vote on creating this specification project that you've never heard of" is a big fail. My expectation is that, as new specifications are introduced, they are (along with big issues such as this) socialized with the specification committee well in advance of a ballot; this gives the specification committee ample opportunity to debate the matter before they're called on to run a formal ballot. If a specification committee feels that they need to have a ballot before the ballot, then that's entirely up to them.

[starksm64]

Ok, this conflating/mingling of what role committers should/should not have in determining the spec project patent license type has clarified what this issue should be about. This is not splitting hairs when it comes to what ability to specification committers have with regard to any action related to patents. They really have none. It would be an exceptional circumstance where an individual committer had an essential patent that they could take any action on.

Let me detail the failings of the current handling of this topic in the Jakarta Config specification project as an example of why the procedure needs to be tightened up.

1. Jakarta Config project was reformed with an initial contributor lists that contains an over weighted sampling of vendors favoring the CPL.
2. A vote was called to choose a patent license. It resulted in an 8/6 in favor of/opposed to use of the CPL.
3. A config spec lead asked for the exception to be approved by the Steering Committee. For whatever reason, the SC only does votes within meetings. The vote had two members missing, one member who delegated their vote to match the contributor vote because they felt they had the authority to chose, one member voting in opposite of what they had in the config committer vote, and the rest voting more or less consistently with how they have on this topic.

Problems:

1. We have no interest in babysitting the initial contributor membership list to ensure a fair voting around the one time choice of the patent license.
2. The vote is a reflection of the vendors weighted by committer count. Which such a voting strategy was used in MicroProfile, it was labelled as unfair, we make the same statement here.
3. The requirement that SC votes be held in person usually results in lack of representation. There also are members voting that have no skin in the game in terms of patent commitments, and there have been statements to the effect that they don't have expertise in the matter. The net effect is that it is debatable that the SC simple majority voting mechanism is a viable approach to dealing with patent license type choices.

This leaves the Specification Committee and its super-majority requirement as the only viable place to make such determinations.

[edbratt]

My input on this is: we don't have a strong position in how the committer group makes decisions and we have, in fact had teams suggest they want to have a more heavy handed lead approach. I believe, to date, the committees have refrained from attempting to direct governance within the committer teams. I think that's appropriate and so long as all participants abide by the process -- however it may be laid out -- those decisions are the purview of the committer team. So long as they are operating within the guidance of the Eclipse Developer Handbook. If the oversight committees then apply a high-bar with regards to allowing an exception to the default -- then we should not call it a default because that would suggest it is actually a 'strong preference.' Committer groups may only select between two alternative choices so it's not as if there is a wide range of choices. If a change such as this were to be proposed, it probably belongs in the handbook, not in the EFSP. The EFSP covers what to do, if the committer group wants to use the non-default option. That seems appropriate to me,

[m0mus]

Jakarta Config project was reformed with an initial contributor lists that contains an over weighted sampling of vendors favoring the CPL.

It's not true. The committers list didn't change since the initial project proposal. That time the patent license choice was not at the horizon.

The vote is a reflection of the vendors weighted by committer count. Which such a voting strategy was used in MicroProfile, it was labelled as unfair, we make the same statement here.

It's different and not related to this topic. The unfairness concern was raised when the voting model you mentioned was proposed as the main decision making mechanism for the whole MP group (steering committee, spec committee, etc.) which would be different from Jakarta EE where vendors have one vote in all committees.

Projects is Jakarta have freedom in choosing a governance model. The only limitation is a compliance with EDP. It cannot be achieved in MicroProfile because it's one project containing multiple specifications and not distinguishing one spec committers groups from another.

Red Hat does not believe that specification projects, who are mostly composed of technical contributors, should have a simple bar for proposing a patent license type that differs from the working group default.

I see this as an attempt to make default option the only option. There are two patent licenses and both of them are legit. My understanding of default option is that it should be selected by default in "select patent license" drop down list in the proposal creation form. That's it.

[starksm64]

Red Hat does not believe that specification projects, who are mostly composed of technical contributors, should have a simple bar for proposing a patent license type that differs from the working group default.

I see this as an attempt to make default option the only option. There are two patent licenses and both of them are legit. My understanding of default option is that it should be selected by default in "select patent license" drop down list in the proposal creation form. That's it.

This is an attempt to move a non-technical issue out the hands of a technical project. Neither the EDP nor the EFSP are adequately dealing with patent license choice for the reasons detailed in this issue.

[starksm64]

Jakarta Config project was reformed with an initial contributor lists that contains an over weighted sampling of vendors favoring the CPL.

It's not true. The committers list didn't change since the initial project proposal. That time the patent license choice was not at the horizon.

Yes, it is the same over weighted list. We view this aspect as irrelevant now as the real issue is that the committers have no legal standing for proposing requirements around patent licenses. This has nothing to do with management of the specification project. The patent license choice affects all implementors of the specification. It has no impact on technical direction or scope of the specification project.

[waynebeaton]

1. We have no interest in babysitting the initial contributor membership list to ensure a fair voting around the one time choice of the patent license.

You don't have to. Let's say that (hypothetically) the project proposer stacked the deck and the eight folks who voted for the CPL all worked for the same company. The organizations whose people all voted no then have a choice to make: do they continue anyway, or do they pull their people off the project? If they opt to pull their people off the project, then the hypothetical organization that stacked the deck has a choice of their own: do they care about the patent license option more than they care about the investment and patent grants from the other participants? The steering committee and specification committee then also have a similar choice to make.

If any participant in the process feels like a project vote was not run in good faith, then they can appeal to the project leadership chain or to the working group committees through their representative. In the case of an entirely new project proposal, we have several options up to the executive director pulling the plug.

I don't see how requiring a super majority vote of the committers changes the deck stacking problem. An organization that is inclined to stack the deck would just have to stack it a bit more...

No part of this happens in a vacuum.

2. The vote is a reflection of the vendors weighted by committer count. Which such a voting strategy was used in MicroProfile, it was labelled as unfair, we make the same statement here.

There's two cases here: selecting the default patent license for the working group and dealing with exceptions.

There's no rule in either the EFSP or the working group process that the committers need to be consulted when a steering committee decides what their default patent license will be. A steering committee can opt to consult with committers, but I strongly advise against making any consultation with committers on the topic binding.

There is a case to made that it is the organizations involved who should be making the call regarding patent grants and that any committer vote on the topic is irrelevant. In fact, I'll argue that the committer vote is only relevant if the supporting organizations want it to be relevant. The organizations involved all either have direct members or elected representatives on both committees. Ultimately, it is the committees who decide. That is, when the steering committee rejects the petition for an alternative patent license, we're done; when the specification committee fails to reach a super-majority approval, we're done. The only path forward for a rejected proposal is for the inputs to be changed and try again (e.g., change the patent license selection, wait for changes in the committee composition or attitude, etc.).

Note that a specification project can only have one patent license, and that applies to all specifications that it contains, so this isn't an issue when adding specifications to MicroProfile.

In the case where a working group is creating a new specification project... If a steering committee is united (or at least heavily weighted) in its opinion, then the default patent license should naturally prevail. If it's not, then... well... democracy is messy.

3. The requirement that SC votes be held in person usually results in lack of representation. There also are members voting that have no skin in the game in terms of patent commitments, and there have been statements to the effect that they don't have expertise in the matter. The net effect is that it is debatable that the SC simple majority voting mechanism is a viable approach to dealing with patent license type choices.

The requirement is that the steering committee approves the exceptional license. The process does not prescribe how that occurs; it is the responsibility of the steering committee to decide how it makes decisions. In the absence of specific direction, the default is simple majority. My recommendation is that you propose a motion to the working group that votes regarding patent license selection be done electronically to ensure that every member gets an opportunity to vote.

This leaves the Specification Committee and its super-majority requirement as the only viable place to make such determinations.

[starksm64]

What we are now saying is that any perception of authority regarding the choice of a patent license cannot lie in the specification project. The vacuum comment misses the point. The only concern around membership of a specification committee is whether they are technically competent. What we have outlined as happening is a technical group influencing the choice of a legal requirement, and that should not be allowed. It is bad enough that we have non-lawyers and even members without legal counsel advice voting on patent license issues.

Regarding the voting process being electronic, yes, that is something we will take up.

[waynebeaton]

A specification project team has no actual authority to select the patent license. The project team's selection of patent license is effectively no more than a recommendation or -- especially in the case where their selection is different from the default -- a request. Both the steering committee and steering committees can choose to reject their project team's selection and it's full stop. That is, most of the actual authority rests with the specification committee and -- to a lesser degree -- with the steering committee, but only when an exceptional patent license selection is involved.

My comment that this does not happen in a vacuum is the point. During the required community review period for a project proposal, everybody (including both the specification and steering committee members) has an opportunity to weigh in, ask questions, and recommend changes. More than that, the project team for any new specification project proposal that shows up to a working group has a definite interest in socializing, discussing, and arguing all details of the proposal with of the committees that have the power to block creation of the project.

I'm going to add a step to our project proposal workflow that's very obviously missing: we need to inform the specification committee that a new specification project has been proposed to ensure that they're engaged at the very beginning of the community review period, well in advance of any request that we'll make to run a ballot. In the case where a steering committee vote on an exception for a patent license is required, it's my strong preference that the specification committee initiate that.