Licensing options for firmware

[scott at opentrac.org]

Thanks - I'm reading over that paper now.  Lots of good information, and
food for thought.

What's interesting is that these Japanese radio manufacturers seem to care
very little about what their users here in the US want.  All of the
innovations I've seen them come up with in recent years have been because of
domestic demand - if something spills over into this market, it's just a
byproduct of what they're doing there.

That might get more interesting when I get the hardware done and start
working on improving the protocols - I've already got a development effort
under way (all BSD-licensed stuff), but it's mostly stalled for want of good
hardware.  But the protocol I'm working on is an internationalized thing,
with support for Unicode and such - the current protocol is very US-centric,
based around 7-bit ASCII and English units of measure.  If I start
supporting a Japanese-friendly alternative that runs on my hardware, I
expect they'll take a whole lot more interest.

I've had very little contact with these companies, but from what I've seen
there's quite a difference in corporate attitude and culture compared to the
US and probably Europe.  Perhaps they suffer even more from the 'not
invented here' syndrome?  Americans like to do a lot of brainstorming and
constructive criticism... seems like Japanese like to quietly develop their
ideas independently, and take criticism personally.  Or maybe I'm
over-generalizing.  I suppose it wouldn't hurt to do some reading on the
subject.  I tend to think in terms of what an American business would do,
and it's probably not fair to apply the same assumptions to foreign
companies.

As far as blatant IP theft goes, I think I'd be more worried about China
than Japan.  I might wind up having hardware produced there (for now it'll
all be local), and I've heard horror stories about bootleg units getting
sold out of the back doors of factories.  Even the big guys have gotten bit
by that - I think Nintendo had a chip fab selling their cartridge ROMs on
the black market some years back.  THAT I'm not going to be able to fight.

So... I think my strategy for now is going to be to look into the
dual-licensing some more, and see how I might discourage wholesale
assimilation of my work.  I'd like to be able to label it as true Open
Source, but to tell the truth, I don't think that's done much for my current
BSD-licensed product.  I don't think a non-commercial clause would have cost
me any sales, and I don't seem to have lost any to competitors using the
code.  At least, that I know of.  Granted, this is a far more complicated
project, and will be a larger target.  We'll see...

Thanks again for the excellent information.  Looks like I'd better start
reading.

Scott


-----Original Message-----
From: Joel West [mailto:svosrp at gmail.com]
Sent: Tuesday, April 05, 2005 9:01 PM
To: Scott Miller
Cc: license-discuss at opensource.org
Subject: RE: Licensing options for firmware


Scott,

Just to add to the previous useful suggestions.

Effectively you want to fully release the code but to attach strings to it
to make it less likely that large hardware companies will use it without
paying. (In a 2003 paper, I called this approach "partly open").

Some restrictions (like the viral clauses of the GPL or LGPL) are acceptable
to OSI and FSF and thus you get to call yourself an "open source" (or even
"free software") distribution.

Other restrictions (like most of the Microsoft Shared Source licenses and
some of Sun's licenses) do not satisfy the OSD and thus you can't use the
term "open source" -- but that doesn't mean your code wouldn't be useful to
others nor does it mean it wouldn't be economically feasible. You could
conceivably (using the Rosen or St. Lauren OSS licensing books) draft your
own license, but for once I agree with the lawyers that (like brain surgery)
this is best left to a trained professional.

By the way, there are many licenses compatible with the GPL that are not the
GPL. The FSF publishes a list at
	http://www.fsf.org/licensing/licenses/license-list.html
Getting OSI or FSF to approve your new license would add time and money to
your efforts.

What you're describing is very similar to the "dual license" model used by
MySQL and others. These companies technically conform to the OSD and/or FSF
model, but their restrictions effectively discourage commercial customers
from using the "free" version and so these customers instead pay for a
commercial license. The Valimaki paper at the MIT open source site
	http://opensource.mit.edu/papers/valimaki.pdf
describes how this works.

In particular, your strategy sounds very similar to the Sleepycat Software
business model, and so you might check out the Sleepycat license (a viral
version of the BSD license that is OSI and FSF approved). For embedded use,
the Sleepycat license might be a little bit stronger than the GPL (if the
manufacturers plan to bundle any enhancements at all); it certainly has
worked for Sleepycat to bring device makers (like Cisco) to the table. But
if there's not additional software associated with your device (or if
revealing the additional software is not a big deal) then such restrictions
wouldn't help, and so the downloadable firmware clause might be the way to
go.

I wish I could recommend other resources for the sort of business model
issues you face. If it were big money, then I'd just hire Larry Rosen to
come up with a license that meets your terms. For small money, you should
stay away from legal fees and choose something off the shelf that has the
desired effect. Chapters 6, 10 and 11 of the Rosen book would be well worth
reading.

Finally, there's the practical question of does a license matter? If you're
a little fish facing a billion dollar multi-national, will you be able to
enforce your license (pay the lawyers) if it comes to that? The
MySQL-NuSphere lawsuit is one of the few tests of viral clauses; most of the
other enforcement has happened by letters, persuasion, PR and perhaps a
little bluffing. If you were using the actual GPL, the FSF (or the Software
Free Law Center) might be willing to provide some help in enforcing the
sanctity of the reciprocal clauses. But, as with other cases, when little
companies go to court they typically run out of money before they can win.

Best of luck.

Joel


--
Joel West, Research Director
Silicon Valley Open Source Research Project
http://www.cob.sjsu.edu/OpenSource/