The idea (not originally mine) is to have keep only compatible licensed code under an isolated (3rdparty) directory.
I think on the long run we should try to use the system versions of such software when available, and every linux/bsd distribution is probably doing that for LO already. Pedro. --- On Wed, 9/28/11, Dennis E. Hamilton <[email protected]> wrote: > 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 > > > > >
