openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juergen Schmidt <jogischm...@gmail.com>
Subject Re: What rights are given in an SGA
Date Tue, 22 Jan 2013 07:10:59 GMT
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 <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?)
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
> > > > > > >  
> > > > > >  
> > > > > >  
> > > > >  
> > > > >  
> > > >  
> > > >  
> > >  
> > >  
> >  
> >  
>  
>  
>  



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message