[copyleft-next] Redline

Richard Fontana fontana at sharpeleven.org
Sat Feb 9 06:16:12 UTC 2013


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


More information about the copyleft-next mailing list