Hacker News new | past | comments | ask | show | jobs | submit login

As someone who has a highly ambivalent attitude toward the military for very real, legitimate reasons I'd love it if you could elaborate. I myself live that way now, as in; I don't work for the military, anyone who subcontracts to the military or the homeland security, etc. And it is precisely for reasons that would push one to include a no-military-use patent on OCB. fwiw I'm not intimately familiar with the figures involved, I know who they are, read some of bernsteins code/math/writing, and no vaguely who Rogaway is (but haven't yet had a chance to read the "moral character" essay).



It is basically incompatible with both Open Source and Free Software definitions. ie:

"6. No Discrimination Against Fields of Endeavor" https://en.wikipedia.org/wiki/The_Open_Source_Definition

and

"The freedom to run the program as you wish, for any purpose (freedom 0)." https://en.wikipedia.org/wiki/The_Free_Software_Definition


It happens that Rogaway added an explicit license for open-source software, regardless of military use, relatively recently (2013).

http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm

Part of the history here is that OCB used to have a patent grant for all GPL software, again regardless of military use, and then in 2012 authorized Mosh to use it under GPL + two exceptions.

https://github.com/mobile-shell/mosh/blob/master/ocb-license...

(In the general case, yes, such a restriction on use makes it non-free / non-open-source, which makes it annoying for people who want to use the software through an intermediary like Debian.)


However, Rogaway also issued a separate patent license for free and open source use (which does not exclude military uses).

http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf

So while it's true that free and open source software would not be able to impose a no-military-use restriction, Rogaway in this case is exempting free and open source projects from that restriction.


>> However, Rogaway also issued a separate patent license for free and open source use (which does not exclude military uses).

That's true, and if you were making a one off library like NaCl OCB might be a good choice. But the restrictions means it couldn't be adopted into any standard for interoperable software. Though ISTR that recently there was another license grant that allows it to be incorporated into TLS.

In addition because it was never adopted into any standard interoperable software it didn't get as much scrutiny as it might have otherwise, and so even for a one off you might be skeptical.

The long and short of it is that if OCB hadn't been patented at the time it was invented it probably would have "won" and been widely used. GCM was invented several years later, has some worse performance characteristics, and AFAICT considerably harder to implement well in software. Instead it is something that is taught but rarely used in practice. Whether Rogaway prefers this world to the counterfactual one, only he knows.


Free and open source software don't allow that sort of restriction. So while Rogaway's intentions are honorable, the results aren't coherent.


I'm not 100% sure, but I think this is a choice of one of a few licenses for the software rather than a dual license. The licenses aren't coherent if you apply the licenses simultaneously, but I think only one of the licenses need apply to the software for a given user.

So you can release free and open source software which might be used for military purposes, OR you can release closed sourced software, but it can't be used for military purposes. The effect is that if your software will be used for military purposes you have to release it as free and open source software.

In this case it's not a dual license where you're bound by the terms of both licenses, it's a situation where you choose one of the licenses based on which set of terms you can comply with. Multi-option licenses like this are frequently used for proprietary software to enforce tiered pricing (such as nonprofit/personal/corporate licenses all applying to the same software but different licensees).

This is my interpretation, but I'm not a lawyer. I wouldn't stake my business on my interpretation without consulting a lawyer and neither should you.


The fact that the current formulation of the details of most open source licences don't allow restrictions against military use doesn't make them incoherent. Just like you can argue that open source software makes the world a better place, you can argue that making the military more powerful makes the world a worse place.


> Free and open source software don't allow that sort of restriction. So while Rogaway's intentions are honorable, the results aren't coherent.

I'm not quite sure what you're referring to, but I don't think any interpretation is quite right.

* "No existing FOSS license limits military applications of its covered software." That's true, but Rogaway's license doesn't even limit military applications of covered software either.

* "If a FOSS license limited military applications of its covered software, it wouldn't qualify as a FOSS license." Also true, but Rogaway's license doesn't do that.

* "Some FOSS licenses try to make it hard to grant a patent to some of their users but not to all." Also true, but Rogaway's license probably doesn't do that (depending on how we interpret the part about "Software Implementation"), and not all licenses have this property.

* "If a patent grant is specific to a particular program, FOSS projects can't accept or rely on it as a matter of policy." Maybe true for some projects, but this concern comes up more regularly for copyright licensing rather than patent licensing, and not part of the definition of FOSS licensing, and Rogaway's license only refers to the licensing style rather than the identity of the program.

* "If a patent grant is specific to FOSS, then FOSS projects can't accept it as a matter of policy." I don't think this is true at all; I think many FOSS projects have been quite happy to rely on such licenses in the past and I think there are a number of precedents for them. (That doesn't mean that the developers or projects necessarily think that software should be patentable or that they should require a license in the first place.)

I agree with the observation that Rogaway's licensing terms have discouraged standards adoption of the technology, but I don't see how they would forbid individual free and open source projects from adopting it.

I think people may have been confused by the presence of alternative patent licenses; recall that license #1 requires only FOSS (not non-military), while license #2 requires only non-military (not FOSS). If license #1 would be sufficient for FOSS projects to benefit from in the absence of license #2, it should still be sufficient in the presence of license #2. (Edit: geofft also points out that the terms of the licenses have changed over time and that #1 used to be GPL-specific -- but I think my observations still apply in the case of GPL-covered projects.)


One big reason is that with this restriction his algorithms almost certainly won't be included in any of the common security standards (FIPS 140 and NIST 800-53 are the primary ones in the US), which means that anyone who needs to follow those standards won't be able to use it.


That was the point though, no?


No, those standards dictate how many organizations beyond the military adopt security protocols.


That's a side effect. The intended purpose of those standards are government procurement.


ah, yes. that should have been obvious I suppose. thanks.


Just a guess, but maybe wtbob is getting at the fact that odd licenses are generally GPL-incompatible or otherwise awkward or ambiguous. See for example, the JSLint license https://en.wikipedia.org/wiki/JSLint#License


thanks for replying.


Did you read the OP? It is addressed there.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: