Re: free licensing of TEI Guidelines
Scripsit Syd Bauman <Syd_Bauman@Brown.edu>
> HM> If the deletion is required, it must be possible - then Debian
> HM> could at least distribute copies with the section removed. (And
> HM> then ship a cleanroom rephrasing of the relevant information in
> HM> README.Debian).
> I'm sorry, I don't understand this at all. Why would Debian be
> interested in distributing Guidelines with the conformance section
> removed?
Because the premise was that the conformance section must not be
modified - i.e. it is not licensed freely, and we do not want to
include not-freely-licensed text in Debian.
> If an author wishes to *comment on* the TEI Guidelines, he or she does
> not need our permission to copy that portion he or she wishes to
> discuss. That's fair use.
Many jurisdictions do not have "fair use" concepts that are as
inclusive as the one you're speaking about. One that I know personally
is Denmark, and I expect most EU counties (possible except UK) to be
similar. We want things to be free in such jurisdictions too.
> Our discussion here is about people who are creating text encoding
> guidelines of their own using the Guidelines as their starting point.
Yes, that too.
> Sure, if someone changes my bio in a sufficiently nasty (and untrue)
> way, I can sue for libel. But I'd really like to be able to stop 'em
> before it gets to that point. Particularly when published in a book
> likely to be read by my peers, and when the information could be
> misunderstood as having been written by me.
The way to prevent that is to require that derivations are made in
such a way that they *cannot* be misunderstood as having been written
by you. All of the other problems evaporate then.
> HM> I think you're wrong. One should be allowed to derive a document
> HM> that described the official TEI elements as well as Microsoft's
> HM> (hypothetical) namespace-[invading] extension. The license of the
> HM> specification cannot stop Microsoft from implementing its own
> HM> extensions; it would add insult to injury if the license helped
> HM> Microsoft keep their extensions secret (by making it more
> HM> difficult for white-hatted reverse engineers to reuse text from
> HM> the original document when describing their findings).
> I don't understand this scenario at all -- what is there to be reverse
> engineered? XML is plain text.
The Microsoft program that interprets the plain text in certain
specific ways may be reengineered, and it may make sense to derive a
findings document that specifies how the Microsoft program interprets
plain text. If the Microsoft program is found to attach a specific
meanings to elements within the TEI namespace other than specified in
your standards document, it is perfectly reasonable for the findings
document to add a description of how the Microsoft program reacts to
those elements in the TEI name space.
> What we'd like to prevent is Microsoft's claiming that documents
> that conform to their modified Guidelines conform to the TEI
> Guidelines (if they don't). That's all.
And you're not going to achive that by a copyright license that
forbids text from the standard from being reused in the findings
document.
> I am wondering (aloud on this list) whether or not a) writing into
> the copyleft notice that modified elements should not claim to be in
> the TEI namespace achieves this goal,
I doesn't, and it explicitly disallows the findings document I am
speaking about above. My premise is that the Microsoft program behaves
in a certain way *only* when it finds that the element name is in the
TEI namespace. Not allowing me to mention the TEI namespace while
stating that fact is a functional restriction on the modifications of
the document I'm allowed to make, and thus non-free.
> Besides, I don't honestly believe any copyright, no matter how
> applied, could possibly inhibit any reverse engineers from reuse of
> text from the original document when describing findings
Copyright, by default, inhibits everybody else than the author from
reuising text from the original document no matter what they are
doing. Any reuse that the author does not explicitly allow is
forbidden. That is, unless one happens to live in one of the few
countries whose concept of "fair use" is as broad as it is in the US.
> MJR> ... preventing TEI-incompatible and TEI-unauthorised elements
> MJR> from being in the TEI namespace seems fine to me. Putting our own
> MJR> forms into TEI's namespace would be similar to claiming that they
> MJR> said something they did not.
> HM> No it isn't - not unless you *explicitly* claim that it was TEI
> HM> who said it.
> How more explicit than pointing to our namespace can you get? :-)
The way to be explicit is to say "TEI says (quote)bla bla(unquote)".
If someone else says something about an element in the TEI namespace,
that statement does not automatically get reattributed to the TEI. It
may be a *false* statement, but it is still not implicit in the false
statement that it is TEI who said it originally.
> HM> Perhaps, but it is not DFSG-free.
> It sort of defeats the purpose of having a standard which says "you
> can use the TEI <cb> element to assert that a column break occurred in
> the source" if modified versions of the standard say "you can use the
> TEI <cb> element to describe the cost-basis of a stock".
No - because the modified version of the standard text will not be THE
standard. And for this, all that is necessary is to require that
modified versions are clearly identified as being modified.
--
Henning Makholm "Punctuation, is? fun!"
Reply to: