Clarification around the DCO

James Bottomley James.Bottomley at
Sat Oct 17 01:20:02 UTC 2020

On Fri, 2020-10-16 at 17:56 -0700, Jeremy Allison via samba-technical
> On Fri, Oct 16, 2020 at 05:43:57PM -0700, Jeremy Allison via samba-
> technical wrote:
> > On Fri, Oct 16, 2020 at 04:59:20PM -0700, James Bottomley via
> > samba-technical wrote:
> > 
> > > We'd also be very interested in bringing Samba back into the
> > > fold of projects using unmodified DCOs.  We now have 17 years of
> > > operating experience and for every other modification request
> > > (and there have been many) we've always found a way to add the
> > > needed clarity to the licence of the file instead of the DCO, so
> > > we really think we could help you make this work for Samba as
> > > well.  It would be really great if we could work together to do
> > > this because Samba is the last outlier using a modified DCO and
> > > with it brought inside the fold we'd have a unified front against
> > > the various CA/CLA abuses corporations try from time to time.
> > 
> > I'm not averse to moving to your "standard" DCO, so
> > long as it doesn't mean chasing down everyone to
> > re-submit :-).
> > 
> > Otherwise, renaming ours to "Samba Developer's Declaration"
> > might seem to work also (with proper (C) attribution
> > added of course).
> Ah, I've just remembered *why* we have a difference from
> your "standard" DCO text.
> In our text we have the clause:
> "(e) I am granting this work to this project under the terms of both
> the
>     GNU General Public License and the GNU Lesser General Public
> License
>     as published by the Free Software Foundation; either version 3 of
>     these Licenses, or (at the option of the project) any later
> version."

OK, so legally LGPLv3 and GPLv3 are the same licence: LGPLv3 is GPLv3
with an additional permission.  Your clause (e) effectively requires
GPLv3 with the additional permission on every contribution.

> The reason for this is that Samba as a whole is under
> GPLv3, but there are many useful libraries within Samba
> (talloc, tevent, tdb etc.) that started life as an integral
> part of Samba - so GPLv3, but then external projects wanted
> to use them without being bound by GPLv3 terms, so asked
> us to re-license under LGPLv3.

Right so what you really want is some event to trigger the addition of
the permission that changes the licence from GPL to LGPL.  This more or
less is why the apache model is broad inbound grant coupled with
licensing by the project board to the contributor, so the board
decides.  Without this governance trigger effectively the whole of
Samba is LGPL because every contribution was required to have the
additional permission.

Obviously, a lot of open source projects don't like the apache inbound
!= outbound model (and don't have a real governing board), so something
else has to be the trigger.  The model I've always liked is all code in
X (usually lib/) is under the LGPL, so the trigger is accepting a patch
moving the code under X.  You can see this with the efitools project,
which is under GPLv2 but shares its lib/ code with shim, which is under
BSD-2-Clause.  This is how the licence of efitools copes:

The trigger is very rudimentary and hasn't really been changed for 8
years, so perhaps we could craft something better for Samba.

> We have done this for a number of our libraries, and will
> probably do this for more in future (I'm expecting our
> async LDAP library tldap will eventually be requested
> to be moved to LGPLv3 once it's matured enough).
> Doing it without clause (e) is a pain, as we have to
> track down all contributors and check if this is OK.
> With our clause (e) it allows us to re-license more
> permissively as required without the burdon of tracking
> down all contributors.
> Hope this explains things better. I doubt you'd want
> something like this inside the Linux DCO (but I'm
> happy to be proven wrong :-).

Well, I think the efitools model above shows it can be done within the
DCO framework so I think we have a basis for exploration of whether
this can work for Samba as well.


More information about the samba-technical mailing list