Open Source – How to Handle Copyrighted Media in Git History

gitopen sourcereleasetesting

I want to release an audio fingerprinting software project under a free license, but the repository contains copyrighted audio files. The test cases also currently use these files. How do I release the code to the public with maximum version history but without violating copyright?

Details:

The code is versioned under git. We will collapse it all back into one branch before release.
There are 400 MB of audio data. Some files are free-licensed music from e.g. Jamendo, others are MP3s from our personal collections.
No matter what approach we take, we'll always keep an immutable copy of the original repo, so as not to destroy project history.

Main question: How to handle the public release?

Expunge all history of the files in question from the git repository and release the altered repo. (v64 pointed out a way to do this.)
Alternatively, take a snapshot of the current state of the code and don't even bother having a public history of the pre-release code.

Side question: How could we have avoided this dilemma in the first place, given that sometimes private code or media is needed for the early stages of a project?

Best Answer

GitHub has a page explaining how to expunge a file from all history: Remove sensitive data.

From time to time users accidentally commit data like passwords or keys into a git repository. While you can use git rm to remove the file, it will still be in the repository's history. Fortunately, git makes it fairly simple to remove the file from the entire repository history.

Danger: Once the commit has been pushed you should consider the data to be compromised. If you committed a password, change it! If you committed a key, generate a new one.

Purge the file from your repository

Now that the password is changed, you want to remove the file from history and add it to the .gitignore to ensure it is not accidentally re-committed. For our examples, we're going to remove Rakefile from the GitHub gem repository...

Related Solutions

Git – Best way to convert existing project to be open source in GitHub

Well you seem to want to use the Apache licence because it's the most common one.

I was thinking of going with Apache 2.0 licence just because it seems to be widely used

This Coding Horror Post explains in a clear and concise fashion the different licences available.

If you create a new branch and commit to it, it's cleaner. unless you want the older version(s) available to your users.

Git – Create separate GIT repository for publishing with different history

Use the Gitflow Workflow

Following this model, the master branch contains only releases, the develop branch contains the WIP (work in progress) commits, and feature branches are used to develop features.

The main benefit of this approach is, if you screw up and publish a bad commit to develop you'll be able to rollback the changes without screwing up the the history of the publicly accessible version on master.

So, that doesn't answer your question...

What about combining partial features into a single feature commit?

Simple, before merging a feature branch into develop squash the commits using interactive rebase.

git rebase -i feature-branch

It'll pop up an editor and you can change which commits you want to squash. It also concats the commit logs so you can add all/part of them into the squashed commit message.

Note: There are many ways to squash commit history. IMHO, I think interactive rebase is the most straight-forward but YMMV.

When you're ready for a release, simply create a release branch from develop and merge the release branch into `master.

Developing features can be challenging because a maintainer may require a contributor to make additional changes piecemeal prior to accepting a PR (pull request).

Using the strategy above, the contributor will still have a granular history containing all of the changes made to the feature throughout development. This makes it easy to roll-back and/or cherry-pick commits individually.

Note: The ability to cherry-pick commits is extremely valuable if the contributor runs into complicated merge conflicts.

If you want features to commit cleanly, simply have the contributor squash the changes as the last step prior to a merge.

Best Answer

Purge the file from your repository

Related Solutions

Git – Best way to convert existing project to be open source in GitHub

Git – Create separate GIT repository for publishing with different history

Related Topic