On Fri, Feb 08, 2013 at 12:23:00PM -0500, Pamela Chestek wrote:
If this is inappropriate for the full list then reply separately, but I thought I'd start by asking here as part of the further exploration of the Github-Gitorious kerfuffle.
It is appropriate since it concerns the Harvey Birdman Rule.
Why is redline so objectionable? It is simply another form of version control and is available in LibreOffice.
[...]
I appreciate that redline is incompatible with Git and so is inappropriate for this project. But I am a bit puzzled by what seems to be antipathy to redline in general, which I just see as another form of version control and perhaps better suited to text documents that the Git functionality.
This is a good question, and requires a very lengthy answer. I begin by acknowledging that (as some people said early on) git is really an over-powerful tool for a license-drafting project.
Also, there may be some on this list who do not know all of the following: Many lawyers do a lot of drafting of documents, sometimes collaboratively/negotiatively with other lawyers internal or external to their organization. By some time in the 1990s, lawyers were most commonly doing this by personal use of word processing software that has 'redline' functionality. Redline functionality visually shows changes from earlier versions of a document, typically using strike-through for deletions and underlining for additions. I cannot overemphasize the degree to which the contemporary legal profession is dependent on such word processing software (today most commonly Microsoft Word), to the point of discomfort with plain text as an editable format, an aversion to or unfamiliarity with plain text editors, and a relative unfamilarity with technologies that involve manipulation of plain text documents.
Reason 1: Desire not to alienate project constituency
The target user constituency for the copyleft-next project is contemporary software developers and other technically-oriented individuals interested in free software/open source project development and/or FLOSS legal issues. It seemed to me to make some sense to focus on using tools and practices that are most familiar to participants in contemporary community FLOSS projects. This way, such persons could more easily get involved or at least observe what was going on in this project.
That constituency tends not to use word-processing software at all, proprietary or otherwise, except when absolutely necessary for tasks having nothing to do with FLOSS project activities (and probably associated with drudgery). And I suspect when they do occasionally use word processing software, they aren't likely to use or be familiar with redline functionality.
So if it became a common mode of collaboration to email redlines around, which of course would be natural if copyleft-next were some lawyer collaboration effort, I believe this would alienate the target user constituency of this project. At best it would discourage participation and drive away interest until the project was substantially complete.
Allowing collaboration by redline would undoubtedly make it easier for lawyers to participate, but at the expense of participation by individuals from other professional cultures. Which brings me to Reasons 2 and 3.
Reason 2: Lawyers are not the target constituency
Unquestionably lawyers are useful for a license-drafting project because many of them know a lot of relevant legal stuff or at least know what they don't know.
As an aside, Bradley has sometimes said that lawyers didn't get involved in FLOSS licensing until a fairly late stage. I do not think this is borne out by historical evidence.
But lawyers are not the target of this project, other than that small subset of lawyers who might, as individuals, start FLOSS projects. If the goal (however remotely achievable) is to get software developers to consider use of copyleft-next, lawyers will not aid this process in any socially useful way. Most projects do not have legal counsel (and it is my experience that few community projects seek legal advice on license selection anyway). I specifically don't want lawyers recommending to clients the use of copyleft-next as a proprietary upsell mechanism, to the point of having one or two notable license provisions aimed at discouraging such use.
While lawyers may advise corporate clients on license selection for 'open sourced' projects, the use of strong copyleft licenses for corporate-initiated open source projects, benign or otherwise, is unquestionably in decline, and I haven't particularly expected copyleft-next under the best of circumstances to arrest that development. The main relevance of lawyers in the context of this project is as a source of friction in the desire of a business to make use of some upstream copyleft software. Minimization of that friction is a goal, by making the license as commercially reasonable as possible consistent with its policy goals, but the whole thing is too speculative for lawyer involvement in the project itselt to be a major objective.
Because lawyers are not the target constituency, we don't need to go out of our way to make it convenient for lawyers to participate (by adopting or tolerating the alien collaboration customs of the contemporary legal profession). The most helpful and interested lawyers will probably find a way to participate within the norms of the project. You've certainly demonstrated this, as has Luis Villa. I see some hopeful signs of a potential merge request by Aaron Williamson.
Reason 3: History suggests lawyer dominance is problematic
This one is a bit difficult to explain.
Here I am influenced deeply by the experience of GPLv3. While GPLv3 was drafted by a small group of people within the FSF and its counsel, lawyers for commercial vendors and end-users of Linux and other GPL-licensed software had a significantly influential external role, and unquestionably a far more influential role than individual developers and users of GPL-licensed projects. Mostly-non-developer individual users actually had more influence than developers. What I now would say was the most important potential constituency for GPLv3, actual individual software developers working on authentic community GPL-licensed projects, was largely uninvolved and arguably mostly ignored.
It is no secret that I believe that GPLv3, like GPLv2 and the Apache License 2.0 and the BSD and MIT licenses and the EPL and MPL 2.0, not to mention every COTS and negotiated proprietary software licensing agreement, is a license with imperfections, susceptible to improvement. What's different about GPLv3 is that many of those imperfections resulted from the nature of the unique drafting process I described, one in which I'd say that commercial lawyers had too much influence relative to other constituencies. Maybe it wasn't so much the fault of lawyers as the effect of the combination of such lawyers with the FSF and its counsel coupled with the relative non-influence of project developer constituencies.
I saw an echo of those problems in the later Project Harmony effort (~2010), which had a big impact on me.
I can't explain why the Apache License 2.0 has the imperfections it has, but I think I understand some of the reasons for GPLv3's imperfections. One way to guard against them from recurring in a present-day license-drafting project, I believe, is to carefully limit the potential influence of commercial legal profession culture. Have transparent public communications rather than the private conference calls or other confidential communications that many lawyers may seem to be more comfortable with. Require lawyers to make the effort to adopt the methodology of free software project developers (which may help them with the underlying subject matter) rather than the other way around. And so no redlines, because if you start allowing redlines, I don't know where it stops. I realize (at least at present) this is kind of a silly concern since few people have heard of or care about copyleft-next, but it seems reasonable to prepare for the unlikely possibility that interest in copyleft-next might grow.
I hope that explanation was understandable and helpful.
- RF