incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Date Wed, 28 Sep 2011 20:09:09 GMT
The problem with bringing the 3rd party software completely into the SVN tree and modifying
it in the tree has to do with the license the updated software is under.  In that case, there
*is* a code provenance issue and I believe it crosses a line that the Apache Software Foundation
is unwilling to cross with regard to the integrity of its code bases.

The current patches to Boost, for example, do not change the license on the code and preserve
the Boost license.  But since this is ephemeral and the source is never in the SVN tree (is
that correct?) the derivative use disappears at the end of a build.  It is sufficient then
to include the dependency in the NOTICE for the release and not worry further.

Also, the current dependency is several releases behind the current Boost release.  This might
not matter - the specific Boost libraries that are used might not be effected.  But there
is a release synchronization issue.  A fork would have to be maintained.  Also, the dependencies
are managed better now, rather than having the entire Boost library installed for cherry picking.

(This will all change at some point, since Boost is being incorporated into ISO C++.  It is
probably best to wait for that to ripple out into the compiler distributions.)

 - Dennis

-----Original Message-----
From: Pedro F. Giffuni [] 
Sent: Wednesday, September 28, 2011 08:32
Subject: Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach
to IP review?]


I don't like the patches because I can't really examine well
the code, besides this is something the VCS handles acceptably:
commit the original sourcecode and then apply the patches in a
different commit. If we start with up to date versions there
would not be much trouble.

just my $0.02, not an objection.


--- On Wed, 9/28/11, J├╝rgen Schmidt <> wrote:


> > I wouldn't give up the patches, as they allow to
> handle updates better.
> > This would cause a problem, as direct changes to the
> 3rd party stuff without
> > additional authorization (means: changing the source
> code must not happen
> > accidently, only when the 3rd party code gets an
> update from upstream) must
> > be prevented, while still patch files must be allowed
> to added, removed, or
> > changed, not the original source code. If that wasn't
> possible or too
> > cumbersome, checking in the tarballs in "3rdparty"
> would be better.
> >
> i also wouldn't give up the patches and for that reason i
> would like to move
> forward for now with keeping the tarballs as proposed. But
> i like the name
> "3rdparty" for the directory and we can later on change it
> from the tarballs
> to the unpacked code it we see demand for it. At the moment
> it's just easier
> to keep the tarballs and focus on other work.
> >
> > As svn users never download the complete history as
> DSCM users do, the pain
> > of binary files in the repo isn't that hard. In case
> AOOo moved to a DSCM
> > again later, the tarballs could be moved out again
> easily.
> >
> agree, we don't really loose anything, can change if
> necessary and can
> continue with our work
> Juergen

View raw message