incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <...@apache.org>
Subject Re: CWS swbookmarkfixes01 rebasing and licensing
Date Tue, 03 Jul 2012 16:26:58 GMT


--- Mar 3/7/12, Bjoern Michaelsen ha scritto:

> Hi Ross,
> 
> Thanks for the constructive reply!
> 
> On Tue, Jul 03, 2012 at 03:58:54PM +0100, Ross Gardler
> wrote:
> > If the CWS was included in the original SGA then it is
> > available under the AL2.
> 
> How can I check that? It was not integrated in m106 at OOo,
> if that is the criteria, but I assume there is more to that ;)
> 

I don't think we committed it. You can review the SVN history
in fisheye, but it's probably easier to look at the code and
recognize it.

> > If it was not included in that original SGA, you want
> to bring it here and
> > the OpenOffice project want to see the work committed
> then Oracle will, in
> > all likelihood, make it available to us.
> 
> Great!
> 
> > Therefore, I suggest the following order of execution:
> 
> > - determine whether the OpenOffice committers want the
> work
> 
> Where would that be done?
> 

Here. You may want to send us a description. If you prefer
you can handle it through a bugzilla issue.


> > - confirm that Oracle have already or will make the
> code available
> > under the AL2 at our request
> 
> Are there established workflows for that, or should I just
> go about that ad-hoc?
> 

ad-hoc. They are very cooperative.

> > - submit patches against AOO trunk
> 
> Are the patches already released AL2 by Apache when they are
> published on the list then?

Unfortunately it's not that easy. The code is strictly under
ALv2 only when the code has been released by the ASF.
We are under incubation still so being strict that means
that you can only count with code officially reviewed by
the ASF IPMC and released.

> Given that AOO might switch to the Symphony codebase and fail to
> even release a version with the patches against the original
> OOo, I would need that assureance that the effort to rebase
> the work is not in vain.
> 

I think the "effort to rebase" is actually pretty small as
we have avoided wild changes (precisely to ease code
merging). If we do rebase on Symphony (which is only
an option and not the most popular ATM), merging changes
from AOO is still relatively easy (I tried this myself
already).

I am going to be pretty honest with you (as with everyone).

We welcome new contributions, especially from people that
have experience with the codebase, but if the idea is simply
getting "your" code relicensed on the short term and leave
us with the problem of maintaining it or even worse, fixing
it, this is not going to work.

best regards,

Pedro.

Mime
View raw message