Axil's interpretation strikes me as the standard interpretation for those
writing free software. I retain the copyright the code I write, and license
it under the GPL or some other license, but also maintain the right to
relicense it under a revised version of the GPL, a BSD style license, or any
other agreement I choose.
In many cases this standard practice is amended to include the assignment of
copyright to the Free Software Foundation, or some other organization which
I trust with the ability to relicense my code under whatever license they
choose. As long as an entity retains copyright, they will be able to
release the copyrighted material under whatever license they choose. Not
assigning copyright is therefore a protection against undesirable license
changes, but at the very least it is common practice to view the assignment
of copyright as a separate transaction from submitting code under a
particular license.
Legally, if you want us to assign copyright to you, I think you need to
change the wording of the submission text, and add some verbiage to the top
of your license page.
I am not a lawyer, but this is my understanding of the current situation,
and can easily be confirmed by consulting a lawyer with some experience with
free software, or by looking up stories on the subject at www.lwn.org, or
looking into the faq on why you should assign copyright to the FSF at
www.gnu.org.
Yours
Mark
-----Original Message-----
From: Larry Sanger [mailto:lsanger@nupedia.com]
Sent: Monday, February 04, 2002 6:10 PM
To: wikipedia-l(a)nupedia.com
Subject: Re: [Wikipedia-l] File upload Copyright notice
On Thu, 31 Jan 2002, Axel Boldt wrote:
> 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)? As far as I
can tell, Axel, you were the first to insist, several months ago, that
this was the case. If I recall correctly, Jimbo and I admitted that this
might be a valid interpretation. For my part, I thought it was obvious
from the beginning that writers are donating text to the project, in order
for it to be distributed freely to the public at large. 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 don't think we've settled the issue.
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.
Larry
[Wikipedia-l]
To manage your subscription to this list, please go here:
http://www.nupedia.com/mailman/listinfo/wikipedia-l
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.
Axel
I must agree with that. We shouldn't add non-intuitive
features to Wikipedia mark-up. In particular, I don't
see any substancial difference between
[[Elrond (Middle Earth)]] and [[Middle Earth/Elrond]]
(The former looks more aesthetical to me, though), and
if Wikipedia software itself does not recognize subpages,
we shouldn't add subpage-like features.
Unlike most others encyclopedias, Wikipedia is about
ease of editing too, and editing is made harder by the
abiguity in the convert-links-once solution. What I like
in the idea of aliases is the total control of the author
over what he links to. This won't be possible if Wiki
software is the thing that decides about the conversion.
Uri Yanover
P.S. My appologies if this message reaches the list
twice, my mailer drives me crazy :-(
----- Original Message -----
From: <lcrocker(a)nupedia.com>
To: <wikipedia-l(a)nupedia.com>
Sent: Thursday, January 31, 2002 9:39 PM
Subject: Re: [Wikipedia-l] yet another modest proposal
to address subpage-like behavior
>
> Sorry, Magnus, but your counter-proposal changes the
> runtime behavior of the system and is /far/ too complicated.
> Let's not shoot the golden goose here: Wikipedia works
> because it is SIMPLE. Article title space should be
> flat (whether or not we add typing conveniences).
>
> Also, disambiguation isn't the problem we're trying to
> solve here. That can be done easily enough manually.
> There are already great disambiguating pages like "Java",
> and we should allow the software to do those automatically
> because we want human judgment and creativity to apply to
> making them.
>
> The issue really is just one of typing convenience. When
> I write about Texas Hold'em strategy, I might say something
> like "A raise from late position on the flop will often
> cause an opponent to check to you on the turn, giving you
> the chance to check behind him and take a free card." In that
> sentence, I might want to link words like "raise", "position",
> "flop", "free card" and such, and typing "[[Raise (Poker}|raise]]"
> for every one of them is a pain. But I /want/ to do the right
> thing semantically and make sure that the link actually does go
> to the "Raise (Poker)" page, and not just to a disambiguating
> "Raise" page that will interrupt and confuse the reader.
>
> Of course, when I /want/ links to be ambiguous to encourage
> "accidental" discovery, I can still do that too. In my
> "See also" lines, for example, I'll probably just link to
> simple titles, hoping that accidental links do interesting
> things. So there /will/ be an "Elves" page with pointers to
> other contexts, as well as "Elves (Tolkein)", or whatever.
> The author should have the choice, and the power. The software
> should support what theauthor wants to do, not enforce its
> ideas or structure upon the author.
> 0
What's up with Natural Family Planning
<http://www.wikipedia.com/wiki/wiki.phtml?title=Natural_family_planning>
? I'm trying to edit it (capitalizing "Catholic Church," if you're
curious), but when I save, I get the old version again. I've tried
several times, and each time, Recent Changes shows a new entry: "(diff)
Natural family planning 09:54 (6 changes) ... conversion script M
[Automated conversion]"
Has the conversion script decided to adopt this article as its very own?
Or is it just the wrong time of month to edit this article?
--
the Epopt
We are now running:
Linux 2.4.17
Apache 1.3.23
Php 4.1.1
mod_fastcgi 2.2.12
And the latest version of wikipedia that Magnus sent me earlier today.
Also, the machine has been upgraded from 512 megabytes of memory to 1
gigabyte of memory.
It is hoped that this will improve our performance, perhaps
substantially.
I'm in the process of rolling upgrades to all my servers, bumping them all
up to 2 gig, and in some cases beyond. Wikipedia will eventually benefit
from that.
In the meantime, everyone please keep the bug reports flowing, or even better,
check out the CVS on sourceforge and send in patches. :-)
--Jimbo
These statistics are for the two International
Wikipedias (English and Esperanto). I took into
account duplicate listing for states, but not for
countries, so the country stats may be a bit off. I
think you'll all find this interesting. This took a
while so don't expect me to do it too often...
Enjoy!
Chuck Smith
--- English Wikipedia ---
Listed in US: 85
Actual in US: 79
43.9% in US
Listed Most Times: 4 - Jimbo Wales (Alabama,
California, Illinois, Indiana)
Listed non-US: 101
En - predominantly English speaking countries
(8 Australia, 11 Canada, 1 Singapore, 1 South Africa,
22 United Kingdom, 79 United States)
Actual in En: 122
67.8% in En
Breakdown by Country:
1 Andorra
8 Australia
1 Bosnia and Herzegovina
11 Canada
1 Chile
2 Denmark
4 Finland
7 Germany
1 Hungary
2 Republic of Ireland
4 Israel
2 Italy
4 The Netherlands
1 Malta
1 Mexico
2 New Zealand
2 Norway
5 Poland
2 Portugal
1 Russia
1 Singapore
1 South Africa
4 Spain
9 Sweden
1 Switzerland
1 Turkey
22 United Kingdom
Breakdown by US State
1 Alabama
2 Alaska
3 Arizona
0 Arkansas
19 California
1 Colorado
2 Connecticut
0 Delaware
1 District of Columbia
0 Florida
1 Georgia
0 Hawaii
0 Idaho
3 Illinois
2 Indiana
2 Iowa
0 Kansas
2 Kentucky
1 Louisiana
0 Maine
2 Maryland
4 Massachusetts
3 Michigan
2 Minnesota
0 Mississippi
1 Missouri
0 Montana
0 Nebraska
2 Nevada
0 New Hampshire
1 New Jersey
0 New Mexico
8 New York
3 North Carolina
0 North Dakota
2 Ohio (!)
0 Oklahoma
1 Oregon (!)
1 Pennsylvania
0 Puerto Rico
0 Rhode Island
0 South Carolina
0 South Dakota
1 Tennessee
3 Texas
0 Utah
0 Vermont
2 Virginia
4 Washington
0 West Virginia
0 Wisconsin
0 Wyoming
5 Nomadic and shy (includes Larry Sanger, but we know
where you live...*evil laughter*)
85 Total
--- Esperanto Wikipedia ---
Actual in US: 7
0% living in predominantly Esperanto speaking country
:)
Actual non-US: 10
41.2% in US
41.2% in En
1 Brazil
1 Catalonia
1 China
1 France
1 Japan
1 Polland
2 Russia
1 Spain
7 United States
=====
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
Hello,
if one (hypothetically :-) wanted to help in finding bugs, should one
start with the version of the software on sourceforge, in CVS, or is
there a newer version? Also, if one (hypothetically) would fix a
bug, should one just submit it to CVS or send it directly to
Magnus/Jimbo?
On another note: somebody wrote a suggestion on the website that the
slow response might be caused by one of the special features that have
been added. Maybe that could be tested, by running the site for a
while without watchlists, orphans, most wanted, page counters etc.
When we had response problems with the old perl script, I remember it
was due to too many RecentChanges accesses.
Axel
I'm adding wikipedia stuff to the LDP site. I will definitely pass the
result past you before any publication, to make sure you're happy with
how I've implemented it - since the official "policy" has never been
finally established.
I hope you know by now I will do everything I reasonably can to make
sure what I do benefits the Wikipedia and doesn't "fork" it in any
meaningful way. I'll be driving traffic to you, for one thing, and
won't do any actual "editing" on my site. Clicking the "Edit this
page" link will do just what it says -- but will take you to the
Wikipedia to do your edits. I think the LDP probably gets a lot more
traffic right now than the Wikipedia does (6 million page views a
month), so that should be a good thing for you.
I do have a problem though, that you can help me with if you will.
It seems the tarball is not being updated regularly. I want to
download and process it regularly, probably weekly. An rsync feed
would be really ideal, because it would minimize the bandwidth
requirements. It's not a problem on my end, but it could be on yours.
But if an rsync feed is not in the cards, at least update the tarball.
Can you get the tarballs updated on a more regular basis? It should
just take a few minutes to write a script and put it in
/etc/cron.daily.
Thanks,
--
David C. Merrill http://www.lupercalia.net
Linux Documentation Project david(a)lupercalia.net
Collection Editor & Coordinator http://www.linuxdoc.org
Mine is the ecstasy of the spirit
And Mine also is joy on earth.
For My law is love unto all beings.
-- from The Charge of the Goddess, Doreen Valiente
Just a thought re: vandalism
At some point, some of the vandals are going to spot the "minor edit" button,
and realise it makes their vandalism harder to police. Would it be too unwiki
to limit the option of "minor edit" to those logged in (most non-vandal new
users don't seem use it anyway).
--
Gareth Owen
"Wikipedia does rock. By the count on the "brilliant prose" page, there
are 14 not-bad articles so far" -- Larry Sanger (12 Jan 2001)