ECE / BaS August 2015 - page 10

August 2015
10
T
OOLS
& S
OFTWARE
Open source vs. proprietary:
an embedded hardware issue
By Michael Parks, P.E.,
and Lynnette Reese,
Mouser Electronics
Fewer things ignite
more passion in software
geeks than the debate of
open source versus
proprietary code,
but when going to market
with an embedded system,
sometimes you don’t
get a choice.
„„
Source code has a lot to do with the con-
cerns that businesses have concerning control
of their destiny and future costs. Source code
is a set of human-readable (mostly) instruc-
tions that tell a processor what to do. Before
it can be used by a computer it must be com-
piled or interpreted into binary object code.
If you have the source code, you can mod-
ify it and recompile it to meet your speci c
needs. You can also do an independent review
to ensure there are no bugs or hidden back-
doors. Operating systems can also be open
source and therefore transparent, but work
at a deeper level on the processor to provide
interrupt handling, peripheral management,
and more.
With open source, you are not beholden to
another party to keep your product work-
ing. Proprietary-based systems, if they are not
home-grown and thus belonging to you are
open to the possibility of getting “orphaned”
if the proprietary so ware is abandoned. For
example, an operating system (OS) might be
purchased from and maintained by another
company, but what happens if that company
gets bought by your competitor? Updates
and bug xes would be done to their sched-
ule. Worse, you might be ordered to cease and
desist using the so ware immediately. On the
other hand, if you go with an open source com-
piler or operating system, you need to know
what you are doing; open source is rarely turn-
key in the embedded world. You also need to
have reasonable expectations of what the open
source maintenance community can do with
respect to your need-for-speed in going to
market, since open source may adopt a speci c
technology at a comparatively glacial pace. You
can always roll up your sleeves and create and
contribute to the open source community for
what you need, but even then the acceptance
into the formal repository (e.g. the maintained
Linux “tree” for a speci c embedded processor)
may not proceed as you would like. If you do
not contribute your changes back to the com-
munity, which is entirely legal, no one will help
you maintain it but you, no matter how good
you think it is (this is known as “forking” the
code). Sometimes you don’t have a choice in
whether you use proprietary or open source,
however.
A processor may not have an open source
operating system, so ware, or tools.
e
immediate choice is to use a proprietary ver-
sion, or if you have the time, start an open
source tree or library on your own. It would
be remiss not to include a mention about
open source hardware (OSHW). OSHW is
similarly “open,” especially if source les for
the schematics are provided, but the openness
may stop at the doorstep of the SoC, processor,
or a support chip on the board. OSHW can
also be supported by proprietary development
tools, as well, depending upon the processor.
Nevertheless, an open source movement is
afoot, inspired perhaps by Linux.
Both open source and proprietary so ware
have equal shares of misconception. Further
complicating matters for open source is the
vast number of licenses that can confuse even
the savviest technologist.
e Open Source
Initiative states, “Open source so ware is so -
ware that can be freely used, changed, and
shared (in modi ed or unmodi ed form)
by anyone. Open source so ware is made by
many people, and distributed under licenses
that comply with the Open Source De nition.”
Some of the most popular open source licenses
include the Creative Commons, Apache License,
BSD, GNU General Public License (GPL), MIT
License, and the Mozilla Public License. For a
complete listing, you can head over here. Open
source licensing varies, but a typical license
ensures that if you build or expand on an open
source project, you are given attribution and
those who build upon your work must also
release their code under the same license. is
prevents someone else from unfairly pro t-
ing from your hard work, or at the very least,
making it much harder to do so. Open source
so ware is fundamentally about sharing and
gaining wisdom from the crowd. Many larger,
1,2,3,4,5,6,7,8,9 11,12,13,14,15,16,17,18,19,20,...56
Powered by FlippingBook