diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..5777375
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,61 @@
+
+Please feel free to put a fork in the [fork drawer](https://gitlab.org/deejoe/fork-drawer). 
+
+[Free software](https://www.fsf.org) projects only, though, please.
+
+To do so, please clone/fork this repo, do the necessary, and then [submit a merge request](https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html) for your entry.
+
+For now, I think a simple ```parent-child``` naming scheme for entries is
+enough. Might be fun to make an index or table or something eventually.
+
+Tell us who forked what, when.  Give the name of the parent project, and of
+the child project.  Please provide some links--if it's an old fork, a
+[Wikipedia](https://en.wikipedia.org/wiki/List_of_software_forks) entry (perhaps for a specific date) may be enough--we don't need
+to re-invent the wheel __entirely__.  If not, links to blog posts or mailing lists
+entries or About pages or readme files are fine.  It would be especially
+diligent and appreciated to make sure [The Wayback Machine](https://archive.org) has a copy of whatever it is.
+
+Merges are also interesting here (for our purposes we'll just
+think of them as a special kind of fork--a reverse fork) so feel free to
+include those. If the successor projects of a merge take on a new name, then
+list any constituent predecessor project names first and the combined
+project name last. If the merge is the later evolution of an earlier fork,
+with development continuing on under the earlier name, just include that in
+the write-up of the original fork.
+
+Please be sure to include a suitable license with your submitted entry.
+
+I'll be using 
+
+[CC-BY-NC-SA-4.0](https://spdx.org/licenses/CC-BY-NC-SA-4.0.html)
+
+but any CC license that doesn't include the NC or ND clauses should be fine.
+
+Please put a copyright and license statement either in your entry or add it
+to the [LICENSE.md](LICENSE.md) file.
+
+I haven't given workflow or branching models a lot of thought for this just
+yet, given that this is so far nice and casual and has only one entry. 
+
+With suitable licensing and attestation we can cross that bridge if we come
+to it.
+
+Also, I don't have much in the way of Codes of Conduct. For now let me just
+say: Be cool. The point of this is to collect and report the facts of there
+having been a fork for any given instance. 
+
+Characterizing the timing and nature of the fork is what we're after beyond
+that. If we have to choose between "the fork resulted from so-and-so
+being a real jerk" or just a very simple and barely-informative "so, that
+happened" we definitely want the latter.
+
+It would be nice to include some indication as to the impact of the software
+in question. A light and breezy style, free from significant
+[attachment](https://en.wikipedia.org/wiki/Up%C4%81d%C4%81na), would be
+nice, if we can manage it.  Heavy editorializing and opinionated
+judgmentalism about how it all went down is for a different project. 
+
+If we've done our work here well enough, people who want details of who said
+what, and how far whose veins were popping out when it was said, they should
+be able to start from the links we've provided and see for themselves.
+
diff --git a/LICENSE.md b/LICENSE.md
new file mode 100644
index 0000000..bf64310
--- /dev/null
+++ b/LICENSE.md
@@ -0,0 +1,10 @@
+
+This collection is copyright D. Joe Anderson 2017.
+
+All content in this collection by D. Joe Anderson is released for use
+under the [CC-BY-NC-SA-4.0](https://spdx.org/licenses/CC-BY-NC-SA-4.0.html)
+license.
+
+Other contributions are copyright their original authors using the indicated
+licenses where different from the collection as a whole.
+