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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev