Mailing List Archive

Re: We need to make it easy to fork and leave [ In reply to ]
On 08/14/11 11:51 PM, Tim Starling wrote:
> On 15/08/11 16:30, David Gerard wrote:
>> 2011/8/15 David Richfield<davidrichfield@gmail.com>:
>>> It's not just financial collapse. When Sun was acquired by Oracle and
>>> they started messing about with OpenOffice, it was not hard to fork
>>> the project - take the codebase and run with it. It's not that easy
>>> for Wikipedia, and we want to make sure that it remains doable, or
>>> else the Foundation has too much power over the content community.
>>> Let me make it clear that I currently am happy with the Foundation,
>>> and don't see a fork as necessary. If the community has a problem
>>> with the board at any point, we can elect a new one. If things
>>> change, however, and it becomes clear that the project is being
>>> jeopardised by the management, we need a plan C.
>> Pretty much. It's not urgent - I do understand we're chronically
>> underresourced - but I think it's fairly obvious it's a Right Thing,
>> and at the very least something to keep in the back of one's mind.
> So you're worried about a policy change? What sort of policy change
> specifically would necessitate forking the project? Is there any such
> policy change which could plausibly be implemented by the Foundation
> while it remains a charity?
>
> I'm just trying to evaluate the scale of the risk here. The amount of
> resources that we need to spend on this should be proportional to the
> risk.
>

The primary value of a fork(s) is not financial or technical, but
epistemological. We are the big kid in the playground, and that has a
significant effect on the nature of the content. When we work so hard to
build an aura of reliability readers begin to depend on us.
Paradoxically, that's not always good. If we are so reliable, the reader
is not motivated to look elsewhere for alternatives. Natural human
laziness is bad enough by itself. We too easily fall into the trap of
treating Group POV as Neutral POV. Forks, would develop their own
versions of NPOV, and end up with very different results that are as
easily reliable as ours, but still different. It becomes up to the
reader to compare corresponding pages, and draw his own conclusions on
the matter at hand.

We should not be viewing forks as inherent evils to be resisted at all
costs. We should be encouraging them, and helping them.

Ray

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
Hi!

> That technical staff have effective power to decide whether a fork is
> justified is reason enough.


If you tried reading more of the message than just From: header, you wouldn't write this bullshit.

The whole topic is about ease of forking, and:

a) Member of technical staff did not allege that he is making any kind of decision, he just explains that there're tradeoffs to be made
b) It was not being discussed whether "resources to allow forking" are to be spent or not. The message was more about "how much"
c) He also questioned if organization bylaws/format/etc is a high risk, and he solicited feedback.
d) He also wanted to know what is seen as a bad foundation decision worth forking. That is more of a "how not to need a fork" rather than "how not to allow a fork".

I hope you will fix your attitude.

As for resources spent on ease of forking, it can go many ways.

WMF could be extremely supportive of forks/mirrors/whatever. That is not just about providing a dump, that is also about allowing to query an API for page-loads of remote forks. Essentially, it could become data engine for whatever gets built on top. That is expensive, fundraising becomes inefficient, but here you are, lots of resources and a commitment to spend them just to support forks. WMF could also give initial grants and actually help on fork engineering problems ;-)

WMF could also impose rules on number of articles/data size, to put editors into britannica-like editing more, where each word added is a word removed from elsewhere :-) This would keep projects way more forkable, albeit this would be a catalyst to a fork without such a restriction ;-D

WMF could provide reliable/robust change feeds/distribution mechanisms, including media. Depending on a requested feature set this may be relatively expensive operation (albeit it may be more expensive to be on a receiving end at that time - it is just multitude of polling people that may be costly for WMF ;)

As you see, each of these things may require lesser or bigger MTS participation at the tactical level, k'thx.

Domas
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
On Mon, Aug 15, 2011 at 09:38, Ray Saintonge <saintonge@telus.net> wrote:

> A comprehensive fork would probably need ad revenue more than the WMF
> unless it has deep pockets to get it going.

I don't think this is a requirement. Wikipedia have to support
enormous amount of traffic while a fork don't expect such. I'm sure I
could easily fork enwp with just one machine, and handle a few hundred
visitors a day, or even in an hour. I believe Fred Bauder have made a
fork of a kind (yes I know it used a different method) and I guess he
do see the traffic stats and resource requirements to do that. ;-)


