Trivial: Update http URL of MIT license to use https #12192

fwolfst · 2018-01-15T14:18:21Z

Replace many occurrences of the old (non-https and HTTP/301 moved permanently anyway) URL to MIT license by newer link.

(Archive) First_ attempt was:
In two steps, update the links as described in the issue.

First commit: sed everything.
Second commit: Fix whitespace syntactic sugar that got bitter due to different length of URLs.

maflcko · 2018-01-15T15:00:56Z

src/crypto/ctaes/ctaes.h

Should be submitted upstream for the ctaes subtree, if wanted

Good point, I do not know the codebase very well yet. Issued PR to ctaes in bitcoin-core/ctaes#13 .

morcos · 2018-01-16T14:09:30Z

@fwolfst Please see the notes on Scripted Diffs in doc/developer-notes.md.

Please note that there has been a large increase in PR activity recently (a good problem to have!) and reviewers are struggling to keep up, so simple refactoring, language changes or other cleanup sometimes don't get a lot of immediate attention.

maflcko · 2018-01-16T14:54:24Z

You could also help with review, if you feel like it. Due to the amount of open pull requests, there are some easier ones to get started.

Even with limited understanding of the code, just compiling them and passing in edge-cases until they break is useful.

https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Aopen+label%3ADocs
https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Aopen+label%3ATests
https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Aopen+label%3ARPC%2FREST%2FZMQ

fwolfst · 2018-01-24T19:19:56Z

@fwolfst Please see the notes on Scripted Diffs in doc/developer-notes.md.
@morcos Thanks for pointing that out, I'll happily do that. Sorry for being such a pita-noob, whats the suggested work flow now? Closing this PR and reopen a new one?

Edit Will figure that one out - will re-read CONTRIBUTE.md and just try if a changed commit message influences the PR.

fanquake · 2018-01-29T10:50:25Z

src/secp256k1/contrib/lax_der_parsing.c

Please send secp256k1 changes upstream.

Thanks for pointing that out. Issued in bitcoin-core/secp256k1#503 .

fanquake · 2018-01-29T10:50:42Z

src/univalue/gen/gen.cpp

Univalue changes also need to go upstream.

Thanks for pointing that out. Issued at jgarzik/univalue#47 .

fanquake · 2018-01-29T10:53:53Z

