Almost. So we can use any libary in any version if the license is in the approved > list
The library and version needs to have been vetted either by the Eclipse IP Team (i.e., a CQ exists for that library and version) or in the Clearly Defined dataset with a high confidence score (we're thinking 80% at this point). I'm going to assume that most of you don't know what Clearly Defined is (I talk a bit about it here <https://waynebeaton.wordpress.com/2019/10/09/revising-the-eclipse-ip-policy-third-party-content/> ). We've had a "service release" exception for a while now; a service release of a third party library based on a major or minor version that we've already approved may be used without creating a CQ. HTH, Wayne On Fri, Jan 24, 2020 at 11:30 AM Christian Dietrich < christian.dietr...@itemis.de> wrote: > Hello Wayne, > > thanks for that explanation. > So we can use any libary in any version if the license is in the approved > list > and there is no tracking of which libary in which version > is used by which projects? > > ~Christian > Am 24.01.20 um 17:24 schrieb Wayne Beaton: > > I'm working on some updates to the handbook and we're rolling out some > (relatively minor) updates to the "Create a CQ" functionality on the PMI. > My apologies to all that this is taking longer than I'd hoped. > > The short version is that you don't need any tools to not create a CQ. > > In this particular case, we know that the libraries in question have been > approved by the IP due diligence process, so just don't create any new CQs. > The challenging bit is how we make it easier for committers to know that > they don't need to create a CQ; I'm working on a solution to that problem > that I've committed to rolling out this quarter (at least part of which > will be contributed to Eclipse Dash, so you all can help maintain it). I > need you to be patient for a little while longer for this. > > The slightly longer version is that I've spent a lot of effort to get our > existing IP data into a state where we can do more in an automated manner. > Over the years we've collected a lot of data, but--as you likely already > know--it's not been collected in a form that makes it consistently > queryable. I've got that (mostly) sorted out. We're also starting to > leverage license data from Clearly Defined, a project which crowd sources > license data from open source projects. My expectation is that we will > still need to create CQs for third party content, we'll just have to create > a lot fewer of them. Those that we do create will follow the same process > that we do today. Again, I owe a longer explanation. > > Regarding IP Logs, I've been experimenting using build tools to fill in the > gaps. This works pretty well for Maven-, Gradle- and NPM-based builds, > where you can build an accurate dependency list right out of the tool > (e.g., "mvn dependency:list"). FWIW, the tools that I referred to have > evolved from scripts that I've been using for a few months to map the > results from that dependency list to license and CQ information. I'll start > attaching the output from the scripts to IP Log CQs as a stop gap. > > HTH, > > Wayne > > On Fri, Jan 24, 2020 at 11:02 AM Christian Dietrich > <christian.dietr...@itemis.de> wrote: > > > but where is then new tooling for that ? > > the portal still creates cqs > Am 24.01.20 um 16:58 schrieb Wayne Beaton: > > - the bureaucracy > > > I assume that you mean IP due diligence. There should be no Eclipse > Foundation bureaucracy required. All of the libraries in question have > already been approved, so the project team can just start using them. > > Following the Eclipse Foundation's Board of Directors approval of our new > IP Policy in October, Piggyback CQs are no longer required. I owe the > community a much longer discussion about all of the changes. There is some > discussion on by > blog<https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> > > <https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> > <https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> > <https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/> > . > > You will still have to submit your IP Log for review, but only the next > time that you actually have to do a release review. Note that changes made > to the EDP in December 2018 make it so that you can do releases for an > entire year following a successful release review (i.e., we no longer > require a review for every single release). > > I hope that this knocks at least one thing off of the list (I understand > that the other things on the list are harder > > HTH, > > Wayne > > On Fri, Jan 24, 2020 at 3:07 AM Christian Dietrich > <christian.dietr...@itemis.de> <christian.dietr...@itemis.de> wrote: > > > Hi, > > we (Xtext) currently have no capacity to do > > - the bureaucracy > - analyze impacts on logging customization points in Xtext > - analyze who else uses what logging and how that change would affect them > and indirectly us > > Regards > Christian > Am 23.01.20 um 15:05 schrieb Ed Willink: > > Hi > > If there is a conflict hazard then it already exists. Examining one of my > workspaces... > > Good (SLF4J) - jgit, m2e > Bad (LOG4J) - mwe, ocl, qvtd, xtend, xtext > > This is complete news to me. I continue to use log4j since it avoids > changing code styles that have been unchanged for many many years. Other > projects probably just copy prevailing practice. > > I presume changing is rather easy, and of no consequence to the exported > API, since the use of log4j is by import package. > > However without a commitment to change by Xtext, I would be reluctant to > change any Xtext-based project. > > Regards > > Ed Willink > On 23/01/2020 13:09, Hickman, Steve (AdvTech) wrote: > > Log4j 1.x reached end of life in 2015. The documentation for it now > appears to have gone offline. There are some Eclipse projects (call them L1 > projects) that currently use Log4j 1.x directly rather than SLF4J. That > means that any projects that depend on L1 projects cannot use Log4J 2.x > without risking dependency collisions from attempting to load multiple > versions of Log4J. > > > > SLF4J was created precisely to eliminate dependencies on specific logging > implementations. > > > > It is important that libraries like those that plug into Eclipse not > unintentionally force a specific logging implementation on their users. > Those library developers have no way of knowing – and probably no way of > satisfying – all the requirements of their various sets of users. > > > > Given that, it seems that Eclipse should make SLF4J the ‘official’ logging > API for all Eclipse libraries. > > > > > > > > > > > > *Steve Hickman* > > Software Architect > > *Honeywell* | Aerospace > > Office: 480-236-8367 > > steve.hick...@honeywell.com > https://in.honeywell.com/sites/aero/ENG/advance-tech/crew-intf/Pages/crewhome.aspx > > > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, > visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, > visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > _______________________________________________ > cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, > visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Wayne Beaton Director of Open Source Projects | Eclipse Foundation, Inc.
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
