Open Stack

On Fri, 2015-06-12 at 13:05 -0700, Dmitry Borodaenko wrote:
> On Fri, Jun 12, 2015 at 08:33:56AM -0700, James Bottomley wrote:
> > On Fri, 2015-06-12 at 02:43 -0700, Dmitry Borodaenko wrote:
> > > On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
> > > > What about code history and respect of commit ownership?
> > > > I'm personally wondering if it's fair to copy/paste several thousands of
> > > > lines of code from another Open-Source project without asking to the
> > > > community or notifying the authors before. I know it's Open-Source and
> > > > Apache 2.0 but well... :-)
> > > 
> > > Being able to copy code without having to ask for permission is exactly
> > > what Free Software (and more recently, Open Source) is for.
> > 
> > Copy and Paste forking of code into compatibly licenced code (without
> > asking permission) is legally fine as long as you observe the licence,
> > but it comes with a huge technical penalty:
> > 
> >      1. Copy and Paste forks can't share patches: a patch for one has to
> >         be manually applied to the other.  The amount of manual
> >         intervention required grows as the forks move out of sync.
> >      2. Usually one fork gets more attention than the other, so the
> >         patch problem of point 1 eventually causes the less attended
> >         fork to become unmaintainable (or if not patched, eventually
> >         unusable).
> >      3. In the odd chance both forks receive equal attention, you're
> >         still expending way over 2x the effort you would have on a
> >         single code base.
> > 
> > There's no rule of thumb for this: we all paste snippets (pieces of code
> > of up to around 10 lines or so).  Sometimes these snippets contain
> > errors and suddenly hundreds of places need fixing.   The way around
> > this problem is to share code, either by inclusion, modularity or
> > linking.  The reason we paste snippets is because sharing for them is
> > enormous effort.  However, as the size of the paste grows, so does the
> > fork penalty and it becomes advantageous to avoid it and the effort of
> > sharing the code looks a lot less problematic.
> > 
> > Even in the case where the fork is simply "patch the original for bug
> > fixes and some new functionality", the fork penalty rules apply.
> > 
> > The data that supports all of this came from Red Hat and SUSE.  The end
> > of the 2.4 kernel release cycle for them was a disaster with patch sets
> > larger than the actual kernel itself.  Sorting through the resulting
> > rubble is where the "upstream first" policy actually came from.
> 
> Thanks for the excellent summary of the technical penalties incurred by
> straying too far from upstream.

You're welcome.

> It's funny how after years of trying to convince Fuel developers to put
> more effort into collaboration with upstream, in this thread I managed
> to come across as if I were arguing the opposite. To reiterate, I
> understand and support the practical reasons to reduce the gap between
> Fuel and Puppet OpenStack, and I believe that practical reasons are a
> much better way to motivate Fuel developers to collaborate than arguing
> whether what Fuel team has done in the past was fair or wrong.

I agree; recriminations never solve anything but just to close out on
the topic of authorship and commit history, since I think there's been
some misunderstandings there as well:

The licence is the ultimate arbiter of what you absolutely *have* to do
to remain in compliance.  The licence governs only the code, not the
commit history, so under the licence, you're free to flush all the
commit history with no legal consequence from the terms of the licence.

However, the commit history is vital to obtaining the provenance of the
code.  If there's ever a question about who authored what part of the
code (or worse, who copied it wrongly from a different project, as in
the SCO suit against Linux) you need the commit history to establish the
chain of conveyance into the code.  If we lose this, the protection of
the OpenStack CLA and ICLA will be lost as well (along with any patent
grants that may have been captured) because they rely on knowing where
the code came from.  So in legal hygiene and governance terms, you're
not free to flush the commit history without setting up the project for
provenance problems on down the road.

James