@fwolfst Please don't close PRs and open new ones with the same changes. For this to be merged, you'll need to remove any changes to sub-trees in this repository (you can open PRs with the changes upstream if you'd like).

Then rebase and update the commits to be proper scripted diffs, see developer-notes.

A large diff like this will likely be merged after a branch off.

maflcko · 2018-02-10T19:12:13Z

Needs rebase if still relevant

fwolfst · 2018-02-11T06:23:24Z

will do that next week

…

On Sat, Feb 10, 2018 at 8:13 PM, MarcoFalke ***@***.***> wrote: Needs rebase if still relevant — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12192 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANY7XmNYdqhXMOtKkrRfdjKc5pFEDYeks5tTepFgaJpZM4Reeff> .

laanwj · 2018-02-13T10:03:11Z

From a 'use https everywhere' perspective I agree with this change, but changing every single source file seems a bit much.

promag · 2018-02-13T10:19:34Z

New URL ACK:

curl -v http://www.opensource.org/licenses/mit-license.php
< HTTP/1.1 301 Moved Permanently
< Location: http://opensource.org/licenses/mit-license.php

curl -v http://opensource.org/licenses/mit-license.php
< HTTP/1.1 301 Moved Permanently
< Location: https://opensource.org/licenses/mit-license.php

curl -v https://opensource.org/licenses/mit-license.php
< HTTP/1.1 200 OK

Agree with @morcos regarding scripted diff.

@laanwj does this change conflicts with other branches?

laanwj · 2018-02-13T10:27:31Z

@laanwj does this change conflicts with other branches?

Depending on how github computes conflicts (I'm not sure if, and if so how much, lines of context it uses - but how easy this builds up a list of conflicts below is one omen), possibly every single one.

fwolfst · 2018-02-13T10:32:28Z

I will rebase soon and include a scripted_diff commit (I will have to figure out how this works WITHIN this PR). The target is moving a bit, because changes have already been accepted in included projects (jgarzik/univalue#47 and I guess bitcoin-core/secp256k1#503 will follow).

fwolfst · 2018-02-14T07:29:37Z

I am not git native yet, but I think 8d16208 comes close to what should be (have been) done:

I reset my branch, merged upstream and created a new "scripted" diff.

There are still some 70 occurences of the old URL, which I will gladly scripted-diff-replace once I get green lights here.

fanquake · 2018-02-14T11:09:50Z

@fwolfst 8d16208 is still modifying the univalue subtree.

fwolfst · 2018-02-14T12:36:12Z

@fanquake Dealt with in fwolfst@a164d7f . Thanks.

maflcko · 2018-02-14T13:18:02Z

utACK a164d7f6dd5df1dbb9a77c56a57350f469e4b2da

At this point you might as well bump the copyright headers altogether. Please add another commit with the dates bumped to 2018 (see ./contrib/devtools/README.md).

fwolfst · 2018-02-14T15:39:51Z

@MarcoFalke Yep, cool. Tough my preferred way to deal with the copyright extension would be the following: you create an issue for that and assign it to me - I'd personally prefer to keep that stuff in a separate PR, as it has a different class of legal implications, but if the majority thinks otherwise I'd give it a go.

fanquake · 2018-02-14T15:48:25Z

@fwolfst Creating additional issues isn't required. Bumping the year of all copyright headers is trivial, and easily verifiable. See #12062 & #9450 for examples. I'm not sure what you mean by legal implications?

fwolfst · 2018-02-14T16:10:34Z

Well its a legal statement indicating when (in certain countries) these (versions of the) files will enter the public domain. Anyway. Done.

maflcko · 2018-02-20T20:33:11Z

Needs rebase

fwolfst · 2018-02-21T07:01:28Z

@MarcoFalke Thanks for seeing that. Done. Now, needs merge ;)

maflcko · 2018-02-22T18:09:22Z

test/functional/rpc_signrawtransaction.py

Why this change?

My mistake. Glitch in my workflow after new rebase experience. Will fix soon. If I might ask: currently I replace old commits in this PR/my branch with hard resets and push -f, to keep changes small and honor the scripted_diff checks (except in last case, my apologies) - is that a correct thing to do?

Jup, correct. You can also check the scripted diffs with the ./contrib/devtools/commit-script-check.sh script.

fwolfst · 2018-02-23T08:42:23Z

Corrected in cdc7d3c .
And also, I adjusted the URL. The canonical URL (and the one linked already in Bitcoins README as well as from within the opensource.org site) is https://opensource.org/licenses/MIT .

curl --silent --head  https://opensource.org/licenses/mit-license.php -o -  | grep canon
Link: </licenses/MIT>; rel="canonical",</node/66>; rel="shortlink"

laanwj · 2018-02-23T10:45:37Z

And also, I adjusted the URL. The canonical URL (and the one linked already in Bitcoins README as well as from within the opensource.org site) is https://opensource.org/licenses/MIT .

Yup, good catch! If we're going to change this, let's be 100% sure we're using the correct address, and the one that is most likely to stay the same going forward.

Which makes me wonder (sorry for always being a heretic) - what is the motivation for an external link at all? We carry a copy of the license in the repository, after all. Is the answer to cover for individually copied files?

fwolfst · 2018-02-23T11:09:11Z

Gregory asked that as well and I had a good answer that I don't find in the archives - probably it was "moderated away". It'd find it odd if header stuff were to be removed, but would not consider it a serious issue to dramatize about. 1) On the opensource.org website you can get further links, more information, explanation and inspiration. 2) Like you mentioned: should you find the file out in the wild out of context (happens all the time ;) ) you know what you have, saves a google-query. Why not skip all the header stuff? 3) Its a convention, although questioned. I guess there would be some PRs trying to get it back it ("missing license headers"), because its so common. Btw afaik same is true for the copyright headers in many legislatives. They are not necessarily needed to protect your IP. It'd opt **for** the headers though, to make the statement that a conscious choice and responsability was taken, and that these decisions can be seen as part of a bigger picture.

