openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: An example of what's wrong up with the wiki
Date Sun, 07 Aug 2011 21:39:13 GMT
On Sun, Aug 7, 2011 at 2:46 PM, Eike Rathke <ooo@erack.de> wrote:
> Hi Rob,
>
> On Sunday, 2011-08-07 13:16:33 -0400, Rob Weir wrote:
>
>> > So basically you tried to troll the wiki to prove a point:
>> >
>> > If your edit stay in place you claim that there is a problem...
>> > if your edit are taken down, you claim there is a problem...
>> >
>> > Damn if you do, damn if you don't.... implacable logic.
>> >
>>
>> It is called reductio ad absurdum.  This is a form of logic.  I
>> demonstrated that the inconsistencies that exist in the way the wiki
>> is run today lead to contradictions.  I'd like us to move to system
>> for managing the wiki where these problems don't exist.
>
> Where do you see such problems would end? After challenge/response
> verification of the email address given? Helps against spammers, but who
> really wanted to abuse the wiki would pass also that. Upload of an
> OpenPGP key with trust at least in the 5th level? Apache committers
> only? The more barriers you put in, the less community you'll get.
>
>

In general I see it like this (and mind that IANAL):

A license is the terms that a rights owner gives to content that they
control of the rights to. So there are four facts of interest:

1) The identify of the rights owner
2) The identity of the person granting the license
3) The person physically contributing the content
4) The identity of the work

In the the majority of cases, 1-3 is the same person.  But for works
for hire, 1-2 might be a corporation, and 3 might be an employee.
When you upload content that is under a compatible license, then 1-2
would be the original author and 3 would be the person uploading it to
Apache.

The edge cases, quite rare, but still important from the risk
perspective, are the case where someone uploads content that they do
not own and for which they have no rights to upload it.  In that case
there is no license; the rights owner did not consent.

As you can easily see, it is far easier to establish some of these
facts than others.  For example, identifying the work is trivial.  It
is revision in SVN, or a message id of the patch, or a bugzilla ID, or
a wiki revision.  That is easy.

Identifying the person contributing the content can be done with
various degrees of accuracy, from IP address, email address, to
assertions made at login, to a signed and returned iCLA.

Note that in general you cannot identify the original rights owner
independently of the assertions made by the person contributing the
content.  That is why knowing their identity is important.

The greater the certainty with which you can identify the contributor,
and that they understand and agree with their obligations to upload
only works that they have the right to upload, the less risk there is
to users and downstream  consumers of our deliverables.  Asking less
of our contributors is to transfer the risk from the person who knows
most about whether they have sufficient rights, to a downstream
consumers who knows nothing of this.

This is why the iCLA is so important.  It identifies the contributor.
Their real name and contact information and signature is recorded by
Apache. It also represents an agreement by the contributor that they
will not contribute content that they do not have rights to.   It is
the due diligence that we do to ensure that the product that the
project delivers has a clean pedigree, that our users and downstream
consumers can use it safely.  Yes, I know there are no absolutes.  But
having the iCLA makes it safer than not having it.

Is the iCLA too much of a burden for an author?  As mentioned before
it is no more a burden than the copyright assignment form that an
author would sign when submitting an article to a magazine for
publication.  But yes it is more of a burden than not having it.  But
I think we should make the effort to explain to contributors why the
iCLA is important and what the benefits are.  We'll always have the
ability to accept small changes and patches, even without the iCLA.
But where the contribution amounts to something larger, for example
entire multiple-page works, then I think we need to pay more
consideration to the license.


-Rob

Mime
View raw message