from_name: Julie Kemp

subject: [Wikipedia-l] Reactions to the list and its discussions

body:
Right.  Talk about private clubs.  I understand that
the list serves mostly to facilitate improvements on
the site, and therefore runs to programming
conversations.  HOWEVER, even though I have worked on
a development team where I had to deal with SQL
developers on a regular basis, I can't follow you guys
at all.

This is all in the way of showing that the geekspeak
is a bit exclusionary.  Probably not in and of itself
a problem -- except that you guys are talking about
changes (and in the case of the new site, implementing
changes) that affect all of us other users -- AND YOU
AREN'T COMMUNICATING THEM.  The FAQ's haven't really
been updated, lots of people seem unaware that the
/subpage no longer exists....  and even those of us
who would be happy to help document changes and spread
the word can't, because we don't speak programmer well
enough to be sure.

For pity's sake -- can we please clean up the
documentation for rev2 before going to rev2a?  I'll
help -- but not unless somebody helps me first!

Thanks for letting me rant -- [[JHK]]
--- wikipedia-l-request at nupedia.com wrote:
> Send Wikipedia-l mailing list submissions to
> 	wikipedia-l at nupedia.com
>
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 	http://www.nupedia.com/mailman/listinfo/wikipedia-l
> or, via email, send a message with subject or body
> 'help' to
> 	wikipedia-l-request at nupedia.com
>
> You can reach the person managing the list at
> 	wikipedia-l-admin at nupedia.com
>
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Wikipedia-l digest..."
>
>
> Today's Topics:
>
>    1. Re: Modest proposals (Uri Yanover)
>    2. Re: Modest proposals (Tim Chambers)
>    3. Re: Copyrights (Larry Sanger)
>    4. Re: Copyrights (Hr. Daniel Mikkelsen)
>    5. Re: Modest proposals (Uri Yanover)
>    6. Re: Re: Modest proposals (Jan Hidders)
>    7. Re: Modest proposals (Jan Hidders)
>    8. Re: Modest proposals (Uri Yanover)
>    9. Re: Re: Modest proposals (Jan Hidders)
>   10. MySQL dump available (Jan Hidders)
>   11. File upload Copyright notice (Axel Boldt)
>   12. Re: MySQL dump available (Jimmy Wales)
>   13. Summary of pseudo-subpage discussion (Magnus
> Manske)
>   14. RE: MySQL dump available (Magnus Manske)
>   15. Re: Summary of pseudo-subpage discussion
> (Michel Clasquin)
>
> --__--__--
>
> Message: 1
> From: "Uri Yanover" <uriyan_subscribe at yahoo.com>
> To: <wikipedia-l at nupedia.com>
> Subject: Re: [Wikipedia-l] Modest proposals
> Date: Tue, 5 Feb 2002 22:00:20 +0200
> Reply-To: wikipedia-l at nupedia.com
>
> > (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.
>
> I used to think so when I'd written that post, but I
> no longer do.
> Having considered the subject for long enough, I
> reached the
> concept of aliases (more details in the mailing
> list). The general
> usefullness of aliases is for disambiguating (that
> is, making [[root]]
> point at [[root (mathematics)]] on pages concerning
> with algebra
> and at [[root (botanics)]] at pages concerning with
> plants).
>
> However, the other useful thing that could be done
> with aliases
> is facilitating the editing of pages like [[Middle
> Earth]], so that
> ineed [[Elrond]] on an a page that uses aliases
> becomes
> [[Elrond (Middle Earth)]]. But this use is
> secondary, and
> confined only to pages that describe a specific
> universe.
> The fact that the vast majority of the other
> articles does not
> use subpaging indicates that probably there won't be
> too much
> abuse of aliasing in this way.
>
> 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.
> But not only that would be inconvenient (making it
> more
> difficult to edit the article afterwards and
> sometimes creating
> links that the author doesn't want), it would also
> be out
> of policy, as it would essentially be a substitute
> for subpages.
>
> Sincerely yours,
>             Uri Yanover
>
>
>
> --__--__--
>
> Message: 2
> From: "Tim Chambers" <tbchambers at yahoo.com>
> To: "Wikipedia List" <wikipedia-l at nupedia.com>
> Subject: Re: [Wikipedia-l] Modest proposals
> Date: Tue, 5 Feb 2002 15:28:33 -0700
> Reply-To: wikipedia-l at nupedia.com
>
> I haven't seen a need to write again since making my
> proposal, but today Uri
> Yanover <uriyan_subscribe at 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.
>
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com


list: wikipedia-l

source: pipermail-mbox

from_name: Jan Hidders

subject: [Wikipedia-l] Re: Modest proposals

body:
From: "Uri Yanover" <uriyan_subscribe at yahoo.com>

> > 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.

And, of course, as Lee already pointed out, it also makes it less tempting
for the casual user. A very important argument.

> 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.

Perhaps the user wants this to happen, perhaps not. I suggest we first wait
and see how many people actually need such features.

> 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_.

Have you seen the parsing code? There is nothing _very light_ about it, at
the moment. I intend to improve that in the future, but found some other
problems I would like to solve first. Anyway, adding non-trivial features is
not going to make that job easier.

Kind regards,

-- Jan Hidders


from_name: Uri Yanover

subject: [Wikipedia-l] Re: Modest proposals

body:
> 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


subject: [Wikipedia-l] MySQL dump available

body:
Is there a dump of the Wikipedia tables available somewhere? I would like to
do some testing on a database with a realistic size.

-- Jan Hidders


from_name: Larry Sanger

subject: [Wikipedia-l] Copyrights

body:
I don't see that there has been the consensus you mention.  Frankly, I
don't care if there has been, because I'm not arguing with you, I'm asking
for clarification, for pete's sake!  Sheesh!

OK, let me put my confusion a different way, because I still don't
understand:

WHO has the right to sue, and FOR WHAT do they have that right?

Larry


from_name: Mark Christensen

subject: [Wikipedia-l] File upload Copyright notice

body:
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


subject: [Wikipedia-l] Copyrights

body:
Now, Jimbo, do you agree with that?  It's "those who wrote the content"
who would have the legal standing to sue if, for example, Microsoft were
to make an altered version of Wikipedia and try to copyright and sell it?

On Wed, 6 Feb 2002, Mark Christensen wrote:

> I want to publically apologize, I intended that last message to go directly
> to Larry, not to the list.  I'll try to discuss the issue with Larry offline
> untill we at least both understand what the other is trying to say.
>
> Also, I agree, the issue of concensus is clearly of secondary importance to
> understanding what acutally is the case, regardless of what anybody thought
> in the past.
>
> In the mean time, let me answer Larry's question briefly.
>
> I don't think anybody could sucessfully sue, because we have a strong
> argument that the wikipedians page fulfills the FDL authorship requirement.
> But it would be the copyright holders (those who wrote content) who would
> have the legal standing to sue if there were in fact an actuall violation.
>
> Yours
> Mark
>
>
>
> -----Original Message-----
> From: Larry Sanger
> To: 'wikipedia-l at nupedia.com'
> Sent: 2/6/02 6:35 PM
> Subject: RE: [Wikipedia-l] Copyrights
>
> I don't see that there has been the consensus you mention.  Frankly, I
> don't care if there has been, because I'm not arguing with you, I'm
> asking
> for clarification, for pete's sake!  Sheesh!
>
> OK, let me put my confusion a different way, because I still don't
> understand:
>
> WHO has the right to sue, and FOR WHAT do they have that right?
>
> Larry
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


from_name: Brion Vibber

subject: [Wikipedia-l] Copyright notices

body:
While we're on the subject of copyright notices, a little question about
the copyright assertion on the upload page. Currently it reads:

  [ ] I hereby affirm that this file is *not copyrighted*, or that I own
  the copyright for this file and donate it to Wikipedia.

Which has been questioned as ambiguous as to whether the *use* or the
*copyright* of the file is being donated. A revised version was just
checked into the code in the CVS repository which reads:

  [ ] I hereby affirm that this file is *not copyrighted*, or that I own
  the copyright for this file and place it under GPL licence.

Now, I'm assuming that the "GPL" is a typo for "GFDL", which can be
easily corrected before the change goes online. With that in mind, can
we all agree that the new message is sufficiently clear and correct? If
not, what ought it to say?

-- brion vibber (brion @ pobox.com)


from_name: Jimmy Wales

subject: [Wikipedia-l] Copyrights

in_reply_to: <2100F5D84712D411A00E00B0D0221D1A972AEB@kodiak.htec.com>; from mchristensen@htec.com on Wed, Feb 06, 2002 at 07:08:49PM -0500

body:
Mark Christensen wrote:
> I was not clear. Those who wrote content would have standing to sue, as
> would Bomis, because the writers own the copyright to the texts, and Bomis
> owns the copyright to the collection.

I think this is true only to the extent that someone does something
naughty with _the collection_.  If Microsoft takes an individual
article from Wikipedia and modifies it and publishes it with the claim
that it is proprietary and no one can redistribute it, then I think
I'd have a hard time pressing a claim that they violated the copyright
of our collection.

So then it would be up to the individual contributors to do something
about it.  Probably they could sell me the copyright for a dollar at
that time, with the understanding that I'd go after the bad people in
court.  Or possibly various people who care about the project,
including me, could put together a fund to sue.

--Jimbo


subject: [Wikipedia-l] Copyrights

body:
Larry Sanger wrote:
> Now, Jimbo, do you agree with that?  It's "those who wrote the content"
> who would have the legal standing to sue if, for example, Microsoft were
> to make an altered version of Wikipedia and try to copyright and sell it?

I think, absent an explicit assignment of copyright, preferably in
writing, that we should assume this.

If they took the _entire_ Wikipedia, or even a _substantial part_,
then I assume our copyright on "the collection" might mean something
useful.  I'm not sure to what extent that's the case, though.

And finally, of course, the name Wikipedia is our trademark, and that
gives us some significant leverage over certain types of bad uses of
our content.


subject: [Wikipedia-l] Copyright notices

in_reply_to: <1013040840.8185.0.camel@rdaneel.moisty.org>; from brion@pobox.com on Wed, Feb 06, 2002 at 04:13:59PM -0800

body:
Shouldn't it just say exactly the same thing (or grammatically close to it)
as the text on the submit button when people edit pages?

Brion Vibber wrote:

> While we're on the subject of copyright notices, a little question about
> the copyright assertion on the upload page. Currently it reads:
>
>   [ ] I hereby affirm that this file is *not copyrighted*, or that I own
>   the copyright for this file and donate it to Wikipedia.
>
> Which has been questioned as ambiguous as to whether the *use* or the
> *copyright* of the file is being donated. A revised version was just
> checked into the code in the CVS repository which reads:
>
>   [ ] I hereby affirm that this file is *not copyrighted*, or that I own
>   the copyright for this file and place it under GPL licence.
>
> Now, I'm assuming that the "GPL" is a typo for "GFDL", which can be
> easily corrected before the change goes online. With that in mind, can
> we all agree that the new message is sufficiently clear and correct? If
> not, what ought it to say?
>
> -- brion vibber (brion @ pobox.com)
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Axel Boldt

body:
>> 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


subject: [Wikipedia-l] Copyrights

body:
I assume this is the post you intended for me to refute.  I can't.  I agree
you THOUGHT the contents where assigned to Bomis.  This makes no difference.
The legal position I hold is that unless I have specifically, in writing,
assigned copyright to somebody they do not hold copyright.  When I've
published in literary magazines, I generally refuse to sign any paper which
assigns copyright to the publisher, and will only sign limited use licenses.

The FSF requires a paper document on file assigning copyright to them to be
on file at their offices to accept a patch.  It may be that now there's a
way to attach a digital signature (which legally can be as simple as
checking a box in a web page form) to some text assigning copyright to bomis
rather than requiring a signed sheet of paper.  But regardless, wikipedia
has not done this in the past, and apart from specific verbiage assigning
copyright to bomis it will be maintained by the author of the work in
question.  (The FSF objects to click through licenses, so their stance on
paper signatures may be the result of this.)

If you have a specific REASON to believe that something in the language of
the FDL, or in the wording of the submission text on an edit page actually
does function to inform me specifically that I no longer maintain copyright
to my work, then I'd be glad to refute that too.

Perhaps what you are trying to say it that you believed that Bomis released
the contents of the wikipedia under the FDL, and could only do so if the
contributors had already assigned copyright to Bomis.  This however is as
far as I can tell false, the text of the submission says that contributors,
by submitting their text, are licensing it under the FDL. There is nothing
about copyright assignment there.

What Axel, Jimbo, and I are saying is that wikipedia gets to use a
contributors work only because that contributor licensed it to wikipedia
(and everybody else) under the FDL.  The contributor owns that piece of
work, and can sell it under a different license, but he or she cannot stop
others from using it as long as they comply with the terms of the original
license (the FDL).  This means that I could put the draft of a book on
presocratic philosophers on the wikipedia, and then turn around and sell
that book to Oxford press, granting them special rights not offered under
the FDL.

What Bomis OWNS is the copyright on the collection, just as a magazine can
own the copyright on the collection of works in the magazine while the
contributors retain ownership of the individual works in the collection.  In
this case the magazine has a license to use the contributors works under
specific circumstances, but the contributors could not get together and
create a copy of the magazine for resale -- even if they collectively own
all of the pieces in the magazine.

Overall, I think you've made to main points:

1) There has been no agreement about the issue of copyright assignment, and
Axel's interpretation is just one among many.

2) It is possible to interpret the text of the FDL and the submission notice
on the edit page as assigning copyright to Bomis.

