[Cryptech Core] ipr, ghu forbid

[Patrik Wallström]

Sorry for top-posting. This is a large subject, and I just want to add some to it.

There is one thing to have rights on standards documents, and another thing to have ipr on implemented software/hardware.

I believe the copyright is a non-issue really, since we are using the BSD license. I believe we have decided to use the BSD license for all code, right? Any rights-holder can then keep their copyright on the code, as long as it is under the same license. We use this model in the OpenDNSSEC project, and I believe it is quite common in other BSD licensed projects as well.

However, to protect the name Cryptech as you speak of in the beginning, you can do that by using trademarks. Trademarks has been successfully been enforced by for example Mozilla Firefox. Anybody who patches the source, and package it for you have to change the name, as it is no longer endorsed by Mozilla. I have been involved with other projects that has been using the same model for protecting the name. One example is a bandwidth measuring tool, where we wanted to protect the name so nobody could use it while changing the method of measuring bandwidth which would output other results.

I am not sure what it would take for third parties to ship Cryptech hardware, but I guess most of them would make some changes to the design. This is also what I believe is our plan. So by having a license on the trademark that explicitly says what is required to use it is needed, if we go this way.

Here you can find more on Mozilla Trademark Policy: http://www.mozilla.org/en-US/foundation/trademarks/policy/

On 16 May 2014, at 18:48, Randy Bush <randy at psg.com> wrote:

> < thinking aloud >
> 
> like it or not, the cryptech project produces stuff with ipr.  i am
> heavily influenced by the ietf model, so feel free to whack me.
> 
> we need to be explicit about ipr
>  o so others can not claim to be a direct cryptech design (think
>    poison), unless they actually are of course
>  o so someone can ajudicate licensing questions ("can i do x with y?")
>  o we need to walk further down the path of cc/bsd and what rights
>    statements we put on sources, documents, ...
>  o so we know how to handle incoming ipr - i.e work that is contributed
>    both as the result of pay-for-work and pro-bono contributions that
>    is covered by ipr in some form.
>  o ...
> 
> cryptech ipr probably falls into a few classes,
>  o stuff cryptech engineers do for pay
>  o stuff non-paid folk agree to license to cryptech (under what terms?)
>  o stuff cryptech adapts from other sources (and is constrained by the
>    license conditions of those sources)
>  o ...
> 
> the ietf has The IETF Trust (http://trustee.ietf.org/), which holds the
> ipr (rfcs, drafts, ...) of the ietf.  unlike the ietf, the ietf trust is
> a real legal entity, so it can actually hold the ipr.  it is constrained
> by the Trust Agreement.  it is way too complicated because the ietf and
> the ietf trust were extracted from CNRI in a method analogous to a root
> canal and pulling a wisdom tooth.  i would hope something far simpler
> would do the job for cryptech.
> 
> ---
> 
> leif has suggested one proposal for the "incoming IPR" case:
> 
>    Anyone who wants to make a contribution to cryptech that is covered
>    by IPR must agree to publish an Internet-Draft describing how the
>    technology covered by the IPR is used in the context of the cryptech
>    design and must make an IETF IPR statement covering said I-D which
>    would be acceptable (i.e a non-discriminatory, non-exclusive,
>    permanent grant of a free license to use within the specific context
>    on which cryptech relies) under normal conditions of IETF standards
>    work.
> 
>    In other words we tie ourselves to the IETF trust!
> 
>    That would allow some researchers to keep their patent bonuses
>    (which is a big deal for some).
> 
> ---
> 
> i am somewhat wary of this as internet-drafts are ephemeral.  but i get
> what leif is trying to do here.
> 
> i can probably get free legal for this once we have consensus on what we
> actually want.
> 
> randy
> _______________________________________________
> Core mailing list
> Core at cryptech.is
> https://lists.cryptech.is/listinfo/core

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.cryptech.is/archives/core/attachments/20140518/a973530f/attachment.sig>