[License-discuss] 3-clause BSD with additional clause forbidding key disclosure

[Cinly Ooi]

On 5 February 2015 at 17:33, Johnny A. Solbu <johnny at solbu.net> wrote:

> On Wednesday 4. February 2015 15.37, Zluty Sysel wrote:
> > The issue here is one of trust from stakeholders that do not have
> > enough familiarity with the open source movement.
>
> 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.
>
>
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.


> > The code is already separated in a way that isolates the Private Key
>
> How are they separated?
> I think a little info on how you currently do it might give better
> understanding among those who give advice on this list.
>
>
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.

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.



> > there have been
> > instances of these keys leaking into the public domain in the past,
> > and the persons in charge want to avoid that happening again. This is
> > unfortunately out of my control so my goal here is to try and find a
> > middle-ground solution that allows us to open source a bunch of code
> > for the benefit of everybody, users and company alike.
> > That is why they insisted in modifying the 3-Clause BSD to include an
> > explicit ban of the Private Key redistribution,
>
> As I see it, there is no middle ground. Either it is open source or it is
> not.
> 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.
>

Agreed.

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.


> But this rises another question: Will those keys be distributed with the
> downloadable source code?
> 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.
>
> 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.
>
> > and what I am trying
> > to find out with these emails is whether that additional clause would
> > be in contradiction with the Open Source Definition.
>
> As I see it, it does contradict the Open Source Definition.
>
>
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.

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.

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.

> If that additional clause turns out to be incompatible with the OSS
> > standards, then we will go back to the drawing board and start
> > negotiating a different solution.
>
> The suggestion from a few of us is to license the key separate from the
> rest of the software.
> I don't see any other way to do it if you want to make the software Open
> Source.
>
>
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?

HTH
Cinly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20150205/15cef58e/attachment.html>