scancode-toolkitを使う
びっくりするほど日本語の記事がない。これ結構有名だよね？そうだよね？
https://github.com/nexB/scancode-toolkit
それではやっていきます。
概要
READMEを見ると、意外と色々できそうだと思わされる。
なぜScanCodeを使うのか？
ScanCodeはスタンドアロンのコマンドラインツールとして、インストール、実行、CI/CD処理パイプラインへの組み込みが簡単に行えます。Windows、macOS、Linuxで動作します。 ScanCodeは、Eclipse Foundation、OpenEmbedded.org、FSFE、FSF、OSS Review Toolkit、ClearlyDefined.io、RedHat Fabric8 analyticsなどのプロジェクトや組織で使用されています。 ScanCodeは、ソースコードとバイナリファイルの両方でライセンス、著作権、パッケージマニフェスト、直接依存関係などを検出します。 ScanCodeは最も正確なライセンス検出エンジンを提供し、近似正規表現パターンや確率的検索、編集距離、機械学習に頼るのではなく、ライセンステキストのデータベースとコードの完全な比較（差分や赤線比較とも呼ばれます）を行います。 Pythonで書かれたScanCodeは、プラグインを使って簡単に拡張することができ、新しいスキャナ、データサマリ、パッケージマニフェストパーサ、新しい出力を提供します。 スキャン結果はJSON、HTML、CSV、SPDXとして保存することができます。ScanCode Workbench GUIアプリを使用して、スキャン結果や統計情報、グラフィックを確認したり、表示したりすることができます。 ScanCodeは積極的にメンテナンスされており、ユーザーと貢献者のコミュニティが成長しています。 ScanCodeは20,000以上の自動化されたテストスイートでテストされています。
ほう。 ドキュメントはこちらにある。なかなかごついね。日本語はないようだ。
https://scancode-toolkit.readthedocs.io/en/latest/
インストール
丁寧にPythonの入れ方が書いてある。 https://scancode-toolkit.readthedocs.io/en/latest/getting-started/install.html#prerequisites
$ sudo yum install python3.6-devel zlib bzip2-libs xz-libs libxml2-devel libxslt-devel
やってみたらなんかpython3.6-develが入らなかった？っぽいので、一応自らpythoin3を入れておく。
$ sudo yum install -y python3 python3-devel
ではscancode-toolkitを入れていこう。 https://scancode-toolkit.readthedocs.io/en/latest/getting-started/install.html#installation-as-an-application-downloading-releases
GItHub Releaseからzipを取ってきて展開するだけっぽい。 Releases · nexB/scancode-toolkit · GitHub
けどなんかバージョン21系と3系があるっぽい？なにこれ。 とりあえずドキュメントにある3.1.1を使おう。そうしよう。
$ curl -O -L https://github.com/nexB/scancode-toolkit/releases/download/v3.1.1/scancode-toolkit-3.1.1.zip $ unzip scancode-toolkit-3.1.1.zip $ ls scancode-toolkit-3.1.1 $ cd scancode-toolkit-3.1.1 $ ls AUTHORS.rst apache-2.0.LICENSE docs scancode-toolkit.ABOUT CHANGELOG.rst appveyor.yml etc scancode.bat CONTRIBUTING.rst azure-pipelines.yml extractcode setup.cfg ISSUE_TEMPLATE.md cc0-1.0.LICENSE extractcode.bat setup.py MANIFEST.in codecov.yml plugins src NOTICE configure pyvenv.cfg thirdparty PKG-INFO configure.bat samples README.rst conftest.py scancode
とりあえずよく分からんがREADMEに書いてあったQuick Startのコマンドを叩く。
./scancode -clip --json-pp - samples * Configuring ScanCode for first use... （省略） OSError: libbz2.so.1.0: 共有オブジェクトファイルを開けません: そのようなファイルやディレクトリはありません
はぁ？って感じなんですけど。 ドキュメントを見たところ、venvやれって書いてある。これかな。
https://scancode-toolkit.readthedocs.io/en/latest/tutorials/how_to_run_a_scan.html
$ python3 -m venv venv $ source venv/bin/activate (venv) $ pip install --upgrade pip (venv) $ pip install scancode-toolkit[full]
スキャン対象はsamplesというフォルダ。まずこのフォルダ内にあるアーカイブファイルを展開する必要があるらしい。
$ extractcode samples
同じエラーで止まった。とりあえずextractはスルーしよう。
スキャン
ということでスキャンだ。以下のコマンドで、sample.jsonというファイルに結果が吐かれるっぽい。
$ scancode -clpeui -n 2 --ignore "*.java" --json-pp sample.json samples Setup plugins... Collect file inventory... Scan files for: info, licenses, copyrights, packages, emails, urls with 2 process(es)... [####################] 0 Scanning done. Summary: info, licenses, copyrights, packages, emails, urls with 2 process(es) Errors count: 0 Scan Speed: 2.12 files/sec. 80.28 KB/sec. Initial counts: 44 resource(s): 33 file(s) and 11 directorie(s) Final counts: 37 resource(s): 26 file(s) and 11 directorie(s) for 985.34 KB Timings: scan_start: 2021-02-21T111455.169845 scan_end: 2021-02-21T111508.529217 setup_scan:licenses: 1.06s setup: 1.06s scan: 12.27s total: 13.38s Removing temporary files...done.
とりあえずスキャンは通った。 まぁとりあえずスキャンしたjsonを見る。以下は一部抜粋。
{
"path": "samples/JGroups/LICENSE",
"type": "file",
"name": "LICENSE",
"base_name": "LICENSE",
"extension": "",
"size": 26430,
"date": "2019-02-11",
"sha1": "e60c2e780886f95df9c9ee36992b8edabec00bcc",
"md5": "7fbc338309ac38fefcd64b04bb903e34",
"sha256": "a190dc9c8043755d90f8b0a75fa66b9e42d4af4c980bf5ddc633f0124db3cee7",
"mime_type": "text/plain",
"file_type": "ASCII text",
"programming_language": null,
"is_binary": false,
"is_text": true,
"is_archive": false,
"is_media": false,
"is_source": false,
"is_script": false,
"licenses": [
{
"key": "lgpl-2.1",
"score": 100.0,
"name": "GNU Lesser General Public License 2.1",
"short_name": "LGPL 2.1",
"category": "Copyleft Limited",
"is_exception": false,
"owner": "Free Software Foundation (FSF)",
"homepage_url": "http://www.gnu.org/licenses/lgpl-2.1.html",
"text_url": "http://www.gnu.org/licenses/lgpl-2.1.txt",
"reference_url": "https://scancode-licensedb.aboutcode.org/lgpl-2.1",
"scancode_text_url": "https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/licenses/lgpl-2.1.LICENSE",
"scancode_data_url": "https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/licenses/lgpl-2.1.yml",
"spdx_license_key": "LGPL-2.1-only",
(省略)
Visualize
Visualize resultをした方が良さそうだ。
https://scancode-toolkit.readthedocs.io/en/latest/tutorials/how_to_visualize_scan_results.html
ScanCode Workbenchなるものが必要らしい。
https://github.com/nexB/scancode-workbench/releases/tag/v3.1.1
$ curl -O -L https://github.com/nexB/scancode-workbench/releases/download/v3.1.1/ScanCode-Workbench-linux-x64-3.1.1.tar.gz $ tar -zxvf ScanCode-Workbench-linux-x64-3.1.1.tar.gz $ cd ScanCode-Workbench-linux-x64-3.1.1 $ ./ScanCode-Workbench ./ScanCode-Workbench: error while loading shared libraries: libXss.so.1: cannot open shared object file: No such file or directory
よく分からないけどここの情報を参考に必要そうなパッケージをインストールする。 https://sh-yoshida.hatenablog.com/entry/2016/11/30/002247
$ yum install libXScrnSaver $ ./ScanCode-Workbench
起動したー！ けどjsonのインポートとかができない。意味が分からない。
気が向いたらまた遊んでみよう。
askalonoを使う
というわけでやっていきます。
https://github.com/jpeddicord/askalono
Rustのパッケージがあるようなので、入れていきます。 Rustが入ってない場合はインストールします。
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh cargo install askalono-cli
なんかワケわからんエラーが出たな。
error: linker `cc` not found | = note: No such file or directory (os error 2) error: aborting due to previous error error: could not compile `libc` To learn more, run the command again with --verbose. warning: build failed, waiting for other jobs to finish... error: linker `cc` not found | = note: No such file or directory (os error 2) error: aborting due to previous error error: failed to compile `askalono-cli v0.4.3`, intermediate artifacts can be found at `/tmp/cargo-install0FR8B7`
なにこれ。 gccが必要との噂。 https://qiita.com/ismt7/items/a6b17b01b56f098b2dd5
いうことで、
yum install gcc -y
はい。成功しました。
$ askalono -V askalono 0.4.3
ではidしてみましょうか。git clone してきたgsonちゃんのLICENSEファイルをidしてみます。
$ askalono id LICENSE License: Apache-2.0 (original text) Score: 0.999
おおお。良いですね。 ではクロールしてみましょう。
$ askalono crawl . ./LICENSE License: Apache-2.0 (original text) Score: 0.999 ./gson/LICENSE License: Apache-2.0 (original text) Score: 0.999
jsonでも出せますよと。
$ askalono --format json crawl .
{"path":"./LICENSE","result":{"score":0.9993655,"license":{"name":"Apache-2.0","kind":"original","aliases":[]},"containing":[]}}
{"path":"./gson/LICENSE","result":{"score":0.9987318,"license":{"name":"Apache-2.0","kind":"original","aliases":[]},"containing":[]}}
気持ち良い。 READMEを見た感じ、optimizeフラグをつけるとファイルヘッダのライセンスとかも検知できる的なこと書かれてるのでやってみた。
Gson.java
/* * Copyright (C) 2008 Google Inc. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.google.gson; import java.io.EOFException; import java.io.IOException; import java.io.Reader; （以下、省略）
これが検知できるかどうか。
$ askalono id Gson.java Error: Confidence threshold not high enough for any known license $ askalono id --optimize Gson.java Error: Confidence threshold not high enough for any known license
できないじゃん。まぁいいか。
ライセンスのデータはSPDXらしい。READMEには以下が記載あり。
Where do the licenses come from? License data is sourced directly from SPDX: https://github.com/spdx/license-list-data
オープンソーススキャンの歴史みたいな記事の翻訳
WhiteSourceのとある記事が面白かった。ので、日本語にしてとっておきたいと思います。
それがこちら。
まだオープンソースを識別するためにオープンソースコードスキャナを使用していますか？もっと良い方法があります
それでは、以下が翻訳となります（DeepL先輩にお世話になってます）。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
"オープンソースは無料" なぜコンマを反転させているのかと聞かれるかもしれません。ほとんどの組織が、オープンソースは自由に使用、変更、再配布することができますが、...それには許諾されたライセンスを遵守するという条件がつきものだということを理解していると思います。
現在では、オープンソース監査により、多くの組織がオープンソースライセンスの法的要件に精通するようになりました。オープンソース監査は通常、M&A、IPO、または新規投資ラウンドの場合に発生し、外部関係者がレビューのためにオープンソースのインベントリレポートを要求します。その他のケースでは、法律顧問、セキュリティ監査人、コンプライアンス担当者など、さまざまなチームから内部要件が提起されることもあります。
しかし、この種の情報を手動で収集することは、特に製品にオープンソースを多く使用している組織では、非常に時間がかかります。結局のところ、最近ではオープンソースがコードベース全体の 60 ～ 80% を占めており、オープンソースのインベントリを最初から監督し、管理する必要性と価値があることが明らかになっています。
3 年前までは、ほとんどの企業は、オープンソースのスキャンツールを使用して定期的に監査を実施することで、オープンソースの使用状況が準拠していることを確認したいと考えていました。しかし、近年では、ほとんどのオープンソース コード スキャナがアプローチを変更したり、顧客基盤を失ったりするなど、市場に目に見える変化が見られるようになりました。
すべての始まり
組織のオープンソース監査を支援するために、Black Duck Softwareという新興企業が、2002年に最初のオープンソーススキャンソリューションを発表しました。その後すぐに、Protecode、Palamida、Open Logicなど、オープンソースの発見という課題を克服するためにオープンソースコードスキャナを提供するベンダーが加わりました。一般的に、これらのオープンソーススキャナは、コードをスキャンして、オープンソースコンポーネントに含まれるコードに類似したコードの断片（「スニペット」とも呼ばれる）を識別することができます。ユーザーはコードの類似性を警告し、それぞれの警告を個別に確認する必要がありました。
当初、オープンソーススキャナは、組織がオープンソースのインベントリを監視・管理する方法に革命をもたらしたように見えました。しかし、オープンソース スキャナには重大な欠陥があり、コードベースのスキャンは当初考えられていたほど簡単で自動化されたものではないことに気づくまでにはそう時間はかかりませんでした。
スキャナベースのオープンソースライセンスとセキュリティ管理ソリューションの3つの落とし穴
オープンソース管理のプロセスを容易にする代わりに、オープンソーススキャナはより多くの課題をもたらしているかもしれません。以下では、このソリューションの3つの主な落とし穴を強調しています。
落とし穴1: 終わらない偽陽性の物語
オープンソーススキャナを使用する際に発生する主な課題の1つは、「偽陽性」アラートが大量に生成されることです。これらのアラートは、スニペットと一致しているように見えましたが、よく見ると、実際にはオープンソースコンポーネントの一部ではないことが判明しました。これらの誤検知はオープンソースのスキャンソリューションによってフラグが立てられ、開発チームによって除外されます。
あなたは、「ここにもここにもいくつかの誤検出があるかもしれない」と思うかもしれません。大多数が正しければ」と思うかもしれませんが、実際のところ、製品に使用されているオープンソースコンポーネントの総数が限られている場合、これらの誤検出は通常、管理可能な程度です。しかし、長年にわたり、オープンソースコンポーネントは指数関数的に増加しています。当社のデータベースだけでも、Java、Ruby、Pythonなどの言語の1億5500万以上のオープンソースコンポーネント（ソースとバイナリの両方）と、C/C++、Javascript、PHP、ObjectiveCなどの言語の110億のオープンソースファイルが存在します。これだけ多くのオープンソースコンポーネントが開発チームに提供されているのですから、スニペットが一致することは保証されています。偶然と言えば、何千ものスニペットが存在することになります（大げさではありません！）。
要するに、これらの偽陽性をふるいにかける作業は、非常に退屈で時間のかかる作業になります。
落とし穴2: アジャイルSDLCプロセス? オープンソースのスキャナではダメ
落とし穴1は、オープンソース コンポーネントのスキャンに時間がかかるという側面を明確に強調しています。これにより、ピットフォール2にスポットライトが当たります。オープンソースコンポーネントのスキャンは、継続的に行うことはできません。今日の時代にあって、ソフトウェア開発チームは、より頻繁に、より厳しい締め切りの下で新しいバージョンをリリースすることで、SDLCの俊敏性を高めようと、これまで以上に努力しています。しかし、この加速されたペースは、オープンソースのスキャナによって不本意に停止されてしまいます。自動化されたオープンソースのスキャンプロセスは、完了までに最大数週間かかることがありますが、これには落とし穴1（アラートのレビューが非常に（非常に）長い）が続きます。組織がウォーターフォール開発モデルを使用している場合でも、リリーススケジュールに大幅な遅延が生じる可能性があります。
コードのスキャンが完了するのを辛抱強く待っていたとしましょう。オープンソースのコンポーネントが、組織のポリシーに沿っていないライセンスで使用されていることがわかったらどうしますか? あるいは、深刻なセキュリティ上の脆弱性を持つコンポーネントを発見したらどうでしょうか？このような結果が遅れると、問題のあるコンポーネントの削除に集中しなければならないため、敏捷性が損なわれる可能性があります。結論から言うと、このような作業方法では、敏捷性とスピードが危険にさらされます。
落とし穴その3: セキュリティ脆弱性は時間が肝心
最後になりましたが、最後に挙げたのは、落とし穴その3「セキュリティの脆弱性」です。セキュリティの脆弱性が知られるようになったら、できるだけ早く修正することが重要であることは、潜在的な攻撃者がその脆弱性を悪用する絶好の機会であるということを、私たちは誰もが何らかの形で学ぶようになりました。これは、プロプライエタリなコードにもオープンソースコードにも当てはまります。残念ながら、スキャナベースのパラダイムでは、オープンソースの脆弱性を知るのは、次にスキャンを実行したときだけで、これはすでに説明したように、数ヶ月後になる可能性があります。さらに悪いことに、ソリューションがオンプレミスで展開されている場合は、データベースが更新されるまで、その脆弱性に気づくことができません。結論から言うと、ソリューションが継続的でない場合（オープンソースのスキャナを使用している場合、これはあなたにも当てはまります！）、あなたの顧客はずっとずっと長い間、脆弱性のままになってしまいます。
オープンソーススキャナではないなら...何が必要か？
オープンソース スキャナが導入された当初は、優れた主要なソリューションであったかもしれませんが、アプリケーションへのオープンソース コンポーネントの採用がますます増加していることや、今日の組織の敏捷性とペースに合わせて、オープンソース スキャナを採用することはできません。
オープンソースのコンポーネントを適切に管理することは、それほど面倒なことではありません。効果的で時間を節約し、最も重要なことは、オープンソースの使用状況を管理するための継続的なアプローチを提供する新しいソリューションが登場して久しいのです。最初のアジャイルなオープンソース管理ソリューションは、2011年に WhiteSource によって導入されました。実際にコードを一行ずつスキャンすることなく、リポジトリやビルド内のすべてのオープンソース コンポーネントのデジタル署名を計算できるプラグインが利用できます。これらのシグネチャは WhiteSource の包括的なデータベースと相互参照され、すべての依存関係を含むすべてのオープンソース コンポーネントを識別し、ライセンス、セキュリティ脆弱性、新しいバージョン、品質問題に関連する洞察力のある実用的な情報を提供します。
WhiteSource がこの新しいアプローチを開拓して間もなく、他の多くの企業が後に続き、このテクノロジーの背後にある膨大なメリットに気付きました。時間のかかる何千もの誤検出、長いスキャン期間、セキュリティの脆弱性に対するリスクの高い暴露ウィンドウの時代は終わりました。このソリューションの利点を以下の画像にまとめました。
アジャイルなオープンソース管理に向けて前進する時が来た
オープンソーススキャナは、敬意を持って安らかに眠る必要があることを認め、オープンソース管理を左にシフトさせるために開発された新世代のソフトウェア構成分析ツールに移行する時が来たのです。
今日のアジャイル開発環境では、オープンソースのコードスキャナに頼り続けることはできません。ウォーターフォールモデルに従っている人にとっては、新しいツールは開発チームやDevOpsチームの労力を大幅に軽減し、より多くの機能を提供し、時間の何分の一かを消費します。セネカがかつて言ったように、「すべての新しい始まりは、他の始まりの終わりから来る」。
Twitter APIを使うのでメモっておく
というわけでメモっておく。
手順
参考にしたのはこちら。サイオスさん。ありがとうございますです。
この手順とだいたい同じだった。
んで助言通り、Twitterアカウントには電話番号を設定しておく必要があるので事前にやっておいた方が良い。
申請内容
いろいろ申請内容を記載する必要がある。
以下のとおり記載した。
- 「Twitter開発者ツールを使用する主な理由は何ですか？」→Building Tools for Twitter users.
- 「住んでいる国とニックネームを書いてください。」→Japan daicon
さらに以下５つの質問に回答する必要があった。質問と回答はそれぞれ以下（サイオスさんのとだいぶ一緒）。
①
Twitterのデータおよび/またはAPIをどのように利用する予定なのか、英語で説明してください。回答が詳細であればあるほど、レビューや承認がしやすくなります。
→I want to get popular posts on twitter. And I would like to investigate the characteristics of it. Furthermore, I would like to make a new post based on that feature. The posting frequency is not decided.
②
Twitterのデータを分析する予定はありますか？
→yes
→I want to analyze tweets from famous accounts and popular tweets. And I would like to investigate its characteristics.
③
→yes
これらの機能をどのように利用する予定かを記載してください。
→My application uses a tweet function. Perhaps it also uses the like feature. The main function is the tweet function.
④
→yes
Twitterのコンテンツに関するツイートおよび/またはデータが、Twitter以外の場所でどのように表示されるかを記載してください。
→Popular tweets are displayed on websites, chat tools, smartphone apps, etc. The display frequency has not been decided.
⑤
あなたの製品やサービス、分析によって、Twitterのコンテンツや派生情報が政府機関に提供されることはありますか？
→no
申請を出す
上記で申請を出した。
審査はどれくらいかかるか分からんが、待ち。いつかメールが来る。
APIキーの取得
サイオスさんの記事に書いてなかったっぽいので、こちらを見た。
GitHubで共有アカウントを複数人で使っていいの？
調べなきゃいけなくなったので書いておきます。
GitHubで共有アカウントを使う？
こんなことやる奴がいるのか？と思うかもしれませんが、いることを前提に書かせていただきます。
要は複数人で一つのアカウントを使うというアレです。なんとも問題が起きそうな気しかしませんね。
GitHubの規則
ログインを使用できるのは 1 人だけです。つまり、1 つのログインを複数の人で共有することはできません。
という文言がある。うん、ルールとしてもダメですね。ハイ終了。もうめんどくさいからこれで説得しよ。
そもそも共有アカウントはやめようよ
まぁあまり詳しく書きませんが以下などにも書かれているとおり、そもそも共有アカウントはやめましょう。
結局GitHubのアカウントは会社と個人でまとめるべきか？
考えなきゃいけなくなったので調べたことを書いておこうと思います。
GitHubのルールと対応事例
有名な事例としては以下がある。
GitHub利用規約では以下のような記載がある。
1 人の個人または 1 つの法人が複数の無料「アカウント」を保持することはできません
本件について、上記記事では次のように記されている。
GitHub社のソリューションエンジニアであるikeike443氏に確認していただきました。 会社用に新たに作成したアカウントは有料GitHub組織に所属しているが、そのアカウント自体は無料アカウントであるため、この規約に準拠していないと返事をいただきました。またGitHubというサービス自体マルチアカウントで使うような設計になっていないため、GitHub社としてはアカウントの一本化を推奨するとのことでした。
要は、無料アカウントを同一人物が個人用＆会社用でそれぞれ持ってしまうのは利用規約に非準拠であるという話だ。
また、GitHubからはアカウントをマージする手順なんかも出ており、
ここには以下のように、複数アカウントを持つことが非推奨である旨が記載されている。
「お勧めします」という文言が気になるが、まぁGitHubとしてはやはりアカウントの一本化が推奨であるということは間違いがないだろう。
これに対する皆さんの声
実際のところ、無料アカウントを個人と会社で使い分けているところは存在していると思う。
例えば以下のような記事もあるくらいだから、皆さんどうなんだ？と思ったりする。
ということで、色々と世間の声を確認。
GitHubの親会社、Microsoft社員さんからは以下のとおり。
マイクロソフト社員もGitHubの利用では個人アカウントを使っています。個人アカウントでマイクロソフトのOrganizationに参加、二要素認証を強制、って感じです。 / 全社的に会社用GitHubアカウントを廃止した件 https://t.co/0NKrwEd8cn
— Toru Makabe (@tmak_tw) 2019年4月11日
うむ。やはりそうなのですねーという感じ。
色々とある意見の中で個人的に気になったのは、「私用アカウントを会社に紐づけて身バレしたくないのだが？」という点。これについては元記事のFAQで回答が書かれていた。
Ｑ. 私用アカウントを会社に紐づけて身バレしたくないのだが？
「新しい社内レギュレーション」では私用のGitHubアカウントで会社リポジトリにアクセスすることを推奨してはいますが、必須とはしていません。 新しく無料アカウントを作ると規約非準拠となるので、そちらは会社としては非推奨になりますが、新しく有料アカウントを作って利用することは可能です。 まだ社内事例がないため、社内レギュレーションには記載していませんが、そちらの支払いについては社内でこれから検討が必要です。
なるほど、必須とはせず、会社の有料アカウントを作って利用することは可能ということか。
つまり、
- 個人アカウントで業務したい人→アカウント統合
- 個人アカウント業務したくない人→有料のアカウント取る
とするのがベストっぽい。
でも実際これやるとなると不平等感がでるような。難しいですねぇ。
まとめ
とりあえず調査結果は以上。
実際のところ無料アカウントを複数持ってる人たちはたくさんいそうなのでなんとも言えないが、先人たちの情報を参考に検討していこう。
