4 ms·

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

by yarrel 11y ago

kerkeslager 11y ago
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.
dave2000 11y ago
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.
schoen 11y ago
> 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.)

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

by yarrel 11y ago

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

kerkeslager 11y ago

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.

dave2000 11y ago

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.

schoen 11y ago

> 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.)