►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
so
we're
recording
this
I,
don't
know
who's
gonna,
find
it
interesting
and
not,
but
we're
gonna
discuss
like
hey.
We've
got
a
dependency
list
here.
We've
got
a
license
list.
Should
we
combine
them
is
combining
them
an
absolutely
terrible
idea
if
we
do
combine
them,
what
things
do
we
have
to
consider,
and
so
this
is
just
throw
random
stuff
out
there.
That's
the
agenda,
it's
very
high-tech.
A
A
Let's
note
that
down,
that's
a
good
call
out
and
to
do
so
I'm
gonna
say
no,
it's
your
fault,
the
UI.
Only
and
so
I
think
that
we
would
still
want
the
scanners
to
be
separate
or
analyzers,
and
we
we
want.
We
want
the
technical
doodads
to
be
separate,
but
the
UI
interface
I
would
potentially
want
to
be
merged
and
then
I'm.
B
They
see
this
dependency
list
page
and
those
license
compliance
page
and
when
you
click
on
one
there's
some
info
on
one
side
and
there's
some
info
on
the
other
side,
when
there's
a
bit
of
overlap
and
I,
think
that's
the
overlap
that
we're
concerned
with
and
we're
trying
to
this,
whether
or
not
there's
enough
overlap
that
we
can
actually
combine
these
two
pages
and
then
all
the
actions
that
they
would
take
on
either
page
can
be
done
from
a
single
interface
rather
than
having
some
data
on
one
page
and
some
data.
Another.
Am
I
paraphrasing?
A
Lot
of
overlap
between
them,
so
you
know
why
not
put
them
together,
but
the
other
part
of
it
is
that
in
some
cases
for
my
particular
use
case,
I
may
actually
need
the
combination
of
data
to
be
useful
so
like
for
rape
for
right
now,
you
could
be
coming
at
this
information
in
a
bunch
of
different
ways.
You
could
be
coming
at
this
information
from
I
am
a
legal
person
and
I
need
to
make
sure
that
we
don't
have
licenses
in
the
project
that
I
deem
to
be
dangerous
to
my
organization
and
I.
A
Don't
care
about
the
dependency
nonsense.
However,
the
dependency
nonsense
is
going
to
be
necessary
when
I
see
that
there's
a
license.
I,
don't
like
that.
I
would
like
to
deny
where
I
need
to
now
notify
developers.
Okay,
as
a
result
of
me
denying
license
X
I
need
you
to
remove
dependency
y
I,
don't
actually
care
about
the
dependency,
but
when
I
create
an
issue
or
create
an
action
as
a
result
of
something
I've
done,
somebody
else
is
gonna
care
about
the
dependency
in
other
cases.
A
I
may
just
need
to
be
creating
like
a
list
of
hey.
What's
included
in
our
software?
Well,
that's
gonna,
be
your
dependency
plus
your
license,
plus
your
version
plus
whatever
and
so
to
the
question
you
kind
of
asked
earlier.
I
would
want
the
skins
to
happen
on
the
back
end
separately,
but
on
the
front
end.
I
would
want
a
UI
to
be
potentially
combined
but
filterable
to
my
use
case,
but
I
also
might
want
an
export
and
that's
something.
B
Way:
okay,
okay,
okay
and
right
now
it
for,
let's
say
someone
who
wanted
to
get
a
list
of
licenses
that
we
currently
have
in
a
project
that
are
put
puts
our
organization
out
of
compliance
with
whatever
policies
we
have
in
place.
They
go
to
license
compliance
and
we
don't
have
any
sort
of
export
function.
B
A
A
A
A
So
like
in
the
scenario
that
I
had
mentioned,
is
that
if
I
decide
to
deny
a
license,
what
do
we
need
to
replace
as
an
example
and
then
to
Cindy's
next
point
different
users?
Would
they
can
be
confused
by
seeing
both
together,
and
this
is
actually
one
that
I'm
concerned
about
and
that's
why
I
was
saying?
Maybe
we
should
have
filters
he's
lit
up
yep?
Can
we
ask
some
customers
their
opinion,
their?
A
So
first
I
wanted
to
see
if
anybody
found
any
really
good
gotchas
like
definitely
one
we're
gonna
have
to
consider
is
how
do
we
explain
that
this
list
isn't
complete
because
of
the
language
discrepancies,
so
we
wanted
to
figure
out
the
gotchas
to
work
them
in
the
UI,
make
one
or
two
designs
and
then
do
some
kind
of
survey
or
interviews
to
be
like
you
know
you
were
interested
in
licenses
or
you
were
interested
in
dependencies
or
you're
interested
in
just
doing
mr-s.
Is
the
screen
overwhelming
like
what
do
you
think
of
this
screen?
D
Okay
yeah,
my
my
biggest
concern
in
combining
them
is
one
getting
the
customer
feedback
and
I
mean.
Maybe
UX
could
do
some
research
for
you
on
that,
but
and
then
the
other
would
be
mapping
it
to
the
way
the
analysts
talk
about
it
like.
Will
it
ever
cause
them
confusion
on
what
we're
doing
so
they
end
up
just
going
blood
over
the
whole
thing.
That
kind
of
happens
sometimes,
if
it's
not
in
their
frame
of
reference,
not.
D
E
A
Released
anything
like
new
tab
that
could
totally
be
a
solution
of
your
dependencies.
Have
your
licenses
have
your
combined
or
whatever,
but
whatever
it
is.
I
definitely
want
to
make
like
a
low-cost
mock
and
like
kick
it
around
for
a
couple
weeks
with
some
people
first,
because
we
might
get
an
instant
I
hate.
It.
E
Like
it
wouldn't
be
that
hard
to
read,
I
mean
every
weird
to
have
in
both
places,
but
we
could
embed
the
dependency
list
view
as
a
tab
and
license
compliance,
because
it's
like
that
way.
It's
on
a
tab
and
you
don't
have
to
like
go
between
pages.
You
just
go
between
tabs
and
it's
a
lot
more
responsive.
So
it's
very
quick
to
tab
between
nest
opposed
like
loading
their
page
because
going
between
life,
the
license
compliance
and
the
dependency
list
page
is
a
whole.
E
B
Like
that
idea
on
the
backend
rails,
part
we're
doing
some
magic
to
like
merge
some
of
the
data
from
the
dependency
list
and
the
license
list
reports,
and
so
we're
unnecessarily
doing
that
in
some
places
so
that
the
data
can
be
utilized
in
one
place
and
data
can
be
utilized
in
another.
So
if
we
were
to
do
with,
Fernando
is
sort
of
suggesting
I
support.
B
That
I
think
is
what
I'm
saying
I
don't
know
exactly
what
the
visuals
would
look
like,
but
so
I'm
picturing
the
detective
and
project
which
shows
us
the
list
of
the
licenses.
We've
got
policies
and
then
I
think
what
you
said:
Fernando
is
like
there'd,
be
another
tab
specifically
for
just
the
dependencies.
So
maybe
it's
like
a
matter
of
renaming
the
page
from
license
compliance
to
something
more
abstract
that
matches
the
needs
of
both
licenses
and
dependencies
and
still
utilizing
the
existing
code.
B
That
was
done
there
because
it
it
for
what
the
reasons
the
friend
Ahmet
mentioned:
it's
responsive!
It's
it's!
What
he's
currently
working
on
so
he
has
a
good
understanding
of
current
code,
any
objections
to
that
or
concerns
that
we're
overlooking
I,
I'm
naive
in
the
sense
that
I
don't
know
the
full
context
of
the
existing
dependency
Lisp
aging,
the
nuances
around
that
so
I,
don't
know
what
we'd
be
losing.
If
we
did
that
I
I.
E
Think,
for
me
the
only
concern
is,
and
probably
I
guess
I
could
reach
out.
The
Kyle
is
that
we
had
added
the
whole,
like
recently,
the
policy
violation
badge
and
the
banner
and
stuff
so
like
some
of
those
workflows.
I
want
to
make
sure
that
don't
get
confused
well,
I
mean
I,
guess
yeah,
because
it's
like
I
I
feel
like.
E
E
If
you
want
to
roll
back
some
of
the
ideas
we
don't
have
in
terms
of
development
engineering
effort,
it's
less
for
us
is
my
concerns
that
we
blow
we
change
the
functionality
we
get
rid
of
what
we
had
before
and
then
we
take
a
step
back
and
we're
you
have
making
more
work
for
ourselves.
Adding
a
new
tab
would
be
a
good
first
iteration,
at
least
from
the
front-end
development.
A
F
The
kind
of
like
what
Fernando
is
saying
we're
putting
too
much
information
on
one
page.
We
have
dependencies,
we
have
licenses,
we
have
vulnerabilities
as
well
and
the
dependency
list.
The
dependency
list
is
more
about
what
vulnerabilities
are
my
dependencies,
exposing
me
to
where,
as
a
license,
this
page
is
more
about
what
licenses
have
I
implicitly
agreed
to,
and
that's
the
you
know,
there's
two
sort
of
perspectives
on
related
issues,
but
there's
no
link
between
licenses
and
vulnerabilities,
for
instance,
that
putting
it
all
together
and
well
I
mean.
A
Like,
let's
just
say,
magically,
we
had
one
chunk
of
data
that
had
all
of
the
information,
so
it
has
your
dependency,
your
version,
your
license
so
on
and
so
forth.
Circling
back
to
kind
of
the
tabbing
idea,
but
skipping
ahead,
maybe
a
couple
iterations:
what
if
it
was
all
the
same
information
but
sorted
and
grouped
and
displayed
differently
when
you
pick
two
different
tabs.
So
it's
all
the
exact
same
data,
but
it's
like
I
want
a
license.
Centric
view,
I
want
a
dependency
centric
view
or
I
want
a
exportable
s-bahn
view
and
exportable
X
s.
A
Bom
view
is
like
the
fugly
baby
or
no
I'm,
not
supposed
to
use
that
the
you
know
just
CSV
list
where
it's
not
beautiful,
but
I
know
that
it's
not
beautiful,
but
I
mean
exporting
it
for
a
particular
purpose,
but
like
the
first
two
tabs
are
very
geared
to
that
particular
mental
use
case.
And
so
maybe
the
first
list
with
licenses
is
grouping
it
all
together
for
licenses
and
then
the
next
one
is
dependency
use
grouping
it
by
dependencies
with
their
vulnerabilities.
A
E
B
Not
sure
what
data
is
missing
and
so
I
I'm
having
a
bit
of
hard
time,
answering
that,
because
right
now
the
license
compliance
page
has
the
list.
Policies
that
are
configured
by
are
the
owners
of
the
project,
which
is
to
say
that
this
is
the
classification
we've
applied
to
each
of
these
software
licenses.
It's
got
the
software
license.
Name
the
SPD
X
identifier,
the
URL
for
the
license,
the
dependency
name.
B
I,
don't
think
we
have
version
at
the
moment
a
dependency
version
which
I
think
is
a
little
more
important
for
NPM,
where
you
have
projects
with
multiple
versions
of
the
same
dependency,
which
is
hard
to
see
currently
and
I'm,
not
sure
what
data
we
have.
That's
in
the
dependency
list.
Do
you
know
Fernando
from
the
API
endpoints,
like
with
data
you're,
getting
there
that
isn't
in
license
compliance
data,
I'm
getting
that
isn't
in
it.
They
would
need
I,
guess.
E
Well,
right
now,
I
have
like
honestly
I'd
be
guessing
right
now,
but
I
do
okay
other
than
what's
shown
in
the
UI.
I
could
circle
back
and
get
you
the
exact
field
says
I
know,
there's
a
lot
of
stuff.
We
don't
necessarily
use
that's
available,
but
I
mean
from
the
UI
that's
consumed
is
like
the
license
name,
it
has
a
URL
and
then
the
classification.
If
it's
like,
allowed
or
denied
that's
one,
that's
detected
in
licenses
page
and
then
the
policies
will
return
the
name
and
like
again
like
the.
E
B
B
I'd
love
for
some
of
those
pieces
of
data
such
as
the
URL
associated
with
a
saucer
license
since
we've
already
got
the
software
licensed
in
the
software
licenses
table
to
be
able
to
store
that
next
to
it.
That
way,
it's
consistently
shown
when
that
software
license
is
shown
and
it's
not
dependent
on
whether
there
is
a
report
or
if
it
was
found
in
the
report
or
not.
It's
all
straight
an
issue
to
discuss
that.
B
But
nothing
jumps
out
at
me
is
not
possible
in
terms
of
providing
the
backend
data
to
circle
back
on
to
the
effort
involved
to
do
that,
I
think
one
other
piece
that
we
did
have
was
maybe
the
path
of
where
it
was
detected
in
the
dependency
list.
I,
don't
think
we
provide
that
today
in
the
license
list,
so
you.
B
B
C
So
I
think
I
brought
that
to
the
attention
of
kind
in
the
first
base,
where
you
know
a
woman,
once
we
started
discussing
about
more
component
center
of
view,
because
I
find
the
current
situation
be
disturbing
and
confusing
for
the
users
were,
if
you
have
license
compliance,
for
example,
license
scanning
any
burden
on
your
project.
We
will
be
reporting
licenses
referring
to
companies
that
are
actually
dependencies,
but
there
is
no
link
in
there.
That's
a
dead
end
when
you
want
to
start
winning
about
these
differences,
there's
no
link
or
whatsoever.
C
So
I
started
to
brainstorm
with
Karen
about
how
can
we
make
that
more
compliment
sandwich?
Because
in
the
end,
if
you
have
a
problem
with
the
permeability,
if
you
have
a
problem
with
risings,
you
have
a
problem
with
license,
except
you
have
a
problem
with
the
component
in
the
first
place,
now
not
going
to
do
anything
with
the
license.
You
are
going
to
do
something
with
the
component
here,
either
accepting
the
risk
or
the
license,
or
you
change
the
component
or
you
just
say
to
the
person
that
wanted
to
introduce
that
in
finance.
C
B
About
the
very
far
future,
so
one
thing
I
heard
you
say
is
that,
like
maybe
we
can
describe
the
problems
in
terms
of
like
these
are
stories.
Like
so
I
know,
this
is
a
little
old
school,
but
if
we
were
to
say
something
like
as
a
developer,
I
want
to
be
able
to
go
to
the
package
men
or
the
dependency
URL
when
I
find
a
dependency
in
the
license,
lists
that
I
can
learn
more
about
it,
and
so,
starting
from
that
point
figuring
out
how
to
achieve
those
goals.
I
think
honestly,.
A
For
if
you're
the
developer,
making
NMR
I
want
you
to
see
it
in
the
merger
quest
report,
I
don't
want
you
to
have
to
go
to
the
page.
In
my
mind,
and
people
can
tell
me
like
this
is
not
how
this
works,
but
I
always
figured.
It
would
be
someone
who
is
new
to
a
project
or
a
manager
of
a
project
who
would
be
looking
at
these
lists
because
they
want
to
look
in
a
more
holistic
okay
for
this
project.
A
A
I
won't
use
your
product
if
you're
using
X
and
then
I
see
the
the
legal
list
or
the
the
license
list
being
more
like
your
legal
compliance.
People
checking
that,
but
to
your
point
of
a
user
story,
if
I
come
in
from
the
dependency
thing,
I
need
to
be
able
to
see
oh
well
I'm,
using
this
two
different
versions
of
this
dependency.
A
I
need
to
have
this
conversation
with
three
different
people,
so
I
kind
of
like
the
idea
that
was
proposed
earlier,
of
making
it
tabs
so
almost
for
the
use
for
the
personas
we've
got
the
same
view
sliced
in
different
ways
on
different
tabs
for
the
different
personas,
but
it's
all
in
one
place.
So
if
anybody
goes
to
look,
it's
all
there
for
them.
A
A
B
If
we
were
to
capture
that
on
the
webpage
and
might
convert
that
to
just
an
independent
issue
for
each
one
of
those
things,
can
we
solve
that
one
particular
story
at
a
time
and
then
over
time
we
can
see
whether
the
choices
were
making
helps
resolve
other
issues,
because
right
now,
I
think.
What
we're
trying
to
do
is
we're
trying
to
pick
a
solution
that
will
cover
most
of
those
issues
all
at
once
and
we're
not
we're
not
we're
not
we're
quite
sure
if
we're
actually
solving
one
or
some.
B
A
Possibly
I'm
just
can
I
like
the
tabie
idea,
because
I'm
my
original
concern
was,
if
we
do
it
and
we
break
two
personas
to
fix
one
persona.
Oh
no,
but
if
we
do
like
this,
tabby
thing
I
think
we're
a
little
safer
and
we
could
do
like.
You
were
saying
one
person
at
a
time
without
worrying
about
breaking
the
other
personas
yeah.
A
E
E
E
So,
ideally,
if
we
were
able
to
just
have
an
end
point
where
we
have
the
data
and
we
pass
it
a
bunch
of
query
of
parameters
like
you
know,
programmatically
right,
but
but
from
the
UI
it'd,
just
be
like
a
drop-down
with
like
preset
filter
for
a
context.
If
he
really
wanted
one
table
to
show
this
data
in
different
contexts
for
now,
I
think
the
middle
ground
in
the
past
for
prior
projects
has
been
having
completely
different
tables.
E
There
might
be
based
off
the
same
data
set
on
different
tabs
and
then
when
we
find
like
the
most
useful
use
cases,
and
we
really
want
it
in
one
table,
if
you
really
want
to
do
that,
then
you
could
have
like
preset
filters
that
would
hit
the
same
end
point,
but
then
had
the
data
filter
back.
If
he
wanted
something
like
that
in
the
long
run,
but
I
think
the
safest
bet
would
be
having
some
form
of
tabs,
so
we're
not
blowing
away
existing
contacts
that
we
have
is
what
I
would
suggest
is.
A
E
Id
to
use
a
follow
up,
I
had
an
idea
of
like
what
about
like
so
instead
of
adding
new
tabs
to
the
license
compliance
page,
because
I
feel
like
that,
may
confuse
the
context
of
what
it's
the
license.
Compliance
pages
force
to
me.
Why
don't
we
just?
What
have
we
add
a
new
section
in
the
nav,
so
we
have
dependencies.
E
We
have
license
compliance,
we
add
a
new
section,
but
that
page,
because
these
are
built
in
reasonable
view,
components
that
new
page
can
then
just
have
the
license
list,
not
the
policies,
because
we're
not
worried
about
like
the
policy
tab
in
that
context,
and
then
the
second
tab
would
be
whatever
we
have
from
dependency.
This
so
like
it's
essentially
a
new
view
making
use
of
the
tables
that
we
already
have,
at
least
for
version
one
and
see
kind
of
like
because
I'm
concerned
about
adding
just
new
tabs
arbitrarily
to
license
compliance
page.
E
A
However,
that
option
was-
and
if
that
was
a
popular
option,
I
think
maybe
have
like
you
know
how
there's
the
new
thing
that
pops
up
this
is
like
word:
removing
a
lot
of
stuff
in
13
I
know:
I,
go
read
this
blog
post,
if
that's
targetable,
and
they
interact
with
that
option
that
we
gave
them
I
want
to
see
if
we
could
have
like
that,
pop-up
happen,
like
oh,
hey,
you're,
checking
out
our
new
page.
It's
you
know
in
its
first
iteration.
Could
you
give
us
some
some
feedback
about
it
except
I?
A
A
A
B
A
choke
once
so
in
the
sense
that
deduping
I
believe
currently
is
based
on
name
I,
don't
know.
If
we
do,
we
can't
do
version
and
license
at
the
moment
cuz
we
don't
collect
the
license,
the
version
in
the
license
list
or
in
the
license
report,
there's
an
open
budget
for
that
that
is
solvable
and
so
I
believe.
When
we
merge
the
dependency
list
report
with
the
license
list
report,
we
do
it
based
on
dependency
name
alone.
B
A
B
So
I
think
if
we
could
add
version
to
the
license
report
that
will
help
with
some
of
that
dee
doop
you
mentioned,
and
I'm
just
looking
at
the
URL
that
philippe
sent
the
data
that
did
license
or
the
dependency
list
has
a
name
package
manager,
version,
location
and
licenses.
So
it
does
not
have
the
classification,
so
the
policy
associated
with
the
license
and
then
the
data
that
the
license
list
has
that
dependency
list
has
that's
not
in
the
license
list
is
the
location
and
version
number.
B
So
we
could
probably
at
least
make
sure
that
we're
producing
the
same
data
from
both
reports
and
then
that
way,
some
of
the
DQ
ping
issues
would
be
resolved.
I
think
in
the
back
of
the
Leafs
head,
he's
saying:
damn
it
mo
just
attached
the
license
info
to
the
existing
common
report
structure,
and
then
we
don't
have
a
problem
here
and
most
slowly
catching
up
and
starting
to
understand.
Why
now
so.
A
One
item
we
have
in
the
backlog,
which
I'm
wondering
should
happen
in
parallel
to
this-
was
the
thought
that
we
enhance
our
current
dependency
module
when
it
does
the
scan
to
also
do
the
license.
Work,
I
believe.
If
we
identified
two
benefits
to
this
one,
we
would
be
dependent
on
open
source
projects
which
we've
had
interesting
experiences
with
related
to
like
trying
to
get
them
all
to
work.
Offline,
Thank,
You
mo,
but
like
so
would
possibly
starting
to
do
that
for
our
top
languages.
Put
us
in
a
better
position.
A
B
I
think
it
is
related.
I
just
don't
know
that
the
timeline
to
make
that
happen.
So
if
we
were
so
the
missing
piece
of
information
that
I
think
we're
missing
in
the
existing
report
structure
that
we're
producing
from
the
dependency
analyzers
is
just
the
SPD
X
identifier,
and
if
we
could
include
the
SPD
X
identifier
in
that
report,
then
at
least
when
we,
you
know
aggregate
the
dependencies.
We
know
here's
the
software
licenses
associate
with
that
dependency.
B
The
other
thing
is
I'd
like
to
get
the
URLs
for
each
of
the
known
software
licenses
in
the
software
licenses
table
in
the
database.
That
way,
we
don't
have
to
produce
that
URL
as
well
in
the
report,
which
is
just
like
a
duplication
of
effort.
It's
like
it
reduces
the
amount
of
work
that
needs
to
be
done
in
the
analyzers,
so
like
at
a
minimum.
I'd
say
like
if
we
could
just
get
this
SPD
X
identifier
into
the
report,
then
that
moves
us
for
quite
a
bit.
B
Some
of
the
that
you
know,
dependency
analyzer
report
would
have
main
package
manager
version,
location
and
the
SPD
X
licenses
or
identifiers
x'.
Then,
if
we
were
to
add
the
software
license
URL
to
the
software
licenses
table,
we
could
then
display
everything,
that's
necessary
in
both
the
license
list.
B
Ui,
as
well
as
a
dependency,
do
I,
that's
related
to
a
software
license
such
as
the
name
SPD
X
identifier
in
the
URL
to
go
visit
that,
and
there
was
one
other
thing:
oh
and
the
policy
associated,
so
the
classification
for
that
particular
license
so
yeah
that
would
work
I
just
don't
know
how
quickly
that
would
be
another
approaches.
We
could
add
the
version
to
the
existing
license
list
report,
which
I
think
would
be
faster.
B
But
again
it's
I
know.
There's
like
I,
don't
know,
I,
don't
know
what
the
priority
is
on
that
right.
So
in
one
case
like,
if
you
add
version
to
the
license
list
report
now,
you'd
get
that
for
all
the
different
project.
Types
mm-hmm
and
that'd
be
available
sooner.
If
we
added
the
license
the
SPD
X
identifier
to
the
dependency
analyzer,
we
probably
have
to
go
through
each
analyzer
one
at
a
time,
which
is
a
good
thing
going
forward
long
term.
B
A
A
B
Is
there
a
way
to
like
use
the
license
management
analyzer
as
it
is
today,
but
have
it
feed
pieces
of
the
report
that
can
be
aggregated
into
the
full
report,
or
does
it
have
does
that
code?
I,
guess
what
I'm
saying
is
like
we
have
to
go
through
the
dependency
analyzers
and
add
the
licenses
there,
or
can
we
do
it
from
a
separate
analyzer.
B
Because
if
we
kid
what
I'm
thinking
about
doing
this
in
pieces
like
if
I
could
get
the
license
management
analyzer
to
produce
JSON
that
could
be
utilized
or
like
merge
into
the
common
structure
that
just
has
the
missing
pieces,
then
at
least
we
have
a
starting
point
for
getting
the
missing
information
into
the
common
reports
structure.
On.
C
A
A
batshit
question
right,
like
our
feature
flags,
are
not
what
I
think
of
its
feature
of
legs,
but
if
we
were
to,
let's
say
add
that
as
PDX
identifier,
when
we
scan
for
the
five
scanners
for
dependencies
and
we
added
a
feature
flag,
but
we
left
it
off
by
default,
we
just
like
mention
it
in
a
blog
post,
like
hey
we're
looking
at
this,
it's
not
for
all
languages.
You
know
we're
starting
with
this
one
language,
so
it's
only
gonna
work
for
this.
One
language
today
feel
free
to
turn
it
on.
If,
if
for
funsies.
A
And
so
like
we
could,
we
could
literally
just
start
with
one
one
internally
that
we're
using,
and
so
we
add
it
for
the
one
we
see
how
it
looks.
We
see
what
bugs
we
run
into.
If
people
want
to
turn
it
on,
they
can,
and
then
we
just
kind
of
keep.
Would
that
be
a
reasonable
way
to
keep
inching
forward.
I
would.
A
A
B
So
you
do
one
at
a
time
you
insert
them.
You
know
pieces
of
data.
In
this
case
we
just
said
the
SPD
X
identifier,
for
the
license.
Let's
say
just
for
one
scanner
type:
that
data
would
be
in
the
report.
It
may
be
dormant
for
a
while
before
it's
fully
utilizing
the
rails
app.
Maybe
what
we
do
is
we
it's
like
I'm
just
going
to
pick
one
which
was
the
top
year
list
there
maven.
So
let's
say
for
maven
we
added
the
SPD
X
identifier
for
each
dependency,
that's
detected
in
the
common
report
format.
B
Then
we
go
to
the
rails
app
and
let's
say
we
start
parsing
that
lice,
you
know
the
actual
SPD
X
identifier,
and
we
include
it
as
part
of
that
intermediate
representation.
We
have
in
the
objects
and
then
we
find
a
way
to
shim
in
that
data
into
the
existing
license
compliance
JSON.
So
this
should
not
affect
front-end
at
all.
We'd
be
producing
the
same
JSON,
but
at
least
now
we've
like
hit
all
the
layers.
We've
made
sure
that
we
can
get
the
license
into
the
analyzer.
We
can
parse
the
license
out
of
the
report.
B
We
can
use
that
license
information
to
provide
the
data
necessary
for
the
existing
license,
compliance
page,
but
just
from
one
analyzer,
and
so
from
the
customer
perspective.
It
should
have
no
impact,
and
then
we
can
slowly
do
this
for
one
the
next
analyzer
next
analyzer
until
eventually
the
data
that
we
had
from
the
license
compliance
report
is
just
there,
but
not
necessary
Philippe.
What
do
you
think
this
is
a
crazy
idea?
Am
I
off
base
on
this?
What
am
ia
missing.
B
That
sorry,
okay,
the
idea
that
I
was
proposing
was
instead
of
feeling
like
a
wholesale
replacement.
We
do
piece
by
piece,
so
we
start
with
the
highest
priority
and
this
example:
I
provided
Java
maven
as
the
example,
and
so
the
Cole
is
to
be
able
to
produce
a
list
of
software
licenses
associated
with
each
dependency
and
put
that
into
the
existing
dependency
scanning
report.
And
the
proposal
was
we
start
with
gymnasium
maven
and
we
add
the
SPD
X
identifier
into
the
report
for
each
dependency
as
just
a
starting
point.
B
So
now
that
analyzer
is
now
producing
a
new
report.
It's
including
the
SPD
X
identifiers,
the
license
info
for
each
dependency
and
the
next
layer
would
be
going
to
the
rebels
app
and
actually
starting
to
parse
out
that
new
piece
of
data
from
that
report
type
and
and
then
trying
to
get
that
new
piece
of
data.
Instead
of
from
the
old
license
report
from
the
dependency
report,
particularly
for
Java
maven
project.
B
So
it
makes
the
code
a
little
bit
ugly
as
an
intermediate
state,
but
at
least
we're
getting
that
data
from
the
dependency
report,
rather
than
license
this
report
specifically
for
Java
maven,
and
then
we
can
make
sure
that
we
can
surface
the
same
JSON
that
we're
serving
today
in
the
license
compliance
page
but
sourcing.
Just
the
Java
maven
project
types
from
the
dependency
list
report,
rather
than
from
the
license
list
report.
B
B
The
same
is
just
we're
just
shifting
where
the
data
comes
from
and
where
it's
produced
the
part
that
I
don't
know
is
like,
if
it's
better
to
update
gymnasium
maven
and
also
do
the
license
detection
there
or
if
it
should
be
in
a
separate
analyzer,
and
this
is
the
part
that
I
think
you
could
fill
me
in
with
the
goal.
There's
it's.
C
B
I'm
hoping
I
can
just
add,
like
one
field
or
called
either
licenses,
which
is
an
array
or
licenses
which
is
a
string.
That
is
an
SPD
X
expression,
because
with
different
SP
DX
expressions
allow
for
license
a
or
license
B
license
a
and
license
B
license
a
with
exception,
which
is
hard
to
represent
today
with
the
arrays.
So
this
I.
That
would
be
what
I
would
propose
this
to
use.
A
Like
right
now,
I'm
looking
at
the
dependency
page,
we've
got
component,
which
includes
version
I,
don't
know
when
that
populates
or
where
populates
from
but
we've
got
a
version.
It
says
what
package
manager
it's
coming
from.
It
has
a
location,
it
has
the
file,
it
has
a
thing
that
says
license,
but
there's
no
license
displayed.
B
A
A
Research
project
talk
to
Olivia
and
see
if
I
can
get
two
people
assigned
for
five
days.
You
know
one
week
and
you
know
like
I,
think
13,
because
in
13
1
we
should
discuss
like
what
exactly
do
we
want
to
test
out
which
analyzer
do
we
want
to
test
out
adding
licenses
and
the
project
just
being
like?
How
hard
is
it
to
add,
license
data
so
to
fetch
and
record
properly
license
data
when
I'm
doing
a
dependency
scan
and
see
what.
B
C
B
B
B
A
A
B
A
A
B
A
B
Know
so
I'd
like
to
get
through
all
the
project
types,
if
that's
possible,
because
then
I
think
I
could
use
that
knowledge
or
sorry
I,
keep
saying
I,
but
I
think
we
could
then
use
that
knowledge
to
add
license
detection
for
the
other
project
types
to
the
dependency
analyzers
and
maybe
also
use
that
knowledge
for
doing
the
like
filling
in
the
missing
pieces
for
the
project
types
and
dependencies.
So
hopefully,
I
can
at
least
finish
that
and
then
say
goodbye
to
my
beloved
Ruby.
B
A
Through
that
was
the
major
concern,
but
if
nobody
has
any
others,
that's
the
major
concerns
and
it
sounds
like
the
next
one
is
to
do
a
proof
of
concept
for
one
of
our
crazy
ideas,
which
I
think
is,
let's
see
how
far
we
get.
If
we
just
take
one
dependency
scanning,
analyzer,
add
some
data
where
and
then.
If
that
works
out,
okay,
where
can
we
expose
it
being
stepped
to
and.
B
Think
then,
that
would
give
us
enough
knowledge
like
so
that
one
experiment
with
one
analyzer
gives
us
enough
knowledge
to
find
out
whether
this
is
a
reasonable
path
to
move
forward
or
if
we
need
to
rethink
without
spending
too
much
time
designing,
and
you
know
analyzing
before
we
actually
get
working
softer
done
now.
Philippe
do
we
have
your
do?
I
have
your
blessing
on
this.
Like
am
I
driving
you
crazy
with
my
nonsense,
or
is
this
falling
in
line
with
the
Philippe
master
plan.
C
To
be
honest,
it's
been
my
six
hours
today.
Oh
right,
it
seems
to
be
a
good
idea
to
me
just
we
need
to
put
you
put
that
in
an
issue
so
that
I
can
give
someone
some
second
thoughts,
but
I
don't
see
any
pitfalls
like
this
I
will
be
happy,
as
I
said,
on
the
chart
to
pair
with
you
do
some
pronunciation,
since
we
are
almost
on
the
same
time.
Zone
and
I
don't
want
more
some
reason
so
I
have
some
availability
with
the
abbe
to
do
some
more
go
as
well.
C
C
A
Think
it
would
to
be
13
to
because
we're
trying
to
finish
up
okay
work
right,
but
in
13
1
we
groom
the
plan
13
to
execute
the
crazy
plan.
I
think
I
want
to
have
two
items
going
in
parallel.
One
is
how
do
we
add
license
data
to
the
dependency
scan
and
I?
Think
I
want
to
make
a
separate
item.
That's
hey,
front-end
team.
What
information
do
we
have
that
we're
not
exposing
today
and
what
is
some
cheap
information?
We
could
expose
behind
a
feature
flag
today,
just
to
see
how
users
respond
to
it.