The Samba project has started
discussions to alter its long-standing copyright policy. For years, the
project has accepted only code contributions where the copyright is held by
an individual rather than by a corporation. Under the proposed change, the
project would accept corporate-copyrighted code, but would still prefer
that its contributors submit work as individuals.
Jeremy Allison posed the question to the Samba community in a July 12th email to the samba-technical mailing list. He described the proposal as coming from himself and Andrew Tridgell, a solicitation for input from the broader Samba community before putting the issue to a vote by Samba team members themselves.
policy is detailed on the project's site, along with a note that
contributors for whom a personal copyright is infeasible can also choose to
assign their copyright to the Software
Freedom Conservancy (SFC), which has Samba as one of its member
Because Samba is a clean-room reimplementation of proprietary software, the
project also requires that
developers who have signed Microsoft's CIFS license agreement not submit
code, and that contributors ensure that their patches do not infringe on
known patents. Although all free software projects and developers are well
aware of the
trouble fueled by software patent litigation, Samba is in the minority of
projects by asking its contributors to assert up front that their work is non-infringing.
Contributions, yesterday and today
Allison lists two reasons for the project's historical stance against allowing corporate-copyrighted contributions. First, the team simply preferred that GPL enforcement decisions be made by individuals not by corporations. "Enforcement decisions" would typically include how and when to contact suspected violators, who would speak on behalf of the project, and what course of action to pursue at each stage of the discussion.
The second reason deals specifically with the consequences of a
successfully-resolved license violation — meaning one in which the
violator has come back into compliance. Under GPLv2 (which Samba was
available under prior to the 3.2 release in July of 2007), a violator
automatically loses all rights to modify or distribute the software under
the license (section 4), and those rights can only be reinstated by the
copyright holders' collective decision. Individuals, the Samba project
believes, act much more reasonably in these rights-reinstatement
circumstances than corporations sometimes do.
The termination-of-rights section in GPLv2 is commonly
overlooked (see section 5.2) by casual readers, and was one of the key
points in drafting GPLv3. Because the earlier license did not specifically
address how copyright holders go about reinstating the rights of former
violators, every project could enact its own policy, or be completely
arbitrary on a case-by-case basis. A high-profile example of the confusion
over this issue is Richard Stallman's public argument
that early KDE releases automatically lost their redistribution rights to some
GPL-covered software by combining it with the QPL-licensed Qt toolkit, and
call for the affected copyright-holders to publicly reinstate the project's
rights. In response, KDE called
Stallman's interpretation of the clause "absurd" and refused
to request "forgiveness" as Stallman suggested.
The corresponding section in GPLv3 (section 8) attempts to standardize the situation and provide for a simple reinstatement procedure. A former violator's rights to redistribute the licensed software are reinstated if the violation is corrected and the copyright holders do not make further complaints for 60 days, or if the violator corrects its first violation within 30 days of the first notice. Furthermore, "provisional" permission to redistribute the software is granted as soon as the violation is fixed, pending the expiration of the 30- or 60-day window (whichever applies).
Due to that change, Allison said, the GPLv3 releases of Samba no longer benefited by excluding corporate-copyrighted patches outright. However, he did recommend that the project continue to encourage personal copyrights (or SFC copyright-assignment) over corporate contributions for most code, and continue to ban corporate copyrights for the project's library components or "code that might be moved into a library." Allison does not draw a bright line between the situations where personal copyright would still be required and where it would only be encouraged, but the intent seems to be to free up companies to contribute fixes and patches, rather than to open the door for entirely new features or large modules submitted under a corporate copyright.
The reason for the desire to retain the individual-only policy for more
significant changes is re-licensing (an issue which is also referred to on
the current policy page). Consent of the copyright holder is also required
to re-license the contribution. Although it is not a frequent occurrence,
the Samba project believes that getting assent for the re-license from
individuals is both simpler and faster than getting it from corporations
— which typically require decisions to be made by internal managerial
and legal teams.
Samba has re-licensed portions of its code in the past, notably the tdb and talloc libraries were re-licensed under the LGPL. But for general patches, including "things like build fixes for specific platforms," Allison said the non-corporate policy can only delay or prevent potential contributors from sending in their work.
Both individual and corporate contributors participated in the subsequent list discussion. By and large the community either approved of the proposal or simply deferred to the Samba team's wishes, but there were a few concerns voiced over the split-policy nature of the draft policy.
Simo Sorce, the Samba team GPL compliance officer, speculated as to whether corporate-copyrighted contributions of new features would hinder the team's later ability to split new features into separate libraries (thus triggering the re-licensing problem). Corporate copyrights not only slow down the re-licensing process, he said, but potentially cause greater problems when the corporation in question shuts down or is sold.
Andrew Bartlett expressed
concern that having a more complex policy regarding corporate
copyrights would make it harder to communicate to companies about their
responsibilities, which could slow down development by forcing them to
adjust their engineers' employment agreements. Generally, engineers'
employment agreements (or the legal norms of their jurisdiction) dictate that all code produced while a salaried employee are "for hire" works with the copyright held by the company. Even in those situations where the developer retains copyright, however, he or she must typically get approval from upstairs to contribute.
The select circle of companies who devote employee time to Samba
development must make a contractual exception in order to comply with
Samba's current policy (though judging by list traffic these companies have
been willing to do so because of their desire to contribute to Samba).
Bartlett's concern, then, is that subdividing the copyright policy to
distinguish between different types of code contributions would further
complicate the contracts of corporate-paid Samba contributors. Bartlett
also pointed out that the contribution guidelines need clarification
between code and non-code contributions, which are currently not treated
differently. Clarifying the situation around non-code contributions could
encourage companies to contribute documentation or help to the wiki, he
A week has passed since the initial message to the list, and so far there are no adamant objections, so it appears likely that the new policy (perhaps with clarifications) will eventually go into effect.
In the end, the policy shift is a fairly minor change, and in effect
loosens some of the restrictions on corporate contributions. So it's not
too much of a surprise that there has been little opposition. It is also interesting to observe that the discussion came up so soon after the final release of the much-debated Harmony project, which set out to craft a suite of contributor agreements.
It does not appear that the Harmony project's templates or tools had an influence on the Samba team's decision or process. However, it also appears that the Harmony project's agreements leave several issues of importance to the Samba team unaddressed. Harmony encompasses two separate types of agreement: contributor license agreements (CLAs) and copyright assignment agreements (CAAs). Samba's copyright policy is essentially a CLA, albeit an informal one instead of a signed contract.
The Harmony CLA templates cover ensuring the originality of the submitted code, and deal at length with the project's right to re-license the work as a whole. They do not, however, deal with either the patent-non-infringement issue or the clean-room reimplementation guarantee that Samba requires of contributors. Regarding the re-licensing question, having that permission in place from the beginning might simplify Samba's occasional re-licensing work — although historically it is a rare enough occurrence that the project has never felt the need to address it up front. In his message to the list, Sorce did ask corporate contributors for feedback on the re-licensing process, including the need to get "promises about the kind of licenses we will consider in case changes are needed."
The Harmony CLAs also do not provide a framework for Samba to specify that only contributions under personal copyrights are permitted, however, nor to provide separate rules for minor patches, new functionality, or library code.
The next major release of Samba is version 3.6.0, which is currently in
its second release-candidate testing phase. Allison and the other members
of the team did not set a timeline for a new copyright policy to take
effect — if one is eventually adopted — but presumably it
would not be before the next development cycle begins after a vote of the
to post comments)