Hi everyone,

I'll chime in here too. At the University of Nebraska Omaha, we started a
project focused on building a tool (DoSOCS) that integrated with CI


It's been a little while since its last action but could potentially inform
efforts discussed here.


On Fri, Feb 9, 2018 at 7:48 AM, Foster, Jeremiah <jfos...@luxoft.com> wrote:

> Hello!
> This looks interesting, I'll definitely check it out. (Also good to hear
> about the tool HERE uses since it includes dependency checking which can
> get kinda messy in the Java world.)
> The only thing I can comment on at the moment is that the name is a bit
> confusing, for two reasons;
> 1. It doesn't 'check' licenses
> 2. There is already 'licensecheck' in Debian
> The first issue is a little important in the sense that the tool is not
> actually analysing a given license like ninka might. That is to say doing
> some kind of textual analysis to check which license a given license file
> is. Rather the code appears to read files and compare words to a database
> which helps *identify* the license a given file is under, but it doesn't do
> the more complex work of validating the license text itself. While this is
> no big deal (identifying licenses is important work and tools are still
> needed) it may cause a tiny bit of confusion to folks out there looking to
> ensure that the software they're using is licensed under the license listed
> and sometimes that due diligence requires an extra step.
> The second issue is likely not a big deal if you're not targeting
> Debian-based systems which has licensecheck and has had that tool for about
> a decade. Written in perl (as is ninka) because of perl's strong text
> capabilities, it is mostly used inside Debian. But Debian and its
> derivatives are widely used, the DEP-5 served as the basis for SPDX, and
> Debian's license compliance process has been around for a couple decades,
> so you may run into a namespace clash on those type of systems.
> I don't mean to sound pedantic or discouraging, just thought it might be
> worth it to raise these issues now.
> Cheers,
> Jeremiah
> On Fri, 2018-02-09 at 14:11 +1100, Ben Boyter wrote:
> Hi All,
> Thanks for the feedback before when I was seeking clarification about how
> to generate portions of the SPDX. One of the issues I had with getting SPDX
> adopted was to have a simple tool that would do it can could be hooked into
> CI pipelines and the like So I made one,
> https://github.com/boyter/lc
> I just released version 1.0.0 and would love to get some feedback on it.
> Its written in Go which was a decision I made in order to learn it and
> because I wanted a single binary that was easy to distribute. It works
> pretty well for all of the example projects I have tried and I will be
> using it on client sites where possible.
> _______________________________________________
> Spdx-tech mailing 
> listspdx-t...@lists.spdx.orghttps://lists.spdx.org/mailman/listinfo/spdx-tech
> ------------------------------
> This e-mail and any attachment(s) are intended only for the recipient(s)
> named above and others who have been specifically authorized to receive
> them. They may contain confidential information. If you are not the
> intended recipient, please do not read this email or its attachment(s).
> Furthermore, you are hereby notified that any dissemination, distribution
> or copying of this e-mail and any attachment(s) is strictly prohibited. If
> you have received this e-mail in error, please immediately notify the
> sender by replying to this e-mail and then delete this e-mail and any
> attachment(s) or copies thereof from your system. Thank you.
> _______________________________________________
> Spdx-tech mailing list
> Spdx-tech@lists.spdx.org
> https://lists.spdx.org/mailman/listinfo/spdx-tech

Mutual of Omaha Associate Professor
Information Systems
College of Information Science & Technology
University of Nebraska Omaha
Spdx-tech mailing list

Reply via email to