…

On Fri, Feb 23, 2018 at 11:46 AM, Wladimir J. van der Laan < ***@***.***> wrote: And also, I adjusted the URL. The canonical URL (and the one linked already in Bitcoins README as well as from within the opensource.org site) is https://opensource.org/licenses/MIT . Yup, good catch! If we're going to change this, let's be 100% sure we're using the correct address, and the one that is most likely to stay the same going forward. Which makes me wonder (sorry for always being a heretic) - what is the motivation for an external link at all? We carry a copy of the license in the repository, after all. Is the answer to cover for individually copied files? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#12192 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANY7SQS1XuFIDPuEzPJWXy5qCZPqh-vks5tXpcbgaJpZM4Reeff> .

laanwj · 2018-02-23T11:37:35Z

Thanks. To be clear I'm not advocating for removing the headers completely! that would require an infinite amount of discussion which I'm not going to spend my time left on earth partaking in. I was just curious as to an external URL link, as it is both more[1] and less[2] self-contained at the same time.

*1 disambiguation of "MIT license" for individual files, as you say, without having to copy the whopping thing into every single file
*2 the link is external, so it could potentially change under us

But to be clear, keeping it like this is OK to me. utACK.
I've verified that commit 506c92ce208f2e620314dd9952516ebbd68b3f20 and cdc7d3ce48df4575ba1313a7225372008763c31b match the output of their scripts.

maflcko · 2018-02-23T13:52:59Z

Hmm, find . will recurse into .git and potentially corrupt the directory. Could you change that to git ls-files | xargs sed ..., please?

Sorry for mentioning that so late.

This commit deals with one part of bitcoin#12190 by replacing many occurrences of http://www.opensource.org/licenses/mit-license.php with https://opensource.org/licenses/MIT . A second commit could tackle the other occurrences where either "comment-star-boxes" (/* 80 chars */) are used or the URL appears in a different context. The src/univalue/ path is ignored, as it references https://github.com/jgarzik/univalue , where a similar issue is ady closed (jgarzik/univalue#47) and waiting to be included into this (bitcoin) repository. -BEGIN VERIFY SCRIPT- git ls-files | grep --invert-match 'src/univalue' | xargs sed -i \ -e 's,http://www.opensource.org/licenses/mit-license.php.$,https://opensource.org/licenses/MIT.,g' -END VERIFY SCRIPT-

laanwj · 2018-02-23T14:11:01Z

good point @MarcoFalke. I ran it on a temporary clone to avoid corrupting unrelated stuff such as depends downloads. But I did not think of git's internal state. `git ls-files` is much better.

Used the contrib/devtools/copyright_header.py script to extend Copyright in files edited in 2018. -BEGIN VERIFY SCRIPT- contrib/devtools/copyright_header.py update . -END VERIFY SCRIPT-

fwolfst · 2018-02-23T14:32:50Z

@laanwj Yes, you are right. Unfortunately the --exclude option of git ls-files seems to only be able to exclude untracked files.
But facepalm - messed up the commit message in 23f4029 (ady instead of already). Also there are still occurrences of the old URL in those shiny /* boxes */. If there is green lights, I'd like to change the commit message, get this merged and come back with the next step in a couple of days/weeks.

maflcko · 2018-02-25T18:50:18Z

utACK b3047f4

maflcko · 2018-03-22T19:05:55Z

@fwolfst Needs rebase

fanquake · 2018-04-08T12:44:34Z

Closing now that #12914 is open.

maflcko reviewed Jan 15, 2018

View reviewed changes

fwolfst mentioned this pull request Jan 15, 2018