I believe I've shown that at least, myself, Lee, Axel, and Jimbo have
believed that Axel's interpretation was correct, and that there is evidence
on the mailing list going back to the middle of last year that this was the
primary position voiced during that time.  I looked at my archive of
messages which only goes back to Aug 2002, and found no significant
alternative expressed.

I also believe that Axel has asked a valid question.  If you believe that
somehow we have actively assigned copyright of our work to Bomis, can you
provide evidence of that, or explain FROM THE TEXT of the submission notice
or the FDL, how you have arrived at this conclusion?  I believe that you
cannot, and that your belief that this was the case is not legally binding
on me, as from the moment I first arrived at wikipedia I have assumed that
this was not the case.  Apart from specific text assigning copyright, I
retain it.  That is the law.  And this makes wikipedia like Linux, and most
other open source projects, in that the individual contributors maintain
copyright on their work.

I hope this explains it well enough, I think we aren't connecting
conceptually on the issue, and I'd be more than happy to try to explain my
understanding of the facts in a different way, or to defend anything you
believe to be controversial in the above statement.

Yours
Mark

-----Original Message-----
From: Larry Sanger [mailto:lsanger at nupedia.com]
Sent: Tuesday, February 05, 2002 8:09 PM
To: wikipedia-l at nupedia.com
Subject: Re: [Wikipedia-l] Copyrights

On Tue, 5 Feb 2002, Jimmy Wales wrote:

> It is my understanding that copyright to everything in Wikipedia
> belongs to the contributors, who are releasing it under the GNU FDL.

I thought *Bomis* released *the contents of Wikipedia* under the GNU FDL,
in any case; so then each individual contributor first must release their
contributions to Bomis under the same license?  This seems to be what
several of you have been getting at.

I am not convinced.  I'll have to write more later, when I have time.

Larry

[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] Copyrights

body:
On Wed, 6 Feb 2002, Jimmy Wales wrote:

> So then it would be up to the individual contributors to do something
> about it.

This is the part that puzzles me.  We don't know who the individual
contributors are.  The whole POINT of having Bomis (or a Nupedia
Foundation) owning the copyrights is to have a clear entity with clear
legal standing to sue in case of violations.  You know how wikis work.

Larry


subject: [Wikipedia-l] Copyrights

body:
I was not clear. Those who wrote content would have standing to sue, as
would Bomis, because the writers own the copyright to the texts, and Bomis
owns the copyright to the collection.

-----Original Message-----
From: Larry Sanger
To: Mark Christensen
Cc: ''wikipedia-l at nupedia.com' '
Sent: 2/6/02 7:11 PM
Subject: RE: [Wikipedia-l] Copyrights

Now, Jimbo, do you agree with that?  It's "those who wrote the content"
who would have the legal standing to sue if, for example, Microsoft were
to make an altered version of Wikipedia and try to copyright and sell
it?

On Wed, 6 Feb 2002, Mark Christensen wrote:

> I want to publically apologize, I intended that last message to go
directly
> to Larry, not to the list.  I'll try to discuss the issue with Larry
offline
> untill we at least both understand what the other is trying to say.
>
> Also, I agree, the issue of concensus is clearly of secondary
importance to
> understanding what acutally is the case, regardless of what anybody
thought
> in the past.
>
> In the mean time, let me answer Larry's question briefly.
>
> I don't think anybody could sucessfully sue, because we have a strong
> argument that the wikipedians page fulfills the FDL authorship
requirement.
> But it would be the copyright holders (those who wrote content) who
would
> have the legal standing to sue if there were in fact an actuall
violation.
>
> Yours
> Mark
>
>
>
> -----Original Message-----
> From: Larry Sanger
> To: 'wikipedia-l at nupedia.com'
> Sent: 2/6/02 6:35 PM
> Subject: RE: [Wikipedia-l] Copyrights
>
> I don't see that there has been the consensus you mention.  Frankly, I
> don't care if there has been, because I'm not arguing with you, I'm
> asking
> for clarification, for pete's sake!  Sheesh!
>
> OK, let me put my confusion a different way, because I still don't
> understand:
>
> WHO has the right to sue, and FOR WHAT do they have that right?
>
> Larry
>
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


subject: FW: [Wikipedia-l] Copyrights

body:
I agree, the issue of concensus is clearly of secondary importance
to understanding what acutally is the case, regardless of what anybody
thought in the past.

In the mean time, let me answer Larry's question briefly.

I don't think anybody could sucessfully sue, because we have a strong
argument that the wikipedians page fulfills the FDL authorship
requirement.  But it would be the copyright holders (those who wrote
content) who would have the legal standing to sue if there were in fact
an actuall violation.

Because the text is licenced under the FDL, which the copyright holder
has agreed to, he or she would have no standing to sue unless someone
broke that contract.

