> The gain is that the author has at edit time full control over where the
> link points to. With runtime lookup a link might change because a certain
> term was added to a certain namespace.
>
> -- Jan Hidders
Well, that's not a bug but a feature! The term will not be added
to a certain namespace if there isn't already some disrepancy
(and if the author means the other subject he will surely link
to it explicitly, like [[Root (Botanics)]]) By doing the linking
in runtime we could make sure that all links point at their
most updated targets, which is an advantage. This is similar
to the reason why we use redirects.
As to runtime performance concerns, I'm sure that caching and/or
an optimised parser could do wonders in the Wikipedia case.
Wiki markup is _very light_.
Sincerely yours,
Uri Yanover
I think there is some consensus about how copyright is treated in the
wikipedia, which goes back at least half a year.
Jimbo has said:
> It is my understanding that copyright to everything in Wikipedia
> belongs to the contributors, who are releasing it under the GNU FDL.
> Wikipedia has a copyright on the _compilation_, which means something
> very specific under copyright law, and we release the _compilation_
> under the GNU FDL.
Axel has said:
> It [the assignment of image copyright] is also not in line with the way we
have
> handled copyrights up to know for text submissions: the user retains
> copyright, but licenses the work under GFDL. I suggest that this be
> changed.
Nearly six month ago in response to a question Jimbo said:
>> What if someone posts their own
>> article as a Wikipedia topic? I posted one of my articles which I also
gave
>> to a garden site and posted in my own column at BackWash. I'm the only
one
>> who has a copyright to the article. Was that ok to do?
>
> It's o.k. to do, but by doing so, you're releasing the article under
> GNU FDL, which means that anyone can redistribute it and edit it to
> say anything they like. If that's o.k. with you, and presumably it
> is, then it's great!
And even before any of these issues were discussed it was clear on Lee's
homepage that he believed that he maintained the copyright to his
contributions, and could provide versions "unencumbered by the FDL."
This is exactly my understanding. We are allowed to post articles we own the
copyright to on the wikipedia, and by submitting them we are licensing them
under the GNU/FDL.
Thus, I think Axel is right to say:
> There is nothing to interpret. I have never signed over copyrights
> of any Wikipedia article I wrote to anybody, therefore I remain the sole
> copyright owner. I *licensed* my materials under GFDL. Most free
> software projects works that way. For instance, I own the copyright of
> several parts of the Linux kernel.
This is the standard practice in the free software community. And apart
from some active step assigning copyright to Boomis specifically, I don't
see that there is any other possible legal interpretation. This is true when
a magazine publishes my work (I've refused publication rights after
negotiating pay over this issue) as well as when I assign works to the GNU
FDL.
That said, I would like to expand a bit on the subject of the costs and
benefits of this policy. I want to try to make these issues as clear as I
can because I'm concerned that some people may not be able to understand the
consequences of this debate, because they don't understand costs and
benefits of this policy.
Boomis, as creator of the compilation of articles in the wikipedia, and by
default owns the copyright on the compilation unless it is specifically
reassigned. Since, both Boomis and I are releasing our "works" under the
FDL, anyone can use the wikipedia content as long as they abide by the terms
of that license.
That said, from my point of view there are a number of costs and benefits of
maintaining this policy.
First benefit -- Wikipedia authors can contribute works to the wikipedia
which they also plan to publish in revised form under another license
elsewhere. This means for instance that a graduate student could put
sections of her dissertation work in the appropriate wikipedia articles,
even if she hoped someday to publish that work in a reference book with a
boilerplate copyright notice.
Second benefit -- Wikipedia content is not available at the discretion of
Boomis. Since, Wikipedia is not a legal entity and cannot hold copyright and
Boomis Inc. is I assume that that's where the copyright assignment would go
if everybody were required to assign copyright to somebody. While I trust
Jimbo, I don't know the others involved in Boomis, and there's always the
possibility that through bankruptcy or other unpleasant circumstances Boomis
could be under other management -- management more inclined to see wikipedia
content as property to be licensed restrictively to generate as much profit
as possible.
Third benefit -- There's a widespread feeling of ownership (which come from
actual ownership) by the wikipedia community.
In addition to these benefits there are some costs.
First cost -- No matter what happens, we won't be able to change the license
on all wikipedia content, as that would require assignment by every
copyright owner of their work to the new license. And this is logistically
impossible. For example, we might want to dump the authorship requirement,
but there's just no way to do so unless we get the permission of all
copyright owners. And at this point based on one likely interpretation of
the FDL we are in violation of the authorship clause, and because of this we
have no list of copyright owners to ask for an exception to the authorship
clause so we'd no longer be in violation...
Second cost -- It's not practical or even possible to allow for exceptions
to the GNU FDL. Because this closes off the possibility of licensing
revenues for Boomis, it necessarily places limits on the possibility of
wikipedia ever becoming a significant revenue stream for Boomis. This is
important because Boomis will be more willing to pay for hardware,
bandwidth, and Larry, if wikipedia can generate a profit.
And for those anti-advertising people out there, this makes it far more
likely that Boomis will need to advertise on the wikipedia in order to
recoup the costs associated with the wikipedia.
Third cost -- As Jimbo mentioned, some corporate groups may be skittish
about using content from the wikipedia since the copyright ownership isn't
clear, and therefore they'd have to depend entirely on the FDL, which has
not been tested in a court of law. (And submit themselves to the
possibility of a lawsuit by an uncredeted author/copyright holder).
In light of these facts, I think it is clear that there are a series of
complex ramifications to the issue of copyright assignment. We are not the
first to discover these issues, there's clear precedents in the free
software community for us to follow, and so I'd advise looking that the
reasons that some companies which write free software refuse to accept
patches which do not include an assignment of copyright to the company. As
well as the reasons that most free software projects don't ask for copyright
assignment on patches they receive.
Briefly, it's my understanding that MySQL, and KDE's Troll Tech developed
GUI toolkit are examples of for profit companies like Boomis, which require
copyright assignment for patches. And largely their developer communities
have accepted this policy, though, there has, of course been some vocal
resentment expressed by some parts of those developer communities. As Axel
has pointed out the FSF would be an example of a not-for profit, which asks
for copyright assignment and receives it on a regular basis. This works
well because they have a high level of trust from the free software
community.
On the other side, the Linux kernel allows developers to retain the
copyright to their code, and because of this policy they have a couple of
problems. Linus has said that he interprets the GPL to allow for
proprietary drivers to be dynamically linked to the kernel, but others have
disagreed, and the potential that this may someday become the center of an
actual court case has disturbed a number of larger companies which might
otherwise have invested more heavily in development of Linux drivers. If
Linus had the copyright to the kernel code, his interpretation would stand,
because he'd be the only one with the legal right to sue.
My overall view is that it is in the best interests of wikipedia to allow
contributors to maintain copyright on their work, as this maximizes the
incentive to contribute. And minimizes the potential roadblocks to
contribution. And most importantly the assignment of copyright somewhat
undermines the trust and credibility that using the FDL was intended to
foster. But I recognize that this puts some limits on Boomis, and I really
would like to see a clear path to profitability for the wikipedia...
That said, any change that is made must not be retroactive! I have not
assigned copyright to anything I placed in the wikipedia, and will not do
so. If the policy changes in the future, I'll make a decision about future
contributions on the basis of the new policy. And this will almost
certainly
Yours
Mark
>> The current file upload utility requires the user to "donate" the
>> copyright to "Wikipedia". Wikipedia is no legal entity, so this
>> doesn't make sense. It is also not in line with the way we have
>> handled copyrights up to know for text submissions: the user retains
>> copyright, but licenses the work under GFDL. I suggest that this be
>> changed.
> What makes it true that "we have handled copyrights up to now for text
> submissions" in this way (i.e., with this interpretation)?
There is nothing to interpret. I have never signed over copyrights of
any Wikipedia article I wrote to anybody, therefore I remain the sole
copyright owner. I *licensed* my materials under GFDL. Most free
software projects works that way. For instance, I own the copyright of
several parts of the Linux kernel.
Nothing on the website (except the new file upload notice) suggests
that contributors hand over copyrights. You are certainly free to in
the future demand that copyrights be signed over to a legal entity (as
the FSF for GNU software does), but then you need to
* create a legal entity which will hold the copyrights
* get permission of copyright holders
The FSF demands a signed faxed paper to that effect from every
contributor (which I have sent, and therefore I am *not* anymore t
he copyright holder of the parts of emacs I wrote).
> While I can certainly freely admit that there are other
> interpretations, what I can't understand is why you would think
> another interpretation is so clearly the correct one.
I am unclear about what exactly you want to interpret. Is it the
submission notice we see on the edit screen?
" Please notice that all contributions to Wikipedia are considered to
be released under the GNU Free Documentation License. "
This says that whatever I contribute, I automatically license under
GFDL. Is there any way to understand this statement as saying "the
copyright to everything you contribute goes to Wikipedia, which then
licenses the materials under GFDL"? I very much doubt it, since the
sentence doesn't even contain the word "copyright".
The distinction is not just academic: if I give up copyright, then the
new copyright owner can in principle turn around and republish the
material under any license they wish, or sell the copyrights to
somebody else who may want to do that.
> By the way, Wikipedia might soon join Nupedia as part of a Nupedia
> Foundation; that then would be the obvious holders of Wikipedia
> article copyrights.
Yes, for future contributions, if that is desired.
Axel
I haven't seen a need to write again since making my proposal, but today Uri
Yanover <uriyan_subscribe(a)yahoo.com> wrote:
>What I don't like about Tim's idea is the fact that it converts
>the link automatically basing on parsing of the article title.
My proposal is archived at
http://www.nupedia.com/pipermail/wikipedia-l/2002-January/001230.html
There it can be seen that in addition to the simple solution that does
convert links based on the article title, I did include Uri's idea. To
summarize:
#base [[Fantasy Fiction]]
[[/elves]]
could be translated into this:
See also: [[Fantasy Fiction]].
[[elves (Fantasy Fiction)|elves]]
The system could remove the #base line completely instead of translating it,
but I think it's useful to reflect by default that there's a relationship
between the content of a given page and some other related page. After all,
if the author doesn't like that behavior, he or she can simply type the
links manually instead of using #base. Or the author can edit twice: the
first is a major edit, and the second is a minor edit to remove the See
also: line.
Uri's original #base idea is archived at
http://www.nupedia.com/pipermail/wikipedia-l/2002-January/001220.html. He
also proposed an Alias: namespace
(http://www.nupedia.com/pipermail/wikipedia-l/2002-January/001218.html), but
the features are very similar.
The key differences between my proposal and his are:
1. I propose a solution that converts text during save, while Uri proposed
adding to the wikipedia's source syntax.
2. I propose the disambiguating syntax -- [[title (context)]] -- while Uri
proposed subpage syntax -- [[context/title]].
However, Uri also said yesterday in
http://www.nupedia.com/pipermail/wikipedia-l/2002-February/001288.html that
he "didn't mean to use aliaes mainly to categorize, but rather to
_disambiguate_ (e.g. [[root (botanics)]] vs. [[root (mathematics)]])." So I
assume he's flexible on #2.
I take it that there's consensus on the part that deals with link
conversion.
So what about the #base idea?
<>< Tim
> #base [[Fantasy Fiction]]
>
> [[/elves]]
>
> could be translated into this:
>
> See also: [[Fantasy Fiction]].
>
> [[elves (Fantasy Fiction)|elves]]
My apologies for not understanding you perfectly, but it still
would act as I've said if you don't give it a #base.
> The key differences between my proposal and his are:
>
> 1. I propose a solution that converts text during save, while Uri proposed
> adding to the wikipedia's source syntax.
> 2. I propose the disambiguating syntax -- [[title (context)]] -- while Uri
> proposed subpage syntax -- [[context/title]].
As for #2, I no longer support subpage syntax (as I've said, the
parentheses seem to me more aesthetic and helpful for an
encoclopedia).
As for #1, what I dislike in conversion during save is the fact
that _editing afterwards_ is still difficult (and I truly see no
gain in making this sort of pre-processing - it could be done
in runtime just as well). The renaming rules seem quite
complicated and implicit to me. And finally, I have doubts
if it is wise to build a link-resolving AI using regular
expressions if we can have the authors make the same
decisions explicitly.
Sincerely yours,
Uri Yanover
It is my understanding that copyright to everything in Wikipedia
belongs to the contributors, who are releasing it under the GNU FDL.
Wikipedia has a copyright on the _compilation_, which means something
very specific under copyright law, and we release the _compilation_
under the GNU FDL.
The downside of this arrangement is that if someone takes portions of
wikipedia and does something counter to the GNU FDL, we are not in a
position to defend it. That's not a good thing. I suppose that if
that were to happen, and if I were to be in the mood to defend it, we
could ask contributors to those specific sections to _at that time_
sell us their copyright for a dollar, so that we could pursue the
infringers in court.
The upside of this arrangment, if there is one, is that even Wikipedia
can't make the content proprietary.
Another potential downside to this arrangement, and I'm not sure how
important this one is, is that many overly cautious potential
licensees of the content will hesitate to license it absent a single
unified ownership. For example, Yahoo might not want to use Wikipedia
content as the basic for Encyclopedia Yahoo, if they were to create such
a thing, out of concern about there not being a single licensing authority.
--Jimbo
I've just finished going over the enormous set of interesting e-mails
about the problem re the "Middle Earth" subpages. I just have a few
notes. I am sure I haven't caught all the issues here but hopefully I've
said something useful on some of the important ones.
(1) There were *several really good* reasons not to have subpages. Not
just one or two. While I did concede that fictional worlds were prime
candidates (*if* any were) for subpage treatment, I did *not* concede that
the fact that they're useful for that purpose means that we should have
them. In fact, the mere fact that subpage functionality existed meant
that subpages were used in all sorts of different ways.
(2) Those who have said that there's no difference between [[Foo/Bar]] and
[[Bar (Foo)]] have obviously not used subpages very much. There's a huge
difference, and this has been discussed in depth before.
(3) I agree with Lee, Jimbo, Vicki, and I think a few others who
emphasized that it is very important to preserve the ease of editing
Wikipedia articles. Tim's solution has the distinct advantage of making
it no more difficult to edit articles, while preserving keystrokes.
(4) When we think about policy options, it often helps to consider
carefully what problem we're trying to solve, and to make sure that our
solution is the most elegant solution to that problem. It is not entirely
clear to me what the problem is, in this case. Originally, Uri Yanover
said:
>The problem is in the following: it is extremely inconvenient
>(as a policy) to write "[[Middle Earth/Elrond|Elrond]] was
>the lord of [[Middle Earth/Rivendell|Rivendell]]" than it is
>to write "[[Elrond]] was the lord of [[Rivendell]]"
This suggests that the problem is *just* one involved in typing long page
titles in order to create a link, but the solution offered by Uri solves a
lot more than that, so I'm not sure this is exactly the problem he wants
to solve.
(5) *If* the problem is just that, then I'd agree with those who say that
Tim's solution is very neat and elegant, and we should move forward with
it. We should probably also write a script that would allow sysops or
trusted users to rename large numbers of pages (and links) formatted
[[Foo/Bar]] as [[Bar (Foo)]].
(6) I see no particularly good reason why the name of an article about
Elrond needs to be named anything other than [[Elrond]] or [[Elrond
Peredhil]]. The whole point of so-called disambiguating parentheses (I
wrote a little column about these last year) is to disambiguate, not to
categorize.
(7) "Hear, hear" to Lee, or whoever it was, who said that article
structure *should* be flat. This is a good thing!
Larry
Over the last year, we have had many discussions about the various
ways foreign characters are used, and I think we reached consensus
on many of the issues, but those discussions are a bit scattered.
I think a simple, organized, documented policy on these issues is
important to help all the newcomers, and also to serve as a spec
for fixing the new software to properly support and enforce those
choices. I was going to do some of that code myself, but I thought
I should make sure I had a correct understanding of what should
happen first.
Please read the proposal at
http://meta.wikipedia.com/wiki.phtml?
title=Proposed_Wikipedia_policy_on_foreign_characters
and comment.
0
Jimbo just uploaded the latest software version.
It contains some bugfixes, and a cached "Most Wanted" page (that doesn't
list articles starting with numbers). You'll have to refresh it manually
when too many articles are covered. But, that will take stress off the
system, making this page (and others) load a little faster.
The default number of changes on "Recent changes" was increased to 250,
which can result in longer loading time. If it takes too long, add
"&maxcnt=100" to the URL manually, for now. Use "List only new changes" for
even faster loading.
Thanks to Brion Vibber, there's now an option on your preferences page where
you can deactivate minor changes for the "Recent Changes" page. We hope it
works ;)
That's it for today, mostly. Brion has joined me at the "programmer's
staff", for which I am very grateful, as there's now someone else to blame
when the script dies ;)
Also, Jan Hidders has sent me a patch, and wants to continue working on the
code. (If you have a SourceFOrge account, I can give you CVS write access).
Magnus