[CUWiN-Dev] **IMPORTANT** Proposed CUWiN Developer Agreement

Matt Isaacs isaacsm at cuwireless.net
Wed Oct 18 15:52:13 CDT 2006


bBrandon,

I just noticed your questions and comments futher down in the
document.  I missed them as they were interspersed with the text of
the agreement.  Sorry about that.

Some clarification is probably in order as well.  The agreement is
designed to be a general-purpose, overarching document.  The plan is
to make it as general, basic, and short as possible, and then create a
set of policies/guidelines that should be followed.
Policies/guidelines would include things like, what is private and
what is public, etc.  They tend to be things that are more negotiable
as well.

To address your questions:

There are public and private versions of the repository.  Public
versions are, of course, public.  The private version currently
contains things that pertain to our local work and specific
configurations, however it could also contain "privileged code," that
is, non-opensource code we've arranged to be able to
use/modify/incorporate, but are not allowed to distribute the actual
code to, only binaries.  We currently do not have any such situations.
 The public/private can also be extended to other resources.  For
instance, this mailing list is public (as it is openly accessible),
however the staff list is not.  Basically, the way it works now, if
something is private you are told that when given access.  The general
rule here is that if you can get it/do it w/o and special action on
our part, its public, otherwise assume its private.

Your second question is related to the first.  Private
code/information is stuff the Foundation has requested to not be
redistributed.  Tainted code is code that may hold a copyright or a
non open source license that we can not legally use or distribute (ex.
some encyption algorithms, the wma code--if we had access, binaries
under a non opensource lisence, etc).

This is also not directly related to part (b).  Part (b) says the
developer shouldn't use Foundation resources for unlawful purposes.
This is broader than tainted code (which has a degree of
unlawfulness).  Part (b) means things like not using our servers or
bandwidth to distribute illegal media or other, more general, unlawful
things (including, perhaps, as a hop to anonymize oneself when trying
to hack some).

I hope this clarifies things.