Yours
Mark

-----Original Message-----
From: Larry Sanger
To: 'wikipedia-l at nupedia.com'
Sent: 2/6/02 6:35 PM
Subject: RE: [Wikipedia-l] Copyrights

I don't see that there has been the consensus you mention.  Frankly, I
don't care if there has been, because I'm not arguing with you, I'm
asking
for clarification, for pete's sake!  Sheesh!

OK, let me put my confusion a different way, because I still don't
understand:

WHO has the right to sue, and FOR WHAT do they have that right?

Larry

[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l


from_name: Magnus Manske

subject: [Wikipedia-l] MySQL dump available

body:
Try
	mysqldump databasename -u username -p >targetfile
for the complete thing (better gzip it)

Magnus

> -----Original Message-----
> From: wikipedia-l-admin at nupedia.com
> [mailto:wikipedia-l-admin at nupedia.com]On Behalf Of Jimmy Wales
> Sent: Wednesday, February 06, 2002 6:03 PM
> To: wikipedia-l at nupedia.com
> Subject: Re: [Wikipedia-l] MySQL dump available
>
>
> Can someone tell me what I need to do here?
>
> I think Magnus already told me, but I can't find it now.  :-(
>
> Jan Hidders wrote:
>
> > Is there a dump of the Wikipedia tables available somewhere? I
> would like to
> > do some testing on a database with a realistic size.
> >
> > -- Jan Hidders
> >
> >
> > [Wikipedia-l]
> > To manage your subscription to this list, please go here:
> > http://www.nupedia.com/mailman/listinfo/wikipedia-l
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] Copyright notices

body:
I think this is exactly the issue in question.

Are we donating the copyrights to bomis or not?

Regardless of what we decide on the issue, unless wikipedia becomes a legal
entity the text will have to be changed.  If we decide to donate copyright,
the text should read something like:

 [ ] "I own the copyright to this file, and I hearby assign it to Bomis,
inc."

Then there should be an included check box which says:

 [ ] "This file is in the public domain."

If we decide not to assign copyright to bomis, it should read like the new
text and say:

 [ ] "I hereby affirm that this file is in the public domain, or that I own
the copyright for this file and make it avalable under GNU FDL."

-----Original Message-----
From: Brion Vibber
To: wikipedia-l at nupedia.com
Sent: 2/6/02 7:13 PM
Subject: [Wikipedia-l] Copyright notices

While we're on the subject of copyright notices, a little question about
the copyright assertion on the upload page. Currently it reads:

  [ ] I hereby affirm that this file is *not copyrighted*, or that I own
  the copyright for this file and donate it to Wikipedia.

Which has been questioned as ambiguous as to whether the *use* or the
*copyright* of the file is being donated. A revised version was just
checked into the code in the CVS repository which reads:

  [ ] I hereby affirm that this file is *not copyrighted*, or that I own
  the copyright for this file and place it under GPL licence.

Now, I'm assuming that the "GPL" is a typo for "GFDL", which can be
easily corrected before the change goes online. With that in mind, can
we all agree that the new message is sufficiently clear and correct? If
not, what ought it to say?

-- brion vibber (brion @ pobox.com)

[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l


subject: [Wikipedia-l] Summary of pseudo-subpage discussion

body:
AFAIK, we all agree on now:
* No magic character at all in page titles (thus, no real subpages)
* Avoid "/" character in page titles
* Some topics need an easy method of grouping related subtopics
* The obvious soultion is to use "Y (X)" instead of "X/Y"
* Linking within related pages should be simplyfied

Two basic ways to do that:
1. Use the parser to display links differently
2. Change certain "shortcuts" on save

---- Now, for my own opinion:

Personally, I am much in favor of #2, as there will be no special behaviour
added that complicates both the software and the understanding of rules for
newcomers. "Old hands" will know how to use this, other won't bother and
will, eventually, have to type the long title.

IF we could agree on #2, all we need to agree on otherwise is what kind of
shortcut should be used. It should be
* Simple
* Fast to type
* Unusual enough to not be used in a real page title

So, how about
* [[Elves()]] on [[Middle Earth]] becomes [[Elves (Middle Earth)]]

I guess no real article would ever end on "()", except you try to write
articles about functions with no parameter list ;)

Magnus


subject: [Wikipedia-l] Copyrights

body:
Larry Sanger wrote:
> > So then it would be up to the individual contributors to do something
> > about it.
>
> This is the part that puzzles me.  We don't know who the individual
> contributors are.  The whole POINT of having Bomis (or a Nupedia
> Foundation) owning the copyrights is to have a clear entity with clear
> legal standing to sue in case of violations.  You know how wikis work.

Well, presumably they know who they are, the contributors I mean.  And
if someone grabs some little piece of wikipedia and does something
improper with it, and if that part was not ever edited by any of our
regulars, then it's probably such a minor thing that going to court
would be a waste of time anyway.

It's hard to imagine any sort of wholesale violation of someone taking all
or even some big chunk of wikipedia (just the biographies, say) for which we
couldn't rustle up _someone_ with standing.

But, you're right of course.  This is one big downside of not having
people explicitly assign copyright to us: it could conceivably lead to
a situation where there is a violation but we can't pursue it for some
reason.

We should all remember, though, that one reason the GPL has never been
tested in court is that no one's ever _had_ to go that far.  Community
pressure can be a powerful thing.  So this is all probably academic anyway.


from_name: koyaanisqatsi at nupedia.com

subject: [Wikipedia-l] "Trolls" on the Catalan Wikipedia

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020206/185e3444/attachment.diff


from_name: Chuck Smith

subject: [Wikipedia-l] 100,000 articles...

body:
Hey, I was just thinking today about how quickly we're
writing new articles and I was wondering if anyone
(looks around for mathematicians/statisticians) could
calculate the exponential curve for the growth of
wikipedia and based on that try to guesstimate
travelling at the same exponential speed when we will
hit the 100,000 article mark.  There's your math
homework for the day, brought to you by Wikipedia.

Hey, and no comments about my degree in mathematics,
k...?

Thanks,
Chuck

=====
Venu al la senpaga, libera enciklopedio
esperanta reta! http://eo.wikipedia.com/
====
Junuloj!  Filadelfio, Usono 15an-17an de Februaro
http://unumondo.com/cgi-bin/wiki.pl?Filadelfia_JES

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com


from_name: Michel Clasquin

body:
On Wednesday 06 February 2002 20:30, Magnus Manske wrote:

> IF we could agree on #2, all we need to agree on otherwise is what kind
> of shortcut should be used. It should be
> * Simple
> * Fast to type
> * Unusual enough to not be used in a real page title
>
> So, how about
> * [[Elves()]] on [[Middle Earth]] becomes [[Elves (Middle Earth)]]

It's a small thing, but if possible make that [[Elves ()]] - note the
extra space

It's just a little more consistent - the less difference between the
shortcut and the final article, the better. In this case it expands the
required part between brackets, but does not add an extra space where none
was typed.

Of course, if  [[Elves()]] on [[Middle Earth]] becomes [[Elves(Middle
Earth)]] that serves the same purpose, but it looks funny.

--
Michel Clasquin, D Litt et Phil (Unisa)
clasqm at mweb.co.za/unisa.ac.za   http://www.geocities.com/clasqm
This message was posted from a Microsoft-free PC

...hey, at least a wild goose chase gives you some exercise-Neal Stephenson


subject: [Wikipedia-l] 100,000 articles...

body:
On Thu, 7 Feb 2002, David Merrill wrote:

> One interesting phenomenon, though, is that as the content broadens,
> people might tend to work more on existing articles and new article
> creation slow correspondingly. Not that that's a bad thing. It's
> better to have 50,000 excellent articles than 500,000 rambling,
> incoherent, or incorrect ones.

I agree with this, by the way.  I have a little theory that, as the easy
and broad topics get pretty much filled in, the project is going to start
looking more interesting to specialists, and I'll see a gradual influx of
Ph.D.'s and researchers filling in the blanks on the frontiers of their
fields.

This is mainly wishful thinking, of course; there's no *real* way of
knowing what's gonna happen.  It's possible that we will always suffer
from the stigma (if you want to call it that :-) ) of being completely
open to anyone to contribute, and as a result, there will be a level of
speciality, accessible mainly to specialists who care about exclusivity,
beyond which we just won't be able to go.  Of course, there will be
exceptions, as in the case of the engineer who wrote some articles about
some extremely specialized electrical engineering topics...

Idle musings...

Brace yourself for a huge announcement tomorrow.  :-)

Larry


subject: [Wikipedia-l] Re: Modest proposals

body:
> And, of course, as Lee already pointed out, it also makes it less tempting
> for the casual user. A very important argument.
There are 24000 articles now that don't use aliases; they're relatively
difficult to set up, and so it's not likely for them to become a major
subject of abuse.

> Perhaps the user wants this to happen, perhaps not. I suggest we first
wait
> and see how many people actually need such features.

_I_ need this feature. I also feel that bringing subpages back from the dead
the way this proposal stands is wrong

> > 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_.
>
> Have you seen the parsing code? There is nothing _very light_ about it, at
> the moment. I intend to improve that in the future, but found some other
> problems I would like to solve first. Anyway, adding non-trivial features
is
> not going to make that job easier.

