►
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
Shall
I
kick
us
off?
Okay,
great
welcome
everyone
to
the
first
openjs
foundation
standards
group
meeting
for
2021.
It's
been
a
wonderful
few
weeks
of
respite
between
now
and
the
last
time
we
met,
and
today
we're
very
excited
to
have
some
some
guests
to
talk
to
us
about
the
joint
development
foundation.
A
Getting
started,
though
just
for
our
usual
housekeeping
bits.
Please
put
your
name
in
the
attendance
area
of
our
notes
document
which
we
will
pop
in
the
chat
just
momentarily,
and
you
know
in
terms
of
announcements
we're
still
early
in
the
year,
so
we
don't
have
too
much
yet,
but
we
do
have
a
couple.
I
wonder
since,
since
I'm
doing
the
cheering,
if
robin
wants
to
share
one
of
the
biggest
ones
that
came
out
yesterday,.
B
Right
we
announced
the
date
and
opening
the
cfps
or
call
for
speaking
submissions
for
openjs
world.
It
will
be
june,
9th
virtual
experience
and
again
send
your
cfps.
I
think
it'll
be
open
at
about
a
month,
so
it'll
get
here.
Those
deadlines
will
approach
us
sooner
than
we
think
so.
A
Yeah
and
then
the
other
thing
that
we
launched,
I
think
between
now
and
the
last
time
we
met
was
the
js
landia
individual
supporter
program.
So
you
can
also
check
that
out
on
our
blog
at
openjsf.org,
and
but
this
is
an
awesome
way
to
deepen
your
involvement
and
support
for
our
wonderful
projects
here
and
also
get
some
exclusive
contact.
Content
info
and
offers
just
for
individual
supporters
of
the
foundation
for
a
pretty
cheap
annual
price
so
and
check
that
out
as
well.
A
Somebody
let
in
miles
and
then
let
me
just
check
around
any
other
announcements
or
or
possibly
news
from
any
of
our
other
groups
or
affiliations
emily
well,.
C
I
think
it
makes
I
don't
know
if
it
makes
sense,
but
we
have
the
board
seat,
we're
gonna
open
up
soon
for
election.
The
cpc
primary
director
so
look
for
that
soon.
A
Great
good
good
thing
to
point
out:
yeah:
okay!
Well,
I'm
not
hearing
any
other
announcements.
D
A
Great,
I
think,
that's
also
exciting,
because
it
was
it's
the
first
time.
You
know
that
that
was
a
pretty
full
wonderful
slate
of
potential
candidates
to
the
to
the
group,
and
you
know
a
nice
group
of
women
who've
been
nominated
to
the
tag.
So
I
think
that
really
brings
a
lot
of
balance
to
that
group.
So
congrats
to
those
to
the
tag.
B
A
I
think
that'd
be
an
interesting
idea,
maybe
just
doing
some
kind
of
quarterly
just
update
or
check
in
and
and
brian
usually
emails
around
about
w3c
stuff,
but
that's
not
always
something
people
read.
So
I
don't
always
read
my
emails.
I'll,
be
honest
with
you.
G
B
A
Awesome
well,
if
that's
it
for
our
announcements,
I
think
I'll
turn
it
over
to
robin
to
introduce
our
guest
for
today.
B
Yeah,
hey
super
excited
to
have
david
rudin
and
seth
newberry
here
to
talk
about
the
linux
foundation,
joint
development
foundation
and
its
new
community
spec
program.
Some
of
you
may
have
been
following
it
some
of
you
haven't,
but
they
have,
I
believe,
some
slides
to
share
and
obviously
lots
of
time
for
an
interactive
discussion.
B
Jory
and
I
are
also
following
up
from
our
strategic
planning
session.
We
had
to
go
to
the
projects,
so
this
will
really
help
sort
of
supplement
that
information
that
we
take
and
bring
our
projects
up
to
speed
without
further
ado.
H
Well,
thanks
for
having
us
so
no
slides,
I
was
just
going
to
talk
that
that
I
will
we'll
hopefully
walk
you
through
this
and
I
guess
before
we
start
just
as
a
baseline.
I
know
we're
talking
to
the
standards
group
here,
but
just
so
I
can
figure
out
the
best
way
to
start
what
should
I
start
with
like
the
the
different,
the
legal
differences
of
of
standards
in
open
source?
Is
that
helpful,
or
is
that
remedial.
B
B
D
I
G
H
Great,
so
you
know
please
indulge
me
for
a
few
minutes,
I'm
just
going
to
start
really
high
level.
We
can
dig
into
you
know
any
questions
or
details,
but
I
I
just
want.
I
think
it's
important
to
set
the
stage,
especially
for
people
who
come
from
the
open
source
world,
because
open
source
and
standards
have
a
lot
in
common,
but
there's
some
pretty
significant
differences
as
well,
which
leads
to
different
structures
and
approaches
that
we
tend
to
take
so
at
the
risk
of
being
super
high
level.
H
If
you
look
at
the
history
of
open
source,
it
really
is
a
history
of
basically
copyright
and
forking,
and
the
idea
is
is
that
you
make
your
code
available
and
people
can
fork
it
and
change
it,
and
that's
okay.
In
fact,
it's
sometimes
a
really
good
thing,
and
so
your
licenses
are
are
designed
to
allow
that
activity
and
but
the
important
thing
from
a
let's
say
a
patent
perspective.
H
Is
that
because
you're
talking
about
implementations
and
very
loose
communities,
that
can
you
know
either
be
you
know,
drive-by
contributors
or
you
know
foundations
like
you:
have
they
they
account
for
basically
being
able
to
come
in,
make
a
contribution
and
potentially
leave?
H
And
ultimately,
if
you
have
a
patent
issue
with
your
open
source
code
because
it
deals
with
implementation,
you
have
flexibility
in
basically
designing
around
the
patent,
removing
the
offending
area,
but
the
code
is
more
of
a
living
thing.
It
changes
and
it
adapts.
The
other
important
aspect
is:
is
that
open
source
is
about
the
the
code,
the
implementation
details.
H
So
from
your
licensing
point
of
view,
also,
your
open
source
licenses
generally
only
cover
an
individual
contributor's
own
contributions.
So
if
you
think
of
your
all
of
your
open
source
code
base,
as
just
a
let's
pretend
a
box,
you
have
slices
where
each
individual
contributor
has
made
a
patent
commitment
to
the
slice
that
they
themselves
contributed,
but
not
the
work
as
a
whole.
That's
a
lot
of
times,
because
you
don't
have
control
over
the
work
of
a
whole.
You
don't
know
where
it's
going
to
go.
It
could
be
forked,
it
could
be.
H
H
So
you
know
the
ultimate
example,
in
my
mind,
is
the
the
power
outlet
in
your
house.
You
know
in
the
united
states
we
have
one
standard
at
different
countries
at
different
ones,
but
effectively
that
standard
says
here's
what
you
can
expect
from
the
power
outlet,
but
it
doesn't
define
what
you
plug
into
it
or
what
it
works.
H
I
need
to
make
commitments
to
the
work
as
a
whole
from
a
patent
perspective
to
make
sure
that
no
one
can
actually
use
a
monopoly
power
to
block
other
people,
because
if
I
don't
have
any
options-
and
I
have
to
use
your
patent-
that
patent
holder
can
charge
monopoly
rates.
So
that's
why,
in
standards
we
have
a
commitment
to
the
whole
and
that
whole
is
based,
and
you
know,
usually
the
term
we'll
use
is
reasonable
and
nondiscriminatory
terms
that
can
be
with
or
without
royalties.
H
I
I
I
was
just
going
to
ask
and
maybe
you'll
get
to
this
afterwards,
but
in
the
foundation
in
the
open
source
space
we
have
foundations
as
kind
of
a
place
for
vendor
neutral
collaboration
right
in
the
standards
world.
We
see
more
sdo
standards
organizations
and
I
would
love
to
hear
a
bit
of
a
take
on
kind
of
the
differences
in
these
organizations
and
like
why
one
might
go
to
one
organization
versus
the
other
and
if
maybe
the
line
between
them
is
blurring
over
time.
H
Yeah
the
line
is
blurring
in
many
cases,
so
let
me
be
more
of
a
traditionalist,
because
the
gray
areas
get
gets
larger
and
larger
between
the
two.
But
I
think
the
idea
is
that
when
you
typically
go
to
an
open
source
style
foundation,
they
tend
to
be
more
focused
on
specific
code
implementations
and
they
tend
to
have
more.
H
I
almost
say
openness
because
that
that
that's
a
loaded
term,
but
what
I
would
say
is
that
there's
less
due
process-
and
you
know
the
idea-
is
that
the
the
power
to
fork
is
the
thing
that
tends
to
keep
people
together,
and
so
you
tend
to
have
less
formality
in
the
rules
and
you
tend
to
have
more
open
participation
because
you
don't
have
you're,
not
binding
people
to
the
work
as
a
whole.
H
The
case
of
standards
because
they
come
strictly
from
do
from
from
you
know,
antitrust,
there's
formal,
due
process
and
procedures
to
make
sure
that
all
relevant
voices
are
heard
because
forking
isn't
really
an
option.
You
know
if
I
fork
that
power
outlet,
for
example,
it
doesn't
help
anyone
else,
because
it
doesn't
change
anything.
So
you
tend
to
have
more
formality,
also
a
difference
that
you
know
where
standards
and
open
source
people
tend
to
look
at
each
other
differently.
H
Is
that
usually
in
standards
bodies,
the
the
board
or
the
steering
committee
has
a
lot
of
direct
control
over
what
happens
and
and
influence
of
setting
direction
and
approving
materials.
Open
source
foundations
tend
to
be
more
driven
by
a
the
the
technical
steering
committee
that
sets
the
technical,
correct
direction
where
the
board
itself
is
more
of
dealing
with
marketing
and
promotion
and
trademark
type
of
issues.
So
that's
kind
of
a
you
know
at
a
high
level.
What
I
see
the
distinctions
to
be.
J
I'd
say:
there's
also
sort
of
a
I'm
going
to
call
it
almost
a
social
distinction
between
one
and
the
other
yeah
so
oftentimes
with
this,
with
with
an
open
source
project
you're,
starting
with
a
code,
a
piece
of
code
or
a
kernel,
it
says
it
this
does
this
and
then
a
community
arrays
itself
around
that
piece
of
code
and
says,
but
if
we
do
this,
it's
even
cooler
and
and
and
that
all
starts
to
happen,
oftentimes
with
a
standard
you're
actually
trying
to
define
something
that
doesn't
exist.
J
So
you'll
spend
a
lot
of
time
figuring
out.
You
know
it's
a
quantum
toaster
right.
Does
it
float
or
does
it
fly?
You
know
how
do
we?
J
How
do
we
make
it
work
and
so
that
process
by
its
nature
is
often
time
a
lot
longer
and
and
then,
when
you
get
into
really
kind
of
patent-intensive
industries
like
telecom
right,
then
you
you
get
an
awful
lot
of
process,
that
kind
of
tends
to
give
standards
making
or
specification
setting
a
kind
of
a
bad
name,
because
it
it
takes
a
long
time
and
there's
a
lot
of
process
involved
and
and
and
people
can
object
and
and
so
forth.
J
So
it
it
so
one
of
the
interesting
things
about
jdf
and
one
when
you
create
by
the
way.
Let
me
let
me
also
define
a
term
there's
a
difference
between
a
specification
and
a
standard,
so
a
standard
tends
to
come
from
one
of
the
national
standards
bodies
and
see
so
forth
and
those
are
usually
mandatory
in
in
their
most
technical
definitions.
J
So
they're
mandatory
you,
you
know
if
you're
gonna
plug
in
a
ceiling
fan,
it
has
to
be
implemented
this
way,
whereas
a
specification
is
an
implementation,
but
it's
voluntary
and
some
specifications
ultimately
migrate
and
become
standards.
But
that's
rare
and
usually
specifications
are
kind
of
specific
to
a
point,
and
often
you
never
see
a
standard
right.
A
standard
is
just
it's
invisible.
It's
a
protocol,
that's
transport!
It's
something
baked
in
that.
J
No,
nobody
ever
really
sees
very
often
so
so
that's
one
of
the
features
about
standards
that
is
different
from
open
source
and
so
what
what
david
sort
of
originally
went
with?
You
know
the
here's
one
of
the
interesting
thing.
When
you
create
a
bespoke
specification
setting
body
or
standards
body,
you
wind
up
immediately,
getting
the
let's
call
it
five
founding
members
together
and
the
first
thing
they
do
is
they
get
their
lawyers
together
to
define
patent
terms,
rules
of
process,
governance
and
all
that
sort
of
stuff
and
it'll?
Take
you.
J
I
guarantee
never
seen
it
go
faster
than
this
six
months
and
you'll
spend
accumulated
couple
hundred
lawyer
hours
at
minimum,
usually
more
and
then
the
sixth
guy
comes
along
signs,
the
thing
and
says:
okay,
I'm
in
right,
and
so
david
david
sort
of
said,
hey.
How
do
I
get
to
the
sixth
guy
without
going
through
all
the
first
part
of
it,
and
so
jdf
created
a
set
of
templates
that
sort
of
define
the
nature
of
governance
and
the
nature
of
the
working
groups
using
just
best
practices
right?
It's
just
you
know.
J
Everybody
who
looks
at
them
is
gonna
go,
oh
yeah.
I
recognize
most
of
that.
Although
what
is
interesting
is
that,
when
sort
of
non-standards
lawyers
look
at
it,
they
they
lose
their
minds
because
it's
not
like
a
contract.
It's
not
it's!
It's
it's!
The
jdef
is
intentionally
very
loose
because
we
want
the
projects
to
be
able
to
kind
of
define
their
own
level
that
they
need.
So
we've
got
a
couple
of
projects.
We've
got
one
that
is
defining
the
metadata
for
patent
information
unfunded.
J
These
guys
just
set
it
up
themselves,
they're
using
the
jdf
documents
and
they're
going
great.
We
got
another
one
same
thing:
uptain,
which
is
doing
a
secure
download
to
the
automotive.
Can
bus
doing
great
right.
They
get
no
support
from
us
and
they're
and
they're
doing
fine.
They
they
follow
the
rules.
Everybody's
happy-
and
you
know,
they've
got
something
that
is
actually
a
real
decent
standard
and
it
happens
very
very
quickly
compared
to
sort
of
the
more
traditional
standards
practices.
J
So
I
think
jim
zemlin
saw
this.
You
know
what
we
were
doing
at
jdf
and
said
wow.
You
know
what
this
has
really
got
a
high
degree
of
fit
for
what
linux
foundation
is
doing
and
that's
when
we
merged
with
linux
foundation
gosh
two
years
ago,
that's
two
years
ago,
yeah
about
two
years
ago.
I
think
we
announced
it
two
years
ago
and
it
was
officially
a
year
and
a
half
ago.
So
it's
really
been
a
very
successful
yeah.
H
Collaboration
so
yeah,
and
so
let
me
kind
of
back
up
a
little
bit
in
that
when
you
were
going
to
create
a
standards
body,
there's
or
let's
say
you
want
to
get
together
to
do
a
standard.
There's
lots
of
ways
to
do
it.
One
is
you
know
you
can
go
to
an
existing
standards
organization.
You
know
an
iso
ic,
an
oasis,
a
w3c.
I
know
many
of
you
have
experience
with.
You
know
ecma,
but
sometimes
you
want
to
have
a
collaboration.
That
is,
you
know,
a
smaller
consortium
of
select
people.
H
You
want
your
own
control,
you
want
your
own
marketing
and
in
those
cases,
that's
when
you
would
go
and
set
up
your
own
collaboration
and
those
can
be
either
a
series
of
contracts
between
the
parties
or
you
set
up
your
whole
new
legal
corporate
infrastructure
or
then
at
the
smaller
level.
It's
just
you
know
two
or
three
companies
can
work
together
using
you
know
more
lightweight
paper,
but
to
set's
point
that
could
take
you
know.
Six
months
would
be
would
be
ambitious,
and
sometimes
you
know
I've
seen
these
things
take
much
much
more.
H
So
what
jdf
comes?
Is
it
basically
creates
what
we
call
a
standards
organization
in
the
box
where
we
have
preset
materials
that
are
non-negotiable,
but
they
rather
than
negotiate
in
the
traditional
setting
a
you
know
where
every
comma
goes.
We
have
a
series
of
options
and
you
can
choose
from
those
options
like
a
menu
of
the
restaurant.
So
you
can
choose
your
ip
policy.
You
can
choose
your
your
open
source
policy.
You
can
choose
membership
levels,
but
basically
it
up
levels
where
the
discussion
goes
and
that'll
now
allows
us
to
get.
H
You
know
basically
standalone
standard
organizations
up
and
running
within.
You
know,
as
fast
as
days
just
once
you
get
agreement
between
the
parties.
It's
very
quick
and
the
other
thing
we
have
is
from
a
corporate
perspective
right
off
the
bat.
When
you
sign
the
papers,
you
come
under
the
jdf
corporate
umbrella,
you're
your
own,
basically
independent
subsidiary,
but
you
get
to
take
advantage
of
the
non-profit
status
immediately.
The
the
corporate
support
and
admin
support
that's
available
from
the
linux
foundation.
H
So
effectively
you
skip
all
that
ramp
up
period
and
you
start
right
with
the
standards
body
now.
One
thing
to
keep
in
mind,
though
it
is:
it
is
an
independent
foundation
and
so
for
something
like
openjs
effectively
you'd
be
cr.
If
you
were
using
this
mechanism,
you'd
effectively
be
creating
a
you
know,
a
a
sister
organization
that
would
have
its
own
steering
committee
and
its
own
structure,
and
there
would
have
to
be
some
coordination
between
the
two
to
make
sure
they
they
coordinate.
But
it
is
a
separate
organization
covered
a
lot
there,
thoughts,
questions.
F
Question
I
have
is
like:
where
do
you
see
people
crossing
the
line
between
you
know
we
get
together
as
a
open
source
project
and
we'll
say:
hey,
we'll,
recommend
this
extra
metadata.
Please
add
this
extra
metadata
to
your
modules,
we're
going
to
use
it
this
way
right,
not
a
standard,
but
like
we're
trying
to
encourage
everybody
to
follow
that
right.
H
H
Yeah
a
lot
a
lot
of
times
it
comes
down
to
if
you
want
independent
implementations
and
you
need
consistency
for
it
so
and
the
area
is
very
gray
and
you
know
we
have,
for
instance,
you
know
apis
in
the
lynx
kernel
that
have
been
stable
for
years
and
no
one
needs
to
call
them
go.
Take
it
to
a
standards
body,
because
we
all
agree
that
that's
what
it
is
and
we're
not
changing
them.
H
But
if
you're
going
to
add
some
metadata
to,
let's
say
you
know
a
particular
code
base.
If
you
can
add
it
into
that
that
your
your
own
documentation
systems,
you
might
not
need
a
you
know,
quote
unquote
standards.
But
if
you're
looking
for
metadata,
that's
going
to
travel
between
languages
and
approaches
and
not
be
you
know,
open
js
dependent,
you
might
want
to
actually
publish
an
independent
standard,
so
your
c
plus
developers
and
your
ruby
developers
etc
can
all
be
using
the
same
set
of
metadata
in
order
to
interoperate
at
some
level.
J
You
know
one
of
the
things
that's
interesting
about
this
too,
on
your
to
your
question,
and
this
is
a
little
bit
orthogonal
to
it,
but
it's
probably
worth
pointing
out,
but
increasingly
what
you
see
is
all
of
these
efforts
that
are
coming
together,
particularly
the
standards.
Efforts
really
are
data
model,
oriented
right,
you're,
you're,
trying
to
figure
out
okay.
I've
got
a
whole
array
of
applications
that
I'm
trying
to
use
either
over
here
in
salesforce
or
in
somebody
else's
and
and
you
and
you
want
the
data
models
to
be
interoperable.
J
You
want
them
to
carry
roughly
the
same
information
so
that
all
these
different
applications
can
can
access
them.
So
they're
not
really
kind
of
classically
a
standard,
but
they
fall
into
sort
of
they
benefit
from
the
organization
of
standards,
and
so
the
community
specification
that
we
want
to
talk
about
and
and
what
we
refer
to
as
our
latest
release
of
these
actually
allows
really
simple
projects
around
data
models
that
that
kind
of
wasn't
there
before.
J
But
we
we
sort
of
created
a
way
of
of
creating
data
model
consortia
very
quickly
in
in
sort
of
our
latest
revisions.
So
that's
that's
an
interesting
way
of
sort
of
touching
on
what
you
might
have,
which,
if
you
want,
if
you're,
adding
metadata
or
you're
adding
fields
or
something
like
that
that
you'd
like
to
have
become
more
sort
of
canonical.
J
Entity
and
and
get
a
lot
of
what
you
want.
That
might,
I
say,
collaborate
well
with
what
you're
doing
in
your
normal
open
source
activities.
F
H
H
H
So,
if
you
think
about
jdf
as
a
as
a
consortium
in
a
box,
we
think
of
the
community
specification
as
a
as
a
consortium
in
a
repo,
so
to
speak
so
effectively.
What
one
of
the
the
things
you
get
also
is
when
open
source
people
come
to
standards,
it's
just
a
different
set
of
norms
and
approaches,
and
it
doesn't
always
make
sense
and
there's
there's
a
bit
of
a
learning
curve
and
a
lot
of
you
know:
men
are
from
mars.
H
Women
are
from
venus
kind
of
approaches
where
you
know
these
cultures
are
clashing
and
approaches
are
clashing.
So
what
the
community
specification
does
is
lays
out
a
method
where
you
can
just
set
up
a
repo
and
much
like
if
you're
setting
up
an
open
source
repo
where
you
put
a
license
file
and
then
some
governance
information.
H
This
is
specifically
designed
for
for
specification
development,
and
I
see
that
seth
had
posted
the
link
but
effectively.
What
you
do
is
you
set
up
the
repo
you
copy,
the
files
and
what
you
have
is
kind
of
standards,
best
practices
but
grafted
into
a
model
that
is
specifically
designed
for
repo
based
development,
including
drive-by
contributors.
H
You
can
keep
it
private,
you
can
make
it
public,
but
the
idea
is
that
you're
making
it
really
easy
to
start
up
really
really
easy
to
participate,
but
you're
still
using
standards,
best
practices
around
due
process
and
antitrust,
and
if
you
start
also
stepping
back
and
seeing
these
are
various
lego
blocks
that
go
into
the
pieces
into
the
larger
hole.
So
you
can
start
off
a
project
with
a
community
spec.
You
can
attach
it
to
openjs
and
just
be
a
you
know.
H
Another
repo,
like
you
have,
and
people
can
work
in
there
using
methods
and
tools
that
they're
used
to,
but
then,
if
there's
a
time
for
it
to
become
a
real
standard,
if
you
think
oh
well,
this
thing's
got
more
legs
and
needs
some
additional.
You
know
scrutiny
or
due
process
or
its
own
foundation.
H
You
could
actually
then
spin
it
over
into
a
jdf
project
and
jdf
is
also
built
to
accept
specific
community
specification
pro
develop
specs
and
has
that
mode
is
just
a
native
operation
mode
now
and
then
to
take
it
a
step.
H
Further
jdf
we
didn't
mention
this
before
actually
has
something
called
a
pass:
submitter
status,
which
means
you
can
do
work
in
jdf
and
be
a
specification
and
then
have
a
fast
path
to
take
it
to
iso
iec
jtc1
to
become
an
international
standard,
and
so
what
you
basically
get
now
is
a
path
to
start
really
small
experimental
in
a
repo
that
can
actually
expand.
If
you
need
to
all
the
way
to
an
international
standard.
Should
that
ever
be,
you
know
something
that
makes
sense
for
you,
but
you
don't
have
to
go
down
that
route.
Obviously,.
J
Spdx
and
open
chain
open
chain
has
been
accepted
as
an
iso
standard
and
spdx
is
in
the
process
and
being
balloted.
Should
it's
a
big
spec
so
we'll
we'll
see,
but
it's
due
to
be
balloted
sometime
in
march.
K
I
had
a
few
questions
about.
You
know
where
things
kind
of
blur
the
line
between
open
source
and
specification.
So
one
thing
that
kind
of
comes
up
often
is
test
suites.
You
know
you
can
think
of
tests
as
kind
of
non-normative
here's.
K
You
know
consequences
of
the
specification,
but
they're
usually
maintained
separately
from
the
specification
and
often
they're,
not
really
they're,
not
data
bundles,
as
such,
you
know
they
are
kind
of
code
is
is
is,
is
that
kind
of
something
that
is
that
within
the
purview
kind
of
how
to
arrange
those
is
that
within
the
purview
of
community
specifications-
and
the
other
question
I
wanted
to
raise
is:
is
there
any
kind
of
contractual
work
about
things
that
happen
have
to
happen
outside
a
repo?
K
So
if
somebody
finds
an
architectural
problem
with
a
specification
that
probably
affects
all
implementations
like
a
security
problem,
you
might
you
might
embargo
things,
you
might
say
every
we
need
to
bring
a
group
of
people
from
each
of
the
the
member
organizations
into
a
group
that
is
going
to
discuss
this
offline.
K
How
to
address
this
across
all
the
specifications
we
don't
want
to.
We
don't
want
to
to
make
you
know
the
nature
of
the
vulnerability
public
until
we
have
a
story,
but-
and
so
you
know
kind
of
obligations
to
participate
in
an
embargo
in
particular
ways
is.
That
also,
is
that
something
that
that's
within
the
purview
absolutely.
H
So,
let's
so
sure,
so,
let's
start
with
test
suites
test.
Suites
are
tough
because
they
come
in
all
shapes
and
sizes,
and
so
I
think,
as
you
know,
they
can
be
a
gray
area
in
general,
I
would
say
a
classic
test
suite
which
basically
says
you'll,
give
us
your
implementation
and
we're
going
to
run
run
the
test
against
it.
And
if
you
pass
you
pass,
if
you
fail,
you
fail
we'll.
H
Let
you
know
what
in
general,
I
would
not
think
those
are
a
standard
and-
and
you
know
it's
generally
code
or
it's
just
more
of
a
best
practice
style
document
that
you
you
react
to.
H
However,
sometimes
test
suites
can
have
the
effect
of
creating
a
standard,
and
what
I
mean
by
that
is,
you
know
if
you've
got
three
options
and
a
spec
on
how
to
do
something
and
the
test
suite
says
you
must
do
this
well,
you're
kind
of
setting
a
standard
or
sometimes
test
suites
can
add
additional
functionality
or-
and
maybe
this
isn't
exactly
what
you're
asking.
H
But
if
you
take
certification
entities-
something
like
you
know
the
wi-fi
alliance-
they
they
tend
to
build
on
top
of
existing
standards
and
they
start
off
as
a
certification
body,
but
they
tend
to
start
filling
in
the
holes
or
adding
things
to
a
spec.
In
that
case,
they
become
much
more
standards
like
and
probably
would
be
well
served
by
standards
like
structure
and
licensing
approach.
J
Yeah
and
also
test
can
david
mention
this
and
alluded
to
it,
but
most
of
the
specification
setting
bodies,
I'm
aware
of
usually
define
interoperability
tests
so
that
implementers
can
understand
whether
or
not
they're
conforming
conformance
tests,
which
are
much
more
like
a
wi-fi.
You
know,
usually
you
get
a
label,
it
says
wi-fi
compliant
or
something
like
that
number
one.
J
Those
are
expensive,
really
really
expensive,
because
you've
got
to
build
harnesses
and
then
you've
got
to
build
a
test
harness
such
that
they
you
know,
can
keep
up
with
the
spec
and
a
lot
of
times.
What
specification
setting
bodies
will
do
is
they'll
work
with
somebody
who
does
test
as
part
of
their
business,
but
but
most
of
the
time,
what
we
see
is
just
basic
interop
tests.
So
it's
essentially
like
a
lan
party
with
a
you
know
where
you're
trying
to
do
something
to
make
sure
that
the
spec
actually
works.
H
And
then
your
question
about
basically
confidentiality
outside
of
of
a
particular
work
stream,
so
both
jdf
and
the
community
spec
have
approaches
to
deal
with
confidentiality
in
the
case
of
jdf.
It
takes
kind
of
a
middle-of-the-road
approach
that
says
there
is
nothing
here,
that's
confidential!
That
way,
you
don't
have
to
lock
things
in
safes
and
and
be
super
careful
with
it,
but
it
also
says
we
agree
not
to
discuss
things
publicly
unless
the
group
has
decided
to
to
announce
things
publicly.
H
So
in
that
case
you
could
have
a
security
work
stream
in
a
jdf
project
that
is,
that
is
not
open
to
the
public.
The
community
specification
deals
with
that
a
little
bit
differently,
which
is
basically
it
has
confidentiality
terms
that
are
tied
to
the
status
of
your
repo.
So
if
your
repo
is
public,
everything
in
there
is
public.
If
your
repo
is
private,
it's
private
until
the
group
agrees
to
release
it
so
in
the
case
of
let's
say,
doing
a
spec
in
the
community
using
the
community
approach.
H
You
know
if
you
choose
to
have
your
main
repo
available
the
public
and
you
had
a
security
issue
you
could
create.
You
know
a
member,
only
security
repo
to
have
those
discussions.
J
One
of
the
other
things
too,
that's
just
a
practical
matter
again
out
if
you're
in
the,
if
you're,
implementing
a
specification
with
a
group,
that's
an
entity
as
opposed
to
a
community
spec,
but
I
suppose
you
could
do
it
even
with
a
community
spec
the
oftentimes,
a
specification,
you
you
want
the
specification
to
be
distributed
well
within
the
ecosystem
of
the
other
people
who
are
doing
what
you
something
similar,
because
usually
one
specification
is
a
component
of
something
larger,
and
so
you
do
what
are
called
liaison
statements
or
liaison
agreements
with
other
organizations
that
might
be
doing
something
adjacent
to
or
similar
to
what
you're
doing
so
that
you
stay
coordinated.
J
So
that
way,
if
somebody's
got
something
and
they
they
want,
you
to
add
a
field
for
a
metadata
field.
They
can
issue
you
a
request
in
sort
of
a
formal
fashion
that
you
can
then
respond
to,
and
then
it
becomes
part
of
the
spec.
And
then
the
other
external
organization
can
normatively
reference.
What
you're
doing
in
the
spec
and
and
life
is
good.
J
Sometimes,
however,
you'll
find
that
other
organizations
are
doing
something
in
draft
and
they
want
you
to
review
it
say:
hey:
how
does
this
fit
within
what
you're
doing
in
your
ecosystem,
but
we're
not
ready
to
publish
yet
so
it
is
very
useful
to
have
some
place
where
you
can
either
a
member's
only
site
or
something
that
is
not
entirely
in
the
public
view
in
specifications
that
kind
of
doesn't
exist
in
open
source.
H
A
So
one
of
the
questions
that
I
was
going
to
ask,
and
david
and
seth,
is
that
you
know
in
our
case,
at
the
openjs
foundation,
we
are
actually
a
an
ecosystem
of
multiple
open
source
projects
right
and
so
within
our
home.
We
have
projects
like
node,
we
have
projects
like
jquery
and
then
we
have
much
smaller
projects
and
all
of
these
communities
have
different
needs.
Different
experiences,
different
sort
of
understanding
of
you
know
the
way
things
should
work.
A
If
you
will
so
when
we
think
about
doing
perhaps
a
community
specification
from
an
open,
js
foundation
project,
you
know,
is
it
the
case
that
we
would
want
to
be
thinking
about
spinning
up
as
sister
for
the
node
community,
for
example,
because
that's
a
project?
That's
that's
a
specification,
that's
developing
from
that
community,
or
is
it
something
that
we
want
to
try
and
tackle
as
a
larger
ecosystem
community.
H
Yeah,
let
me
maybe
give
a
a
slightly
different
reaction,
and
then
we
can
I'll
answer
your
question,
because
one
of
the
things
that
I
think
we
find
the
potential
issue
we're
trying
to
avoid
is
that
groups,
especially
under
linux
foundation,
start
creating
specs
and
put
them
under
an
open
source
license.
They
tend
to
put
it
under
an
mit
and
or
an
apache
license,
and
going
back
to
what
I
originally
was
talking
about
from
a
legal
structure.
H
You
don't
get
the
legal
coverage
that
you
need
to
ensure
that
people
can
implement
it
safely
and
it's
one
of
those
things.
That's
not
a
problem
until
it's
a
problem
but
we'd
like
to
avoid
it
being
a
problem.
So
at
the
base
level.
What
I'd
like
to
see
is,
you
know
all
of
the
open
js
projects
using
a
spec
license.
That's
specifically
designed
for
that
and
procedures
to
make
sure
that
people
can
safely
use
those.
H
Those
specs,
you
know
what
we
didn't
talk
about
is
things
like
you
know,
there's
also
the
open
web
foundation
agreement,
which
is
you
know,
one
of
the
first
community
developed
spec
licenses.
There
aren't
that
many,
so
at
a
base
level,
I
I
you
know
from
implementer's
point
of
view
make
sure
you've
got
the
right.
Your
groups
are
having
the
right
the
right
coverage
for
their
specs.
H
Then,
if
you're
talking
about
okay,
we've
got
a
bunch
of
you
know:
projects
under
under
the
openjs
umbrella.
What
should
we
be
telling
them
to
do?
I
think,
at
a
base
level,
the
community
spec
provides
a
very
lightweight
way
to
ease
into
this
into
the
process.
It's
it
uses
tools
and
approaches
there
that
are
understandable,
they're
easy
to
tack
on
they
don't
require,
and
then
you
know
the
separate
administrative
burden
you
know
boards
and
all
the
all
the
things
that
come
with
it
basically
a
foundation.
H
Then
I
think
the
next
step
is
there
are
projects
that
might
graduate
from
the
community
specification
approach
that
need
more
formality
that
actually
need
their
own
identity.
In
those
cases,
then,
a
jdf
project
could
make
a
lot
of
sense
and
there's
lots
of
ways
to
slice
and
dice
how
you
would
set
it
up.
I
mean
you
could
technically
set
up
a
an
open,
js
found
foundation,
openjs
spec
foundation
under
jdf
and
have
a
bunch
of
individual
working
groups.
H
You
know
one
for
each
work
stream
that
you
have
one
for
each
project
or
it
could
be
that
you
know,
for
instance,
that
you
could
set
the
node
specification
foundation
or
the
you
know.
You
know,
put
it
put
in
your
sub
project
there
and
that
a
lot
will
depend
on
on
what
you
think
it
would
work
best
for
the
community
and
what
kind
of
leadership
you
think
makes
sense.
H
H
So
there
is
some
appeal
there,
but
you
know
I
think
people
are
always
the
tough
issue
here,
and
so
you
have
to
understand
your
constituency,
and
you
know
if
someone
who's
leading
you
know,
node.js
all
of
a
sudden
becomes
a
sub-project
of
of
this
other
foundation.
They
might
not
appreciate
as
much
as
having
a
seat
on
the
steering
committee
at
a
specific
node
specification
foundation,
so
to
speak
and
I'm
just
pulling
up
random
projects,
but
a
lot
of
us
finding
the
right
fit
for
for
the
people
and
their
goals.
J
I
think
just
for
the
sake
of
completeness,
too,
you
know:
we've
we've,
given
you
sort
of
the
pantheon
of
approaches
and
projects
that
we've
got
at
jdf,
but
there's
actually
one
more.
So
one
of
the
things
that
jdf
does
is
we
are
we
consciously
limit
the
amount
degrees
of
freedom
within
our
document
templates?
J
Because
that's
what
allows
us
to
scale-
and
you
know-
and
it
works-
it's
worked
pretty
well
for
us,
but
every
so
often
somebody
comes
along
and
they
just
they've
got
to
have
something
different,
and
at
that
point,
what
happens
is
you
turn
to
linux
foundation
and
and
linux
can
create
a
series
within
their
lf
series
of
something
that's
custom,
but
that
works
kind
of
like
a
jdf.
So
you
know
you
can
you
you
can
go
from
one
extreme
to
the
other
within
the
family
of
linux
foundation,
support
products.
J
Joint
development
foundation
right:
oh,
there
was
a
a
a
chat,
and
so
what
does
jdf
stand
for?
Okay,
sorry,.
E
All
right,
michael
you're,
having
trouble
with
your
audio
just
drop
it
in
the
chat.
Your
question
or
comment.
G
Do
you
recognize
that
you
recognize
mike
champion?
Yes,
yes,
oh
okay,
so
yeah,
sorry
yeah,
that
was
I'm
sort
of
was
moving
now,
I'm
parked.
Hopefully
I
have
a
solid,
but
anyway,
two
questions,
one
legal
and
more
or
less
political.
The
legal
one
is
in
w3c.
The
anti-trust
stuff
is,
is
really
rearing
its
ugly
head.
I
wonder
if
you
can
advise
us
on
whether
you
know
that
would
be
a
reason
for
to
take
the
the
you
know
the
the
foundation.
G
You
know,
standards
approach
more
more
seriously
than
we
might
have
in
the
past.
The
other
is
kind
of
political,
like
with
respect
to
the
community
process.
Whatever
it's
called,
you
know
if
there
was
some
interest
in
developing
something
that
was
say
marginally
in
w3c
scope,
marginally,
in
what
we
g
scope
and.
G
H
H
So
as
far
as
antitrust
goes,
that's
one
of
the
key
things
I
think
is
really
important
to
handle,
because
if
you
are
locked
out
of
the
market
because
your
technology
doesn't
get
included
or
your
interests
aren't,
you
know
addressed
by
the
standard.
It
can
effectively
put
you
out
of
business
and
that's
where
antitrust
comes
into
play
and
that's
why
it's
super
important
in
standards,
and
you
don't
see
it
so
much
in
open
source,
because,
while
it's
an
issue,
you
know
you
can
generally
fork
so
both
jdf
and
and
community
spec
deal
with
antitrust.
H
They
have
antitrust
provisions
in
there
and
they
also
have
provisions
aligned
to
meet
those
organizations
with
us
government
requirements
for
what
it
means
to
be
a
standards
organization,
which
means
you
can
take
advantage
of
the
standards
protections
and
you
can
actually
be
recognized
as
a
as
a
standards
body.
So
that's
really
important
and
I
think
anytime
you're
getting
into
specs
where
you're
a
group
of
competitors
are
agreeing
on
one
way
to
do
something
and
that's
going
to
be
baked
in.
For
you
know
a
long
term.
H
Antitrust
is
really
important,
which
is
why
I
think
it
weighs
in
favor
of
using
something
like
a
jdf
or
community
spec.
Rather
than
just
you
know.
The
benevolent
dictator
for
life
model
does
not
work
for
antitrust
purposes
in
in
standards.
So
I
think
it's
really
important
to
recognize
that
the
other
political
question
you
know
how
how
to
pick
a
venue-
that's
all
that's
always
hard.
H
It's
it's
more
art
than
science,
and
you
know
every
standards
body
at
the
end
of
the
day
is
also
a
business
and
they're
going
to
try
to
you
know
you
know,
sell
their
services
and
and
get
you
to
come
to
them.
Oftentimes,
it's
just
finding
the
right
fit.
You
know.
Different
organizations
are
known
for
different
things,
but
another
thing
to
think
about-
and
this
is
where
both
jdf
and
the
community
spec
come
into
play.
They're,
actually
designed
to
to
be
everything
from
a
full-blown
standards
body
that
can
create
international
specifications.
H
If
you
want
to
basically
being
a
venues
for
pre-standardization
so
oftentimes,
it's
a
good
way
to
get
together
with
a
smaller
group
to
test
things
out
and
then
figure
out
if
it
makes
sense
to
take
those
materials
to
a
you,
know,
a
formal
standards
body,
a
w3c
or
something
else,
and
and
so
in
many
ways,
the
jdf
and
community
spec
structures,
while
they've
we
have.
Many
projects
have
been
with
us
for
many
many
years,
they're
also
designed
to
be
disposable.
J
J
I
think
I
think
it
may
be
the
w3c
community
standards
group
that
I
forget
what
they
call
it
exactly.
J
In
our
in
our
ecosystem,
so
it
does
work
and
it
can
work
and
then
and
but
you
take
a
little
care
and
setting
it
up.
You
make
sure
that
you
pick
the
right
licenses
and
the
working
groups
and
and
then
and
then
it
works,
or
at
least
it
can.
H
And
actually,
likewise,
we
currently
have
a
jdf
project
that
is
doing
incubation
work
for
specs.
That
will
go
into
the
the
open
compute
project
as
well,
so
it
is
designed
to
be
able
to
move
specs
around.
A
I
think
my
question
might
be
a
kind
of
follow-up
to
to
this
one.
There
are
certainly
several
small
efforts
I
can
think
of.
I
should
say
small
because
that
there
are
targeted
efforts
and
I
think
in
our
communities
where
groups
of
folks
are
kicking
the
tires
on
kind
of
that
initial
pass
at,
say:
a
community
community
spec,
and
it's
just
a
group
of
like-minded.
A
You
know
and
smart
developers
who
want
to
want
to
collaborate
on
something
and
that
work
may
happen
without
us.
Knowing
about
it
often
does
right
until
some
point
at
which
they
say.
Actually,
we
think
there's
a
there
there
we're
ready
to
like
mature
it,
but
they've
been
perhaps
already
developing
some
work,
products
and
they've
kind
of
created
some
deliverables.
A
Is
there
any
concern?
You
know
that
we
should
be
thinking
about
when
it
when
we
think
about
one
of
these
truly
community.
You
know
created
documents
bringing
that,
because
we
don't
necessarily
know
the
origin
of
the.
H
Yeah,
so
you
know
a
a
a
story
that
comes
to
mind
is
when
open
id
was
formed,
so
open
id
was
basically
you
know
a
identity
spec
that
was
developed
by
a
bunch
of
you
know
open
web
folks.
You
know
in
the
back
of
bars
and
on
napkins,
and
that
was
all
fine.
Until
a
bunch
of
big
corporations
decide
they
want
to
implement
it,
and
then
it
took
about
a
year
to
clean
up
the
mess
to
make
sure
that
all
the
proper
rights
were
in
place
and
that
that
was
painful.
H
But
the
idea
is,
if
you
have
a
group
of
people
that
are
developing
without
any
legal
agreements
in
place
and
then
they
just
start
working
in
the
community
spec
model
itself,
heals
as
far
as
making
sure
that
the
rights
are
cleared.
You
always
have
a
problem,
however,
if
someone
makes
especially
a
significant
contribution
and
then
disappears
without
any
legal
structure
in
place,
and
that's
something
that's
really
difficult
to
deal
with,
and
it's
a
reason
why
you?
H
J
J
You
know
it's
it's
embedded
everywhere,
then
some
somebody
comes
along
with
a
provable
standards,
essential
patent.
That
says.
Oh,
I
contributed
this
because
I
made
a
presentation
to
xyz
and
I
put
my
standards
essential
patent
in
there
and
all
of
a
sudden.
J
Something
shows
up
that
looks
an
awful
lot
like
my
xyz
so
and
then
they
demand
royalties
and-
and
so
that's
just
so,
the
the
kind
of
documentation
requirements
around
a
specification
setting
organization
are
higher,
and
I
gotta
tell
you
my
colleagues
and
I,
when
we,
when
we
work
on
these
projects,
that's
just
one
of
the
that's
just
that's
just
kind
of
our
that
that
that's
the
stone
we
try
to
push
up
the
hill
every
day
and
because
you
just
you
anybody
who's,
making
a
technical
contribution
should
make
the
technical
contribution
under
some
sort
of
a
contributor
license
agreement
and
usually
that's
the
membership
agreement.
J
The
community
specs
sort
of
implies
all
of
that
within
the
nature
of
the
community
spec.
But
the
more
the
ones
that
are
kind
of
entity
based
the
overhead
gets
kind
of
high
on
that,
and
we're
always
trying
to
figure
out
ways
to
improve
that
the
community
spec
has
a
cla
bot
in
it.
That
allows
you
to
kind
of
ensure
that
people
who
are
making
pull
requests
are
actually
authorized
to
make
pull
requests,
but
so
the
you
know
open
source
code,
because
it
is
code
right
you
can.
J
You
can
read
it
like
a
book
and
somebody
adds
a
chapter
to
that
book
that
all
of
a
sudden
you
find
out
has
got
patent
encumbrances
on
it.
You
just
take
the
chapter
out,
but
an
idea
can
get
shot
through
a
specification,
and
so
anytime.
You've
got
kind
of.
The
word
must
in
in
any
anything
you're
dealing
with
in
a
in
a
implementation.
J
It's
probably
turns
into
a
speck,
and
that's
that's
that's,
and
so
you
want
to
take
some
care
around
that,
depending
on
what
you've
got
right.
If
all
you're
doing
is
hacking
away
and
experiment
experimenting
with
something,
you
don't
need
to
worry
about
it
too
much.
But
if
it
starts
to
get
serious
then
then
you
really
want
to
watch
those.
F
Because
structures
of
ours
would
probably
start
in
a
repo,
that's
our
default
is
at
least
in
safer.
Node
is
an
mit
license,
so
you
would
have
some
agreement
under
which
the
contributions
are
made.
Now
I
know
it
doesn't
have
particularly
strong
patent
protection
or
any
potentially,
but
but
is
it
you
know?
I
guess
I
wonder
if,
like
you
know,
does
this
say
our
default
license
should
be
something
different?
Not
you
know
not
that
we
can
necessarily
do
that,
but
would
it
suggests
we
should
do
something
on
that
front.
H
Yeah,
so
for
for
spec
work,
the
mit
license
doesn't
have
the
advantage
of
covering
the
entire
material,
which
means
that
you
can
have
someone
who
makes
one
contribution
and
then
asserts
their
patents
against
implementations
of
the
spec
that
include
other
people's
materials,
and
that's
where
that's
where
the
spec
license
is
the
the
source
code
licenses
fail
for
specs,
and
so
you
know
well,
I
think
the
community
spec
is
is
the
the
is
a
really
really
good
model
at
minimum
I'd
suggest
using
the
open
web
foundation,
agreements
that
are
bound
that
are
specifically
designed
for
specs
the
the
thing
I
I
view
the
community
specification
as
really
a
you
know,
a
a
descendant
of
the
open
web
foundation
agreement,
one
of
the
things
we
found
with
the
open
web
foundation
agreements
is
while
they're,
legally
solid
and
they've
been
widely
adopted.
H
They
do
require
some
overhead
to
get
people
to
sign
up
for
the
the
final
spec
as
well,
so
you
can
still
be
left
hanging
and
they
come
with
that
administrative
burden,
where
you
know
years
of
experience,
taught
us
to
make
it
more
automatic
and
not
require
that
admin
overhead,
which
is
why,
again,
I'm
going
to
push
you
to
the
community
specification,
but
you
should
at
least
have
something
that's
designed
for
for
specs.
F
I
was
more
like
sort
of
going
off
of
joey's
question
about
you
know.
Typically,
today
we
might
have
people
start
to
collaborate
in
one
of
their
existing
repos,
that's
likely
to
be
something
like
an
mit,
and
then
you
realize
like
okay.
This
is
something
more
sort
of
you
know.
Is
there
anything
we
should
be
thinking
about
in
terms
of
being
best
positioned
to
handle
that
case
or
is
it
or
is
that
like
about
as
good
as
the
you
know,
best
practice
people
achieve
today.
H
Yeah,
so
what
I'd
say
is
if
you
have
a
a
team,
that's
looking
to
do
both
code
and
spec.
H
H
H
So
again
for
code,
I
have
no
problem
with
apache.
It's
designed,
for
it
includes
a
patent.
This
explicit
patent
grant,
I
think
you
know
in
practice
the
mit
and
apache
serve
basically
the
same
purpose,
but
neither
one
is:
is
that
applicable
to
spec
because
keep
in
mind-
and
maybe
I
didn't
say
this
before-
but
the
difference
is-
is
that
yours,
your
code
license,
is
covering
specific
lines
of
code.
H
H
So
if
you're
gonna
have
everyone
using
the
same
code,
then
maybe
the
mit
license
is
okay.
You
know,
sometimes
you
you
decide
we're
gonna
have
interop
by
just
everyone
using
the
same
code,
then
the
source
code
license
is
probably
fine.
If
you're
talking
about
people
independently
implementing,
then
you'll
want
a
spec
license.
K
Oh,
I
was
just
if
I
find
myself
having
to
you
know,
explain
to
somebody
why
why
one
might
want
one
kind
of
license
over
another?
Would
it
be
accurate
to
say
you
know
for
for
an
open
source
project?
You
want
to
contribute
like
contribution,
you
know
many
one-time
contributions
and
contributions
from
a
large
number
of
people,
and
so
you
know
having
it
that
your
the
contributions
are
narrowly
scoped.
K
You
know
any
any
intellectual
property
you
give
relates
to
just
the
small
bit
you're
changing,
whereas
with
the
open
source
with
a
with
a
with
a
specification
license,
you've
you've
got
a
a
a
smaller
number
of
long-term
contributors,
and
the
scope
is
the
entire
project.
K
H
H
Open
source
works
where
we're
all
going
to
be
collaborating
on
the
same
code
base
and
using
that
particular
code
base
and
and
forking
is
okay,
a
spec
code,
a
spec
license
is
more
intended
for
something
that
is
going
to
have
independent
implementations
and
generally
is
you
know
something
that
you
want
to
be
stable
for
a
long
amount
of
time.
So,
using
my
my
you
know,
power
outlet.
Example.
H
I
want
to
make
sure
I
can
get
a
license
to
the
entire
power
outlet.
Whoever
makes
it
I
should
be
able
to
go
home
depot
and
buy
any
brand,
and
it's
just
gonna.
It's
gonna
work
and
I
don't
have
to
worry
about
it.
You
know
no
one
licenses,
the
you
know
a
little
piece
of
of
of
the
socket,
because
I
don't
care
about
the
end
of
the
little
piece
I
care
about
the
thing
as
a
whole,
so
I
think
it's
really
to
me.
The
main
distinction
is
independent
implementations.
J
That
contribution
applies
to
the
scope
of
the
specification
so
because
what
you
don't
want
to
have
happen
is
if
I'm
acme
corporation
and
I've
got
a
standards
essential
patent.
That
applies
over
a
lot
of
stuff
and
I'm
giving
a
ramsey
license
to
something
in
a
narrow
channel
of
endeavor.
J
K
J
Not
mean
that
I'm
giving
my
patent
away
to
everybody
for
any
kind
of
use,
and
so
scoping
is
is,
is
a.
J
Important
feature
when
you
make
a
specification-
and
the
other
thing
I
think
michael
mentioned
about
you-
know
there
you're
doing
some
things
in
node.js,
that
or
in
I
forgot
where,
where
it
was,
but
that
that
he
said
it's
starting
to
take
shape
as
a
specification.
And
what
do
we
do
to
you
know?
Should
we
just
use
the
community
spec?
J
I
think
one
of
the
good
things
to
do
too
is,
if
you
create
a
community
spec
start
over
and
have
everybody
drop
their
contribution
in
as
a
new
thing,
because
it
gives
you
it
kind
of
washes
it
through
the
the
the
the
licensing
filter.
And
so
nobody
says:
oh
wait,
a
minute
I
didn't
realize
I
was.
I
was
granting
this
license
for
that,
because
we
just
transferred
the
whole
body
of
work
back
into
a
a
specification
effort.
Just
haven't
make
the
contribution
new
into
the
specification
effort.
B
I
don't
know
if
we
have
any
other
questions.
I
know
we
are
running
out
of
time,
so
I
appreciate
everyone
joining
as
I
mentioned,
jori
and
I
are
going
on
a
bit
of
a
project.
Road
show
to
get
to
kind
of
share
information
about
the
projects
and
standards.
B
J
B
A
And
thank
you
very
much
david
and
seth.
This
has
been
really
interesting
and
I
am
definitely
excited
to
kind
of
learn
more
from
our
community
about
what
they
want
to
do
and
then
sort
of
triangulate
that
and
see
where
we
can
and
perhaps
collaborate
with
them
with
the
jdf
on
community
specs.
So.