Open Stack

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.

James