I must admit that I did not see the code; however the wiki markup is really
simple, compared to most other markup and general-use languages out there.
High-performance parsers exist; I believe that eventually the Wiki parser
will match them.

If we really want to improve performance, perhaps we should simplify
some syntax structures (e.g. doing ISBNs through links
[ISBN 200145-3453|this way]), write a formal grammar and then
write a parser in C (or some other high-performance language) to
reflect that formal grammar. But I digress :-).

Sincerely yours,
                Uri Yanover


subject: [Wikipedia-l] To all programmers

body:
Hi all,

I just commited a huge change to the CVS repository. The "specialPages.php"
file, which contained a lot of functions and was about 64K (!) long, is now
converted into several small files, all starting with "special_".

This has some advantages:
* As only the need file is now loaded by the PHP compiler (instead of the
whole thing, as it was before), compilation times will drop dramatically
* It is easier to change a single function, as the propability of two people
editing the same file at the same time is reduced
* It is much more easy to read now
* Update/commit times are much shorter ;)

Everyone, please checkout this version. Do not commit any changes you might
have made to "specialPages.php" since your last update, but save them
somewhere else, update your local repository, then insert the changes into
the specific file.

As "specialFunctions.php" could only be included at four points in the whole
software (three of them in wiki.phtml), chances are that there will be no
bugs resulting from this structural change. Try it out anyway, just to make
sure.

Jimbo, update ASAP ;)

Magnus


from_name: David Merrill

subject: [Wikipedia-l] 100,000 articles...

body:
On Thu, Feb 07, 2002 at 03:21:40AM +0000, Jo?o M?rio Miranda wrote:
>
>
> Chuck Smith wrote:
> >
> > Hey, I was just thinking today about how quickly we're
> > writing new articles and I was wondering if anyone
> > (looks around for mathematicians/statisticians) could
> > calculate the exponential curve for the growth of
> > wikipedia and based on that try to guesstimate
> > travelling at the same exponential speed when we will
> > hit the 100,000 article mark.  There's your math
> > homework for the day, brought to you by Wikipedia.
>
> With some imperfect data I got the equation:
>
> Articles=1.6*Days^1.6077
>
> Days=Days after January 15 2000.
>
> That means we will have 100 000 articles in August 2003.

One interesting phenomenon, though, is that as the content broadens,
people might tend to work more on existing articles and new article
creation slow correspondingly. Not that that's a bad thing. It's
better to have 50,000 excellent articles than 500,000 rambling,
incoherent, or incorrect ones.

Regardless, it seems almost a mathematical certainty that Wikipedia is
going to be one of the best resources on the Net. Already is, really.
:-)

--
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   david at lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org

Some weeks it looks like Redmond feels entitled to capture not just part of
what we save, but all of it. That just isn't going to fly with corporate
America forever. When your margins are more sensitive to Bill Gates'
pricing whims than they are the price of oil, that's an untenable position
for a large company to be in.
	--John Chapman Sr., BP Amoco Technology Executive


subject: [Wikipedia-l] 100,000 articles...

body:
On Wed, Feb 06, 2002 at 09:32:54PM -0800, Larry Sanger wrote:
> On Thu, 7 Feb 2002, David Merrill wrote:
>
> > One interesting phenomenon, though, is that as the content broadens,
> > people might tend to work more on existing articles and new article
> > creation slow correspondingly. Not that that's a bad thing. It's
> > better to have 50,000 excellent articles than 500,000 rambling,
> > incoherent, or incorrect ones.
>
> I agree with this, by the way.  I have a little theory that, as the easy
> and broad topics get pretty much filled in, the project is going to start
> looking more interesting to specialists, and I'll see a gradual influx of
> Ph.D.'s and researchers filling in the blanks on the frontiers of their
> fields.

I could see that happening.

Don't take this the wrong way, but it's also possible Wikipedia just
can't ever be really "authoritative" in any field. And that is fine
with me. Perhaps the big draw of Wikipedia will be that it contains
much more accessible general information than anything else. I don't
know if that will be the case or not, but I also really don't care.
However, it finally shapes up, it will be (and is) great. :-)

It's not the kind of thing you can force. It will become what
Wikipedians want it to be. As a Wiki, it really can be all things to
all people.

One thing I already notice about Wikipedia is that the content is much
broader than any other encyclopedia. Almost an Encyclopedia Galactica
or H2G2. That's what I like most about it. In fact, once or twice I
have been interested in finding out about something little-known, and
started an article with nothing but a few questions I had. In each
case, the information was forthcoming. What a cool thing that was!

Anyway, enough meta-discussion on content.

> Brace yourself for a huge announcement tomorrow.  :-)

Oh? Can't wait. :-)

Later,

--
David C. Merrill                         http://www.lupercalia.net
Linux Documentation Project                   david at lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org

We came from Caladan -- a paradise world for our form of life. There
existed no need on Caladan to build a physical paradise or a paradise of
the mind -- we could see the actuality all around us. And the price we
paid was the price men have always paid for achieving a paradise in this
life -- we went soft, we lost our edge.
	-- from "Must'Dib: Conversations" by the Princess Irulan


from_name: João Mário Miranda

subject: [Wikipedia-l] 100,000 articles...

body:
Chuck Smith wrote:
>
> Hey, I was just thinking today about how quickly we're
> writing new articles and I was wondering if anyone
> (looks around for mathematicians/statisticians) could
> calculate the exponential curve for the growth of
> wikipedia and based on that try to guesstimate
> travelling at the same exponential speed when we will
> hit the 100,000 article mark.  There's your math
> homework for the day, brought to you by Wikipedia.

With some imperfect data I got the equation:

Articles=1.6*Days^1.6077

Days=Days after January 15 2000.

That means we will have 100 000 articles in August 2003.

--
jo?o
http://www.nonio.com


from_name: The Cunctator

subject: [Wikipedia-l] Re: copyright

body:
Why doesn't someone ask RMS/FSF for advice? I'm sure they'd be
happy to help clarify the proper application of copyright with (semi)
anonymous authors to the GFDL, with respect to defending the
license.


subject: [Wikipedia-l] Re: copyright

body:
http://www.publaw.com/joint.html

Wikipedia is a clear case of co-authorship, and
Bomis is not only the publisher but a co-author, since
its employees are authors. Joint authorship standards assert
that any co-author may claim authorship over the entire work,
even if that author has only contributed to one particular
section.

In other words, any author (including Bomis) can sue in the
case of infringement of any article in Wikipedia, even if they
didn't contribute to that particular article.

The statement that Bomis is a co-author assumes that Wales &
Sanger are working for hire, which is automatically the case
unless they have an explicit agreement otherwise.

Also, as has previously been discussed, copyright is
not transferrable without a signed contract, even
if there's a checkbox upon initial submission.

(see http://www.loc.gov/copyright/circs/circ1.html#toc)

I have no idea how damages would he dealt with. Probably
injunctions is just about all that could be sued for.


subject: [Wikipedia-l] FSF seeks comments on draft 1.2 of the FDL (fwd)

body:
This would seem to be very important.  If you can, please give this your
full attention!

---------- Forwarded message ----------
Date: Thu, 07 Feb 2002 12:49:47 -0500
From: Bradley M. Kuhn <bkuhn at fsf.org>
Reply-To: fdl-comments at fsf.org
To: comments at nupedia.com
Subject: FSF seeks comments on draft 1.2 of the FDL

I am sending this announcement to this mailing list directly because many
of you likely have a great interest in commenting on this draft, and I
wanted to make sure that you didn't miss it.

A draft of the GNU Free Documentation License (FDL), Version 1.2 is now
available on our website.  We are asking for feedback from the Free
Software community on this draft.  Please send comments to
<fdl-comments at fsf.org>.  The comment period is open until 1 March 2002.

Related URLs:

  FDL Main page:
      http://www.gnu.org/licenses/fdl.html

  FDL 1.2 Draft:
      http://www.gnu.org/licenses/fdl-1.2-draft.txt

  Unified diff of FDL 1.1 and FDL 1.2:
      http://www.gnu.org/licenses/fdl-1.1-to-1.2-draft.diff

--
Bradley M. Kuhn, Vice President
Free Software Foundation     |  Phone: +1-617-542-5942
59 Temple Place, Suite 330   |  Fax:   +1-617-542-2652
Boston, MA 02111-1307  USA   |  Web:   http://www.gnu.org


from_name: lcrocker at nupedia.com

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020207/0bdbaa0b/attachment.diff


subject: [Wikipedia-l] Copyrights

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020207/95bfbc37/attachment.diff


subject: [Wikipedia-l]  copyright

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020207/9afab8d4/attachment.diff


from_name: Bradley M. Kuhn

subject: [Wikipedia-l] FSF seeks comments on draft 1.2 of the FDL

body:
I am sending this announcement to this mailing list directly because many
of you likely have a great interest in commenting on this draft, and I
wanted to make sure that you didn't miss it.

A draft of the GNU Free Documentation License (FDL), Version 1.2 is now
available on our website.  We are asking for feedback from the Free
Software community on this draft.  Please send comments to
<fdl-comments at fsf.org>.  The comment period is open until 1 March 2002.

Related URLs:

  FDL Main page:
      http://www.gnu.org/licenses/fdl.html

  FDL 1.2 Draft:
      http://www.gnu.org/licenses/fdl-1.2-draft.txt

  Unified diff of FDL 1.1 and FDL 1.2:
      http://www.gnu.org/licenses/fdl-1.1-to-1.2-draft.diff

--
Bradley M. Kuhn, Vice President
Free Software Foundation     |  Phone: +1-617-542-5942
59 Temple Place, Suite 330   |  Fax:   +1-617-542-2652
Boston, MA 02111-1307  USA   |  Web:   http://www.gnu.org


subject: [Wikipedia-l] Re: copyright

body:
Lars Aronsson wrote:
> The Cunctator wrote:
> > Why doesn't someone ask RMS/FSF for advice?

I have discussed all this stuff with RMS, and expect to do so in the
future, as well.

--Jimbo


from_name: 'Dragon' Dave McKee

subject: [Wikipedia-l] Possible Legal Fix?

body:
I've been thinking. If there's a legal issue on a copyleft material, who
is legally in charge?

a) *All* editors
b) Most recent editor
c) Original editor
d) Any editor(s)

