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 [mailto:[email protected]] Sent: Wednesday, September 28, 2011 08:32 To: [email protected] Subject: Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?] FWIW; 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. Pedro. --- On Wed, 9/28/11, Jürgen Schmidt <[email protected]> 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 >
