Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] November's Planning Council meeting - topic: Type A vs. Type B licenses

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].



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


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 ?


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



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]
> 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:
> 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

Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio

Back to the top