►
From YouTube: Dogfooding License Approval Policies
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
And
all
right
so
yeah,
thanks
for
that,
sharing
that
Sarah
that
I'm
glad
to
hear
the
excitement
about
it.
That's
great
news
and
yeah
I'm
happy
to
answer
your
questions
as
best
I
can
and
talk
through
it.
The
feature
is
not
fully
developed
yet
so
I
don't
have
like
a
fully
working
demo
we're.
Actually
it's
going
to
be
very
close
for
the
15.9
release
like
we're
going
to
be
getting
it
in
just
before
the
release
cut
off
date,
most
likely.
A
So
it's
a
little
bit
difficult
to
show
at
the
moment,
but
probably
in
three
weeks
time
it'll
be
available
in
the
product
and
you
can
get
your
hands
on
it
and
actually
play
with
it.
In
the
meantime,
I
can
show
you
mocks
and
I
can
kind
of
talk
through
what
to
expect,
which
should
give
you
a
pretty
good
sense
for
what
the
experience
will
be
like
as
soon
as
we
release
it.
B
A
A
It
would
be
up
to
you,
as
a
member
of
the
legal
team,
to
define
those
policies,
so
you
get
to
decide
what
requires
an
approval
and
what
does
not
awesome
so
I
can
show
you
Dominic
is
at
least
somewhat
familiar
with
this
I
can
show
you
the
workflow
for
our
security
policies
today
and
it's
very
very
going
to
be
very,
very
similar.
A
So
just
for
an
initial
demo
and
for
some
initial
understanding
here,
I've
got
this
simple
notes.
Demo.
This
is
a
potential
development
project
right.
It's
a
python
project
where
developers
are
writing
code
and
actually
we
have
this
sort
of
functionality
in
gitlab.
Today
you
go
and
manage
it
under
settings
and
merge
requests,
but
one
of
the
challenges
here
you
know
we
have
this
license
check
functionality.
One
of
the
challenges
is
that
maintainers
can
go
in
and
they
can
edit
this
they
can
delete
it.
A
A
So
if
I
come
up
here
to
edit
policy
project
you'll
see
this
project
is
linked,
simple
notes,
demos
linked
to
a
different
project,
called
simple
notes:
demo,
Dash
security
policy
project
and,
if
I
take
just
a
minute
and
I
come
up
into
this
subgroup
level,
and
here
I've
got
my
policy
project
in
here.
There's
it's
a
very
Spartan
project.
I
mean
it's
empty
right,
like
you've
got
just
this
policy.yaml
file,
and
this
is
what
defines
the
policies
for
any
project
that
is
linked
to
the
security
policy
project.
A
So
all
of
that
complexity,
what
it
does-
and
it
may
be
better
showed
in
this
diagram
that
we
have
in
our
documentation.
A
So
we
support
like
a
one-to-many
linking
you
can
also
link
these
up
at
the
group
or
the
subgroup
level
for
ease
of
management
across
projects,
but
what
this
does
is
it
allows
you
to
have
a
separate
set
of
maintainers
for
your
security
and
compliance
policies
compared
to
who's
a
developer
and
maintainer
for
your
development
project,
if
that
makes
sense,
okay,
so
that's
sort
of
just
just
like
the
foundational
background
that
is
important
to
understand
coming
into
this
as
far
as
actually
managing
the
policies
themselves,
you
don't
have
to
know
all
of
this
yaml
in
order
to
do
that,
because
we've
provided
a
nice
rules,
editor
like
a
visual
workflow
to
help
guide
you
through
the
process
of
generating
that
yaml.
A
So
if
I
come
in
to
create
a
new
policy
and
we'll
create
a
scan
result,
policy
that'll
be
the
kind
that
you'll
use
for
your
license
policies
right
now,
you
can
filter
off,
of
which
scanners
you
want
and
Define
like
your
criteria.
Here,
it's
going
to
be
very
similar,
we're
just
going
to
be
adding
an
extra
drop
down
in
front
of
this,
where
you
can
pick
either
a
security
scanning
or
license
scanning,
and
if
you
pick
license
scanning
this
is
where
I
have
to
come
over
to
the
Mocs.
A
Then
it
gives
you
all
of
this
license
criteria,
so
you
can
either
pick
to
require
approval
when
specific
licenses
are
found
or
you
can
change
this
matching
drop
down.
The
other
option
here
is
accept,
so
you
can
say,
finds
any
license,
except
for
licenses
a
b
c
and
d,
so
you
can
either
go
on
a
you
know
an
allow
list
or
a
denial
list.
B
So
I
was
thinking
we
might
have
to
create
an
individual
rule
for
every
single
type,
but
we
can
pretty
much
say
if
it's
one
of
these,
like
you
know
what
we
consider
are
accessible
licenses,
it
doesn't
need
approver,
but
if
it's
something
that's
on
our
either,
if
it's
you
know
a
defined
list
of
ones
that
we've
identified
as
unacceptable
or
potentially
unacceptable,
we
would
push
that
to
require
an
approver
and
it's
not
any
of
those
it
would
fit.
We
could
still
have
another
rule
to
push
everything
else
to
approve
her
as
well.
That's.
A
That's
exactly
right,
yep!
So
here's
here's
the
ux
mock
of
these
drop
downs
right,
so
you
can
pick
either
matching
or
accept,
and
then
you
go
through
and
pick
individual
licenses
and
you're
right.
There
are
actually
more
than
like
500
I
think
that
we've
got
listed
in
our
database
plus
others
that
you
know
sometimes
don't
match
the
patterns
that
we've
got
in
our
database
that
you
would
have
to
enter
manually
in
the
yaml.
B
Well,
that's
really
good!
That's
it!
It's
kind
of
more
what
I
was
thinking
from
looking
at
those
ux
flows
that
it's
not
like
that.
There's
no
kind
of
judgment
in
us
saying
you
know
hey.
You
should
put
your
code
under
MIT
because
it's
you
know
very
permissive.
What
not
it's
more
just
saying:
hey
we're
the
legal
team.
If
this
license
comes
into
our
project,
we
want
to
know
let
us
approve,
it
seems
a
lot
yeah.
That's
that's
the
happy
path
here
really.
A
A
That's
generally
the
setup
workflow
once
you
do
this
and
you
get
it
right.
You'll
see.
It'll
Auto
generate
that
yaml
on
the
side.
So
let
me
flip
back
to
like
the
live.
You
know
vulnerability
management,
one.
So
you
can
see
as
I
type
it's
it's
updating
the
CML.
If
you
prefer
to
edit
it
in
yaml
mode.
You
can
toggle
that
up
top
here.
So
you
know,
if
there's
for
some
reason,
a
license.
That's
not
listed
in
our
drop
down.
A
You
know
you
can
always
add
that
custom,
but
all
of
this
ends
up
generating
a
merge
request
back
into
that
other
linked
security
policy
project
and
then,
of
course,
that
merge
request
itself
can
go
through
a
set
of
approvals.
If
you
would
like
so
that
no
one
person
can
unilaterally,
you
know,
change
the
approval
criteria,
so
you
could,
you
know,
set
up
your
security
policy
project
to
require
two
people
to
approve
any
changes
to
policies.
There
is
typically
the
recommended
path.
You
know
that
way.
B
B
They
could
approve
attention
to
policy,
so
say
I'm,
just
saying
of
anyone
who's
in
this
security
policy
area
or
security
compliance
area,
yeah.
A
Yeah,
that's
that's
right.
Anyone
in
this
security
policy
group
could
give
their
approval,
but
it
would
require
two
people,
so
you
would
have
to
have
two
eyes
on
it
and
you
could
also
set
up
like
a
code
owner
well
code
owners
wouldn't
work
because
it's
all
in
one
file,
just
thinking
creatively
here-
I
guess:
yeah,
that's
true,
so
the
security
team
yeah
that
that
is
true,
I
think
some
of
this
soon
I
think
some
of
this
will
eventually
get
addressed
on
our
roadmap.
But
yes,
you're
right.
A
The
the
security
team
potentially
could
approve
your
changes,
but
it
would
have
to
go
through
another
person.
You
know
so
you
could
set
it
up
so
that
you
know
permissions
wise
and
it
at
least
lowers
the
surface
that
you
have
to
monitor,
because
you
only
have
a
few
people
in
here,
and
you
only
have
one
project
that
you
need
to
monitor.
C
B
Or
even
like,
is
there
a
Fail-Safe
workaround
in
just
having
some
sort
of
notification
get
sent
out
whenever
a
policy
gets
changed
or
edited
and
somewhere
deleted?
Just
there's
some
thing
that
alerts
us
to.
Let
us
know
that
there
has
been
a
change,
so
we
can
go
in
and
check,
say,
hey,
oh,
this
is
fine.
B
A
Yeah
there's
a
trail
in
a
few
places,
so
right
because
it's
a
git
repository,
you
have
all
of
your
comments
and
your
history
so
that
you
know
automatically
you
get
that
like
I
can
come
in
here
and
I
can
see
here.
All
the
changes
that
I've
made
to
this
project
and
I
can
click
on
any
of
these
and
see
like
who's
approved
it.
A
But
then
you
also
have
your
audit
log,
which
this
doesn't
really
apply
because
in
my
case
you
know
this
doesn't
apply
because
I've
just
been
self-approving
and
merging
things
in,
but
you
would
be
able
to
see
like
if
somebody
changed
the
approval
rules,
you
would
be
able
to
see
that
here
we
also
have
our
streaming
audit
events
and
I
think
we
actually
added
in
support
for
git
commits
as
part
of
that.
A
So
if
you
have
a
place
to
stream
those
out
somewhere,
you
could
monitor
that
if
you
wanted
to
anyway,
there
are
several
ways
of
auditing
this,
depending
on
how
you
want
to
do
it.
We
also
have
the
compliance
report,
which
flags
things
that
haven't
had
an
adequate
number
of
approvers,
but
at
a
bare
minimum.
It's
all
logged
there
in
that
git
history.
That's
probably
your
primary
source
of
audit
information,
no.
B
That's
pretty
helpful
for
the
most
part,
I,
don't
expect,
there's
no
real
reason,
especially
with
that
second
site,
there's
still
another
chance
to
catch
it.
If
someone
just
does
something
thinking
it's
having
a
much
smaller
impact
than
what
it's
actually
going
to
have,
so
it's
something
I'll,
just
I'll
flag,
just
on
our
side,
just
we
have
you
know.
Sometimes
they
get
through,
but
at
least
we
have
it's
good
to
know
that
we
have
that
auditing
function
there
to
kind
of
go
back
and
see.
B
B
A
B
A
B
A
But
like
I
said,
if
there
are
licenses-
and
there
are
some
licenses
that
are
not
included-
you
can
just
add
those
in
the
yaml
directly.
If
that
makes
sense,.
B
So
for
adding
them,
what
would
that
look
like
it's
I
saw
you.
You
had
the
editor
open
there
for
adding
it
in
yellow
bunting
from
the
legal
perspective.
If
we're
trying
to
add
it,
is
it
like
it's
like
a
we're
looking
for,
supposedly
identifier
from
spdx
or
what
the
equivalent
of
this
so
like
the
the
name
of
the
licenses
that
we've
been
putting
in
yeah.
A
So
here,
where
it
says
license
is
allowed
right
now
it's
in
a
dra,
because
it's
just
catching
everything
and
this
it's
a
little
bit
hard
to
bridge
this
gap
between
like
mock-up
and
what
we've
got
in
the
product
so
bear
with
me.
But
if
I
come
back
in
here
and
go
to
edit
one
of
these
policies,
this
would
basically
just
be
foreign.
A
Right
so
you
know
just
like
it
adds
it
here
in
additional
dashes
like
instead
of
severities.
Suppose
this
is
your.
These
are
your
licenses
underscore
allowed.
I
think
is
the
key
that
we
went
off
of
so
you
would
just
add
it
here.
Like
my
custom
license,
you
know
gitlab
ee
license
or
what?
What
not
you
would
just
add
those
like
that
as
text.
B
Cool
and
if
there
is
no
license
file
in
a
library
how
to
react
or
how
we
come
across
that
scenario,
yet.
B
B
Cool
that
gives
us
actually
quite
a
lot
of
it's
a
lot
more
customizable
than
I
I
was
thinking.
Obviously,
like
far
more
granular
I
was
having
to
input
everything
having
to
try
and
keep
that
list
up
to
date
in
the
long
term,
but
it's
cool
yeah.
It's
designed
very
well
that
we
don't
have
to
worry
about
those
kind
of
considerations.
Long
term,
you
mentioned
the
current
operation
of
the
license.
Compliance
tool-
that's
already
in
place
that
is
that
can
be
circumvented
by
maintainers.
Was
that
what
you're
saying.
B
A
Yeah,
the
the
new
tool
captures
several
use
cases,
so
we
also
have
the
ability
now
to
do
that
matching
or
excludes
which
is
new,
whereas
before
we
could
only
denied
matching
licenses,
so
we
didn't
have
that
except
you
know
that
accept
functionality
and
then
the
other
big
thing
that
we're
rolling
out
is
just
improved
accuracy.
A
So
we
have
you
know
our
current
engine
only
detects
a
small
handful
of
licenses
I
think
we
only
detect
like
12
different
types
of
licenses,
and
even
then,
we've
had
reports
of
all
kinds
of
inaccuracies
related
to
our
license.
Detection,
that
you
know
we
haven't
been
able
to
properly
address,
and
so
just
for
your
understanding,
we're
actually
redoing
the
way
that
we
do
the
license
scanning
entirely.
A
Re-Architecting
it
and
I'll
spare
you
some
of
the
details
of
this
I'll
try
to
keep
it
pretty
high
level,
but
essentially
just
by
running
dependency
and
container
scanning,
actually
just
dependency
scanning
to
start
with,
and
that
will
be
a
requirement.
So
you
know
you
will
have
to
have
dependency
scanning
running
in
the
Repository,
but
that's
going
to
generate
just
a
list
of
the
dependencies
that
exist
in
the
project.
We
won't
attempt
to
do
any
license
scanning
down
here
in
the
CI
pipeline.
A
Instead,
we'll
just
report
up
a
list
of
dependencies,
those
are
going
to
be
stored
in
our
backend
database
and
what
we've
done
is
we've
created
a
bunch
of
workflows
in
gcp
and
Iris
was
involved
in
the
legal
side
of
this,
but
we're
querying
out
to
the
apis
of
all
the
various
Upstream
Registries
and
we're
pulling
the
license
data
out
of
the
package
metadata
or
in
some
cases
there
is
no
API
to
call,
and
so
we're
actually
analyzing
the
license
files
themselves.
A
It
just
kind
of
depends
on
the
registry,
but
we're
compiling
all
of
that
into
a
set
of
CSV
files
that
you
know
contains
that
license
data
and
we're
bringing
that
into
our
database.
So
we
have
that
information.
For
you
know
the
vast
vast
majority
of
Open
Source
components
that
are
out
there
across
all
of
the
major
Registries,
and
then
we
use
that
information
in
this
license
match
job
to
compare
it
to
the
dependencies
that
exist
in
your
project
so
that
we
can
Surface
up
those
licenses.
A
So
it
is
a
little
bit
different
because
we're
not
extracting
the
metadata
as
part
of
the
CI
pipeline,
we're
relying
on
that
centralized
database,
but
that's
allowing
us
to
be
far
more
accurate
because
the
license
data
isn't
always
carried
down
and
it's
not
always
carried
down
accurately
into
the
package.
That's
brought
down
into
your
local
local,
build
environment.
B
Oh,
that's
awesome,
yeah
that
I
can
see
why
she's
been
like
talking
to
me
about
it
did
sound
very
exciting,
so
yeah
I
think.
From
my
perspective,
it
sounds
like
we're.
It's
a
yeah,
far
more
accurate
model
of
what
we're
using
I
know
because
we've
been
as
part
of
some
a
project
we
were
working
on
recently
with
like
product
development
teams.
B
We
pulled
in
a
step
for
reviewing
licensing
quite
manually
and
it's
something
we'll
you
know
we'll
still
continue
to
work
with
the
product
team
as
they
have
new
dependencies
come
into
as
part
of
the
product
development
flow,
but
I
can
see
that's
having
like
a
massive
impact
on
that
project
long
term
as
well.
So
it's
yeah,
it's
absolute
brilliant!
You
mentioned
it's
gonna,
be
close
to
the
the
wire
to
get
it
in
for
15.9
I
assume.
Documentation.
Probably,
then,
is
still
a
work
in
progress
right,
correct.
A
Honestly,
we
are
doing
everything
we
can
just
to
get
it
out
the
door,
so
we've
had
other
customers
ask
to
be
like
beta
testers
of
this
as
well,
and
it's
not
something
that
we
can
easily
beta
test.
I
think
everyone
is
just
going
to
have
to
wait
until
we
officially
release
it.
It's
just
going
to
come
out
all
at
once.
Unfortunately,
but
that's.
B
Fine,
as
we're
out
of
here
I'll,
see
than
anything
else
but
I'm
trying
to
consider
anything
else
on
where
they're
going
to
15
nine,
just
it's
going
to
land
on
us
quickly,
so
more
I'm,
just
trying
to
think
there's
any
need
for
us
to
from
the
liability
and
the
same
result.
I
think
we're
we're
fine
on
that
now.
I
I
think
I
think
we're
good
I
am
like
I
assume
the
defaults
when
it
when
it
goes
live
is
that
it
will
have
zero
rules
anyway
in
it
right.
B
B
Of
default
setup
or
anything
that
could
be
the
only
other
ledge
case
that
might
catch
us
out,
but
yeah
so
far,
that
sounds
actually
that's
yeah,
exactly
all
the
information
I
needed
to
know.
For
now
it
sounds
like
it's.
You
know
exactly
what
we've
kind
of
dreamed
of
at
various
points.
Over
the
last
year
we
talked
about
having
a
nice
licensing
solution,
as
opposed
to
a
lot
of.
It
is
obviously
very
manual,
as
you're
probably
used
to
expect.
A
A
Work,
probably
the
other
big
question
dominant
for
you
is:
where
are
we
at
with
rolling
out
dependency
scanning
across
the
organization?
And
how
can
we
make
sure
that
that's
enabled?
Because
that
is
a
requirement
without
dependency
scanning?
We
can't
get
the
license
data.
C
All
of
our
main
projects
have
it
see
all
the
individual
components
that
I
have
to
look
in
our
inventory
and
see
which
one
have
been
flagged,
but
most
is
already
done,
so
it
wouldn't
be
a
huge
list
to
actually
only
add
it.
Yeah,
especially
like
it
doesn't
fail
the
job
or
anything.
It's
just
just
to
get
the
data
in
yeah.
C
C
C
A
Got
it
okay,
that
sounds
good.
Just
a
few
other
things
to
note
about
this
as
well.
Is
that
it
does
the
license.
Data
does
get
driven
off
of
that
Cyclone
DX
file.
So
if
there
is
a
project
with
a
language
or
something
that
we
don't
support,
I
think
on
on
forgetting
the
name
of
the
project
for
a
moment,
but
I
know
we
have
at
least
one
project
where
dependency
scanning
doesn't
find
the
dependencies.
A
A
So
that's
just
something
to
be
aware
of,
and
then
yeah.
Otherwise,
we're
really
looking
forward
to
Rolling
this
out,
it'd
be
great.
If
we
can
start
dog
fooding
it
right
away
and
would
love
to
get
any
feedback
that
you
have
to
share
once
you
actually
start
using
it.
B
Yeah,
oh
Daphne,
we're
like
setting
from
the
ux
mock-ups
that
I've
seen
on
one
of
the
other
issues.
You
shared
what
we've
kind
of
gone
through
there.
It
looks
a
lot
more
logical
than
I.
Think
initial.
In
the
background
my
worry
was.
Maybe
there
was
some
sort
of
like
subjective
element
about
saying
hey.
This
is
a
good
license
to
use,
or
this
isn't
a
good
license
so,
but
the
kind
of
logic
flows
we
have
it
now.
It's
you
know
all
those
fears,
gonna
go
away
and
it
like
the
other
words,
was
like
maintenance
of
it.
B
Admin
side
is
completely
taken
care
of
because
the
list
is
updating
dynamically.
So
for
the
most
part,
that's
me
sorted
for
now.
I'll,
take
it
away
and
have
a
think
about
it.
If
anything
else,
crops
up
I'll
pop
into
the
issue
and
also
I'll
talk
to
Iris
next
week
to
bring
her
up
to
speed
as
well.
So
we
may
have
one
or
two
follow-ons,
but
in
the
meantime
yeah
in
terms
of
like,
if
there's
anything
else,
you
need
from
legal
yeah.
B
C
B
B
I
think
within
legal
products
we
kind
of
come
there,
yeah
that's
within
legal
practice,
but
three
or
four
of
us
who
handle
licensing
side.
The
other
side
are
kind
of
more
focused
on
marketing,
so
I
can
give
you
the
three
names.
If
we
can
get
like
that
group
spilled
up,
we
can
rely
on
something
like
that
and.
C
B
B
C
It
will
handle
that.
A
Yeah
I
did
want
to
highlight
Sarah
just
that
we
are
calling
the
licenses
out
as
denied
or
allowed.
You
know
this
is
all
based
off
of
the
policy
that
you've
defined,
but
this
is
what
it
looks
like
in
the
merge
request.
Just
so
you
can
get
a
view
into
that.
So
in
this
case
we're
introducing
a
Paul
a
license.
That's
not
allowed
it's
going
to
show
up
here
as
denied
and
then
the
merge
will
be
blocked
and
it'll
be
pending.
A
A
A
All
right!
Well,
thanks.
Everyone
appreciate
the
time
today,
look
forward
to
Rolling
this
out
at
the
end
of
the
month,.