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.
Why is redline so objectionable? It is simply another form of version control and is available in LibreOffice.
My challenges with Github were that I could not figure out how to compare my last revision to anything but the most previous commit. In a case where all I had changed from the previous commit was an uppercase letter to a lowercase, that wasn't particularly helpful. In order to compare my latest iteration to the base document I was revising, I took copies and compared them in LibreOffice because I couldn't figure out how to do it any other way. I concede I don't know if there was a way to do it if I was using Git proper and knew how to use it, though.
The other challenge was changing my mind. There was one addition I made in one commit, then changed my mind and took it out, which was a second commit. In a LibreOffice redline it would have simply disappeared. I suppose you can argue that it shouldn't, and you should have insight into my every keystroke, but I think that's overkill when it's a contemplative process.
I found the commit process apparently requires more forethought about when to commit that what I exercised (sorry Richard). Ideally one would commit at logical iterations, but I don't find it very easy to do that when revising a text document, where I often jump around and change my mind after I've read and absorbed more. Richard broke out my changes into logical issues after the fact, but they didn't get created so logically.
I also find a redlined document no harder to read than a version comparison, it's pretty clear what's what (unless you have too many cooks before accepting changes). It's also easy to do, just turn it on.
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.
Pam
On Fri, Feb 8, 2013 at 9:23 AM, Pamela Chestek pchestek@gmail.com wrote:
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.
My main objection is that redline is more like a lossy facility for a particular class of annotations than version control. When I really want to see what has changed substantively between two word processor files, I export to plain text and do a wdiff. I admit that for a small number of people working intensively on a document over a short time period, track changes can be more natural. But that's not what copyleft-next is.
Not relevant for copyleft-next, but I'd love better, standard tooling around version control, annotations, and Open Document Format documents. Aren't in-house things along those lines one of the reason for MSOffice lock-in at law firms? Purely conjecture and hearsay, I have no knowledge of such things.
Mike
Hello,
On 02/08/2013 06:23 PM, Pamela Chestek wrote:
My challenges with Github were that I could not figure out how to compare my last revision to anything but the most previous commit. In a case where all I had changed from the previous commit was an uppercase letter to a lowercase, that wasn't particularly helpful. In order to compare my latest iteration to the base document I was revising, I took copies and compared them in LibreOffice because I couldn't figure out how to do it any other way. I concede I don't know if there was a way to do it if I was using Git proper and knew how to use it, though.
github as far as I know does not have a way to compare arbitrary diffs, similarly the "github for windows" desktop application does not seem to have such a feature either.
On the commandline "git diff" allows you see the difference between any range of commits. (Or if you have a GUI diff tool installed "git difftool" can give you a nicer view of the same changes).
The other challenge was changing my mind. There was one addition I made in one commit, then changed my mind and took it out, which was a second commit. In a LibreOffice redline it would have simply disappeared. I suppose you can argue that it shouldn't, and you should have insight into my every keystroke, but I think that's overkill when it's a contemplative process.
I found the commit process apparently requires more forethought about when to commit that what I exercised (sorry Richard). Ideally one would commit at logical iterations, but I don't find it very easy to do that when revising a text document, where I often jump around and change my mind after I've read and absorbed more. Richard broke out my changes into logical issues after the fact, but they didn't get created so logically.
In general, when working on code, the projects I'm involved in prefer to keep the full commit history even if this includes false starts or invalid approaches or other chunks of code which do not end up in the final branch. So, for code, we prefer to preserve the contemplative process.
However, other projects have different policies, and git does give you various tools to "squash" various commits into a single commit, specifically "git rebase --interactive" and "git merge --squash".
I also find a redlined document no harder to read than a version comparison, it's pretty clear what's what (unless you have too many cooks before accepting changes). It's also easy to do, just turn it on.
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.
As a developer, I prefer working with plain text files, as all the tools I use work on plain text files (or streams). My antipathy is to word processor software in general, not redline in particular :)
-- kuno / warp.
Thanks, all very helpful info.
Pam
On Fri, Feb 8, 2013 at 5:25 PM, Kuno Woudt kuno@frob.nl wrote:
Hello,
On 02/08/2013 06:23 PM, Pamela Chestek wrote:
My challenges with Github were that I could not figure out how to compare my last revision to anything but the most previous commit. In a case where all I had changed from the previous commit was an uppercase letter to a lowercase, that wasn't particularly helpful. In order to compare my latest iteration to the base document I was revising, I took copies and compared them in LibreOffice because I couldn't figure out how to do it any other way. I concede I don't know if there was a way to do it if I was using Git proper and knew how to use it, though.
github as far as I know does not have a way to compare arbitrary diffs, similarly the "github for windows" desktop application does not seem to have such a feature either.
On the commandline "git diff" allows you see the difference between any range of commits. (Or if you have a GUI diff tool installed "git difftool" can give you a nicer view of the same changes).
The other challenge was changing my mind. There was one addition I made
in one commit, then changed my mind and took it out, which was a second commit. In a LibreOffice redline it would have simply disappeared. I suppose you can argue that it shouldn't, and you should have insight into my every keystroke, but I think that's overkill when it's a contemplative process.
I found the commit process apparently requires more forethought about
when to commit that what I exercised (sorry Richard). Ideally one would commit at logical iterations, but I don't find it very easy to do that when revising a text document, where I often jump around and change my mind after I've read and absorbed more. Richard broke out my changes into logical issues after the fact, but they didn't get created so logically.
In general, when working on code, the projects I'm involved in prefer to keep the full commit history even if this includes false starts or invalid approaches or other chunks of code which do not end up in the final branch. So, for code, we prefer to preserve the contemplative process.
However, other projects have different policies, and git does give you various tools to "squash" various commits into a single commit, specifically "git rebase --interactive" and "git merge --squash".
I also find a redlined document no harder to read than a version
comparison, it's pretty clear what's what (unless you have too many cooks before accepting changes). It's also easy to do, just turn it on.
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.
As a developer, I prefer working with plain text files, as all the tools I use work on plain text files (or streams). My antipathy is to word processor software in general, not redline in particular :)
-- kuno / warp.
______________________________**_________________ copyleft-next mailing list copyleft-next@lists.**fedorahosted.orgcopyleft-next@lists.fedorahosted.org https://lists.fedorahosted.**org/mailman/listinfo/copyleft-**nexthttps://lists.fedorahosted.org/mailman/listinfo/copyleft-next
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
copyleft-next@lists.fedorahosted.org