openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: What rights are given in an SGA
Date Tue, 22 Jan 2013 03:41:58 GMT

On Jan 21, 2013, at 6:49 PM, Rob Weir wrote:

> On Mon, Jan 21, 2013 at 9:40 PM, Rob Weir <robweir@apache.org> wrote:
>> On Mon, Jan 21, 2013 at 9:18 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>>> 
>>> On Jan 21, 2013, at 5:48 PM, Rob Weir wrote:
>>> 
>>>> On Mon, Jan 21, 2013 at 8:36 PM, Rob Weir <robweir@apache.org> wrote:
>>>>> On Mon, Jan 21, 2013 at 8:10 PM, Dave Fisher <dave2wave@comcast.net>
wrote:
>>>>>> 
>>>>>> On Jan 21, 2013, at 10:59 AM, Rob Weir wrote:
>>>>>> 
>>>>>>> Since this has come up recently, I'd like to point you all to
a recent
>>>>>>> thread on the legal-discuss list:
>>>>>>> 
>>>>>>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201301.mbox/browser
>>>>>>> 
>>>>>>> If you are not familiar with the SGA form, you can see it here:
>>>>>>> 
>>>>>>> http://www.apache.org/licenses/cla-corporate.txt
>>>>>>> 
>>>>>>> As you can see, it is a combined Corporate CLA and Software Grant
>>>>>>> Agreement.  Notice it does not speak of the Apache License, but
it
>>>>>>> does offer its own copyright and patent license.
>>>>>>> 
>>>>>>> The license portion in question was this:
>>>>>>> 
>>>>>>> "Grant of Copyright License. Subject to the terms and conditions
>>>>>>>    of this Agreement, You hereby grant to the Foundation and
to
>>>>>>>    recipients of software distributed by the Foundation a perpetual,
>>>>>>>    worldwide, non-exclusive, no-charge, royalty-free, irrevocable
>>>>>>>    copyright license to reproduce, prepare derivative works of,
>>>>>>>    publicly display, publicly perform, sublicense, and distribute
>>>>>>>    Your Contributions and such derivative works."
>>>>>>> 
>>>>>>> The question was:  What does "software distributed by the Foundation"
>>>>>>> mean?  Does that mean only releases?  Code in SVN?  What exactly?
>>>>>>> 
>>>>>>> As you can read in the archives, the response was that stuff
in SVN is
>>>>>>> considered "distributed by the Foundation", so the license of
the SGA
>>>>>>> applies to contributions made under SGA and checked into Subversion.
>>>>>>> 
>>>>>>> But note also Roy's later clarifying response:
>>>>>>> 
>>>>>>> "The dev subversion repo is not a means of distributing to the
>>>>>>> "general public".  It distributes to our self-selected development
>>>>>>> teams that are expected to be aware of the state of the code
being
>>>>>>> distributed.
>>>>>>> 
>>>>>>> When we distribute to the "general public", it is called a release."
>>>>>>> 
>>>>>>> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201301.mbox/browser
>>>>>>> 
>>>>>>> That was the basis for the DISCLAIMER I put in the root of our
>>>>>>> Subversion a couple of days ago:
>>>>>>> 
>>>>>>> https://svn.apache.org/repos/asf/openoffice/DISCLAIMER
>>>>>>> 
>>>>>>> I don't think this is anything new.  We already know that code
that
>>>>>>> we're releasing requires careful review and verification of file
>>>>>>> headers, LICENSE and NOTICE files, etc.  That is part of what
it means
>>>>>>> to publish a release at Apache.  But we have other stuff in Subversion
>>>>>>> that we do not intend to include in a release, and for which
we do not
>>>>>>> make this effort.  For example, /devtools, /ooo-site and /symphony.
>>>>>> 
>>>>>> Agreed this follows the policy here: http://www.apache.org/legal/src-headers.html
>>>>>> 
>>>>>> One subtle point here is the following:
>>>>>> 
>>>>>> "If the source file is submitted with a copyright notice included
in it, the copyright owner (or owner's agent) must either:
>>>>>>       • remove such notices, or
>>>>>>       • move them to the NOTICE file associated with each applicable
project release, or
>>>>>>       • provide written permission for the ASF to make such removal
or relocation of the notices."
>>>>>> 
>>>>>> The SGA does not give those rights.
>>>>>> 
>>> 
>>> Until we address this subtle distinction we have two classes of committer on
this project. IBMers and others. This distinction needs to be eliminated / minimized.
>>> 
>>>>> 
>>>>> And perhaps a more subtle point (you seemed to miss it, for example)
>>>>> is the section that says:
>>>>> 
>>>>> "When must Apache projects comply with this policy?
>>>>> 
>>>>> All releases created and distributed after November 1, 2006 must
>>>>> comply with this policy."
>>>>> 
>>>>> The source in the /symphony directory is not planned to be included in
>>>>> any release, so I don't see this policy as applicable.
>>> 
>>> I did not miss that at all. You are correct that it is not required by the ASF.
But because something is not required does not mean it should not be done.
>>> 
>>>>> 
>>>>>> If IBM will or has granted the ASF these specific rights then anyone
from the project can make these changes as they move the files. But unless this is so it is
only safe for an IBM employee listed on a CCLA to do it. That is the hang up as non-IBM project
committers may be constrained from doing this until this matter is cleared up.
>>>>>> 
>>>>> 
>>>>> That is a hypothetical issue, since no developers have stepped forward
>>>>> to volunteer merging these files into the AOO 4.0 trunk.
>>>>> 
>>>> 
>>>> And just in the spirit of brainstorming, if a project member is able
>>>> to confirm that the SGA terms are sufficient for them to work with the
>>>> code (and I think any reasonable reading would show that they are)
>>>> then they can go ahead and help merge it and ignore the header cleanup
>>>> question.
>>> 
>>> Let's do this. Should any project contributor wish to work on a portion of this
code someone from IBM will handle these two tasks:
>>> 
> 
> Heck, I'll do one better.  I volunteer to run a RAT scan on the trunk
> every two weeks and remove any IBM headers that are found there.  So
> we'll never be more then two weeks behind.
> 
> If you recall, the project worked on the trunk for AOO 3.4.0 for
> nearly 6 months before all of the headers were cleaned up, and I don't
> recall hearing you complain that this was an unacceptable risk.  We
> trusted Oracle, via Andrew, to do the right thing.  So I'll do better
> than that by a factor of 6*4/2 = 12.  So 12x faster header cleanups
> than occurred with AOO 3.4.
> 
> Does that satisfy your concern?

Yes, I think that allows for any committer to scratch an itch. Please publish a note on dev
since it might spark the interest of other devs

Will you practice your rat fu on the Symphony branch? (maybe you have already?)

Best Regards,
Dave



> 
> -Rob
> 
>>> (1) Add the Apache License 2.0 Header.
>>> 
>>> (2) Move the IBM (and other) Copyrights to NOTICE.
>>> 
>>> I'm not saying the whole tree, but on request for a reasonable number of files.
>>> 
>>>> 
>>>> But before we release AOO 4.0 we'll of course run a RAT scan and that
>>>> will identify any issue.  And so no one need worry about this further,
>>>> I volunteer to fix any header inconsistencies that show up there
>>>> before we release.
>>>> 
>>>> OK?
>>> 
>>> It may not be OK for some. It is a risk, better to do the changes before or as
the code goes into trunk or a release branch.
>>> 
>> 
>> Dave, I'm not asking you to speak for the universe, only for yourself.
>> Do you want to help merge the Symphony code?  Do you believe that you
>> have insufficient rights to do this?  Do you deny that my volunteering
>> to update the headers in any release completely addresses the policy
>> issue that you raised?
>> 
>> Any other committer is free to speak for themselves on these
>> questions.  There is not need for you to guess what they may or may
>> not think.
>> 
>> -Rob
>> 
>>> A supplemental note from IBM to the ASF secretary saying that there is no objection
to any Apache OpenOffice committer removing an IBM copyright in the Symphony codebase to the
NOTICE. With that in hand then we can all be free to do the correct work with this wonderful
codebase and contributions from two of the most successful software corporations!
>>> 
>>> Regards,
>>> Dave
>>> 
>>> 
>>>> 
>>>> -Rob
>>>> 
>>>>> -Rob
>>>>> 
>>>>>> Regards,
>>>>>> Dave
>>>>>> 
>>>>>> 
>>>>>> 
>>> 


Mime
View raw message