Clarification around the DCO

[James Bottomley]

On Fri, 2020-10-16 at 19:38 -0700, Bradley M. Kuhn via samba-technical
wrote:
> Jeremy Allison via samba-technical wrote:
> > Ah, I've just remembered *why* we have a difference from your
> > "standard" DCO text.
> 
> Yes, a tremendous amount of time and effort went into figuring out
> the right policy for Samba with regard to contributor
> licensing.  Some of those details were reported publicly, and some
> were reported privately to the key folks in Samba.  I myself put in
> many hours of work on this, as did many other Conservancy staff,
> lawyers and Samba volunteers.  Nothing has changed with regard to the
> analysis.  We also had a private discussion at a developers' meeting
> at a Samba XP about the reasoning, IIRC.

In legal terms you usually really, really don't want to be special
because it causes all sorts of complications if there's any litigation.
This reasoning lies at the heart of our desire to move the DCO beyond
the kernel, because if we keep it to the kernel it becomes our legal
specialness problem in the same way.

> Obviously, if Samba wants to redo that analysis at this time, we'll
> do what needs to be done to help Samba as a member project.  But I
> don't see any reason given here to redo that work.

In 2013 there was only one other of these LGPL/GPL migrating
permissions under DCO solutions, but even then I don't think your
analysis found it?  Now with the expansion of the DCO system there are
several, all still using unmodified DCOs and seven years later also
with a reasonable history of operation.  Since none of this was
included in the original analysis, isn't it worth considering now?

> I already made a merge request days ago about changing the name and
> there is a thread discussing that (but consensus hasn't been
> reached).  The name really doesn't matter, but the content of the
> terms certainly do.  What works for Linux as a project doesn't work
> for everyone.  One size doesn't fit all.

In some ways the DCO is still an experiment that we're gathering data
on, but the data do seem to say that apart from Samba it does actually
work for everyone else.

> James has every right to his stated agenda of getting the whole world
> to use the unmodified DCO, but the statement that Samba is "outside
> the fold" for failing to use the specific terms is just rhetoric.

It's more a statement of the current facts.  However the logic
underlying it is that by doing something different Samba places itself
in some legal uncertainty and having a counter example to the standard
DCO adds a scintilla of legal uncertainty to the rest of the DCO
ecosystem.  Samba not calling it a DCO removes our side of the
uncertainty.  Samba adopting the DCO, if the community chooses to do so
, would remove all uncertainty.

> Samba doesn't use Linux's license (GPLv2-only) either, and is
> unlikely to want to switch to GPLv2-only.

That's a bit of a red herring: the DCO was deliberately made licence
agnostic.  It's currently used unmodified in projects using LGPLv2
GPLv2 only, v2+, v3, Apache and a whole host of other licences.

> But changing your contributor licensing terms is as big a change as
> changing the license of the project itself.  It's not usually
> considered particularly friendly for folks outside a project to come
> by and ask for the project to change its license details.

I can assure you there's no sinister motive.  It's purely what I said
above: reduction of legal uncertainty for everyone.

> Finally, changing the *name* of your developer representation
> statement and its *contents* are very different discussions and
> should not be conflated.  The former is an easy change and purely
> cosmetic.  The latter is hard and will change policy and legal
> outcomes for Samba.  IANAL and I'd want Samba to get confidential
> legal advice from a lawyer that represents Samba's interest (as
> it received back in 2013) before making the latter change.

Our expectation is that Samba can update the licence in some files (so
there would be some file patching to be done) and slide in a standard
DCO without any change in effect on the current or prior project
contributions, but obviously everyone needs to be comfortable that this
is the net effect.

> I suggest the community first consider the name change and execute
> it, and then only after that's done consider whether the contents
> need to change.

As I said to Jeremy, mature consideration is definitely required and
we're not trying to rush anybody into this.

James