Re: [eclipse.org-planning-council] November's Planning Council meeting -

[Nick Boldt <nboldt@xxxxxxxxxx>]

If I captured it correctly, here's the outcome of this conversation today:

* release records [1] will be updated to include which level of due
diligence (Type A or B).

* Type A / Type B applies to third party libraries ONLY, not to the
project's code itself.

* if a hypothetical company wants to invest resources to move a
project from Type A back to B, they could do so; they could also do
the additional provenance checking and never report back to the
Foundation or the project.

--

Had a brief chat with Gorkem Ercan (project lead for Thym) and he's
happy to put something into his release documentation, eg., a new
section on this page [1] or a new blurb in the release doc itself [2].

[1] https://projects.eclipse.org/projects/tools.thym/releases/2.0.0
[2] https://projects.eclipse.org/projects/tools.thym/reviews/2.0.0-release-review

--

There was also some discussion on the call today about using
about.html [3] (or perhaps license.html [4] or LICENSE [5]) to
identify the license check style. How many of these touchpoints are
really required if the information is captured at the release review
level?

[3] https://github.com/eclipse/thym/blob/master/plugins/org.eclipse.thym.core/about.html
[4] https://github.com/eclipse/thym/blob/master/features/org.eclipse.thym.feature/license.html
[5] https://github.com/eclipse/thym/blob/master/LICENSE

Do we need a new bugzilla to capture HOW we suggest projects identify
their License Check Style = {"License Approved" or "License &
Provenance Approved"}, or should we just use
https://bugs.eclipse.org/bugs/show_bug.cgi?id=501014 ?

--

If I missed anything important in today's call re: this topic, please
add it or correct me.

Cheers,

Nick

On Tue, Nov 1, 2016 at 9:56 PM, Nick Boldt <nboldt@xxxxxxxxxx> wrote:
> In the October Planning Council call [1], we discussed the notion of the new
> Type A (only the license is checked) vs. Type B (old school full due
> diligence, with code provenance checked too) licensing.
>
> [1] https://wiki.eclipse.org/Planning_Council/October_05_2016
>
> Decision on that call was to only include type B stuff in release train for
> now, and wait for projects to complain they should be included, or perform
> more due diligence to be upgraded to Type B. Including Type A stuff opens a
> lot of trickle-down problems that no one wants to deal with unless we have
> to, such as "will end users still be allowed by their employer to use
> Eclipse, if there's no longer a guarantee of provenance check in the
> bundles?".
>
> In the minutes [1], it's noted:
>
> When asked "who wants this" the only answer known was "web projects" such as
> Orion, where they do not necessarily have detailed, advance knowledge of
> "which jars, exactly, might be pulled in as they run". It was also believed
> that perhaps "new projects" wanted this, to get a quick start, but we were
> not positive about that.
>
> But since the call, I've found there are a number of other projects who want
> to take advantage of this new Type A licensing. Some are existing projects
> sick of doing Type B diligence; others are new projects who want to get up
> and running faster without the Type B overhead.
>
> Here's a list of some projects who would like to be in the release train,
> but would like to be Type A instead of B:
>
> JSDT
> Thym
> Che
> vert.x
>
> Much of the push here to move to Type A is to avoid the weeks or months of
> provenance vetting that has in the past been needed for JavaScrript
> libraries.
>
> Bottom line, I think it's important that we consider HOW to include Type A
> stuff in the SimRel repository, but still ensure they're labelled correctly
> as Type A or "licence type checked only".
>
> Maybe we could enforce some sort of feature.xml or license.html labelling,
> as is done for incubating projects?
>
> Could this topic be revisited at tomorrow's call?
>
> Thanks,
>
> --
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools & Dev Studio
> http://nick.divbyzero.com



-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com