Fedora website, Red Hat, copyright notices and FPCA

[Toshio Kuratomi]

On Tue, Jun 28, 2011 at 02:02:36PM +0530, Rahul Sundaram wrote:
> On 06/28/2011 12:47 PM, Toshio Kuratomi wrote:
> >
> > Depends on what you mean.  If you're talking about bugzilla you may be
> > correct.  But currently, as you point out we don't require you to do either
> > of those in bugzilla.  So if you propose that people do this in bugzilla,
> > you're imposing an additional burden.
> 
> Right.  Since we don't do this now,  FPCA doesn't protect us and we have
> to rely on the rights granted by a explicit license.  FPCA as a catch
> all only works if the person submitting the patch has agreed to it which
> is not the case in bugzilla. 
> 
Yep.  I'm not disagreeing with you about the limits of FPCA protection.
I am saying that unless you want to impose additional work on people,
explicit patch licensing doesn't help you at all.

> > OTOH, if you take away the FPCA and then demand that they
> > put an explicit license on all of their patches, then you're expecting them
> > to do the work of generating the license boilerplate for every single patch
> > that they create and check in.
> 
> That is not true.  Most of the patches I have ever checked in have been
> either cherry picked from upstream or trivial.  Non-trivial patches
> being checked in without any license should be rare
>

One way to look at this is that both of these are true of our respective
usages.  Another way to look at this is that it's much easier and less error
prone to specify that everything must carry an explicit license because
otherwise we have to teach packagers what is trivial and what is
non-trivial.  Since trivial vs non-trivial is a matter that is often decided
in court, it doesn't seem like we really want to be trying to teach all of
our packagers how to make that decision on their own....


> and in those cases
> adding a copyright notice is not a big burden.
>
You say this, but it doesn't make it so.  Just like spot says that signing
the FPCA is not a big burden and you dispute that.  Example, some upstreams
place themselves in the public domain -- authors from non-US countries often
have difficulty doing the same.  Example, some upstreams contain a mixture
of licenses -- the Fedora Contributor then has to choose one of those
licenses.  Example, I'm a provenpackager helping to fix FTBFS bugs.  If
I have to submit explicit licensing terms on all my patches, then I have to
research all of the programs I'm lending a hand with to see what the
licensing terms need to be.  Example, I'm merging a patch that
a provenpacakger submitted in bugzilla.  They did not add explicit licensing
when they submitted the patch so now I have to spend time trying to get
ahold of them and trying to get them to add explicit licensing to their
patch before I can merge the patch.

> Major upstream projects
> routinely merge in patches from dozens and dozens of people.  They all
> require explicit license for the patches.

1) I think "all require" is wrong.  I've contributed patches to many
major projects that don't require explicit licenses.  I've also contributed
patches to many major projects that don't require explicit licensing and
instead require copyright assignment... and I know that neither you nor
I want to follow those examples just because they're "major upstreams
routinely merging patches".

> We are going to be handling
> much less patches.  I don't see why need a FPCA to handle this

The first step is for you to find out if this is a requirement from Legal.
If it is not, then you can take your arguments to the Board and we will
evaluate whether the benefits outweigh the costs.  Since you are questioning
whether the FPCA really is a requirement from Legal, the first step is to
find out whether your guess that it is not is true or not.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20110628/ee17fbfb/attachment-0001.bin