Once we have the software grant ready for review on the Apache side, where exactly do we send it?
Thanks, Gj On Tue, Oct 11, 2016 at 7:43 PM, Craig Russell <craig.russ...@oracle.com> wrote: > > > On Oct 11, 2016, at 10:40 AM, Geertjan Wielenga < > geertjan.wiele...@googlemail.com> wrote: > > > > Tue, Oct 11, 2016 at 7:37 PM, Craig Russell wrote: > > , > > > >> The CCLA clarifies the status of all Oracle employees with regard to > their > >> contributions to the code. > > > > > > But that's not the software grant. This is the software grant: > > http://www.apache.org/licenses/software-grant-template.pdf > > Please. The CCLA’s complete name is > > Software Grant and Corporate Contributor License Agreement > > It contains Schedule A which names the employees. > > It also contains Schedule B which makes the separate > software-grant-template unnecessary. > > Whoever is working with Oracle Legal can ask that whatever we decide is > the best wording for the grant, that wording goes into Schedule B. > > Please do not use the software-grant-template. > > Craig > > > > Gj > > > > On Tue, Oct 11, 2016 at 7:37 PM, Craig Russell <craig.russ...@oracle.com > > > > wrote: > > > >> Hi Geert, > >> > >>> On Oct 11, 2016, at 12:10 AM, Geertjan Wielenga < > >> geertjan.wiele...@googlemail.com> wrote: > >>> > >>> Here's what it looks like: > >>> http://www.apache.org/licenses/software-grant-template.pdf > >> > >> Please do not use this license. Use the CCLA instead. > >> > >> The CCLA clarifies the status of all Oracle employees with regard to > their > >> contributions to the code. > >> > >> http://www.apache.org/licenses/cla-corporate.txt > >> > >> Thanks, > >> > >> Craig > >> > >>> > >>> It's in the process of being signed right now, it's being worked on > right > >>> now, might take a week or so the way it looks now. > >>> > >>> The question remains -- and can someone answer it: once the grant has > >> been > >>> signed and handed over to Apache, what happens if for some reason the > >>> process fails, must Apache then sign a document to grant the code back > to > >>> Oracle? > >>> > >>> Gj > >>> > >>> > >>> On Tue, Oct 11, 2016 at 8:34 AM, Emilian Bold <emilian.b...@gmail.com> > >>> wrote: > >>> > >>>> I didn't mean just an empty git repo, I meant the canonical repository > >> from > >>>> which daily builds and releases are made. > >>>> > >>>> I believe with this proposal Oracle has agreed to the following: > >>>> > >>>> 1. Changing the project license to the Apache license > >>>> 2. Contributing further changes under the Apache license > >>>> 3. Following the Apache governance model and > >>>> 3. Granting code ownership to the Apache Software Foundation. > >>>> > >>>> I don't know how a software grant document looks like but I assume > there > >>>> are articles about 'unwinding'. Oracle legal should talk to Apache > legal > >>>> and clear this out. > >>>> > >>>> It seems to me though that without the code grant incubation hasn't > >> really > >>>> started. I mean, incubation is not about due diligence or legal > >> discovery. > >>>> > >>>> Still, there is nothing stopping Oracle from following 1, 2 and 3. > They > >>>> could change the license to the Apache license this very week. > >>>> > >>>> > >>>> > >>>> --emi > >>>> > >>>> On Tue, Oct 11, 2016 at 5:46 AM, Geertjan Wielenga < > >>>> geertjan.wiele...@googlemail.com> wrote: > >>>> > >>>>> The point is this -- during incubation, we're going to be working on > >>>>> establishing whether Apache NetBeans can exist or not, from many > >>>> different > >>>>> points of view. And, even though we don't believe the process will > >> fail, > >>>> it > >>>>> would be a problem if Oracle has granted the code to Apache only to > >> find > >>>>> that for some reason Apache NetBeans will not be able to leave the > >>>>> incubator. Let's say, for example, there's a licensing problem that > >>>> cannot > >>>>> be fixed. If the software has already been granted, it would then > need > >> to > >>>>> be 'ungranted' at that stage. That's my concern and why I think the > >> code > >>>>> should only be granted formally, i.e., via the formal SGA document, > >> when > >>>> we > >>>>> know for sure that incubation will succeed. > >>>>> > >>>>> That means that we can work on setting up the Git repo immediately > and, > >>>>> once we know what we want to move there, we move the source code > there. > >>>>> Then we start the process of 'scrubbing the code', i.e., checking its > >>>>> licenses and noting any problems and seeking their solutions. Not > sure > >>>> how > >>>>> long this will take, but maybe not too long, a month or so, just a > >>>>> guesstimate. Once we have worked through the licensing, and we know > for > >>>>> sure incubation will succeed, we can get the SGA, if we know for sure > >>>> there > >>>>> will be no blockers. We did a preliminary investigation of this prior > >> to > >>>>> putting the proposal together, but at this point we'll have done a > >>>> thorough > >>>>> analysis. > >>>>> > >>>>> Then, once we have the SGA, those who have signed the ICLAs can begin > >>>>> working on committing code agreed upon by the project in terms of a > >>>>> commonly drawn up roadmap. So, it's not a question of waiting until > >> next > >>>>> year sometime to start committing, just a question of waiting until > we > >>>> know > >>>>> for 100% sure that the process will not have to be unwound before > >>>> actually > >>>>> having the code granted from Oracle. > >>>>> > >>>>> Does the above make sense? > >>>>> > >>>>> Gj > >>>>> > >>>>> > >>>>> On Tue, Oct 11, 2016 at 1:29 AM, Emilian Bold < > emilian.b...@gmail.com> > >>>>> wrote: > >>>>> > >>>>>> Migrating the repository over to git and the code grant should > happen > >>>> in > >>>>>> 2016. > >>>>>> > >>>>>> We have some momentum here but if I have to wait until Summer 2017 > to > >>>>>> commit using my @apache ID I signed the iCLA 6 months too soon. > >>>>>> > >>>>>> Also, it's a premature optimization to change too much the code > >>>>> repository. > >>>>>> It seems like a juicy engineering task to split it up, filter it, > >>>>> whatever. > >>>>>> But it is pointless. > >>>>>> > >>>>>> What's essential first is for work to be possible and to start on > the > >>>> git > >>>>>> repo. We could have another goal during the incubation or even after > >>>>>> incubation to split the repository. > >>>>>> > >>>>>> I don't think the unwinding should be your main concern. Code > changes > >>>>> will > >>>>>> have to be done regardless of who owns the IP. > >>>>>> > >>>>>> As an alternative to this Oracle concern, you could require > >>>> contributors > >>>>> to > >>>>>> have both an iCLA and an OCA, although perhaps the Apache iCLA might > >> be > >>>>>> sufficient. Apache Legal might intervene and explain things here... > >>>>>> > >>>>>> An incubating project must do a major release during incubation. I > >>>>> believe > >>>>>> that release will have be the Java 9 release. > >>>>>> > >>>>>> > >>>>>> > >>>>>> --emi > >>>>>> > >>>>>> On Tue, Oct 11, 2016 at 12:18 AM, Geertjan Wielenga < > >>>>>> geertjan.wiele...@googlemail.com> wrote: > >>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> An overview of the sequence as far as I understand it. Consider it > a > >>>>>> basic > >>>>>>> starting point for discussion. > >>>>>>> > >>>>>>> Let's start by assuming we want there to be a NetBeans 9 to be > >>>> released > >>>>>> out > >>>>>>> of Apache, and as a top level project, i.e., outside the incubator, > >>>> in > >>>>>> line > >>>>>>> with the release of Java 9. > >>>>>>> > >>>>>>> That puts us in the middle of next year somewhere. > >>>>>>> > >>>>>>> The most important aspect that needs to be worked through before > then > >>>>> is > >>>>>>> the IP, license hygiene, etc. Before we get to the point where > we're > >>>>>>> working on that, we need to actually have one or more Mercurial > repos > >>>>>> that > >>>>>>> we know we want to move. Right now, the NetBeans 9 branch is being > >>>>> moved > >>>>>>> into trunk, once that's done we need to consider whether we should > >>>> take > >>>>>> the > >>>>>>> NetBeans trunk as our starting point -- and determine other brances > >>>>> we'll > >>>>>>> need. > >>>>>>> > >>>>>>> We'll then need to work through the IP issues, i.e., work through > the > >>>>>>> incompatible licenses and work out solutions for those. Some > features > >>>>>> might > >>>>>>> be dropped, others can be installed via plugins, either separately > or > >>>>>>> during installation. > >>>>>>> > >>>>>>> At the point where we've worked through those licensing issues and > >>>> are > >>>>>> at a > >>>>>>> stage where we either have temporary exceptions for truly > problematic > >>>>>>> areas, while knowing what the ultimate solutions for those will be, > >>>> or > >>>>> we > >>>>>>> have solved everything, we'll be at the point where Oracle's SGA > >>>>>> (software > >>>>>>> grant agreement) can be worked on. > >>>>>>> > >>>>>>> In other words, based on the above, the SGA would be executed as > one > >>>> of > >>>>>> the > >>>>>>> LAST steps of the incubation period. After all, if we do uncover > >>>>>>> insurmountable issues during the incubation period, in particular > in > >>>>>>> relation to licensing, having executed such a grant too early would > >>>>> lead > >>>>>> to > >>>>>>> a very difficult unwinding of the process. > >>>>>>> > >>>>>>> In parallel to the licensing process described above, since we're > >>>>>> confident > >>>>>>> that in one way or another things will work out favorably, we could > >>>>>> decide > >>>>>>> to move the tutorials and other content from netbeans.org to the > >>>>> website > >>>>>>> structure, whatever that will be, at Apache, including setting up a > >>>>> Wiki > >>>>>>> structure in our new Confluence environment. > >>>>>>> > >>>>>>> Comments to the above -- bring 'em on! > >>>>>>> > >>>>>>> Gj > >>>>>>> > >>>>>> > >>>>> > >>>> > >> > >> Craig L Russell > >> Secretary, Apache Software Foundation > >> c...@apache.org http://db.apache.org/jdo > >> > >> > > Craig L Russell > Architect > craig.russ...@oracle.com > P.S. A good JDO? O, Gasp! > > > > > >