Trivial: Update URLs of MIT license (http -> https) bitcoin-core/ctaes#12

Closed

fanquake added the Docs label Jan 18, 2018

fanquake changed the title ~~Trivial: Issue 12190: Update http URL of MIT license to use https~~ Trivial: Update http URL of MIT license to use https Jan 18, 2018

fanquake reviewed Jan 29, 2018

View reviewed changes

This was referenced Jan 29, 2018

Update links to MIT license (use https) jgarzik/univalue#47

Closed

Update links to MIT license (use https) bitcoin-core/secp256k1#503

Closed

fwolfst force-pushed the 12190-UPDATE_MIT_LINK_TO_HTTPS branch from 9c47171 to 8d16208 Compare February 14, 2018 07:23

fwolfst force-pushed the 12190-UPDATE_MIT_LINK_TO_HTTPS branch from 8d16208 to a164d7f Compare February 14, 2018 12:31

fwolfst force-pushed the 12190-UPDATE_MIT_LINK_TO_HTTPS branch from 3297f28 to 25ac012 Compare February 21, 2018 06:58

maflcko reviewed Feb 22, 2018

View reviewed changes

fwolfst force-pushed the 12190-UPDATE_MIT_LINK_TO_HTTPS branch from 25ac012 to 506c92c Compare February 23, 2018 08:27

fwolfst force-pushed the 12190-UPDATE_MIT_LINK_TO_HTTPS branch from cdc7d3c to 23f4029 Compare February 23, 2018 14:13

scripted-diff: update copyright headers

b3047f4

Used the contrib/devtools/copyright_header.py script to extend Copyright in files edited in 2018. -BEGIN VERIFY SCRIPT- contrib/devtools/copyright_header.py update . -END VERIFY SCRIPT-

maflcko added the Up for grabs label Apr 6, 2018

practicalswift mentioned this pull request Apr 8, 2018

scripted-diff: Remove redundant license reference (HTTP URL) #12914

Closed

fanquake closed this Apr 8, 2018

fanquake removed the Up for grabs label Apr 8, 2018

bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021

Trivial: Update http URL of MIT license to use https #12192

Trivial: Update http URL of MIT license to use https #12192

Uh oh!

Conversation

fwolfst commented Jan 15, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fwolfst Jan 15, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

morcos commented Jan 16, 2018

Uh oh!

maflcko commented Jan 16, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fwolfst commented Jan 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fanquake commented Jan 29, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maflcko commented Feb 10, 2018

Uh oh!

fwolfst commented Feb 11, 2018 via email

Uh oh!

laanwj commented Feb 13, 2018

Uh oh!

promag commented Feb 13, 2018

Uh oh!

laanwj commented Feb 13, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fwolfst commented Feb 13, 2018

Uh oh!

fwolfst commented Feb 14, 2018

Uh oh!

fanquake commented Feb 14, 2018

Uh oh!

fwolfst commented Feb 14, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maflcko commented Feb 14, 2018

Uh oh!

fwolfst commented Feb 14, 2018

Uh oh!

fanquake commented Feb 14, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fwolfst commented Feb 14, 2018

Uh oh!

maflcko commented Feb 20, 2018

Uh oh!

fwolfst commented Feb 21, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fwolfst commented Feb 23, 2018

Uh oh!

laanwj commented Feb 23, 2018

Uh oh!

fwolfst commented Feb 23, 2018 via email

Uh oh!

laanwj commented Feb 23, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fwolfst commented Jan 15, 2018 •

edited

Loading

fwolfst Jan 15, 2018 •

edited

Loading

maflcko commented Jan 16, 2018 •

edited

Loading

fwolfst commented Jan 24, 2018 •

edited

Loading

fanquake commented Jan 29, 2018 •

edited

Loading

laanwj commented Feb 13, 2018 •

edited

Loading

fwolfst commented Feb 14, 2018 •

edited

Loading

fanquake commented Feb 14, 2018 •

edited

Loading

laanwj commented Feb 23, 2018 •

edited

Loading