By the way someone asked about reasons to fork. A very possible reason
could be when an established ("senior") editor gets mass attacked
and/or banned and/or having to work in a very hostile environment.
(Not just a few editors avoid commons for the very reason that they
feel images tend to disappear without warning. I try to handle these
cases, nevertheless, but I know it happens. It happens on enwp often
that religious/nationalist pressure drives editors away, and if
someone is involved enough s/he may feel the need to fork and continue
the work with a different ruleset.)

--
 byte-byte,
    grin

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
Just a point: WMF projects have spilt out before, for example was the
September 11 remembrance wiki (sep11.wikipedia) although the fork is
now offline, also one of the other "plain" language specific projects
(Spanish Wikipedia comes to mind but I can't confirm) but as far as
I'm aware never really took off so it basically became idle.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
On Mon, Aug 15, 2011 at 08:26, Nikola Smolenski <smolensk@eunet.rs> wrote:
> On 15/08/11 08:16, David Richfield wrote:
>> It's not just financial collapse.  When Sun was acquired by Oracle and
>> they started messing about with OpenOffice, it was not hard to fork
>> the project - take the codebase and run with it.  It's not that easy
>> for Wikipedia, and we want to make sure that it remains doable, or
>> else the Foundation has too much power over the content community.
>
> I'm fairly confident it would be much easier to fork Wikipedia than
> OpenOffice.
>

Technically, it's much easier to fork code than it is to fork wikis
especially now in an era of distributed version control systems (Git,
hg, bzr) where everyone who checks the code out of a repository has a
full copy of the repository. The only technical infrastructure you
need is some hosting space for the repo and the other common bits you
need for software dev (mailing list, bug tracker etc.)

One thing I've been thinking about from the failure of Citizendium is
how an expert community could set up their own external version of
pending changes: basically a simple database of stable versions, so
any individual or group could set up a server with stable versions of
articles, then you could subscribe to a set of stable version sets -
so, say, the International Astronomical Union mark a bunch of
revisions of astronomy articles as stable, and if you've got the
browser plugin installed with their dataset installed, when you visit
one of those pages, it'd show you the stable version they chose. And
the flipside is that if you are (in my humble opinion) a cold fusion
nut or a homeopathy nut, you could find some crazy person who believes
in those things to come up with his or her own set of crank stable
versions.

And the stable version could be marked as checked by a particular
person from a particular institution with their real name if that is
the practice in that community: perhaps in physics or philosophy or
psychology or some other academic subject, having a real name person
sign off on a particular stable version is fine and dandy, but in,
say, the Pokémon fan community, they don't really have the same
assumptions. (Again, one of the failures of Citizendium: you don't
need a guy with a Ph.D to approve the articles on Pokémon in the way
you might want a credentialed expert to sign off on, say, an article
on cancer treatment.)

The essential thing is to separate out the things that people want:
some people want "distributed Wikipedia", but why? Well, one good
reason seems to be so you can have stable versions with expert
oversight (like Citizendium) - well you can get most of the desiderata
that led to Citizendium by having a third-party distributed approval
layer and browser plugins etc. A little bit of hacking provides a lot
of opportunity for different communities to take Wikipedia and run
with it in the ways they want to. This kind of proposal would provide
a lot of what Citizendium was shooting for but without the
coordination problem of trying to get disparate communities of people
to work together in a way the CZ community kind of failed to do.
Consider for instance the ethnic studies/women's studies people who
didn't find Citizendium a welcoming environment.[1] Under this kind of
proposal, if there is a community of people involved in ethnic studies
who want to participate in Citizendium-style expert approval, they can
set up some very lightweight software and organise their approvals in
whatever way fits best with their academic community norms.

Essentially, in software terms, this would be like a 'packager',
someone who takes Wikipedia's output on a certain topic and marks
specific revisions or whatever as good or bad. They'd still be welcome
(and indeed encouraged) to participate in editing on Wikipedia in the
traditional way, and ideally the community wouldn't take participation
in such an enterprise against them as an editor (just as they
currently don't or shouldn't take participating in Wikinfo or
Citizendium or even Conservapedia against someone), and any comments
that come up in the 'packaging' process could be taken as feedback in
the normal way just as if packager at Debian finds a bug with a piece
of software, he or she can point that out the upstream maintainer.

Feedback?

[1] see http://cryptome.info/citizendium.htm and
http://rationalwiki.org/wiki/Citizendium

--
Tom Morris
<http://tommorris.org/>

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
treating Group POV as Neutral POV.

> Ray

Bingo

Fred


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
> I'm sure I
> could easily fork enwp with just one machine, and handle a few hundred
> visitors a day, or even in an hour. I believe Fred Bauder have made a
> fork of a kind (yes I know it used a different method) and I guess he
> do see the traffic stats and resource requirements to do that. ;-)


