incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pedro F. Giffuni" <giffu...@tutopia.com>
Subject RE: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Date Wed, 28 Sep 2011 21:08:21 GMT
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 <dennis.hamilton@acm.org> 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:giffunip@tutopia.com]
> 
> Sent: Wednesday, September 28, 2011 08:32
> To: ooo-dev@incubator.apache.org
> 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 <jogischmidt@googlemail.com>
> 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
> > 
> 
> 
> 

Mime
View raw message