http://www.techradar.com/pro/linux March 2020 LXF260 49Kate Stewart INTERVIEW
the server space, so we needed to get
reference Linux ports. Well first off we
decided to get the GCC toolchains working
and go from there. I started learning about
it as a manager rather than a developer.
My developer days were doing POWER
optimisations back at IBM, but by that
point, in the early 2000s, I was a manager.
It’s probably a slightly different path than
how most people get into open source.
Anyhow, we used Linux to bring these
systems up, and we’d gone through the
whole legal issues of getting copyright
assignments to the FSF so that we could
get our architecture contributed upstream.
I very much believed open source was one
of the saner ways of doing things and was
much more supportable long term. The
magic is that you do something, someone
else does a little bit more, and these
solutions keep getting contributed back.
So there’s no need to worry about things
going stale and patch porting.
From there I went to the embedded
space and then to Canonical. I was
Ubuntu’s release manager for two years
and I learned an awful lot about open
source there. When I was doing embedded
stuff at Motorola/Freescale there’d be
about 500 packages in a BSP. So moving
to Ubuntu, which has tens of thousands
of packages, and trying to get all of that
released on schedule was a challenge.
I learned a lot about community
there too, about what works and whatdoesn’t work. Communities are a gift,
and it’s important not to take them for
granted. After that I was doing product
management at Linaro, and trying to figure
out where it made sense to collaborate
with new areas in that ecosystem.
Throughout all of that I’d actually had a
project at the Linux Foundation, SPDX,
which you may have heard of.LXF: Yes! It’s all about keeping track of
open source licenses in projects. I went
to a talk about it a couple of years back.
KS: Right, so what we’re trying to do with
that is improve the software transparency
of the ecosystem, so people actually
understand what they’re shipping and
what they have installed on their system.I ran into issues at Freescale because we
had no way of sharing license information.
We’re trying to make Zephyr a first-
class citizen in that respect. Each file is
licensed, so it’s very clear which license
you’re working under when you contribute
to that file. Zephyr is one of the few
projects, the Linux kernel is another,
that’s a Developer Certificate of Origin
(DCO) project. So when you contribute
to it you retain your copyright, and you’re
contributing under the license of thefile, you don’t have to sign a Contributor
License Agreement (CLA) or a copyright
assignment, so it’s fairer, I think, to
developers. That’s my personal opinion,
but I’m very much a fan of the DCO,
I think it makes a very good basis for
communities. That was definitely one of
the lessons we picked up from Linux.LXF: I guess in Linux things can get really
muddy, because some of those files
have unclear provenance and find their
way into other projects that are working
under other licenses. I guess it’s nice
to be starting with everything explicitly
licensed in Zephyr.
KS: One of the things I’ve been working
on with Thomas Gleixner, PhilippeOmbredanne and your friend Greg K-H
is cleaning up the licensing in the kernel.
Right now 79% of all the kernel source files
have a license identifier at the top, then
there’s a variety of interesting cases we’re
going to be working on to finish it off.
The idea is you shouldn’t have to sit
there [trying to track down licenses]. I
was seeing people trying to use artificial
intelligence to figure this out. Uh uh, totally
attacking the problem from the wrong
side. Garbage in, garbage out. Again. So
fix it in the source, and let it come up
from there. That way if someone copies
your file, which happens all the time, that
license information is there.
With Zephyr we’ve been very careful
about our licensing. I do a couple of passes
every now and then to make sure we’re still
keeping that discipline.LXF: Well I guess it’s nearly time to wrap
up, and I’m not sure we can get more
exciting than reindeer. But do you have
other interesting applications or animals
that Zephyr has been used with, or in?
KS: Actually the aspect of taking Zephyr
to places where it can be used within,
like inside your body, is why we’re really
starting to focus on safety. There’s other
use cases too, but being able to get Zephyr
to where you can have enough provenance
associated with it and then follow the best
practices in that sense, that’s a goal for us.
I’ve got a lot of friends who have
medical devices implanted in them, and
they want access to that source code. I
think everyone has that right, whether
the device is running Linux or Zephyr
or something else. I think if you’ve got
devices in your body you want to know
what’s running on them.MAKING ZEPHYR TRANSPARENT
“We’re trying to make Zephyr a first-class
citizen in that respect. Each file is licensed,
so it’s very clear which license you’re
working under when you contribute.”
4446March 2 h6r0789h08 March 2020 LXF260 49
Kate Stewart INTERVIEW
the server space, so we needed to get
reference Linux ports. Well first off we
decided to get the GCC toolchains working
and go from there. I started learning about
it as a manager rather than a developer.
My developer days were doing POWER
optimisations back at IBM, but by that
point, in the early 2000s, I was a manager.
It’s probably a slightly different path than
how most people get into open source.
Anyhow, we used Linux to bring these
systems up, and we’d gone through the
whole legal issues of getting copyright
assignments to the FSF so that we could
get our architecture contributed upstream.
I very much believed open source was one
of the saner ways of doing things and was
much more supportable long term. The
magic is that you do something, someone
else does a little bit more, and these
solutions keep getting contributed back.
So there’s no need to worry about things
going stale and patch porting.
From there I went to the embedded
space and then to Canonical. I was
Ubuntu’s release manager for two years
and I learned an awful lot about open
source there. When I was doing embedded
stuff at Motorola/Freescale there’d be
about 500 packages in a BSP. So moving
to Ubuntu, which has tens of thousands
of packages, and trying to get all of that
released on schedule was a challenge.
I learned a lot about community
theretoo,aboutwhatworksandwhat
doesn’twork.Communitiesareagift,
and it’s important not to take them for
granted. After that I was doing product
management at Linaro, and trying to figure
out where it made sense to collaborate
with new areas in that ecosystem.
Throughout all of that I’d actually had a
project at the Linux Foundation, SPDX,
which you may have heard of.
LXF: Yes! It’s all about keeping track of
open source licenses in projects. I went
to a talk about it a couple of years back.
KS: Right, so what we’re trying to do with
that is improve the software transparency
of the ecosystem, so people actually
understand what they’re shipping and
what they have installed on their system.
I ran into issues at Freescale because we
had no way of sharing license information.
We’re trying to make Zephyr a first-
class citizen in that respect. Each file is
licensed, so it’s very clear which license
you’re working under when you contribute
to that file. Zephyr is one of the few
projects, the Linux kernel is another,
that’s a Developer Certificate of Origin
(DCO) project. So when you contribute
to it you retain your copyright, and you’re
contributingunderthelicenseofthefile,youdon’thavetosignaContributor
License Agreement (CLA) or a copyright
assignment, so it’s fairer, I think, to
developers. That’s my personal opinion,
but I’m very much a fan of the DCO,
I think it makes a very good basis for
communities. That was definitely one of
the lessons we picked up from Linux.LXF: I guess in Linux things can get really
muddy, because some of those files
have unclear provenance and find their
way into other projects that are working
under other licenses. I guess it’s nice
to be starting with everything explicitly
licensed in Zephyr.
KS: One of the things I’ve been working
on with Thomas Gleixner, PhilippeOmbredanne and your friend Greg K-H
is cleaning up the licensing in the kernel.
Right now 79% of all the kernel source files
have a license identifier at the top, then
there’s a variety of interesting cases we’re
going to be working on to finish it off.
The idea is you shouldn’t have to sit
there [trying to track down licenses]. I
was seeing people trying to use artificial
intelligence to figure this out. Uh uh, totally
attacking the problem from the wrong
side. Garbage in, garbage out. Again. So
fix it in the source, and let it come up
from there. That way if someone copies
your file, which happens all the time, that
license information is there.
With Zephyr we’ve been very careful
about our licensing. I do a couple of passes
every now and then to make sure we’re still
keeping that discipline.LXF: Well I guess it’s nearly time to wrap
up, and I’m not sure we can get more
exciting than reindeer. But do you have
other interesting applications or animals
that Zephyr has been used with, or in?
KS: Actually the aspect of taking Zephyr
to places where it can be used within,
like inside your body, is why we’re really
starting to focus on safety. There’s other
use cases too, but being able to get Zephyr
to where you can have enough provenance
associated with it and then follow the best
practices in that sense, that’s a goal for us.
I’ve got a lot of friends who have
medical devices implanted in them, and
they want access to that source code. I
think everyone has that right, whether
the device is running Linux or Zephyr
or something else. I think if you’ve got
devices in your body you want to know
what’s running on them.MAKING ZEPHYR TRANSPARENT
“We’re trying to make Zephyr a first-class
citizen in that respect. Each file is licensed,
so it’s very clear which license you’re
working under when you contribute.”