| Re: [jakarta.ee-spec.committee] TCK Projects vs Spec Projects |
On 2018-09-06 9:34 AM, Kevin Sutter wrote:
I think Bill is accurate. We had decided that the TCK needed to be separate from the Spec due to the "Working Group" Participation Agreement that would be necessary for the Specs (due to the necessary IP flows). We didn't want to require TCK developers to be bound to this same "Working Group" Participation Agreement.
Good point. We need to make sure that all participants in the specification process are covered under a participation agreement. It is unlikely that we would need those for TCK contributions.
Aside... As I have discussed this with IBM colleagues over the last couple of months, they have questioned why this was really necessary. These are seasoned Eclipse developers in the community. And, they were questioning why a special contributor's agreement was necessary over and above the standard ECA. So, maybe this is a question that we need to revisit.
There seems to be some confusion here. The intent is to create a new version of the ECA that will add copyright grants sufficient to allow us to do code first development. This has taken a ridiculous amount of time to get the lawyers to agree on, but that is the intent. (We have been debating one paragraph of text since February if you can believer it.) You may want to speak to Jeff Thompson (IBM attorney) about these conversations.
The participation agreement will lay out the corporate patent license grants. As we've discussed previously, the patent grants which typically flow to the entire specification are quite different and broader than the contribution-based patent grants provided under open source licenses such as the EPL and ALv2.
--------------------------------------------------- https://www.linkedin.com/in/
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn:kevinwsutter
jakarta.ee-spec.committee-bounces@xxxxxxxxxxx wrote on 09/06/2018 06:45:55 AM:
> From: Ivar Grimstad <ivar.grimstad@xxxxxxxxx>
> To: Jakarta specification committee <jakarta.ee-spec.committee@eclipse.org>
> Date: 09/06/2018 06:46 AM
> Subject: Re: [jakarta.ee-spec.committee] TCK Projects vs Spec Projects
> Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
>
> I can't speak for how it works in larger organizations, but for
> JSR371 it is the same people involved.
> The way we work with tags in the asciidoc spec documents that is
> used to generate TCK test coverage, keeping them together makes life
> much easier.
> Would it be possible to allow for both models? Or do we need to
> specify it that detailed?
>
> Ivar
>
> On Thu, Sep 6, 2018 at 1:36 PM Mike Milinkovich <
> mike.milinkovich@eclipse-foundation.org > wrote:
> On 2018-09-05 6:17 PM, Bill Shannon wrote:
> > In a previous discussion, perhaps in the Steering Committee,
> > I believe we came to the conclusion that the TCK needed to be
> > in a separate project from the spec. I think this was due to
> > some IP or licensing issue, perhaps because Spec Projects would
> > operate under different IP rules that we didn't want to apply to
> > code projects such as the TCK.
> >
> > Does anyone remember the exact rationale for this required
> > separation between TCK Projects and Spec Projects?
>
> Bill,
>
> Wayne and I discussed this very topic yesterday.
>
> Given that the TCK is a 1:1 with the Specification and the API, and that
> all three artifacts need to be released at the same time, we're thinking
> that they should all be managed as one project.
>
> Our single reservation is that AIUI the people who work on the TCK and
> the people who work on the spec document are often different. Is that
> actually correct? We typically have a single committer list for everyone
> involved in all aspects of a single project. If we need to manage
> separate lists of committers between the spec doc/API/TCK that may drive
> us towards a different solution.
>
> Thoughts? Comments?
>
> --
> Mike Milinkovich
> mike.milinkovich@eclipse-foundation.org
> (m) +1.613.220.3223
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> _______________________________________________ https://dev.eclipse.org/
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@eclipse.org
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
>mailman/listinfo/jakarta.ee- spec.committee
> --
> Java Champion, JCP EC/EG Member, EE4J PMC, JUG Leader
> _______________________________________________ https://urldefense.proofpoint.
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@eclipse.org
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
>com/v2/url?
> u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee- 2Dspec.committee&d=DwICAg&c= jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m= wUWaeRnTMhpteEBzp0v4mAONMYw3qI e9oCaaH9JfL1M&s= LfIhNM81zlDqwtsl9bhXsOmoGyRGSH dIwbH3-
> NeUR0o&e=
_______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@ eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee- spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee- spec.committee