No Nukes Licensing, the Real Question

No Nukes Licensing, the Real Question 

A number of licenses have clauses stating that the software is not for use in a nuclear facility. The implications have never been completely clear to me. This has been a recent topic of interesting discussion and debate on the Apache legal list.

Black Duck tracks about 2700 licenses in our KnowledgeBase. The Open Source Initiative (OSI) has approved only about eighty licenses. So, we can’t strictly say these are all open source licenses. More accurately, the list comprises “licenses for software freely available on the Internet.” Many are one-off variants on common open source licenses. Some, like the one in question, just include one additional clause.

The Breadth of License Variation

Often when I’m talking about open source licensing, to give the audience of the breadth of variations (as well as to amuse), I’ll cite a few of the crazy variants like the Beer License, the Chicken Dance License, and the JSON (“for good, not evil”) License. I also mention the no nukes licenses, but have never been quite sure how to interpret these qualifications.

So it was instructive to see the topic come up on the Apache list. The debate was about a version of the BSD with the addition of this little clause:

You acknowledge that this software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility.

It’s generally agreed that an open source license may not have field of use restrictions. But (warning, not a lawyer) this has never struck me as a restriction so much as a statement, just making double-sure on the no-liability clause.

Read about the dramatic shifts in open source license enforcement

No Nukes Licensing Discussion

Well, that was exactly the question under discussion. It sounds like most lawyers feel this is clearly intended to keep the software from being used for that purpose, but to some it is simply a liability warning. It’s important to the Apache Foundation, because they are careful not allow any licenses with field of use restrictions. (See how they recently dealt with the JSON License.) My literal reading still leans away from this being a restriction, but someone in the thread made a pretty compelling point: There’s already a strong, general liability disclaimer, so why is another necessary?

What do you think? FOU restriction or just a liability disclaimer?

As one sage participant in the discussion observed, there’s no right answer — until a court decides. And the question may never be raised in court. For the Apache Foundation, the question at hand may be a more practical one. The organization’s mission is “to provide software for the public good.” They do double time to be a trusted source of easily consumable software. So the real question is, do they want Apache projects to utilize software with licenses so open to debate?

0 Comments
Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.
0 Comments

MORE BY THIS AUTHOR

Can Blockchain and the BTC License Fund Health Insurance?

| Jul 26, 2017

The BTC license hit my radar screen recently. Billed as “sexy” by the author, the permissive BTC license employs Blockchain and may signal a new trend going forward that could transform the way many developers work... and how they get their health insurance. Background I chair the Linux

| MORE >

3 Examples of Why Permissive Licenses Deserve a Little Respect

| Jun 21, 2017

To the extent that tech companies manage open source risks, their primary focus tends to be on reciprocal licenses and the GPL in particular. As I've discussed earlier, the potential risks of open source are broader than just license compliance. Additionally, there are other licenses to consider

| MORE >

Encryption Technology in Your Code Impacts Export Requirements

| Jun 6, 2017

US export laws require companies to declare what encryption technology is used in any software to be exported. The use of open source makes complying with these regulations a tricky process. US Export Requirements The regulations on US software exports come from the US Commerce Department’s

| MORE >