Licensing options for firmware

[Joel West]

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/