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

Rafał Pocztarski r.pocztarski at gmail.com
Fri Feb 6 19:11:58 UTC 2015


On Thu, Feb 5, 2015 at 2:16 PM, Zluty Sysel <zluty.sysel at gmail.com> wrote:
>
> Could you however elaborate on why the additional restriction would
> not be OSD-compliant? Do you think it could be reworded so that it
> does become compliant?

The Open Source Definition by Open Source Initiative (as well as The
Free Software Definition by FSF) seems pretty clear about restricting
the distribution of software.

There are some difficult edge cases and sometimes the issue whether a
license meets the open source definition is hard to know at a first
glance, but restricting the distribution of the software in any way is
pretty much a non starter.

Your issue is pretty simple, really. If you insist on including the
private keys in your software (which is the only reason why the
software license should even mention them at all) then (ignoring some
quite obvious security implications) however you reword it you won't
have a license that meets the definition of open source (or free
software) and there seems no way around.

But even if you could somehow reword it in such a way that would make
it technically meet the definition, then the question is, how could I
know if I can redistribute a software that I get from someone if it
has a restriction that it cannot include one of your keys, and I can't
know whether it does unless I know your keys. Who knows, maybe one one
day you create a key that is a string "open source" and suddenly the
software stops being open source, just because it happens to contain
that string somewhere in the README (and your license doesn't specify
where it cannot contain the keys).

If, on the other hand, you don't include the private keys in your
software then what is the point of restricting their distribution in a
license of software that doesn't even include them at all. Would you
add to the license of a music player a special clause restricting its
distribution if someone happens to add some copyrighted music into its
source tree or would you rather make it part of the licence of that
music instead?

In any case, if you want your software to be considered open source
then you should make sure that your license, whatever you finally
choose or create, meets the Open Source Definition (and the same goes
for free software and The Free Software Definition), and that it is
also included in the appropriate lists of licenses kept by the Open
Source Initiative and the FSF, as many people look for licenses there
to make sure they are open source/free software licences.

You can submit your license to the Open Source Licence Review Process
here and it is pretty well explained on how to do it correctly:
http://opensource.org/approval

Of course the easiest way to make sure that your software is
recognized as being open source would be to use some of the well
established licenses instead of creating yet another one but of course
everyone can write a new licence, however problematic that might be in
practice.

Some useful resources:

The Free Software Definition by Free Software Foundation:
https://www.gnu.org/philosophy/free-sw.html

The Open Source Definition by Open Source Initiative:
http://opensource.org/osd-annotated

Report of License Proliferation Committee:
http://opensource.org/proliferation-report

The Debian Free Software Guidelines:
https://www.debian.org/social_contract#guidelines

Best regards,
Rafał Pocztarski.



More information about the License-discuss mailing list