If a), then copyleft is up shit-creek, 'cos all it needs is one
GNU-compliant editor who blocks all legal challenges to stop problems.

If b), we're also stuck, for all it takes is that one blocker to be the
last editor.

If c), then that's bad, 'cos if someone made a stub article, they're
effectively the legal guardian of that work.

If d), then that's great. All we do is get Bomis/Wikipedia/Nupedia or
whatever to be an editor of the work, ensuring that they can act as the
main guys should stuff go wrong.

As for un-copylefting, *ALL* authors are required - so Wikipedia content
can, effectively, NEVER be proprietary unless seventy years pass between
edits.

I may be completely wrong, however...


from_name: Brion L. VIBBER

subject: [Wikipedia-l] Most Wanted Refresh

body:
Chuck Smith wrote:

>Hey Programmers,
>
>How about running a cron job every 30 minutes or so
>that refreshes the Most Wanted page instead of having
>a Refresh link (and tell users the page updates every
>30 minutes)?  I have this feeling that some unkind
>person will find that and run a script to load that
>page every minute or so to really slow down the
>server...  I wouldn't be surprised if it isn't already
>happening!
>
Someone who wants to load the server can do so just as easily by
reloading RecentChanges with the number of changes set to a gazillion or
running searches with lots of wildcards.

However an automatic refresh is a good idea. That's not really something
we can do *inside* the script though; what we *can* do is:

1. Provide a URL which can be called to initiate the refresh (we have
that now). Jimbo could easily slip a call to the refresh URL (via wget
or lynx) into the server's crontab to be run on a regular basis if
that's so desired. Jimbo?

2. Limit the frequency with which a refresh is allowed (hmm, good idea,
I'll add that)

3. Hide the manual refresh link from the page (probably not necessary
with #2 implemented; I can see where somebody's just linked up a bunch
of wanted pages and wants to see the new list, but doesn't want to wait
20 minutes for the next auto refresh)

>I had A LOT of trouble connecting today and I'm
>thinking it would be best to follow our general rule
>to do whatever would best benefit Wikipedia.  I mean
>Most Wanted is great, but not if it keeps people from
>editing and writing articles...  I know I would've
>written a rather lengthy article today, but it was
>down (of course I could've done it offline, but
>hey...)
>
It's improving, slowly. :) The cacheing should help, as should the
Alternative PHP Cache that Jimbo installed. We're also about to try
rewriting the Recent Changes code to be much much more efficient.

Oh, and Chuck, are you still having problems logging in? Unfortunately
both Magnus and I are having trouble replicating the login problems, so
we're not quite sure what it's doing wrong...

-- brion vibber (brion @ pobox.com)


body:
It seems that this (partly) adressed at me...

> Right.  Talk about private clubs.  I understand that
> the list serves mostly to facilitate improvements on
> the site, and therefore runs to programming
> conversations.  HOWEVER, even though I have worked on
> a development team where I had to deal with SQL
> developers on a regular basis, I can't follow you guys
> at all.

Sorry to hear that. We (the geeks;) might get our own mailing list soon
(wiki-geek-l?), so this list can be more "meta" again, concerning content,
and less tech talk.

> This is all in the way of showing that the geekspeak
> is a bit exclusionary.  Probably not in and of itself
> a problem -- except that you guys are talking about
> changes (and in the case of the new site, implementing
> changes) that affect all of us other users -- AND YOU
> AREN'T COMMUNICATING THEM.  The FAQ's haven't really
> been updated, lots of people seem unaware that the
> /subpage no longer exists....  and even those of us
> who would be happy to help document changes and spread
> the word can't, because we don't speak programmer well
> enough to be sure.

The sourceforge test page was announced several month ago, together with the
notice that we will eventually switch to this software. Big signs on the
'pedia itself *and* this list. Not many people showed up.

Then, we got meta.wikipedia.com. People used (and use) it, made some
comments.

Then, we had discussion about subpages (more than I could stand, actually;),
on the wiki, the meta.wiki, and this list.

Then, we got test.wikipedia.com. Again, everybody was invited to look and
test.

Then, after month of testing and announcing, we switched over to the new
software.

True, documentation is not as it is supposed to be. IMHO, this is because of
three reasons :
1. Personally, I dislike writing lengthy documentation for my software, even
more than ironing ;)
2. The software is still "in flux". Things are still changing, because we
can make them better. I write changes and bugfixes as soon as I get home
from work, and I log off at 1am. No time to write documentation that will be
obsolete tomorrow. See the "Most Wanted" as an example of how things change.
3. Non-programmers don't seem to care (except you, I guess).

Anyway, there's *some* docu at "PHP script new behaviours".

> For pity's sake -- can we please clean up the
> documentation for rev2 before going to rev2a?  I'll
> help -- but not unless somebody helps me first!

If there's *anything* you need to know about the software that you can't
conclude from using it, do not hesitate to mail me personally :)

Magnus


subject: [Wikipedia-l] Most Wanted Refresh

body:
Hey Programmers,

How about running a cron job every 30 minutes or so
that refreshes the Most Wanted page instead of having
a Refresh link (and tell users the page updates every
30 minutes)?  I have this feeling that some unkind
person will find that and run a script to load that
page every minute or so to really slow down the
server...  I wouldn't be surprised if it isn't already
happening!

I had A LOT of trouble connecting today and I'm
thinking it would be best to follow our general rule
to do whatever would best benefit Wikipedia.  I mean
Most Wanted is great, but not if it keeps people from
editing and writing articles...  I know I would've
written a rather lengthy article today, but it was
down (of course I could've done it offline, but
hey...)

Chuck

=====
Venu al la senpaga, libera enciklopedio
esperanta reta! http://eo.wikipedia.com/
====
Junuloj!  Filadelfio, Usono 15an-17an de Februaro
http://unumondo.com/cgi-bin/wiki.pl?Filadelfia_JES

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com


subject: [Wikipedia-l] locked front page / sysop status

body:
Can we lock down the Main Page again?  If nothing
else, could we make it so that it cannot be edited by
anonymous users?

Thanks,
Chuck

=====
Venu al la senpaga, libera enciklopedio
esperanta reta! http://eo.wikipedia.com/
====
Junuloj!  Filadelfio, Usono 15an-17an de Februaro
http://unumondo.com/cgi-bin/wiki.pl?Filadelfia_JES

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com


body:
As a sysop, I don't see a link that would let me do this.  Has it already
been done, Jimbo or Magnus?  On other pages, I see a "Protect this page"
link, but not on the Main Page.

Larry

On Thu, 7 Feb 2002, Chuck Smith wrote:

> Can we lock down the Main Page again?  If nothing
> else, could we make it so that it cannot be edited by
> anonymous users?
>
> Thanks,
> Chuck
>
> =====
> Venu al la senpaga, libera enciklopedio
> esperanta reta! http://eo.wikipedia.com/
> ====
> Junuloj!  Filadelfio, Usono 15an-17an de Februaro
> http://unumondo.com/cgi-bin/wiki.pl?Filadelfia_JES
>
> _________________________________________________________
> Do You Yahoo!?
> Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
> Vis?tanos en http://noticias.espanol.yahoo.com
> [Wikipedia-l]
> To manage your subscription to this list, please go here:
> http://www.nupedia.com/mailman/listinfo/wikipedia-l
>


from_name: Lars Aronsson

subject: [Wikipedia-l] Re: copyright

in_reply_to:
<3C625763.D87170C@kband.com> (message from The Cunctator on Thu,
	07 Feb 2002 05:31:03 -0500)

body:
The Cunctator wrote:
> Why doesn't someone ask RMS/FSF for advice?

Those interested in copyright (and -left) issues, might want to join
the UPD-discuss mailing list from the Union for the Public Domain,
http://lists.essential.org/mailman/listinfo/upd-discuss

