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_2016Decision 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:
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,
