►
From YouTube: UX Showcase: License Compliance
Description
0:00 - 06:29 A brief history: proprietary software, free software movement, and open source
06:29 - 9:57 What are software licenses and what makes code open source?
9:57 - 15:25 Current UX review and next steps
A
A
Let's
start
with
the
brief
history
about
different
perspectives
and
the
evolution
of
open-source
software
in
June
1975,
a
group
of
computer
and
Technology
enthusiasts,
or
at
the
Hyatt
and
Palo
Alto
for
a
demo
of
the
Altair
computer,
with
a
new
version
of
basic
program
which
was
created
by
Bill
Gates
and
Paul
Allen.
One
of
the
attendees
made
copies
of
the
punch
tape,
which
was
a
paper
roll
storage.
At
the
time
for
the
program.
A
A
After
hearing
about
the
copies
and
distribution,
a
very
young,
Bill
Gates,
who
again
wrote
the
program
with
with
others,
wrote
an
open
letter
to
hobbyists
to
share
his
perspective
about
that
which
was
also
published
in
the
later
monthly
letter
of
the
homebrew
Computer
Club,
and
he
wasn't
terribly
happy
to
say
the
least.
So
the
audience
of
this
letter,
the
hobbyists
that
he's
writing
really
you
have
to
understand
their
perspective-
is
hacker
ethos
among
them
of
software
should
be
free
period.
A
A
If
you're
really
interested,
there's
a
interesting
backstory
around
that
for
another
day,
whether
or
not
it's
a
bit
debatable
about
that
that
some
it
highlighted
that
most
users
never
bought
the
program,
noting
that
10%
of
Altair
owners
had
it
without
royalties
stated
that
just
as
hardware
is
paid
for
so
should
software
and
a
question
how
anyone
could
afford
doing
this
work
professionally
for
no
money,
it
asked
people
to
send
payment
for
repayment
as
it
turned
out.
Not
many
did
that.
A
So
if
you
take
aways
and
of
course
it's
easy
in
retrospect
to
look
at
this,
but
one
has
to
wonder
if
the
wide
copying
of
the
program
didn't
help
position
the
company,
as
computer
makers
defaulted
to
this
version
and
and
subsequent
versions
and
kind
of
became,
what
we
know
is
it's
the
default
and
at
the
time.
So
would
this
have
been
the
case
without
the
free
copying
distribution,
so
that
is
the
advancement
of
technology
who
knows,
but
it's
it's
just
a
question
that
this
brings
to
mind.
A
On
the
other
hand,
expecting
payment
for
software
may
have
contributed
to
really
opening
up
a
new
industry,
so
this
this
letter
was
certainly
impression
in
a
lot
of
different
ways,
and
it
just
gives
you
a
glimpse
of
the
different
perspectives
at
the
time.
Surely,
they've
changed
since,
let's
look
at
the
other
perspective
around
that
time,
which
was
the
free
software
movement,
one
of
the
leaders
of
this
movement
is
Richard.
A
Stallman
he's
a
fierce
advocate
for
open
source
free
software,
and
here
a
few
quotes
taken
from
a
1985
manifesto
to
get
and
I
d
of
his
view.
He
says
the
golden
rule
requires
that
if
I
like
a
program,
I
must
share
it
with
other
people
who,
like
it,
software
sellers
want
to
divide
the
users
and
conquer
them,
making
each
user
agree
to
not
to
share
with
others.
When
we
call
software
free,
we
mean
that
it
respects
the
users,
essential
freedoms,
the
freedom
to
run
it
to
study,
to
change
it,
to
redistribute
copies
and
without
changes.
A
Once
canoe
is
written,
everyone
will
be
able
to
obtain
good
system
software
just
like
air,
so
canoe
is
an
operating.
It's
the
open
source
operating
system.
He
was
working
on
at
the
time
and
it's
an
acronym
for
canoe,
not
UNIX,
which
UNIX
was
created
in
Bell
Labs,
so
he
and
a
friend
relevant
to
this
conversation
about
license
compliance.
He
and
a
friend
coined
the
term
copyleft
for
this,
which
is
the
reverse
of
copyright,
meaning
that
everyone
has
permission
to
run
copy,
modify
and
distribute
the
versions.
A
Okay,
so
what
does
this
mean
for
us
today
in
terms
of
Licensing
and
license
compliance
and
well?
First,
let's
just
take
a
look
at
what
is
a
life?
It's
a
permission
to
possess
software
property
in
in
our
license
context.
Of
course,
it's
a
grant
of
authority
to
undertake
an
activity,
and
there
are
obligations
that
come
along
with
this
grant
of
permission.
For
example,
it's
like
a
ticket
to
a
free
event.
A
You
can
accept
the
ticket
which
allows
you
access
it
grants
you
that
permission
to
to
come
to
the
event,
but
the
fine
print
on
the
backside
might
state
that
you're
not
allowed
to
take
pictures,
for
example,
and
if
you
do
you'll
lose
your
ticket.
So
if
someone
sees
you
taking
pictures,
they
could
they
have
the
right
to
take
the
ticket
away
from
you
and
you
can't
be
at
the
event
the
same
with
st.
open-source
software,
it
free
to
use
it
in
alignment
with
the
stated
license
obligations.
A
A
notable
distinction
is
a
license,
isn't
usually
a
contract,
it's
easy
to
get
them
confused,
but
a
contract
is
an
exchange
of
promises.
Consider
that
in
a
contract,
once
you
have
predetermined
predetermine
agreements,
you
cannot
revoke
the
right
up
to
the
other
party.
That
would
be
a
breach
of
contract.
So
it's
just
a
small
distinction
to
be
made
there,
but
it
gets
even
more
nuanced
and
more
on
the
legal
side.
In
some
cases
because
licenses
sort
it
can
become
contracts
and,
for
example,
in
the
case
where
there's
end
user
License
Agreement.
A
So
what
then
exactly
makes
code
open
source
based
on
the
following
guidelines
of
the
open
source
initiative
to
be
considered?
The
following
the
following
must
be
met,
so
I'll
highlight
a
few
of
them.
First,
it's
just
the
free
distribution.
That's
clearly
you're
free
to
use
the
software,
but
the
license
must
be
obliged
by
that.
A
The
third
one
is
derived
work.
This
means
that
it
can't
just
be
like
open-source
readable,
but
it
also
needs
to
allow
for
modifications
the
first.
The
fourth
is
integrity
of
the
author
source
code.
So
this
is
the
ability
to
trace
code
to
specific
authors,
/
modifications,
and
it
must
be
public.
So
we
see
this
facilitators
of
this
as
places
like
github
and
get
lab,
which
has
this
facilitated
and
public
repositories
jumping
to
a
must
not
be
specific
to
a
product.
A
One
has
the
right
to
own
the
program,
but
it
must
not
depend
on
other
specific
products,
for
example
requiring
a
person
to
purchase
proprietary
software
to
then
have
access.
So
these
10
guidelines,
once
these
are
met,
that
the
creator
may
assign
a
license.
Common
ones
are
MIT
Apache
BSD
as
long
as
everything's
aligning
to
these
guidelines.
That
is
indeed
open-source
software
again.
Each
license,
though,
that
you
apply
to
it
has
varying
different
obligations
and
restrictions
that
must
be
met.
A
Looking
at
the
job
to
be
done
for
the
person
accountable
for
compliance,
so
that
could
be
the
legal
department
or
the
compliance
department
for
smaller
companies
developed,
it
may
fall
under
the
development
department,
but
the
problem
the
user
is
solving
is
ensuring
that
company
policies
with
the
license
arm
force,
for
example,
here
at
gate
lab.
We
forbid
the
use
of
GPL
version,
1
2,
3,
OS
L,
for
example,
just
to
name
a
few.
In
this
few.
At
the
project
level,
the
user
may
assign
the
policies
to
related
license.
A
License
scanning
will
provide
results
and
will
soon
match
them
against
the
policies,
so
this
will
bring
attention
to
licenses
that
are
out
of
compliance.
That's
what
we
see
here
on
the
screen.
We
see
ones
that
are
detected
in
project
and
then
at
the
top
of
the
table.
We
see
ones
that
have
pipe
policy
violations.
A
Additionally,
having
a
list
like
this
of
just
simply
ones
that
are
detected
in,
there
is
great
for
auditing
purposes.
For
for
companies
and
organizations
adding
purposes
it
surfaces,
the
licenses
they're
clickable,
to
see
the
obligations
to
so
that
will
be
stated
to
make
sure
that
companies
are
important
of
the
license
obligations
and
also
to
share
it
with
their
customers
as
well,
because
they
have
the
right
for
SAS.
Customers
has
the
right
to
request
that
list.
A
Okay,
so
for
the
user
that
is
responsible
for
compliance,
that
being
the
developer,
the
ones
introducing
licenses
and
dependencies
as
a
new
license
is
committed
or
a
dependency
that
has
a
new
license.
The
results
will
be
shown
once
the
scan
job
is
complete
in
the
pipeline.
In
the
merge
request,
this
will
be
shown
in
the
merge
request
in
cases
that
the
user
committed
and
out
of
compliance
design
a
denied
license
in
accordance
with
a
project's
policies.
The
merge
requests
will
be
disallowed.
A
So
I
want
to
highlight
our
next
steps
on
the
team
based
on
where
our
current
feature
maturity
is
here
are
the
following:
UX
related
problems
that
were
focused
on
the
future.
The
future,
as
I
mentioned
earlier,
is
only
at
the
project
level.
So
that
means
that
there
are
compliance
loopholes,
since
the
main
can
override
policies
and
out
of
compliance,
merge
requests
compliance
needs
to
apply
to
all
users.
A
Setting
up
the
feature
per
license.
Scanning
configuration
and
applying
related
policies
is
a
burden
for
large
customers,
as
they
would
need
to
go
individually
to
each
project
one
by
one
and
to
do
the
configuration
and
adding
policies
and
then
adding
conditional
policies
is
an
available
and/or
easy,
such
as
specifying
one
version
is
allowed
or
another
version
of
the
same
license.
A
In
the
interim,
we
have
a
few
introduction
group
level.
Ux
issues
that
we
can
get
out
there
sort
of
as
a
common
denominator,
no
matter
what
direction
we
we
go
in
and
in
terms
of
group
and
instance,
there's
a
few
things.
We
can
still
help
the
users
with
and
that's
showing
project
configuration
status
across
projects
at
the
group
level.
This
gives
customers
a
bird's-eye
view
of
where
license
scanning
exists,
and
it's
a
starting
point
for
the
future,
given
it
to
current
maturity
and
displaying
when
policy
violations
are
made.
A
So
those
earlier
merge
requests
that
we
showed
that
will
become
disallowed
because
of
an
out
of
compliance.
We
can
surface
those
up
to
the
compliance
which
has
an
NBC
of
showing
out
of
compliance.
So
it's
in
alignment
with.
What's
the
list
that's
seen
on
the
compliance
dashboard
as
it
is?
Okay.
So
that
concludes
the
presentation.