Re: [jakarta.ee-spec.committee] Recent Edits

[Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>]

Scott - So I think what you're saying is that you agree with both my logic and my conclusions. Agreed?

Ivar - Yes, communication is key. But it is now crystal clear in my mind why this is absolutely necessary, which will certainly help me explain it to others. This is not about "pay to play". This is about maximizing the permissions given to the community. That is a very different ethical rationale we can use when explaining it.

On 2018-05-29 1:46 PM, Ivar Grimstad wrote:

The "pay to play" term was something some of the more vocal community members used when Eclipse foundation was chosen over e.g. Apache foundation in the beginning. I guess that when they realize that companies can "bypass" the meritocracy rules individual committers must follow, they will see this as proof that they were right. 

Note that I am not disagreeing with having this kind of process, what I am saying is that it has to be communicated really carefully. Otherwise, I guess we will see a lot more "kerfuffle" on the mailing list than we have ever before. The distinction between a spec project and a regular open source project must be so crystal clear that everybody, even the ones that always assume bad intentions with every announcement, are convinced.

Ivar

On Tue, May 29, 2018 at 7:30 PM Scott Stark <sstark@xxxxxxxxxx> wrote:

What is the exact "pay to play" concern, meaning, how is that falling out of the current "limited to parties (the “Participants”) covered under a <<Working Group>> Participation Agreement" wording I see in the requirements?

I'm also not really seeing the concern over the interchangeability of participants in a spec. A given spec working group is made of up implementors/users with expertise in the given spec. The exact set of participants should be flexible. In many areas both copyright and patent rights are owned by an employee's company, so it is a fallacy to believe that a spec can be developed that is able to convey such rights without considering the reality of legal constraints.

The hole in the logic with the specific example of a representative being on a spec who leaves a company, but remains on the spec, is that they need a new "Participation Agreement" in order to be properly representing their ability to meet the copyright and patent flow requirements.

On Mon, May 28, 2018 at 12:09 PM, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:

All,

Ivar did a nice job echoing the concerns that were going through my mind when I had responded earlier. But thinking through this some more, I am coming to the conclusion that we must figure out a way to allow participating companies to have an explicit representative on the Specification Teams that they can change at will. Because it actually is an absolute requirement, and not for the reasons that Richard outlined. This is not about the investment that these companies are making in the code or in the process. It is about the intellectual property that they are contributing.

We want to establish a specification process that clearly provides royalty free licenses to as many patents as possible which apply to these specifications. They way that is going to happen is via corporate participation in the Specification Projects, because it is companies that own large patent portfolios. The IP rules will say that if a company has a representative on the Specification Team that any patents they have which read on the specification must be licensed to all downstream implementations on a royalty free basis. This means that these representatives must be formally representing their employer. This also means that if for whatever reason their employer needs to change their representative on the Specification Project they must be allowed to do so. Any other approach means that a change in on person's involvement in a Specification Project could imply a significant loss of patent rights to the whole community.

I could imagine allowing someone who leaves their employer to remain on the Specification Project as an individual, or as a representative of another participating member company. But that individual's original employer must have the ability to appoint an alternate representative.

Does anyone see a hole in this logic?

On 2018-05-25 1:02 PM, Ivar Grimstad wrote:

Hi,

I think we should tread carefully here so we don't become a corporate club where you have to pay to play, which is exactly what critical voices in the community have warned against. 

I can understand the reasoning behind the wish for a company to being able to replace a committer on a project. But at the same time, if a corporation is allowed to do that it should probably apply to individual committers as well. E.g. someone that wants to resign from the project for some reason and give the reigns over to someone else. By doing so, we are going against the Open Source Rules of Engagement defined by the EDP (https://www.eclipse.org/projects/dev_process/development_process.php#2_1_Open_Source_Rules_of_Engagement). So be prepared for a storm! This will not be well received by our critics...

Ivar