Remove files with contributions from the people where no approval of the licensing terms was received

[est31]

A while back, my RFC to relicense this repo under a dual Apache2/MIT license has been merged. Since then I've opened five issues to track approval of the new licensing terms by the various contributors to this repository and gotten the approval of almost every contributor! Only for the contributions of 7 people I was unable to obtain approval, either because they didn't respond to my contact attempts, or because they were unable to give me approval.

The relevant commits without approval are:

Barosl Lee (3):
      568ed6a75653b75dcd4f36a102afa59cd73f018f
      5b9a48d4ba1e314ce7d4e97d06b91c4a9d6e7865
      be5eb6f88e3e89059917f168123ba10dd2900f43

Benjamin San Souci (1):
      938ff6dac5c19dd6830e3400f6799bfc174b7950

Carl Lerche (3):
      1e5c6030cf48a3021b59dc898c7d0c8f7ec12bcf
      50ff468f9b1d7bafb912374e7df2c51329112d6e
      a17aa3563a07fdedd301faa783a92c9212831eb2

Clark Gaebel (3):
      a1d6e9efc5e264de49ea25b8d5d161972f5105b9
      ab6265e31f7748a8bfd4b7f9451935f677f011be
      d54bd9b55af927b7b9f27c4a5a1a9cb44c91aa53

Sean Patrick Santos (12):
      2d2d81aecdc862f5e2120f03f2f9f0d38534e7d3
      7a3df4d89fd4150aefaea0f23d176baada27c472
      c4024520b3725f1457f311cd6f9984f3863dc9e1
      734e123838907397e689084360012b36905398ed
      e58a632345654f8041fb390be062d4e080d46d34
      2c5876ffe70d5a1395218b275eb7eb90cf7afa78
      d4eec1f72cb36eaf7de651d37665d40e22dda1c1
      8f975bdb96bbcce362c7171feeebca82909a8f6b
      3b5abbfd05049b38dce501f862bcf37b71ad587e
      4ba33ee94a14cb40411c283f9ad4bff7bf8ec0e1
      1ad497df2877d46a85fa256c63797e3d00c24491
      992550b1ac1869c3ef0591ac64c55ca961656f2c

Tom Jakubowski (1):
      8d322ada15e05e0b5640c2dd95a4d3df3b8542c3

Jakub Bukaj (1):
      c539b10a99c59bb96ba4657ff9263e2074aaa637

These commits have touched the following files:

Barosl Lee:
text/0000-rename-connect-to-join.md
text/0000-panic-safe-slicing.md

Benjamin San Souci:
text/0114-closures.md

Carl Lerche:
text/0000-move-thread-local-to-std-thread.md
text/0517-io-os-reform.md

Clark Gaebel:
active/0000-smaller-refcounts.md
text/0000-collections-reform-part-2.md

Sean Patrick Santos:
text/0000-new-array-repeat-syntax.md
0601-replace-be-with-become.md
text/0601-replace-be-with-become.md
text/0195-associated-items.md

Tom Jakubowski:
active/0031-better-temporary-lifetimes.md

Jakub Bukaj:
text/0000-feature-gate-box-patterns.md

Additionally, Clark Gaebel has touched active/0000-smaller-refcounts.md, but it was moved to a rejected directory in commit 7443c30 and removed from the repository in commit abd6134.

This PR removes the current incarnations of those files, ordered by contributor, except of text/0114-closures.md which only received typo fixes by the relevant commit. Here I've chosen a git revert instead.

If in the future approval can be obtained from these contributors, I hope that their changes can be applied again.

[est31]

cc @aturon @joshtriplett

[SimonSapin]

Removing accepted RFCs from the repo seems very very wrong to me. Much worse than having a small subset of files with an unclear license.

[nagisa]

I would just add a licence: All rights reserved Author1, Author2, ... to the files as well.

[est31]

My PR doesn't remove the RFCs from the repo, only from the master branch. If you go back in history, the files are still available. You can still link to them, inspect them, etc. A full clone of the git repo will still contain the files as blobs. You can do deletion from the history as well with git (requiring force pushes and breaking sha1 hashes), but it's not what I'm proposing in my PR.

Removing them from the master branch will mean that we prevent accidental infringement like e.g. if we opt to host a rendered version of the RFCs on doc.rust-lang.org. IANAL, but from my guess it seems that hosting them through Github Pages (like #2192 proposes it) would be okay as it's covered by the license the contributors granted through the TOS to Github, while hosting them on EC2 where doc.rust-lang.org is might get us into trouble already.

[SimonSapin]

Sure they’re in the git history, but IMO that’s not enough. These RFCs still describe aspects of Rust that the community has discussed and found consensus on, and they still shape it. They should be kept available together with the rest of RFCs, and existing links to github’s rendering of the master branch should not be broken.

[est31]

@SimonSapin what about adding stubs like the ones I've just pushed? This will allow hosting in different places and make best use of the limited possibilities we have by pointing to Github.

[Mark-Simulacrum]

I think we'd need to talk to Mozilla's legal. I'd hope that something like what @nagisa proposes with an explicit statement that certain people possess rights to particular files would be possible. I am against removing merged RFCs from the repository, even if they remain in git history. RFCs are intended to be "permanent" so to speak...

[joshtriplett]

Removing accepted RFCs is not OK, especially after this little time. A relicensing process is hard, and we shouldn't skip steps. First of all, for the people who simply haven't responded, we should both try other contact methods and give more time. And for the people who are "unable" to give approval, we should work with them to figure out the issue there. We've gone years with the RFC repository not having a clear license; we can go a few more months while we do this the right way.

[est31]

@joshtriplett we can chat about this in private. Are you using IRC?

[est31]

Talking to @joshtriplett has convinced me to give this more time and more contact attempts before issuing further steps.

[joshtriplett]

Thanks for your work on this, @est31; please let us know if you need further help.