License and Publish Black Lightning

Issue #166 closed
Lewis Eason
created an issue

It is in the long-term interests of this project and the EUTC for reasons of tinkering to select a suitable free software license for this codebase and make the source publicly available - perhaps with a word on how we're unlikely to be of much help in the future.

By opening up the codebase in a way that protects it (and ourselves) we extend the longevity of the project and provide a starting point/how-not-to guide (depending on your viewpoint).

The purpose of opening this issue is to begin the discussion on how to do this, and a couple of things immediately spring to mind:

  1. License - which one? I propose either GPLv3 or MIT. MIT is much simpler, but the 'Share Alike' aspect of the GPL is appealing.

  2. Review. There may be parts of the git tree that we wish to "rewrite" in the interests of removing confidential information. I'm not sure if there's anything in particular, but I seem to remember there being some discussion of this before.

  3. Documentation. Only a little bit, I promise. A short abstract explaining the scope and goals of the project, and enough information to get up and running with a working environment. Lower the barrier to entry...

Have I forgotten anything?


Edit: Please feel free to share this with anybody who may be interested in this project/has expressed an interest in the past.

Comments (13)

  1. Hayden Ball

    The only secrets I'm aware of are:

    • Twilio (which has recently been removed from config/environments/production.rb)
    • Twitter (in app/helpers/twitter_helper.rb)
    • Password in config/deploy.rb

    While the Twilio one has been removed, it is still in history.

    I propose:

    • We remove Twilio support entirely (it's broken, and has no credit)
    • Twitter is moved to secrets.yml (as per Rails 4.2 recommended practice)
    • History is rewritten for the entire prod env file (there isn't much non-standard) and Twitter (again, little value in history)
    • Capistrano config is updated to use keys (as per recommended practice). I propose we simply change the bedlamtheatre user password rather than rewriting history for this, as there is some useful history.

    Is GPL compatible with MIT (which Rails and many libraries are licensed under)? I'm always a fan of 3-Clause BSD, but it isn't share alike.

  2. Lewis Eason reporter

    Sounds good. In particular, maintaining history of the deploy is probably useful.

    The MIT license states:

    Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

    The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software

    Since MIT is GPL-compatible[1] and we don't distribute any Rails code (merely reference it) there shouldn't be any issues. In the interests of being explicit, we could include license information for any 3rd party code we ship.

    I suggested MIT as Rails uses it (and it's really short). I like the conditions enforced by GPL, but am in no way married to the idea - short and understandable may win out here?

  3. Hayden Ball

    Just remembered, I think XTS credentials were also in production.rb - if not, they are in there somewhere.

    Will comment on licensing in a bit - mid something else right now!

  4. Lewis Eason reporter

    Thinking of killing off some branches (making rewriting history a bit easier).

    Are we ever likely to do anything with the following that is worth actually keeping (aka would merging it be more effort than starting again):

    • bootstrap3
    • Stripe
    • StaffingEvents
    • snails
  5. Hayden Ball

    Snails was merged...

    I think the other 3 can go - perhaps keep the Stripe branch (unless there are any secrets in there) because that could be useful for reference.

  6. Lewis Eason reporter

    This is part brain-dump and part documentation for future reference - for removing Twitter info; (I haven't done this yet, but this is the plan):

    # Download the required perl scripts
    git clone .
    # Fetch a (bare) copy of the repository
    git clone --mirror
    cd black_lightning.git
    # Store a list of tags and their commit hashes/messages
    git show-ref --tags | sed 's#refs/tags/##' | perl ../ > ../tags
    # Take a copy of the file as it currently stands
    git show HEAD:app/helpers/twitter_helper.rb > ../twitter_helper.rb
    # Remove it from all commits in the entire tree
    git filter-branch --tree-filter 'rm -f app/helpers/twitter_helper.rb' --tag-name-filter cat -- --all
    # Tidy up
    rm -rf refs/original
    git gc --prune=now --aggressive
    # Now using the list of tags from earlier, try to match each commit message back to its tag again
    cat ../tags | perl ../
    # If any fail (merges seem to), do so manually:
    #   git log --all --grep '<COMMIT_MESSAGE>' --oneline
    #   git tag -a <BRANCH> <NEW_HASH> -m "<COMMIT_MESSAGE>"
    # Verify that the file is no longer present in the repository
    git log --all --follow -- app/helpers/twitter_helper.rb
    # Clone our bare repo
    cd ..
    git clone black_lightning.git
    # Move the backup into the non-bare repo
    mv ../twitter_helper.rb app/helpers/twitter_helper.rb
    #   vim app/helpers/twitter_helper.rb
    #   git commit -a
    #   git push
    # The bare repo is now the canonical version and should be force-pushed back
    # onto master (rewriting all commits, tags and branches)
    cd ../black_lightning.git
    git push origin # --force (presumably)
  7. Log in to comment