5:36 a.m.
>>>> "Robert" == Robert J Chassell
<bob(a)rattlesnake.com> writes:
Robert> It is not merely picturesque rhetoric, it is true: you do
Robert> not have to spend all your time supporting freedom to be a
Robert> fellow who helps others. In the case of software, you can
Robert> do this by choosing a license.
Excuse me? Richard just denied exactly that possibility to us, in
<E1CctyU-0007l0-D7(a)fencepost.gnu.org>. In general, authors of
derivatives of works licensed under strong copyleft have _no_ choice.
I can choose not to distribute my work on XEmacs, but _the FSF_ chose
XEmacs's licenses many years ago, leaving _me_ with _no_ choice[1] of
license. That's what strong copyleft is all about, removing certain
freedoms in order to protect certain other freedoms, deemed to be of
overriding importance. IIRC, the FSF openly acknowledges this on the
GNU web site among other places. It's a reasonable compromise, but it
is compromise.
XEmacs's documentation problem is simply "collateral damage" in the
FSF's war against proprietary abuses. Richard says "too bad." It's a
clear inconvenience for us, and he could have been more gracious, but
he's exactly right. It is both undesirable and unavoidable.
Robert> and suggested, although he did not say so, that choosing a
Robert> good license, and dealing with legal paperwork, takes a
Robert> great deal of time.
You are correct that I did not say so. However, I did not suggest
that choosing a license takes time. I suggested that dealing with a
license chosen by someone else does. That's what this thread is
about, at least for everyone who has posted except you.
Robert> But that is not true. He framed the issue erroneously.
Wrong. You are trying to switch discussion from the difficulties of
dealing with someone else's license to the simplicity of choosing your
own. That doesn't make my framing of _my_ issue erroneous.
[...]
Robert> which means that XEmacs depends on `security by
Robert> obscurity'. This means that if XEmacs becomes widely
No "if", at least not if GNU Emacs is the standard of "widely used."
;-)
Robert> used, this policy may cause unanticipated trouble.
Wrong again. I am satisfied with the XEmacs strategy as I understand
it because I believe that there is no security, period. The SCO case
proves that. SCO did not attack "code of dubious provenance"; they
went after IBM's well-documented contribution. If the meanest patent
shark in the ocean, IBM, doesn't know what "good papers" look like,
who does? Therefore I do not worry about "unanticipated" technical
trouble when the bad guys simply resort to brute force---lies, FUD and
expensive lawyers---rather than anything resembling legal reasoning.
"The Internet interprets censorship as damage, and routes around it."
Similarly, our (implicit) strategy is to interpret copyright claims as
damage, and to code around it. (We already have to do that, with the
Emacs documentation. With friends like these ... well, I'll take such
friends any day---and ask them to stop plinking BBs at my foot.)
Risky strategy? Of course. The FSF's strategy is less risky, but not
a sure thing. (For example, it is always vulnerable to attack via a
completely independent patent on any technology it implements.) In
return for risk reduction in the long run, it does, however, involve
known and certain damage to the interests of some free software users
and developers in the short run. A reasonable compromise---as is
ours. Any ecologist will tell you that monoculture itself is risky.
Vive la difference! Let Freedom ring![2]
In the next paragraphs,
A = practical difficulty of changing license of community-owned
software
B = incompatibility of GPL and GFDL
dak> However, A is in some manner an outgrowth of problem B,
dak> and if we got B solved in a satisfactory way, it might mean
dak> that XEmacs developers (like everybody else) would need to
dak> adapt at most _one_ more time.
Robert> Maybe. But more likely more than one more time.
Doesn't worry me. The big Problem A XEmacs faces with the FSF's old
Emacs documentation license (aka the current XEmacs documentation
license) is that it is unnamed and unversioned. Satisfactory
resolution of B will involve a named versioned license so that a
permission statement of the form "may be redistributed under the GNU
Perfected License, version 1.0 or later, at your option" can be used.
Robert> There is reason to separate the GFDL from the GPL.
IMO, this is very short-sighted. Several hackers have pointed out the
convergence between code and documentation as exemplified by uh, well,
GNU Emacs itself. Don't forget "literate programming". The library
association's brief in the Eldridge case points out the importance of
cut and paste in compilations of existing documents. I have musician
and film acquaintances who wish to have the same freedom to borrow the
recordings of others that I have to borrow the code of GNU Emacs. I'm
sure there are classes of information that you and I would intuitively
agree are "not software" that I have not yet considered.
I don't see why they shouldn't all benefit from the same definition of
freedom as software.
There simply is no reason not to use the GPL, perhaps in a slightly
modified version to avoid referring to documentation as "the Program",
etc, except for reasons of encouraging commerce.[3][4] Those reasons
apply with equal force to software, yet in the case of software are
rejected most vehemently by exactly the folks who insist that the GFDL
is a free license. A rather unappealing combination.
dak> All of those choices don't look very appealing.
Robert> I agree. It is not an appealing world. And it is getting
Robert> worse.
It's always darkest before the dawn. When Milton Friedman and Kenneth
Arrow can sign the same amicus brief for Eldridge, there is hope.
Footnotes:
[1] Yes, I have the option of delegating that choice to the FSF, and
in fact I have done so. This eliminates the problem of
incompatibility between GNU Emacs and XEmacs licenses for my own
contributions, but still leaves me with _no choice of license_.
[2] Sorry, David, but I do so love my own picturesque rhetoric.
[3] Albeit on better terms than the "sorry for the legalese, but the
net effect is that copying without explicit permission is forbidden"
that graces O'Reilly's _X Window System_ series.
[4] Of course there are clauses of the GFDL that deal with issues
like "technical means to prevent copying". But it has long been
recognized that the GPL needs to be amended to deal with those issues,
and the GFDL's terms are arguably problematic.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.