On Wed, Mar 16, 2016 at 9:34 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:
> There's a way around the cut. I don't know why they did it like that > (Carsten, > do you know?), but there's a mechanism in Git to get past this history > restart. The reason is pretty simple, when we take new code we analyze its provenance and check it complies with our IP policy. If a project like tinydtls comes and plans on being dual-licensed EPL/EDL, we check that the tinydtls code is indeed 100% original, that the contributors to the codebase have CLAs in place (and that they agree to relicense their code, where required). We also check the provenance of 3rd party libraries the project depends on. E.g if there is a dependency towards a GPL library for the project to function properly, that's an obvious no-no. Same if a 3rd party library claims it's say EPL but our code scanners tells us otherwise (e.g they have "borrowed" pieces of GPL code). Long story short: in order to perform this analysis, the only reasonable approach is to do it for a snapshot of the codebase, typically HEAD. We can't go through years of history to check that at any point in time the project has indeed been EPL/EDL compatible *and* completely clean from an IP point of view. I hope this makes things a bit clearer :) I know it's somewhat "sad" to lose the SCM history, but experience shows that after a few months, there are very few cases where digging up the history really is necessary. I guess the main case being for people like you with unmerged patches in a now obsolete/orphan (or rather siblingless, kinda) branch. I think the git format-patch / git am should work just fine though as IIRC the patches weren't that big. Benjamin . --- Benjamin Cab? ? IoT Evangelist Eclipse Foundation +33 (0) 619196101 @kartben -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160316/02e85bb3/attachment.html>