Copyright issues are not trivial.  Copyright law exists because of
various historic reasons, which are not completely relevant today.
Even the GNU GPL, while it has served well for more than a decade, has
its limitations and works best for entire software applications.  The
special needs of separately distributed software libraries called for
the creation of LGPL, and the special needs of separately distributed
software documentation called for the creation of GNU FDL.  I should
be really surprised if any of these license texts were perfectly
applicable to the new situation of Wikipedia.  It might be useful to
ask RMS/FSF for advice, but he/they might also need advice from us.

--
  Lars Aronsson
  <lars at aronsson.se>
  tel +46-70-7891609
  http://aronsson.se/ http://elektrosmog.nu/ http://susning.nu/


subject: [Wikipedia-l] Tech update; programmers only! ;)

body:
I just updated the CVS with the caching mechanism I proposed on the tech
talk page.

It is deactivated by default, because you need to alter your database prior
to use.

To activate:
1. In mysql, add the field cur_cache:
	ALTER TABLE cur ADD cur_cache MEDIUMTEXT
2. Edit wikiText.php and remove the # from the last coding line, so that it
reads
	$useCachedPages = true ;

The one thing I didn't implement is the regular "forced update" of the
cache. This could be done by counting the views and flushing the cache
after, say, 50 views. It could also be time-based, so it is refereshed if
the cache is more than two weeks old. (just example values)

Note that pages with variables (like the Main Page with
{{NUMBEROFARTICLES}}) are *not* cached.

I noticed a slight performance improvement at my machine (~15%) when reading
a cached page, and no noticable delay on saving the cache.

"The Need For Speed" continues on this channel ;)

Magnus


subject: [Wikipedia-l] trolls

body:
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020208/dd1975d4/attachment.diff


from_name: Uri Yanover

body:
> IF we could agree on #2, all we need to agree on otherwise is what kind of
> shortcut should be used. It should be
> * Simple
> * Fast to type
> * Unusual enough to not be used in a real page title
>
> So, how about
> * [[Elves()]] on [[Middle Earth]] becomes [[Elves (Middle Earth)]]
>
> I guess no real article would ever end on "()", except you try to write
> articles about functions with no parameter list ;)

I agree with this syntax, as well as with the general () notation; but
for various reasons I think it's best to leave the articles _exactly_
the way they were typed, and do the conversion in runtime.

            Uri Yanover


subject: [Wikipedia-l] Optimizing the Wiki parser

body:
Hello,

During the course of our recent discussion, Jan
Hidders said:

> Have you seen the parsing code? There is nothing _very light_ about it, at
> the moment.

As soon as I had the opportunity, I located the
current Wiki parsing code

(http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wikipedia/phpwiki/fpw/wikiPa
ge.php?rev=1.44&content-type=text/vnd.viewcvs-markup)

It occured to me that while the current code is fine
as an initial version, it should be optimized if we
expect the Wikipedia traffic to grow significantly,
since using PHP regular expressions and string
management functions to process the markup is
inefficient.

The obvious solution would be to write a "real"
one-pass parser. Doing this stand-alone (or as CGI)
would be quickest using C; I do not know whether an
efficient solution exsits using PHP considering the
way strings are implemented in it. However,
executing C code from PHP is complicated in its
own right (UNIX pipes being the simplest solution,
in my opinion).

I could try to re-write the parser in either PHP
or C, but I wanted to ask first the members of
what do they think of the subject (the extent
to which the code can be optimized, which
language to choose, in what technique should the
parser be written, which Wiki syntax changes
should be made, etc.).

Sincerely yours,
                        Uri Yanover


from_name: ephemeron

subject: [Wikipedia-l] Downloadable wiki

body:
Is there a downloadable version of the wikipedia, which I can burn to,
say, CD-ROM? I see this link:

http://www.wikipedia.com/tarballs


subject: [Wikipedia-l] Possible Legal Fix?

body:
On Thu, 07 Feb 2002 14:58:12 +0000
"'Dragon' Dave McKee" <d.n.mckee at durham.ac.uk> wrote:

> I've been thinking. If there's a legal issue on a copyleft material, who
> is legally in charge?
>
> a) *All* editors
> b) Most recent editor
> c) Original editor
> d) Any editor(s)
>
> If a), then copyleft is up shit-creek, 'cos all it needs is one
> GNU-compliant editor who blocks all legal challenges to stop problems.
>
> If b), we're also stuck, for all it takes is that one blocker to be the
> last editor.
>
> If c), then that's bad, 'cos if someone made a stub article, they're
> effectively the legal guardian of that work.
>
> If d), then that's great. All we do is get Bomis/Wikipedia/Nupedia or
> whatever to be an editor of the work, ensuring that they can act as the
> main guys should stuff go wrong.
>
> As for un-copylefting, *ALL* authors are required - so Wikipedia content
> can, effectively, NEVER be proprietary unless seventy years pass between
> edits.

You can't license retroactively, unless there's a clause which states
that the license can be revoked at any time. What's already copylefted
can't be uncopylefted. The withdrawing author might decide to place a
version of his document/article under a more traditional copyright. But
that would affect only the subsequent versions.


subject: [Wikipedia-l] login working

body:
Brion,

Login has been working again for some time now...  I
thought you knew it was fixed... maybe it was magic.
;-)

Thanks,
Chuck

=====
Venu al la senpaga, libera enciklopedio
esperanta reta! http://eo.wikipedia.com/
====
Junuloj!  Filadelfio, Usono 15an-17an de Februaro
http://unumondo.com/cgi-bin/wiki.pl?Filadelfia_JES

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com


subject: [Wikipedia-l]  Plans for RecentChanges page; programmers only!

body:
Jan Hidders wrote:

>Dear fellow programmers,
>
>I saw that the SQL code for the Recent Changes page is rather inefficient
>and causes a lot of database access, so I decided to improve this. However,
>I can only do this properly if the timestamp field in the tables is split in
>a day and a time field.
>
Can I ask how exactly that would help? I'm not much of a database guru,
so the answer isn't obvious to me and I'm a bit curious.

-- brion vibber (brion @ pobox.com)


list: wikitech-l

subject: [Wikitech-l] New list

body:
This is the new list for tech discussions for wikipedia:

wikitech-l at nupedia.com


subject: [Wikipedia-l] wikitech-l

body:
I've set up a new mailing list for technical matters.

Some of you have gotten notices that you're subscribed -- I took the small
liberty of adding a few people by hand.  I'm sure that by no means did I get
everyone who wants to join in.  :-(

http://www.nupedia.com/mailman/listinfo/wikitech-l

Is the place to go to add yourself, or to set your subscription options.


body:
(moving thread to wikitech-l)

Jan Hidders wrote:

>From: "Brion L. VIBBER" <brion at pobox.com>
>
>>Jan Hidders wrote:
>>
>>>Dear fellow programmers,
>>>
>>>I saw that the SQL code for the Recent Changes page is rather inefficient
>>>and causes a lot of database access, so I decided to improve this.
>>>
>However,
>
>>>I can only do this properly if the timestamp field in the tables is split
>>>
>in
>
>>>a day and a time field.
>>>
>>Can I ask how exactly that would help? I'm not much of a database guru,
>>so the answer isn't obvious to me and I'm a bit curious.
>>
>
>It allows me to do a GROUP BY on the day. That way I can take a left outer
>join between the cur table and the old table and group on the combination of
>cur_day and cur_title. This allows me to get all the information I need for
>the page in one SQL statement.
>
Right. Hmm, can you use TO_DAYS(cur_timestamp) or some such? Or is that
just going to cause problems?

If it's more efficient to use a split timestamp, I can't come up with
any objection. But, it's Magnus' baby. :)

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Re: [Wikipedia-l]  Plans for RecentChanges page; programmers only!


subject: [Wikitech-l] Questions about installing

body:
When I check everything out of the CVS, I do it into a directory that has
nothing to do with the real site.

Then, I copy the files over to the proper location.

It seems that wikiText.php AND wikiTextEn.php are always different, and I have
to edit them... so really, I shouldn't be copying them unless there's a good reason,
right?

Here's my exact question:

wikiTextEn.php warns me:
# ATTENTION:
# To fit your local settings, PLEASE edit wikiText.php ONLY!
# Change settings here ONLY if they're to become global in all wikipedias!

But that seems a bit "opposite" to me... doesn't wikiTextEn mean "wikiText English"?
If so, then changes here should ONLY affect the English wikipedia, not "global in
all wikipedias"?

Also, whichever way it is supposed to be, I'm sure I should only have to edit one file.
But I have to edit two.

First, $wikiCurrentServer returns http://wikipedia.com in the default configuration, but
we prefer http://www.wikipedia.com/ (see line 12 of wikiTextEn.php, I always edit to
hardcode this.)

And on the next line, $wikiSQLServer is different locallly: the database is named
"wiki" instead of "wikipedia".

So, should I just add those two things to wikiText.php?  And that will override the
stuff in wikiTextEn.php?


subject: [Wikitech-l] Questions about installing

body:
Brion L. VIBBER wrote:
> But then, should it be called wikiText.php at all? Would
> wikiSettings.php make more sense, maybe?

Yes!  Or, wikiLocalSettings.  This would be settings which override whatever may
be in the "default" package, but specific to this _site_.

For example, on Magnus's machine, the database is 'wikipedia', and the user/password
for mysql are different.  So those would all go in the wikiLocalSettings file.

> I think the wikiTextEn.php defaults should be what you're actually using
> on the English wikipedia!

Right, especially for internationalization stuff.

What might make sense would be for us to have wikiSettings or wikiLocalSettings, and
that's where stuff goes that we are _fairly confident_ will be different on different
people's machines.


subject: [Wikitech-l] Questions about installing

body:
Jimmy Wales wrote:

>wikiTextEn.php warns me:
># ATTENTION:
># To fit your local settings, PLEASE edit wikiText.php ONLY!
># Change settings here ONLY if they're to become global in all wikipedias!
>
>But that seems a bit "opposite" to me... doesn't wikiTextEn mean "wikiText English"?
>If so, then changes here should ONLY affect the English wikipedia, not "global in
>all wikipedias"?
>
My understanding is that wikiTextEn.php is going to contain all the
default values. For the other-language versions, alternate server name,
character set, message strings, etc. will be set in e.g. wikiTextDe.php
or wikiTextPl.php. The theory is that anything that's *not* set in the
language-specific file will get the default value; thus if a new feature
is added that needs a message string $wikiFooBar, the English message
defined in wikiTextEn.php will show up, rather than nothing, if the
local wikiTextXx.php isn't updated.

Ultimately, wikiText.php should probably be nothing more than:
  include("wikiTextEn.php");
  include("wikiTextSomeOtherLanguage.php");

Anything additional in that file might be for site-specific data; for
instance if somebody sets up a read-only mirror of Wikipedia, they could
customize just that file to include their alternate server name, a title
string that links to the live 'pedia, and a hypothetical
refuse-all-edits option.

But then, should it be called wikiText.php at all? Would
wikiSettings.php make more sense, maybe?

>Also, whichever way it is supposed to be, I'm sure I should only have to edit one file.
>But I have to edit two.
>
Yeah, that's a little vague and needs to be worked out in better detail.

>First, $wikiCurrentServer returns http://wikipedia.com in the default configuration, but
>we prefer http://www.wikipedia.com/ (see line 12 of wikiTextEn.php, I always edit to
>hardcode this.)
>
>And on the next line, $wikiSQLServer is different locallly: the database is named
>"wiki" instead of "wikipedia".
>
>So, should I just add those two things to wikiText.php?  And that will override the
>stuff in wikiTextEn.php?
>
I think the wikiTextEn.php defaults should be what you're actually using
on the English wikipedia!

-- brion vibber (brion @ pobox.com)


body:
Jan Hidders wrote:

>From: "Brion L. VIBBER" <brion at pobox.com>
>
>>Right. Hmm, can you use TO_DAYS(cur_timestamp) or some such? Or is that
>>just going to cause problems?
>>
>
>Unfortunately MySQL only allows column names in the GROUP BY clause.
>
D'oh! Well then, two columns it is.

-- brion vibber (brion @ pobox.com)


from_name: Julie Kemp

subject: [Wikipedia-l] Re: Documentation and user aids

body:
HI all --

Magnus, it wasn't really aimed all at you, because
frankly I'm not sure who does what!

Although I truly appreciate the documentation =
ironing thing, there needs to be something.  And
unfortunately, your answer waas sooooo programmer!
Most people aren't.  I'm lucky because I've actually
had to translate geekspeak to sales/customer support
in a couple of jobs, so I had an inkling, but frankly
the discussion bored the hell out of me because it
never got to the user level.

Yes, you guys let interested parties know what was
going on -- i.e., that changes were being made -- but
not how those changes would affect the site and its
use in user-speak.

Here are some very fundamental issues that need
addressing:

1)  What happened to sub-pages and why

2)  What the HELL is a namespace (and a ton of related
questions -- like if there are no subpages, why is
there a talk link?

3)What changes have been made to the use of certain
punctuation marks in titles?

4)Where subpages once existed, how did the conversion
affect them?

5) HOw do I redirect?  (If it's the same as before, it
doesn't seem to work with articles entitled with
people's names)

Lots of questions!  NO answers.  I suggest a New
Features special page that has FAQs and a kind of tour
for newbies and those of us who have been around a
while but just want to use the site -- and don't
really care how it works, as long as it does!! ;-)

I will help in any way I can, but I really think we
need something!  [[JHK]]

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com


from_name: Jimmy Wales

subject: [Wikitech-l] Speedup suggestions

in_reply_to: <200202082235.XAA06413@atm3.uni-paderborn.de>; from axel@uni-paderborn.de on Fri, Feb 08, 2002 at 11:35:17PM +0100

body:
Axel Boldt wrote:
> 3) Assuming that php runs as an apache module, we should use
>    persistent database connections. That way, we won't repeatedly send
>    over the username and password; one connection is reused by apache
>    even after the php script dies.
>    (http://www.phpbuilder.com/manual/features.persistent-connections.php
>    and http://www.phpbuilder.com/manual/function.mysql-pconnect.php)

After reading these two pages, it seemed that all I needed to do was change
mysql_connect in databaseFunctions.php to mysql_pconnect.

It's a little early to get *too* excited, but so far the results seem astonishing!

This is the first time I've seen the 5 minute load on the machine under 3 in days.
And it's 0.46 now.

Also, I'm getting 2.52 pages per second from my little benchmarking tool.  This is
dramatically better than the 1/2 page per second pace we've been seeing.

--Jimbo


in_reply_to: <200202082310.g18NAgQ05717@levi.aronsson.se>; from lars@aronsson.se on Sat, Feb 09, 2002 at 12:10:42AM +0100

body:
Lars Aronsson wrote:
> more efficient can a new parser be?  Twice as fast?  Is it possible to
> add more hardware (multiprocessor) instead?

I'm looking at adding hardware -- this machine is a single processor
Pentium III/866, but it's a dual processor motherboard.  I don't know
how much this will help, though.

However, I will say this: based on my extensive experience running
busy websites (Bomis), it seems very unlikely that the problem is just
_hardware_.  I think we have a long way to go in terms of optimizing
first.

Just switching from mysql_connect to mysql_pconnect has resulted in a
speedup from 1/2 page per second to over 2 pages per second.  So
that's 400% right there.  Adding a second processor may speed things
up by what, well 100% at _best_, but realistically probably 30%.

Anyhow, I agree with you 100% -- I don't think that regex parsing is the
primary bottleneck (although I think we should profile to be sure!).  I
think it's excessive or inefficient SQL queries.

Is there an easy way in mysql to turn on some logging to see which
queries are taking the longest?  If we had some metric telling us what
our bottleneck is, i.e.  things that get called a lot AND that take a
long time, then I bet we could end up very pleased with the results.

--Jimbo


from_name: Jan Hidders

body:
From: "Uri Yanover" <uriyan_subscribe at yahoo.com>
>
> It occured to me that while the current code is fine
> as an initial version, it should be optimized if we
> expect the Wikipedia traffic to grow significantly,
> since using PHP regular expressions and string
> management functions to process the markup is
> inefficient.
>
> The obvious solution would be to write a "real"
> one-pass parser.

Actually that is what I also first had in mind, but now I
think that this would be a bad idea. It makes the code
more complicated and therefore harder to debug and
harder to introduce new and/or changed mark-up
features. It is important that the code is kept so simple
that newcomers who find a bug should in principle, if
they know PHP and MySQL, be able to find the
problem and send a patch.

Moreover, I don't think that doing it with
regular expresssions is that inefficient. The regular
expressions, especially the Perl compatible ones, are
very well implemented in PHP and most wiki systems
do it that way. If you are clever with perl regular expressions
there is still a lot of optimization that you can do. If you
want inspiration look at the implementation of PhpWiki.

> I could try to re-write the parser in either PHP
> or C, but I wanted to ask first the members of
> what do they think of the subject (the extent
> to which the code can be optimized, which
> language to choose, in what technique should the
> parser be written, which Wiki syntax changes
> should be made, etc.).

My advice would be: first try it in PHP with the PCRE's.
If that doesn't work, write a real one-pass parser in PHP. If that
also doesn't work, then you can start thinking about C and, for example,
yacc/bison. As for Wiki syntax changes, IMO we should first get the
current syntax efficiently and error-free working, and only then start
thinking
about changes and extensions.

Kind regards,

-- Jan Hidders


body:
From: "Magnus Manske" <Magnus.Manske at epost.de>
>
> To activate:
> 1. In mysql, add the field cur_cache:
> ALTER TABLE cur ADD cur_cache MEDIUMTEXT
> 2. Edit wikiText.php and remove the # from the last coding line, so that
it
> reads
> $useCachedPages = true ;

I didn't see the cur_cache field in wikipedia.sql. Is that on purpose?

-- Jan Hidders


subject: [Wikitech-l] Old cache on Main Page

body:
Magnus Manske wrote:

>I'm not sure if this will be fixed with the next bugfix, but I edited the
>Main Page (twice) to remove the counter, but I still get the old cached page
>("23.338 articles").
>
Hmm. I did an edit/save and it shows correctly now.

Ahhh, mystery bugs. Love 'em!

-- brion vibber (brion @ pobox.com)


body:
> Actually that is what I also first had in mind, but now I
> think that this would be a bad idea. It makes the code
> more complicated and therefore harder to debug and
> harder to introduce new and/or changed mark-up
> features. It is important that the code is kept so simple
> that newcomers who find a bug should in principle, if
> they know PHP and MySQL, be able to find the
> problem and send a patch.

Well, while easiness of debugging is important, it
is still possible to write a good parser that would
be easy to debug; keeping it simple for as long as
possible might lead to very hasty and ugly attempts
to optimize when it's too late.

> Moreover, I don't think that doing it with
> regular expresssions is that inefficient. The regular
> expressions, especially the Perl compatible ones, are
> very well implemented in PHP and most wiki systems
> do it that way. If you are clever with perl regular expressions
> there is still a lot of optimization that you can do. If you
> want inspiration look at the implementation of PhpWiki.

Looking at PhpWiki was exactly what I did. And I
know that PHP regexps are good, but they still take
time to be evaluated. As of now (v. 1.51), the code
uses regexps (and str_replaces) for the following:

1. Image linking
2. External links
3. Wiki variable substitution
4. Wiki-style text formatting
5. Removal of "forbidden tags"
6. Auto-number headings
7. ISBNs

In addition to that, the internal links check explodes the
array which is expensive both in terms of passing again
over the text and the added use of memory.

Therefore, the code discussed here passes over the text
at least 8 times, often doing the checking against
complicated regular expressions. Be the PHP regexp
performance as good as it can be, converting from one
complicated markup (Wiki) to another (HTML) is
simply not the task they were intended for.

> My advice would be: first try it in PHP with the PCRE's.
> If that doesn't work, write a real one-pass parser in PHP. If that
> also doesn't work, then you can start thinking about C and, for example,
> yacc/bison. As for Wiki syntax changes, IMO we should first get the
> current syntax efficiently and error-free working, and only then start
> thinking about changes and extensions.

For reasons stated above, I don't think PCRE's will do
much better, all regexps will have the same problems.
Having thought a bit about the subject, a one-pass PHP
parser is certainly the easiest solution to write and
maintain; however I'd feel much better if I knew for sure
that PHP does not create a penalty for fetching
characters out of a string one at a time.

Sincerely yours,
                    Uri Yanover


body:
From: "Uri Yanover" <uriyan_subscribe at yahoo.com>
>
> Well, while easiness of debugging is important, it
> is still possible to write a good parser that would
> be easy to debug;

Ok. If you say so. :-)

