Some background on how Android source code is used by developers and
why those copyrighted files might not actual exist in the Android
repository but CAN be created by a CHECKOUT of a particular historical
commit.
The tool used by Android developers to copy and sync the myriad
individual project GIT source-code repositories that make up the entirety of the
Android platform is repo.
re
po manages the
complexity of cloning/pulling all the individual project git repositories at
the correct commit HEADs for each Android version. In other words,
IceCreamSandwich might incorporate dnsmasq v2.54.2, giflib v3.6, bzip2 v1.3.4
(made-up versions numbers!) Each of those projects have likely advanced beyond
the version Android fixes to. Within Android there may be additional patches to
fix unique bugs or add/remove particular functionality for use in Android. Repo
keeps track of which commit each project repository should checkout to match a
particular version of Android.
In reality Android includes more than 100
external projects as well as many internal projects, each with its own GIT
repository.
A GIT repository is a series of DIFFerence (patch) files
tied to a unique history path such that applying the complete history to a
particular commit ID will give the developer a unique view of the state of the
project after CHECKOUT into the WORKING DIRECTORY.
The working directory
contains the files the developer works with. Any particular file may actually
have been built by applying one or hundreds of diff patches as they are stored
in the git repository itself.
In the initial stages of a project some
source-code files may be created almost complete. Over time small changes to
address bugs or add functionality will be captured in small patches (diffs) that
GIT keeps in its archive. Each time a COMMIT is made to the repository a new
history marker is created referenced by a unique one-way hash uniquely
identifying that commit's contents.
If removals of code or complete files
are committed they are represented as 'negative' diffs - in other words, a diff
can instruct the patch program to remove a few lines in a file, or all lines. If
all lines in a file are removed that is equivalent to deleting the file. The
state of the working directory after such a commit is as if the file never
existed.
When working on the HEAD (most recent commit) of a repository
any previous file deletions will mean the working directory DOES NOT CONTAIN the
deleted file.
So if/when Oracle seek to show that Google is still
infringing their copyright in the files at issue - assuming for this purpose
the files are deemed copyright-protected - then the git repository cloned
(downloaded) MIGHT NOT CONTAIN literal INFRINGING COPIES but a
developer who clones the repository to their local system and subsequently does
a CHECKOUT at some point in the history where those files exist (rather than the
current HEAD) will cause the infringing files to be built by git core as it
applies patch upon patch upon patch to put the working directory in the state
matching the point in history the developer asks for.
Very technical but
I hope this helps some of you understand how complex this subject is if you want
to be 100% accurate. [ Reply to This | Parent | # ]
| 
