Samba mulls change to copyright policy

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.

The current 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 projects. 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.

Feedback

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 said.

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 harmony

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 development team.