>  byte-byte,
>     grin

Some of Wikinfo's technical problems at ibiblio result from being on a
shared server, less than one server. I'm pretty sure one small server
would handle a full fledged setup. If there is high traffic there is high
potential for donations.

Fred


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
Good point - risk management isn't just about technical disaster -
geopolitical issues are actually a much greater long term risk

On 8/15/2011 2:04 AM, foundation-l-request@lists.wikimedia.org wrote:
> The primary value of a fork(s) is not financial or technical, but
> epistemological. We are the big kid in the playground, and that has a
> significant effect on the nature of the content. When we work so hard to
> build an aura of reliability readers begin to depend on us.
> Paradoxically, that's not always good. If we are so reliable, the reader
> is not motivated to look elsewhere for alternatives. Natural human
> laziness is bad enough by itself. We too easily fall into the trap of
> treating Group POV as Neutral POV. Forks, would develop their own
> versions of NPOV, and end up with very different results that are as
> easily reliable as ours, but still different. It becomes up to the
> reader to compare corresponding pages, and draw his own conclusions on
> the matter at hand.
>
> We should not be viewing forks as inherent evils to be resisted at all
> costs. We should be encouraging them, and helping them.


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
Feedback: Approval based systems only work on a tiny subset of articles as they disenfranchise the vast majority of contributors who don't have a multi-tiered content approach at all.





-----Original Message-----
From: Tom Morris <tom@tommorris.org>
To: Wikimedia Foundation Mailing List <foundation-l@lists.wikimedia.org>
Sent: Mon, Aug 15, 2011 2:04 am
Subject: Re: [Foundation-l] We need to make it easy to fork and leave


On Mon, Aug 15, 2011 at 08:26, Nikola Smolenski <smolensk@eunet.rs> wrote:
On 15/08/11 08:16, David Richfield wrote:
> It's not just financial collapse. When Sun was acquired by Oracle and
> they started messing about with OpenOffice, it was not hard to fork
> the project - take the codebase and run with it. It's not that easy
> for Wikipedia, and we want to make sure that it remains doable, or
> else the Foundation has too much power over the content community.

I'm fairly confident it would be much easier to fork Wikipedia than
OpenOffice.

Technically, it's much easier to fork code than it is to fork wikis
specially now in an era of distributed version control systems (Git,
g, bzr) where everyone who checks the code out of a repository has a
ull copy of the repository. The only technical infrastructure you
eed is some hosting space for the repo and the other common bits you
eed for software dev (mailing list, bug tracker etc.)
One thing I've been thinking about from the failure of Citizendium is
ow an expert community could set up their own external version of
ending changes: basically a simple database of stable versions, so
ny individual or group could set up a server with stable versions of
rticles, then you could subscribe to a set of stable version sets -
o, say, the International Astronomical Union mark a bunch of
evisions of astronomy articles as stable, and if you've got the
rowser plugin installed with their dataset installed, when you visit
ne of those pages, it'd show you the stable version they chose. And
he flipside is that if you are (in my humble opinion) a cold fusion
ut or a homeopathy nut, you could find some crazy person who believes
n those things to come up with his or her own set of crank stable
ersions.
And the stable version could be marked as checked by a particular
erson from a particular institution with their real name if that is
he practice in that community: perhaps in physics or philosophy or
sychology or some other academic subject, having a real name person
ign off on a particular stable version is fine and dandy, but in,
ay, the Pokémon fan community, they don't really have the same
ssumptions. (Again, one of the failures of Citizendium: you don't
eed a guy with a Ph.D to approve the articles on Pokémon in the way
ou might want a credentialed expert to sign off on, say, an article
n cancer treatment.)
The essential thing is to separate out the things that people want:
ome people want "distributed Wikipedia", but why? Well, one good
eason seems to be so you can have stable versions with expert
versight (like Citizendium) - well you can get most of the desiderata
hat led to Citizendium by having a third-party distributed approval
ayer and browser plugins etc. A little bit of hacking provides a lot
f opportunity for different communities to take Wikipedia and run
ith it in the ways they want to. This kind of proposal would provide
lot of what Citizendium was shooting for but without the
oordination problem of trying to get disparate communities of people
o work together in a way the CZ community kind of failed to do.
onsider for instance the ethnic studies/women's studies people who
idn't find Citizendium a welcoming environment.[1] Under this kind of
roposal, if there is a community of people involved in ethnic studies
ho want to participate in Citizendium-style expert approval, they can
et up some very lightweight software and organise their approvals in
hatever way fits best with their academic community norms.
Essentially, in software terms, this would be like a 'packager',
omeone who takes Wikipedia's output on a certain topic and marks
pecific revisions or whatever as good or bad. They'd still be welcome
and indeed encouraged) to participate in editing on Wikipedia in the
raditional way, and ideally the community wouldn't take participation
n such an enterprise against them as an editor (just as they
urrently don't or shouldn't take participating in Wikinfo or
itizendium or even Conservapedia against someone), and any comments
hat come up in the 'packaging' process could be taken as feedback in
he normal way just as if packager at Debian finds a bug with a piece
f software, he or she can point that out the upstream maintainer.
Feedback?
[1] see http://cryptome.info/citizendium.htm and
ttp://rationalwiki.org/wiki/Citizendium
--
om Morris
http://tommorris.org/>
_______________________________________________
oundation-l mailing list
oundation-l@lists.wikimedia.org
nsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
On 15/08/11 18:14, Fred Bauder wrote:
>> I'm just trying to evaluate the scale of the risk here. The amount of
>> resources that we need to spend on this should be proportional to the
>> risk.
>>
>> -- Tim Starling
>
> That technical staff have effective power to decide whether a fork is
> justified is reason enough.

I'm not in a position to actually allocate resources to this or to
decide whether it's justified. I'm asking these questions mostly for
my own curiosity, and in case someone seeks my opinion on it in the
future.

When you launched Internet-Encyclopedia, I was very positive about its
utility. Brion and I gave it all the support it needed. The "green
link" feature in particular required Wikinfo to be whitelisted in the
server configuration so that it didn't get blocked for its high
request rate. I reviewed Proteus's fork of MediaWiki to see if there
were any changes that we could reincorporate. So it's not like I'm
staunchly anti-fork.

-- Tim Starling


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
> On 15/08/11 18:14, Fred Bauder wrote:
>>> I'm just trying to evaluate the scale of the risk here. The amount of
>>> resources that we need to spend on this should be proportional to the
>>> risk.
>>>
>>> -- Tim Starling
>>
>> That technical staff have effective power to decide whether a fork is
>> justified is reason enough.
>
> I'm not in a position to actually allocate resources to this or to
> decide whether it's justified. I'm asking these questions mostly for
> my own curiosity, and in case someone seeks my opinion on it in the
> future.
>
> When you launched Internet-Encyclopedia, I was very positive about its
> utility. Brion and I gave it all the support it needed. The "green
> link" feature in particular required Wikinfo to be whitelisted in the
> server configuration so that it didn't get blocked for its high
> request rate. I reviewed Proteus's fork of MediaWiki to see if there
> were any changes that we could reincorporate. So it's not like I'm
> staunchly anti-fork.
>
> -- Tim Starling

Tim,

Yes, your help was greatly appreciated.

Here's the conclusion I've come to though. We need to get the software
good enough, and simple enough, that it is firmly in the background.
Mediawiki is like an old DOS computer that constantly drags you into
programing mode, particularly if you fork. We need the equivalent of a
Macintosh that almost anyone can use effortlessly. The emphasis needs to
be on content, not on trying to figure out extensions and templates.

Fred



_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
Hi!

> Here's the conclusion I've come to though. We need to get the software
> good enough, and simple enough, that it is firmly in the background.

OK!

> Mediawiki is like an old DOS computer that constantly drags you into
> programing mode, particularly if you fork.

Yes, especially if you actually are running it, all you do is sit in some black and white text screens, that definitely sucks.

> We need the equivalent of a
> Macintosh that almost anyone can use effortlessly. The emphasis needs to
> be on content, not on trying to figure out extensions and templates.

Yup, we need drag&drop forking support. With clouds nowadays that should be easy - you enter cloud account information (it may auto-detect password), and drag the website you want to fork onto a "drag here" target.
We should definitely work on this kind of functionality. Then you click on it, and it runs, in a cloud!

Emphasis needs to be on content and DRM, so that people don't copy articles without leaving 30% of their revenue to your fork.
ArticleStore is going to be core essence of all content distribution, after it has been previewed on the website, of course, seamlessly integrated with reading devices, like computers.

