<div dir="ltr"><br>On 5 February 2015 at 17:33, Johnny A. Solbu <span dir="ltr"><<a href="mailto:johnny@solbu.net" target="_blank">johnny@solbu.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday 4. February 2015 15.37, Zluty Sysel wrote:<br>
> The issue here is one of trust from stakeholders that do not have<br>
> enough familiarity with the open source movement.<br>
<br>
They do not need to know the technical issues. Microsofts shareholders do not know how Microsoft distributes any secrets like keys, they just need to trust that Microsoft keep secret what neets to be secret.<br>
<br></blockquote><div><br>So, bottom line is does the stakeholder trust the development team to do the right thing? If not, we have to work on the trust issue.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The code is already separated in a way that isolates the Private Key<br>
<br>
How are they separated?<br>
I think a little info on how you currently do it might give better understanding among those who give advice on this list.<br>
<br></blockquote><div><br></div><div>I think it will be important if we know how it is done as well. My horrible feeling is the private key will be compiled into the binary. If so the private key is probably hopelessly compromised since I will get the private key if I know where to look in the binary.  The only solution is to rework the way the private key is given to the software. <br><br>Otherwise, the standard trick of putting the private key in a directory completely away from the source code tree and in a place where it is extremely unlikely to be distributed together with the source code should elevate any concerns about accidental disclosure.<br><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> there have been<br>
> instances of these keys leaking into the public domain in the past,<br>
> and the persons in charge want to avoid that happening again. This is<br>
> unfortunately out of my control so my goal here is to try and find a<br>
> middle-ground solution that allows us to open source a bunch of code<br>
> for the benefit of everybody, users and company alike.<br>
> That is why they insisted in modifying the 3-Clause BSD to include an<br>
> explicit ban of the Private Key redistribution,<br>
<br>
As I see it, there is no middle ground. Either it is open source or it is not.<br>
Shipping something with a requirement that parts of the distributed software cannot be distributed makes it proprietary, and many distributions will refuse to include it as a result.<br></blockquote><div><br></div><div>Agreed.<br><br></div><div>If  private key has been leaked in the past, then the solution is unfortunately not another layer of legalese. No matter how many words you put in the license, the situation will not change at all. What has to be changed is the practice of where the key is to be kept. You can, for example, write checks in the software that prohibits the private key to be in the same directory tree as the source code.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But this rises another question: Will those keys be distributed with the downloadable source code?<br>
If not, I don't see the need to modify the license. Then you just need to have an EULA forbidding it, that needs to be accepted by those wanting to purchase a key.<br>
<br>
If you do not ship the key with the software (e.g. if one can't obtain the key by simply downloading the source tarball) then you dont need to modify the license.<br>
<br>
> and what I am trying<br>
> to find out with these emails is whether that additional clause would<br>
> be in contradiction with the Open Source Definition.<br>
<br>
As I see it, it does contradict the Open Source Definition.<br>
<br></blockquote><div><br></div><div>I will qualify it as saying the way it is done here looks like it will be a contradiction of Open Source Definition as the organization seems to be unable/unwilling to separate the necessarily proprietary part, i.e., the private key, from the open source part. In the worst case I think the stakeholders that wants to hold back the source code wants to ensure one cannot actually use the open source part unless you get a key from them. If you need to get a key then it will be by definition not open source.<br><br></div><div>However, if a way can be found that the software can be used by substituting the proprietary part with something equivalent in functionality then I will argue that it is open source, even if someone has to write the substitute for the proprietary part.<br></div><div><br></div><div>I am not sure whether 3 clause BSD allows the license text to be modified as that would be covered under copyright. But it is a different discussion.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> If that additional clause turns out to be incompatible with the OSS<br>
> standards, then we will go back to the drawing board and start<br>
> negotiating a different solution.<br>
<br>
The suggestion from a few of us is to license the key separate from the rest of the software.<br>
I don't see any other way to do it if you want to make the software Open Source.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><br></div><div class="gmail_quote">It would be also good engineering practice to separate key from the rest of the software. What happen if the key has to be revoked and replaced?<br><br></div><div class="gmail_quote">HTH<br>Cinly<br><br></div></div></div>