Yeah, so we try really hard to keep as much of the source vendored as possible, to avoid build breakage as a result of changing external dependencies. It also allows everyone in the community to have consistent builds, which helps with ensuring that we all have the same set of bugs. :)
Looks like the licenses are fine for the stuff you're using, we should just vendor those tools so they aren't pulled in at build-time and document the licenses in LICENSE so people know what they're using. On Mon, Aug 19, 2019 at 7:02 AM ocket 8888 <[email protected]> wrote: > > Does this need to be vendored and/or added to license listing(s)? > > On Thu, Aug 15, 2019 at 2:35 PM Robert Butts <[email protected]> wrote: > > > +0 > > > > I don't know if small libraries _require_ approval, but getting community > > input doesn't hurt. We just want to be careful about using large libraries > > that could stop being maintained, and difficult to replace. Or that could > > introduce security vulnerabilities. And that licenses are compatible, of > > course. > > > > `gocovmerge` is licensed BSD 2-Clause, which is fine (@lavu1241 here's the > > list, if you don't have it already: > > https://apache.org/legal/resolved.html#category-a). It looks like it isn't > > really popular or well-maintained, but it's also tiny and trivial to > > rewrite if we have to. If it were me, I'd probably just write it myself, > > but I'm a +0 on adding it. > > > > > > On Thu, Aug 15, 2019 at 2:05 PM Lavanya Bathina <[email protected]> > > wrote: > > > > > Hi, > > > I am using the below lib to merge the code coverage report from multiple > > > runs. > > > "github.com/wadey/gocovmerge" > > > > > > Based on the review, it seems there is specific way in which external > > > libraries can be used or it needs approval. I am pretty new to the open > > > source world. Seeking help to understand the process or procedure to use > > > the above library. > > > > > > > > > -- > > > Thanks and Regards, > > > Lavanya Bathina > > > 303-676-7825 > > > > >