It is easy to resolve templates and extensions iOS-development way, charge community for being able to write them, that will make the remaining ones truly useful, because someone was motivated to do that.
Of course, you need an approval process, but it is nothing technical, you can approve that stuff solely on moon phase or peyote effects :)

Anyway, we should definitely build something like that, just don't pay attention to suicide rate.

Cheers,
Domas


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
On 16 August 2011 09:06, Domas Mituzas <midom.lists@gmail.com> wrote:

> Anyway, we should definitely build something like that, just don't pay attention to suicide rate.


:-) I am quite cognisant that the likely number of people wanting to
build a full fork of Wikipedia may well be *zero*. I apologise if I
have given any of this the sound of urgency. I am saying, however,
that forkability is an important right thing, a guard against
disasters and a good way to keep ourselves honest. And a lot (if not
all) of what it requires is stuff we really should be doing anyway.

(BTW - we *do* have someone making sure the Internet Archive - or a
similar organisation, if there are any similar organisations - has a
full collection of all our backups, so if Florida was hit by a meteor
tomorrow people would have something to start from?)


- d.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
On 16 August 2011 09:18, David Gerard <dgerard@gmail.com> wrote:

> (BTW - we *do* have someone making sure the Internet Archive - or a
> similar organisation, if there are any similar organisations - has a
> full collection of all our backups, so if Florida was hit by a meteor
> tomorrow people would have something to start from?)


argh. That's a question, not a statement. Do we have some third party
with copies of everything? I suggest the IA as they have the disk
space and, as a library, rabidly archive everything they can get their
hands on.

(Would anyone from IA happen to be on the list?)


- d.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
2011/8/16 David Gerard <dgerard@gmail.com>

> On 16 August 2011 09:06, Domas Mituzas <midom.lists@gmail.com> wrote:
>
> > Anyway, we should definitely build something like that, just don't pay
> attention to suicide rate.
>
>
> :-) I am quite cognisant that the likely number of people wanting to
> build a full fork of Wikipedia may well be *zero*. I apologise if I
> have given any of this the sound of urgency. I am saying, however,
> that forkability is an important right thing, a guard against
> disasters and a good way to keep ourselves honest. And a lot (if not
> all) of what it requires is stuff we really should be doing anyway.
>
> (BTW - we *do* have someone making sure the Internet Archive - or a
> similar organisation,


I heard Internet Archive downloads dumps every 3 months (but no images).

Also, some time ago I heard about a contact with Library of Congress to host
dumps duplicates. No more news about that.


> if there are any similar organisations - has a
> full collection of all our backups, so if Florida was hit by a meteor
> tomorrow people would have something to start from?)
>
>
Instead of a meteor, maybe a hurricane. Instead of a hurricane, maybe a
faulty RAID. Did you hear about the RAID problem some months ago?

Regards,
emijrp


> - d.
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
On 08/16/11 1:20 AM, David Gerard wrote:
> On 16 August 2011 09:18, David Gerard<dgerard@gmail.com> wrote
>> (BTW - we *do* have someone making sure the Internet Archive - or a
>> similar organisation, if there are any similar organisations - has a
>> full collection of all our backups, so if Florida was hit by a meteor
>> tomorrow people would have something to start from?)
> argh. That's a question, not a statement. Do we have some third party
> with copies of everything? I suggest the IA as they have the disk
> space and, as a library, rabidly archive everything they can get their
> hands on.
>
One suggestion for archiving would be to have a complete set of projects
filed with the copyright office and other key depositories quarterly.

This could also address a potential long-term copyright problem. This
has less to do with Wikipedia infringing on the copyrights of others
than with the reverse. It already happens that others use Wikipedia
material without credit in works on which they claim copyright. Re-use
of that material on-wiki at a later date will inevitably result in a
copyvio squabble, especially if the originally plundered version is no
longer recognizable. This could be many years hence. What other means
are available to protect the viral nature of freely licensed material?

Forks could also be helpful in this regard. They would need to respect
free licences, and, as a by-product, add evidence favouring the freeness
of the material. A person creating a fork based on some topic area is
unlikely to significantly alter all the articles imported, preferring to
draw different conclusions from the same underlying facts. This is
bound to leave an identifiable residue that will protect the licence.

Ray

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Re: We need to make it easy to fork and leave [ In reply to ]
On 08/15/11 7:52 PM, Fred Bauder wrote:
> The emphasis needs to
> be on content, not on trying to figure out extensions and templates.

A key feature of forks!!!

Ray

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

1 2  View All