You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2013/01/21 19:59:55 UTC
What rights are given in an SGA
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.
Regards,
-Rob
Re: What rights are given in an SGA
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Dienstag, 22. Januar 2013 um 04:41 schrieb Dave Fisher:
>
> On Jan 21, 2013, at 6:49 PM, Rob Weir wrote:
>
> > On Mon, Jan 21, 2013 at 9:40 PM, Rob Weir <ro...@apache.org> wrote:
> > > On Mon, Jan 21, 2013 at 9:18 PM, Dave Fisher <da...@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 <ro...@apache.org> wrote:
> > > > > > On Mon, Jan 21, 2013 at 8:10 PM, Dave Fisher <da...@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?)
we ran a Rat scan on the build bots regularly, no need to do it manually. Simply check the output as I did from time to time.
I think it make no sense to run it on the Symphony branch where we know that many files contain the old headers.
And I don't know how often we have now offered to help any individual who really want to start working with files and is interested to merge stuff in trunk. Interested to do some real work!
If we would see huge activities from volunteers to merge stuff in trunk we might invest further time to change the headers in advance to reduce potential overhead. But even this is hypothetical at the moment and I see no single volunteer working on any migration.
We (IBM contributors) continue to invest our time in working on trunk towards 4.0 and will continue to merge stuff like the sidebar during this work.
So please either start to work on or with the code and merge it in trunk and ask for detailed help with file x or let us simply continue with the ongoing work. We have enough to do!!!!!!!!!!!!
Juergen
>
> 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
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>
Re: What rights are given in an SGA
Posted by Andrea Pescetti <pe...@apache.org>.
Dave Fisher wrote:
> On Jan 21, 2013, at 6:49 PM, Rob Weir wrote:
>> 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.
> Yes, I think that allows for any committer to scratch an itch.
OK, great to see we have an agreement here. So, while it's clear that
the former Symphony team will know better than others how to handle the
Symphony code, now any committer can help. (I know this was already the
case, but it's good to have it addressed explicitly).
Regards,
Andrea.
Re: What rights are given in an SGA
Posted by Dave Fisher <da...@comcast.net>.
On Jan 21, 2013, at 6:49 PM, Rob Weir wrote:
> On Mon, Jan 21, 2013 at 9:40 PM, Rob Weir <ro...@apache.org> wrote:
>> On Mon, Jan 21, 2013 at 9:18 PM, Dave Fisher <da...@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 <ro...@apache.org> wrote:
>>>>> On Mon, Jan 21, 2013 at 8:10 PM, Dave Fisher <da...@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
>>>>>>
>>>>>>
>>>>>>
>>>
Re: What rights are given in an SGA
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 21, 2013 at 9:40 PM, Rob Weir <ro...@apache.org> wrote:
> On Mon, Jan 21, 2013 at 9:18 PM, Dave Fisher <da...@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 <ro...@apache.org> wrote:
>>>> On Mon, Jan 21, 2013 at 8:10 PM, Dave Fisher <da...@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?
-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
>>>>>
>>>>>
>>>>>
>>
Re: What rights are given in an SGA
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 21, 2013 at 9:18 PM, Dave Fisher <da...@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 <ro...@apache.org> wrote:
>>> On Mon, Jan 21, 2013 at 8:10 PM, Dave Fisher <da...@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:
>
> (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
>>>>
>>>>
>>>>
>
Re: What rights are given in an SGA
Posted by Dave Fisher <da...@comcast.net>.
On Jan 21, 2013, at 5:48 PM, Rob Weir wrote:
> On Mon, Jan 21, 2013 at 8:36 PM, Rob Weir <ro...@apache.org> wrote:
>> On Mon, Jan 21, 2013 at 8:10 PM, Dave Fisher <da...@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:
(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.
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
>>>
>>>
>>>
Re: What rights are given in an SGA
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 21, 2013 at 8:36 PM, Rob Weir <ro...@apache.org> wrote:
> On Mon, Jan 21, 2013 at 8:10 PM, Dave Fisher <da...@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.
>>
>
> 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.
>
>> 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.
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?
-Rob
> -Rob
>
>> Regards,
>> Dave
>>
>>
>>
Re: What rights are given in an SGA
Posted by Rob Weir <ro...@apache.org>.
On Mon, Jan 21, 2013 at 8:10 PM, Dave Fisher <da...@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.
>
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.
> 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.
-Rob
> Regards,
> Dave
>
>
>
Re: What rights are given in an SGA
Posted by Dave Fisher <da...@comcast.net>.
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.
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.
Regards,
Dave
Re: What rights are given in an SGA
Posted by Kay Schenk <ka...@gmail.com>.
On 01/21/2013 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.
>
> Regards,
>
> -Rob
>
Thanks for posting this. I think it does clarify some
issues/conversations of late.
--
------------------------------------------------------------------------
MzK
"No act of kindness, no matter how small, is ever wasted."
-- Aesop