|
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.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/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@xxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx
> (m) +1.613.220.3223
>
>
> ---
> This email has been checked for viruses by Avast
antivirus software.
> https://www.avast.com/antivirus
>
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password,
or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
> --
> Java Champion, JCP EC/EG Member, EE4J PMC,
JUG
Leader
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password,
or
> unsubscribe from this list, visit
> https://urldefense.proofpoint.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=wUWaeRnTMhpteEBzp0v4mAONMYw3qIe9oCaaH9JfL1M&s=LfIhNM81zlDqwtsl9bhXsOmoGyRGSHdIwbH3-
> NeUR0o&e=
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
![Avast logo]()
|
This email has been checked for viruses by Avast antivirus software.
www.avast.com
|
|