> keeping it simple for as long as
> possible might lead to very hasty and ugly attempts
> to optimize when it's too late.

You don't know how ugly those attempts
will be until you try (or let somebody else try).

> In addition to that, the internal links check explodes the
> array which is expensive both in terms of passing again
> over the text and the added use of memory.

A good point, and indeed something that needs to be
looked at. But you can avoid this also if you use the
regular expressions approach.

> [...] Be the PHP regexp
> performance as good as it can be, converting from one
> complicated markup (Wiki) to another (HTML) is
> simply not the task they were intended for.

When the original Wiki mark-up was designed it was done
so as to be effeciently implementable by Perl regular expressions.

-- Jan Hidders


body:
From: "Uri Yanover" <uriyan_subscribe at yahoo.com>
> > [...] If you
> > want inspiration look at the implementation of PhpWiki.
>
> Looking at PhpWiki was exactly what I did.

Er, I may have been a bit unclear here. I meant:
http://phpwiki.sourceforge.net/

-- Jan Hidders


body:
Dear fellow programmers,

I saw that the SQL code for the Recent Changes page is rather inefficient
and causes a lot of database access, so I decided to improve this. However,
I can only do this properly if the timestamp field in the tables is split in
a day and a time field. In order to minimze the inconvenience for the other
programmers I suggest to split my work in three steps as follows.

Step 1:
1. I will add an SQL script file 'addNewTimeStamps.sql' that changes the
table definitions and fills the new columns with the values computed from
the old time stamps. Jimbo needs to run this to convert the existing
database to the new format.
2. I will make a new dump for 'Wikipedia.sql'.
3. I will adapt every write action in the script to the tables 'old' and
'cur' such that the the new columns are also written.
4. Test and then submit to cvs.

Step 2:
1. start programming on the Recent Changes page.
2  test and submit.

Step 3:
1. Write an SQL script 'removeOldTimeStamps.sql' that removes the old time
stamp columns. This should also be run by Jimbo when he installs the patch
that contains this step.
2. Adapt the scripts that read and write the cur table and old table, so
they don't use the old columns anymore.
3. Test and submit.

If anyone has objections, a better plan, or would like me to wait with this
until a certain piece of work has been finished, please let me know.

Kind regards,

-- Jan Hidders


from_name: Magnus Manske

body:
> I didn't see the cur_cache field in wikipedia.sql. Is that on purpose?

Not on purpose, I forgot to update that one. Sorry. Do it yourself if you
have time, otherwise I'll do it later.

Magnus


subject: [Wikitech-l] Questions about installing

body:
Jimmy Wales wrote:

>What might make sense would be for us to have wikiSettings or wikiLocalSettings, and
>that's where stuff goes that we are _fairly confident_ will be different on different
>people's machines.
>
I've turned wikiText.php into wikiSettings.php, moved some of the
settings from wikiTextEn.php into wikiSettings.php, and put some
commented examples of things that might be done into
wikiLocalSettings.php. Whew! Take a look at the ol' CVS...

Couple of notes though. I'm not sure what would be configurable about
wikiLink () other than the base of the URL (which is set by
$wikiArticleSource), so I moved it into wikiSettings.php intact.

The other functions that were in wikiText*, wikiGetDate () [for
localized date format] and wikiRecodeInput/Output () [for converting
character encodings], I had to change a little. We want to be able to
include both the English file and another language to override it, but
PHP doesn't seem to allow a way to redefine a function, so I added a
language suffix to the function name (ie, wikiGetDateEn) and made
function variables to point to the current-language one ($wikiGetDate
etc). The downside of this is that function variables are not
transparent; you have to put the $ in front when calling it, and list it
as global if you're calling it from another function. Annoying, but it
works.

I'm also working on cleaning up a wikiTextEo.php with the Esperanto
message strings, and tweaking the conversion script to recognize
non-English talk subpages (we use /Priparolu on eo.wikipedia.com, and
most of the others are similarly localized). Hopefully I can figure out
how to grab the old page update histories as well...

Ah, that reminds me. On the subject of namespaces: to what degree can we
localize these? The names of the "special:" pages are hidden away behind
localized titles, and a "wikipedia:" namespace sounds fine, but "user:",
"talk", "user talk:" and "wikipedia talk:" are probably less than ideal,
particularly where local words such as "discuter", "dyskusja",
"priparolu", etc are well-established. Would there be any objection to
localizing these namespaces? They're currently hard-coded in English.

-- brion vibber (brion @ pobox.com)


body:
From: "Brion L. VIBBER" <brion at pobox.com>
> Jan Hidders wrote:
>
> >Dear fellow programmers,
> >
> >I saw that the SQL code for the Recent Changes page is rather inefficient
> >and causes a lot of database access, so I decided to improve this.
However,
> >I can only do this properly if the timestamp field in the tables is split
in
> >a day and a time field.
> >
> Can I ask how exactly that would help? I'm not much of a database guru,
> so the answer isn't obvious to me and I'm a bit curious.

It allows me to do a GROUP BY on the day. That way I can take a left outer
join between the cur table and the old table and group on the combination of
cur_day and cur_title. This allows me to get all the information I need for
the page in one SQL statement.

-- Jan Hidders


subject: [Wikitech-l] Recent changes; flush cache

body:
Jan's change to the database has my blessing, as he is a (the!) database
expert. Anyway, it isn't *my* baby anymore, it is *ours*;) Yeah, the
blessings of modern cloning technology...

As for the cache flushing mechanism Brion proposed in a private mail, the
easiest way would be to link it to the cur_counter field; if "cur_counter
MOD 20 == 0", the cache could be flushed, best by setting the local $cache
variable to "" at the end of the load routine.
20 is just a wild guess...

Finally, thanks to Jimbo for setting up this mailing list.
Gee, I never caused a mailing list before ;)

Magnus


from_name: Axel Boldt

subject: [Wikipedia-l] Suing over copyright violations

body:
I have a couple of points regarding the "inability-to-sue" concerns:

1) Linux has precisely the same issue, and is clearly commercially a
   lot more relevant than Wikipedia. In all the years, nobody has ever
   had to file a suit. People occasionly violate the GPL inadvertently
   and back down once it is explained to them.

2) Bomis has standing to sue: Larry is an employee of Bomis, and as
   such all his contributions are automatically copyrighted by Bomis.
   He has edited a significant proportion of the articles on the site.

3) Imagine you're big bad Microsoft, about to willfully violate the
   GFDL. Which scenario is scarier: being sued by Bomis.com, or the
   prospect of being sued by hundreds of volunteers from around the
   country, even around the world, with lots of sympathetic press
   coverage?

4) Money for such suits wouldn't be an issue. FSF, EFF etc. would all
   be happy to provide pro bono lawyers. By contrast, Bomis wouldn't
   get nearly as much support. "Just two companies with some copyright
   disagreement -- who cares?"

Axel