On 10/4/06, Matt Isaacs <isaacsm at cuwireless.net> wrote:
> Good point Brandon.  I'll see about working something like that in there.
> As a point of reference, we used the NetBSD developer agreement as a model.
> Oddly enough licensing/copyright isn't something they addressed in it.
>
>
> On 10/4/06, Brandon Bowersox <brandon at ojctech.com> wrote:
> >
> >
> > Matt,
> >
> >
> >
> > Thank you for your work drafting this important foundational document.  I
> have 2 questions and comments mixed in below....
> >
> >
> > Also, I wonder why the agreement doesn't talk about assigning copyright.
> I imagine all developers automatically assign copyright for their code to
> the foundation.  That way we know that all CUWiN code can be publicly
> disseminated and no developer can come back in 10 years and try to claim it
> was their intellectual property and we each owe them licensing fees.  I
> would appreciate a statement in this document spelling out that this is an
> open source project and each person's contributions are given over to the
> public good and ownership is held by the Foundation.
> >
> >
> > Brandon
> >
> >
> >
> > On Oct 4, 2006, at 3:49 PM, Matt Isaacs wrote:
> >
> > Listed below is a proposed draft for a CUWiN developer agreement.
> >
> > Please review it and forward any comments to the Dev list (
> cu-wireless-dev at lists.cuwireless.net ).
> >
> > We need your feedback prior to Wednesday, October 11.
> >
> > Thank you.
> >
> >
> >
> >             CUWiN Foundation Developer Agreement
> >
> > Welcome to The CUWiN Foundation.  This Agreement is a binding
> > contract between you and The CUWiN Foundation, Inc., and
> > describes the terms of your participation as a developer for the
> > Foundation.
> >
> > Section I - Definition of terms
> >
> > For the purpose of this document the following terms are defined:
> >
> > (a) `The Agreement' is defined as The CUWiN Foundation
> >     Developer Agreement (this document).
> >
> > (b) `The Foundation' is defined as The CUWiN Foundation, its
> >     Board of Directors, and individuals and groups authorized by
> >     the Board of Directors to carry out certain actions.
> >
> > (c) `The Board' is defined as the Board of Directors of the
> >     CUWiN Foundation.
> >
> > (d) `The Developer' is defined as someone to whom The Foundation has
> >     offered developer privileges, in accordance with its policies, and who
> >     has signed the Agreement.
> >
> > (e) `The Repository' is defined as the collection of source code
> >     and historic records contained in the CUWiN master source
> >     repository.
> >
> > (f) `Commit' is defined as the act of adding to, removing from,
> >     or otherwise altering the contents of The Repository.
> >
> > (g) `Tainted Code' is defined as code for which redistribution by
> >     either The Developer or The CUWiN Foundation would be unlawful,
> >     a violation of applicable licenses or restrictions, or a
> >     violation of this or other contracts to which The Foundation
> >     or The Developer is a party.
> >
> > (h) `Private Information' is defined as information that is
> >     accessible to The Developer but is not available to the general
> >     public, or previously private information that was released
> >     in violation of the Agreement by anyone. Private Information
> >     does not include information which has otherwise become
> >     publicly known, or has been rightfully received from a third
> >     party who is authorized to disclose the information.
> >
> >
> > Section II - Purpose of CUWiN Foundation Membership
> >
> > CUWiN Foundation Developer Privileges are granted for the purpose of
> > developing, maintaining, and otherwise improving the CUWiN
> > Software and participating in other activities related to
> > The CUWiN Foundation. These Privileges are granted pursuant to the
> > bylaws and policies of The CUWiN Foundation.
> >
> > Developers are provided with the following:
> >
> > (a) The ability to make reports, as defined by The Foundation's policies,
> >     to the membership for the purposes of updating the membership on the
> >     progress of the Developer's work, as well as to express the
> Developer's
> >     opinion and concern on issues relating to their work;
> >
> > (b) A CUWiN Developer Account, i.e., an account on one or more
> >     of the computer systems maintained by The CUWiN Foundation;
> >
> > (c) Access to Private Information, including some or all of the
> >     private CUWiN mailing lists, internal documentation, and
> >     internal planning and strategy of The CUWiN Foundation; and
> >
> > (d) Access to The Repository and CUWiN distribution mechanisms.
> >
> > Items (a) - (d) are the only Privileges conveyed to the Developer by the
> > Agreement.
> >
> > Section III - Responsibilities of The Developer
> >
> > The Developer has the following responsibilities:
> >
> > (a) The Developer is considered to be a representative of The CUWiN
> >     Foundation when conducting Foundation business and/or
> >     development efforts.  Therefore, the Developer will abide by the
> >     policies of The Foundation, and will conduct themselves
> >     accordingly.
> >
> > (b) The Developer will not use any resources of The Foundation for
> >     unlawful purposes.
> >
> > (c) The Developer will not disclose Private Information without the
> >     explicit prior permission of The Board or their representative, during
> >     the term of membership and for a two (2) year period thereafter.  The
> >     Developer agrees that the unauthorized disclosure or use of Private
> >     Information will cause irreparable harm and significant
> >     injury to The Foundation which may be difficult to ascertain.
> >     Accordingly, The Foundation shall be entitled to equitable
> >     relief, including, without limitation, an immediate
> >     injunction enjoining any breach by it of this Agreement, in
> >     addition to all other remedies available at law or in equity.
> >     Upon termination of this Agreement, Member shall certify that
> >     no copies of Private Information remain under the Member's
> >     personal control or on Member's computer equipment.
> >
> >
> >
> > This section regarding Private Information gives me some concern.  If I
> were a potential developer, I would want the Foundation to clearly tell me
> which information is private -- once the foundation gives me Privileges to
> (a)-(d) above, I would not want to risk accidently sharing information that
> the Foundation felt was private.  Could we require that the Foundation write
> the word "PRIVATE - CONFIDENTIAL" at the top of everything that shall be
> considered private?  Can you give an example of anything private that
> developers would get access to by signing up as developers?
> >
> >
> >
> >
> > (d) The Developer will not Commit Tainted Code to The Repository.
> >
> > (e) The Developer may not redistribute a particular piece of source
> >     code or differences between two pieces of source code
> >     (hereafter referred to as `The Obtained Code') obtained
> >     from The Repository if:
> >
> >     (1) redistribution of The Obtained Code by either The Developer
> >         or The CUWiN Foundation would be unlawful, or
> >
> >     (2) The Foundation has requested, in accordance with the Foundation's
> >         policies,  that The Developer not redistribute The Obtained Code .
> >
> >
> >
> > Can you provide examples of (1) and (2) here?  Since the whole repository
> and all the code in it are publicly available and not Tainted, it seems that
> all of the code or diffs obtained would be freely publicized.  I can't
> imagine how there would ever be a problem like (1), or why the Foundation
> would ever request that we not distribute this code like (2).  If
> redistribution were somehow unlawful, it would already be prohibited under
> section (b) above.
> >
> >
> >
> > (f) The Developer will hold The Foundation harmless and indemnify
> >     The Foundation in any action resulting from The Developer's
> >     intentional or negligent breach of these responsibilities.
> >
> > In the event that The Developer does not fulfill the above-stated
> > responsibilities, some or all of the privileges outlined in Section II may
> > be restricted or revoked.
> >
> > Section IV - New Versions of The Agreement
> >
> > The Foundation may from time to time, at its discretion, update
> > the Agreement in whole or in part.  Newer versions of the
> > Agreement will be published by The Board, or their representative, to the
> > CUWiN Developers Mailing List (xxxxxxxxxxxxx at CUWiN.org
> > <mailto: xxxxxxxxxxxxx at CUWiN.org>) and to The CUWiN
> > Foundation Web Site (http://www.CUWiN.org/) sixty (60) days
> > before they are to take effect.
> >
> > The Developer agrees to be bound by updated versions of the
> > Developer Agreement, or immediately resign their status as a Developer and
> > waive all privileges thereof, and agrees that continued use of
> > Foundation resources (including membership on private Foundation
> > mailing lists) after the effective date of new versions of this
> > Agreement will constitute affirmative acceptance of new versions
> > of The Agreement.
> >
> > Section V - Termination of the Agreement
> >
> > This Agreement may be terminated by The Developer at any time by
> > sending a resignation message to The Foundation, in accordance with the
> > Foundation's policies.
> >
> > The Foundation reserves the right to terminate agreements with
> > Developers, especially if:
> >
> > (1) they have been inactive (as defined in the policies of The
> >     Foundation) for more than two (2) years, or
> >
> > (2) they have repeatedly and/or severely violated the policies
> >     of The Foundation, or violated the terms of The Agreement
> >
> > After termination of The Agreement by either party, sections
> > III(b) through III(f) shall remain in effect.
> >
> > Section VI - Agreement between The Developer and The CUWiN
> >          Foundation, Inc.
> >
> > I, the under-signed Developer, accept the privileges and
> > responsibilities associated with becoming a CUWiN Foundation
> > Developer as outlined above.  I understand that either myself or The
> > CUWiN Foundation, represented by The Board, or by a Committee in
> > charge of Developer affairs appointed by The Board, reserve the
> > right to terminate this Agreement and my CUWiN Developer's Account
> > at any time.
> >
> > This Agreement shall be governed by and construed in accordance
> > with the laws of the State of Illinois, USA.  Each party to this
> > Agreement submits to the non-exclusive jurisdiction of the state
> > or federal courts in Illinois.
> >
> > The Developer:
> >
> >
> > ___________________________
> _______________________________
> > (print name)
> (signature and date)
> >
> > The CUWiN Foundation, represented by its authorized Member:
> >
> >
> > ___________________________
> ________________________________
> > (print name and title)                        (signature
> and date)
> >
> > --
> > Matthew Isaacs
> >
> > CUWiN Network Engineer
> >
> >
>
>
>
> --
>
> Matthew Isaacs
>
> CUWiN Network Engineer


-- 
Matthew Isaacs

CUWiN Network Engineer


More information about the CU-Wireless-Dev mailing list