incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: Legality of ooo-archive apache git repository
Date Tue, 26 Jul 2011 14:13:19 GMT
On Mon, Jul 25, 2011 at 10:50 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> On Mon, Jul 25, 2011 at 4:58 PM, florent andré
> <florent.andre-dev@4sengines.com> wrote:
>> Hi,
>>
>> This question come from a discussion about OpenOffice.org code migration
>> (ooo-dev thread "single repository status").
>>
>> For giving you context, the actual simpler scenario we have for importing
>> code is :
>> - only import HG trunk code in our svn (with more or less history) [1]
>> - create an apache git read-only repository with all the oracle's hg code,
>> for keeping all the history stuff.
>>
>> So with this scenario, we will have :
>> - a clean (SGA and IP) svn trunk
>> - an ooo-archive git with all the original stuff from Oracle
>>
>> Question around this idea is (Quoting Rob Weir) :
>> " it would be from the IP perspective.  This is more than
>> getting an updated SGA from Oracle. It is also about incompatible
>> licensed code.  We can only carry that in our SVN repository
>> temporarily, until we graduate.  So having it exist long-term in a
>> read-only git archive is something we'd want to understand better."
>>
>> Your insights will be really helpful here as it's more than a month ago from
>> incubation now, an the option here seems the best compromise we had for now.
>
> From a legal perspective, there is no difference between svn, git, or
> even hg for that matter.  This is for the PPMC to decide, in
> conjunction with infrastructure.
>
> What purpose would there be to retaining a "long-term...archive" of
> "incompatible licensed code" on Apache Infrastructure?  I fully
> understand the short term need during incubation, but what is the
> intended purpose of this code post graduation?
>

The idea is this:

1) The existing OpenOffice.org Hg repository has a 100+ unintegrated
developer "child work spaces" (or CWS's).  Some of these are being
actively worked on, other appear to be abandoned.  But in total they
appear to have value to the Apache project.

2)  There does not appear to be a way, given current tooling, to
migrate these CWS's coherently into SVN branches.  Several attempts
have been made, but the underling differences in models has frustrated
our attempts.

3) So current proposal is to move the trunk only into SVN.  This would
be the repository that would be taken through IP review, where we
would remove Category X licensed code, etc.  This trunk would be the
project's official repository for future releases.

4) However, we want to preserve, as a source of future features, the
work in the 100+ CWS's are currently in Hg.  Since these CWS's were
based on older, pre-Apache revisions of the code, they will have
dependencies on Category X licensed code.

5) So the current proposal is to maintain the existing OpenOffice.org
repository (either in HG or in a lossless git translated form) in a
read-only state for the Apache OpenOffice.org project, to allow these
CWS to be integrated into the Apache project, over time and based on
community interest.  The work for developers would then be a two step
merge:

A) First update the CWS to the OOO340 level by doing a pull in Hg (or
equiavalent in git).  Deal with merge conflicts at that stage.

B) Then check out OOO340 from SVN, do a file system copy of the
updated CWS files into the SVN working copy.  Then do an svn update to
bring that code up to date and merge it from there.

The concern was Apache policy appears to be that projects after
graduation must not carry incompatibly licensed code in their
repositories.  What we need to understand is whether this might be
permitted in a read-only archive of the old OpenOffice.org project,
provided we have safeguards in place to ensure that the projects
official SVN repository is not contaminated.

-Rob

>> ++
>>
>> [1] after this first import we gradually import other stuff from hg or git
>> with classical branching / merging.
>
> - Sam Ruby
>

Mime
View raw message