Subject: Re: The NetBSD developers agreement vs. The Ubuntu Code of Conduct
To: None <netbsd-users@NetBSD.org>
From: Jeffrey A. Edlund <jae-bsd@glaxonlabs.com>
List: netbsd-users
Date: 09/03/2006 18:44:32
On Sun, 3 Sep 2006 15:35:20 -0700 (PDT)
Stefan Bozhilov <stefabov@yahoo.com> wrote:

> 
> >Martin Husemann <martin@duskware.de> wrote: A few
> >people asked about details of the agreement that
> >NetBSD developers
> >are required to sign.
> >
> >Since there is nothing secret about this contract, we
> >have just put up
> >the complete, original contract here:
> >
> >  http://www.netbsd.org/developers/agreement.txt
> >
> >The only modification in this copy (besides the CVS
> >tag) is obfuscation of an
> >internal mailing list address (to avoid spam).
> >
> >Section III(c) (no disclosure of private information)
> >might be slightly 
> >irritating (although I personally think it is a
> >standard paragraph, I have
> >a similar one in my work contract too): this is not
> >about hiding the
> >secret cabal (there is none), but (a) to make sure
> >information on developer
> >private mailing lists is respected as such, and (b)
> >needed for The NetBSD
> >Foundation to be able to sign NDAs with third parties
> >(which actually 
> >sometimes happens).
> >
> >Martin
> 
> 
> I would describe the this agreement as draconian. Its
> sole purpose seems to be a complete control over the
> poor developers. They cannot say anything (section III
> (c)) or show code to anybody (section III (e) 2) if
> the Board disapproves it. The entire agreement seems
> to be head down. The purpose of the Foundation should
> be legal protection of developers NOT legal threats!
> Individual developers should sign NDAs and the
> Foundation can provide assistance, but it should not
> be a side in the agreement. No wonder, the project is
> so stagnant. Who would sign off his right to speak up
> in return for the privilege to write free code? Who
> would agree to be sued for talking (go prove who said
> what) in return for the privilege to work late at
> night ... for free? And then there is even "a year
> after" clause. This agreement is incompatible with any
> kind of free or open software development. 
> 
>  Best Regards,
>  Stefan

I agree with Stefan.  Even if Thor's comment about the USL's agreement
with NetBSD isn't completely correct (I'm not trying to make a judgement
either way) it's a good example of why signing NDAs is a bad idea and
should be avoided if at all possible. 

On Fri 01 Sep 2006 at 22:36:01 -0400, Thor Lancelot Simon wrote:
> We have repeatedly been the victims of a particularly ugly kind of
> rumormongering, specifically claims that NetBSD is "tainted", contains
> source code we are not entitled to distribute, or so forth.  It is an
> unfortunate fact that for many years we could not effectively respond
> to those claims (which were false) because our agreement with the owners
> of the Unix source code, which required us to remove certain files that
> had been distributed by Berkeley in Net2 and 4.4BSD, had a binding
> confidentiality clause.

The whole "discussion" going on in the "History of the NetBSD
Foundation" and "The future of NetBSD" threads makes it clear (to me at
least) that having publicly accessible archives of internal
discussions would be a benefit. Of course there might be a need to
have private communication between members of the security team, but
this could be minimized and/or cleared for release afterwards.

Ubuntu has a code of conduct [1] that developers sign which makes a lot
more sense to me and seems to solve a lot of these problems. Although
something could be added to the "Be considerate" section about not
adding code that you don't have a legal right to add.

best wishes, 

Jeffrey


[1] http://www.ubuntu.com/community/conduct

= Ubuntu Code of Conduct =

This Code of Conduct covers your behaviour as a member of the Ubuntu
Community, in any forum, mailing list, wiki, web site, IRC channel,
install-fest, public meeting or private correspondence. The Ubuntu
Community Council will arbitrate in any dispute over the conduct of a
member of the community.

      '''Be considerate.''' Your work will be used by other people,
      and you in turn will depend on the work of others. Any decision
      you take will affect users and colleagues, and we expect you to
      take those consequences into account when making decisions. For
      example, when we are in a feature freeze, please don't upload
      dramatically new versions of critical system software, as other
      people will be testing the frozen system and will not be
      expecting big changes.

      '''Be respectful.''' The Ubuntu community and its members treat
      one another with respect. Everyone can make a valuable
      contribution to Ubuntu. We may not always agree, but
      disagreement is no excuse for poor behaviour and poor
      manners. We might all experience some frustration now and then,
      but we cannot allow that frustration to turn into a personal
      attack. It's important to remember that a community where people
      feel uncomfortable or threatened is not a productive one. We
      expect members of the Ubuntu community to be respectful when
      dealing with other contributors as well as with people outside
      the Ubuntu project and with users of Ubuntu.

      '''Be collaborative.''' Ubuntu and Free Software are about
      collaboration and working together. Collaboration reduces
      redundancy of work done in the Free Software world, and improves
      the quality of the software produced. You should aim to
      collaborate with other Ubuntu maintainers, as well as with the
      upstream community that is interested in the work you do. Your
      work should be done transparently and patches from Ubuntu should
      be given back to the community when they are made, not just when
      the distribution releases. If you wish to work on new code for
      existing upstream projects, at least keep those projects
      informed of your ideas and progress. It may not be possible to
      get consensus from upstream or even from your colleagues about
      the correct implementation of an idea, so don't feel obliged to
      have that agreement before you begin, but at least keep the
      outside world informed of your work, and publish your work in a
      way that allows outsiders to test, discuss and contribute to
      your efforts.

      '''When you disagree,''' consult others. Disagreements, both
      political and technical, happen all the time and the Ubuntu
      community is no exception. The important goal is not to avoid
      disagreements or differing views but to resolve them
      constructively. You should turn to the community and to the
      community process to seek advice and to resolve
      disagreements. We have the Technical Board and the Community
      Council, both of which will help to decide the right course for
      Ubuntu. There are also several Project Teams and Team Leaders,
      who may be able to help you figure out which direction will be
      most acceptable. If you really want to go a different way, then
      we encourage you to make a derivative distribution or
      alternative set of packages available using the Ubuntu Package
      Management framework, so that the community can try out your
      changes and ideas for itself and contribute to the discussion.

      '''When you are unsure,''' ask for help. Nobody knows
      everything, and nobody is expected to be perfect in the Ubuntu
      community (except of course the SABDFL). Asking questions avoids
      many problems down the road, and so questions are
      encouraged. Those who are asked should be responsive and
      helpful. However, when asking a question, care must be taken to
      do so in an appropriate forum. Off-topic questions, such as
      requests for help on a development mailing list, detract from
      productive discussion.

      '''Step down considerately.''' Developers on every project come
      and go and Ubuntu is no different. When you leave or disengage
      from the project, in whole or in part, we ask that you do so in
      a way that minimises disruption to the project. This means you
      should tell people you are leaving and take the proper steps to
      ensure that others can pick up where you leave off.

= End Ubuntu Code of Conduct =