<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ライセンス  |  takeHo（たけほ）のへなちょこ台帳</title>
	<atom:link href="https://blog.takeho.com/tag/%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9/feed/" rel="self" type="application/rss+xml" />
	<link>https://blog.takeho.com</link>
	<description>いわゆる自由帳ってところです。</description>
	<lastBuildDate>Fri, 02 May 2025 09:31:29 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.6</generator>

<image>
	<url>https://blog.takeho.com/wp-content/uploads/2024/08/icon-150x150.png</url>
	<title>ライセンス  |  takeHo（たけほ）のへなちょこ台帳</title>
	<link>https://blog.takeho.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>コードが法廷に立つ日 &#8211; エンジニアが知るべきソフトウェアの法的責任</title>
		<link>https://blog.takeho.com/software-liability-that-engineers-should-know/</link>
					<comments>https://blog.takeho.com/software-liability-that-engineers-should-know/#respond</comments>
		
		<dc:creator><![CDATA[たけほ]]></dc:creator>
		<pubDate>Sat, 26 Apr 2025 09:21:35 +0000</pubDate>
				<category><![CDATA[エンジニアと法律]]></category>
		<category><![CDATA[ライセンス]]></category>
		<guid isPermaLink="false">https://blog.takeho.com/?p=1046</guid>

					<description><![CDATA[目次 はじめにソフトウェアの不具合と法的責任ケーススタディ：実際に起こった事故バグと過失オープンソースライセンスと法的落とし穴ライセンス違反の怖さ代表的なライセンスと注意点エンジニアが押さえるべき法令集著作権法（ソフトウ [&#8230;]]]></description>
										<content:encoded><![CDATA[

  <div id="toc" class="toc tnt-number toc-center tnt-number border-element"><input type="checkbox" class="toc-checkbox" id="toc-checkbox-2"><label class="toc-title" for="toc-checkbox-2">目次</label>
    <div class="toc-content">
    <ol class="toc-list open"><li><a href="#toc1" tabindex="0">はじめに</a></li><li><a href="#toc2" tabindex="0">ソフトウェアの不具合と法的責任</a><ol><li><a href="#toc3" tabindex="0">ケーススタディ：実際に起こった事故</a></li><li><a href="#toc4" tabindex="0">バグと過失</a></li></ol></li><li><a href="#toc5" tabindex="0">オープンソースライセンスと法的落とし穴</a><ol><li><a href="#toc6" tabindex="0">ライセンス違反の怖さ</a></li><li><a href="#toc7" tabindex="0">代表的なライセンスと注意点</a></li></ol></li><li><a href="#toc8" tabindex="0">エンジニアが押さえるべき法令集</a><ol><li><a href="#toc9" tabindex="0">著作権法（ソフトウェア＝著作物）</a></li><li><a href="#toc10" tabindex="0">不正競争防止法</a></li><li><a href="#toc11" tabindex="0">個人情報保護法</a></li><li><a href="#toc12" tabindex="0">電子契約法・電子署名法</a></li></ol></li><li><a href="#toc13" tabindex="0">法的リスクから身を守る開発手法</a><ol><li><a href="#toc14" tabindex="0">契約書の読み方とポイント</a></li><li><a href="#toc15" tabindex="0">開発ドキュメントとログの保管</a></li><li><a href="#toc16" tabindex="0">外部サービスやライブラリの取り扱い</a></li></ol></li><li><a href="#toc17" tabindex="0">終わりに：エンジニアが「法律の言葉」を話す時代へ</a></li></ol>
    </div>
  </div>

<h2 class="wp-block-heading"><span id="toc1">はじめに</span></h2>



<p>技術の進化とともに、ソフトウェアは社会の基盤となりつつあります。インフラ、医療、金融、教育など、私たちの生活を支えるあらゆる分野でコードが使われており、その責任はますます重大になっています。</p>



<p>では、そのコードに欠陥（バグ）があり、事故や損害が発生した場合、その責任は誰が負うのでしょうか？ 開発者でしょうか？企業でしょうか？ それともエンドユーザーがリスクを引き受けるべきなのでしょうか？</p>



<p>この問いに対する明確な答えは、日本国内でもまだ十分に議論されておらず、法整備も不完全です。しかし、既に起こっている訴訟や判例、そして世界各国の動向を見れば、エンジニアが法的責任と無縁でいられる時代は終わりを告げつつあると言えるでしょう。</p>



<p>本記事では、ソフトウェアエンジニアが知っておくべき法律の基礎知識と、実際に責任を問われる可能性のあるケース、そして日常業務の中で法的リスクを減らすための具体的な行動について解説します。</p>



<h2 class="wp-block-heading"><span id="toc2">ソフトウェアの不具合と法的責任</span></h2>



<h3 class="wp-block-heading"><span id="toc3">ケーススタディ：実際に起こった事故</span></h3>



<p>2018年、ある国内銀行でシステム障害が発生し、振込が一時的に利用できなくなるトラブルが起こりました。原因は、コードの一部にあった論理バグ。最終的には復旧しましたが、多くの利用者に影響を与えました。</p>



<p>このケースでは開発委託を受けたベンダー企業と銀行との間で責任の所在が争われ、契約書の条項に基づいて一定の損害賠償が行われました。</p>



<p>こうした事例からわかるように、ソフトウェアの不具合が損害を生み、それが法的責任を伴うことは決して珍しい話ではありません。</p>



<h3 class="wp-block-heading"><span id="toc4">バグと過失</span></h3>



<p>民法上の不法行為責任は「故意または過失により他人に損害を与えた場合」に発生します。バグの発生が単なる偶然ではなく、明らかに注意義務を怠った結果であると判断された場合、開発者個人にも過失責任が問われることがあります。</p>



<p>たとえば以下のような状況はリスクが高いです：</p>



<ul class="wp-block-list">
<li>テストを行わなかった（または十分でなかった）</li>



<li>使用が禁止されているライブラリを用いた</li>



<li>セキュリティ脆弱性が知られていたにもかかわらず修正しなかった</li>
</ul>



<h2 class="wp-block-heading"><span id="toc5">オープンソースライセンスと法的落とし穴</span></h2>



<h3 class="wp-block-heading"><span id="toc6">ライセンス違反の怖さ</span></h3>



<p>エンジニアの多くがオープンソースソフトウェア（OSS）を活用していますが、GPLやAGPLなどのライセンスに違反した場合、企業はソースコードの公開を求められるだけでなく、損害賠償請求や訴訟に発展するケースもあります。</p>



<h3 class="wp-block-heading"><span id="toc7">代表的なライセンスと注意点</span></h3>



<ul class="wp-block-list">
<li><strong>MITライセンス</strong><br>最も寛容なライセンスの一つ。著作権表示とライセンス文の記載義務がある。</li>



<li><strong>GPL</strong><br>ソフトウェアを改変・再配布する場合、派生物も同じGPLで公開しなければならない（コピーレフト）。</li>



<li><strong>Apache License 2.0</strong><br>特許に関する条項が含まれており、特許を保持する企業がソフトウェアを訴えることが制限される。</li>
</ul>



<p>OSSを導入する際には、以下のことに気をつけましょう。</p>



<ul class="wp-block-list">
<li>ライセンスの種類を調査し、使用条件を明確にする</li>



<li>社内ルールやチェックリストを設けて承認制とする</li>



<li>商用サービスとの組み合わせに適しているか検討する</li>
</ul>



<h2 class="wp-block-heading"><span id="toc8">エンジニアが押さえるべき法令集</span></h2>



<h3 class="wp-block-heading"><span id="toc9">著作権法（ソフトウェア＝著作物）</span></h3>



<p>ソフトウェアコードは日本の著作権法において「著作物」として保護されています。他人のコードを無断で流用したり、著作権表示を削除した場合は、著作権侵害として損害賠償や刑事罰の対象になります。</p>



<h3 class="wp-block-heading"><span id="toc10">不正競争防止法</span></h3>



<p>元の会社のソースコードを持ち出したり、業務で得た秘密情報（技術仕様や設計資料など）を別の企業に流用した場合、「営業秘密の不正使用」として罰せられます。</p>



<h3 class="wp-block-heading"><span id="toc11">個人情報保護法</span></h3>



<p>個人情報（氏名、メールアドレス、IPアドレス等）を扱うサービスでは、情報の取り扱いルールを明示し、適切な保管・消去・第三者提供の管理が必要です。違反した場合、数千万円規模の制裁金を課されることもあります。</p>



<h3 class="wp-block-heading"><span id="toc12">電子契約法・電子署名法</span></h3>



<p>WebサービスやAPIを提供する事業者は、ユーザーとの契約が電子的に成立することを意識しなければなりません。特に決済や自動課金などが絡む場合、ユーザーの明確な同意を記録する仕組みが必要です。</p>



<h2 class="wp-block-heading"><span id="toc13">法的リスクから身を守る開発手法</span></h2>



<h3 class="wp-block-heading"><span id="toc14">契約書の読み方とポイント</span></h3>



<p>契約書の中で注目すべきは「責任範囲（免責事項）」「損害賠償の上限」「知的財産の帰属」「瑕疵担保責任」などです。フリーランスエンジニアであっても、受託開発の契約には必ず目を通し、理解した上で署名すべきです。</p>



<h3 class="wp-block-heading"><span id="toc15">開発ドキュメントとログの保管</span></h3>



<p>後から「誰の過失か？」が争点になることもあるため、設計書、要件定義書、コードレビューの記録、コミットログなどはすべて保存しておくべきです。証拠保全の観点からも、ログの改ざんがないようGitなどのバージョン管理を活用しましょう。</p>



<h3 class="wp-block-heading"><span id="toc16">外部サービスやライブラリの取り扱い</span></h3>



<p>無料APIや無保証ライブラリの使用は、サービス停止時に自社サービスが停止するなどのリスクを伴います。また、著作権・商標権の観点からも注意が必要です。利用規約や利用許諾を必ず読み、業務に適用可能か確認しましょう。</p>



<h2 class="wp-block-heading"><span id="toc17">終わりに：エンジニアが「法律の言葉」を話す時代へ</span></h2>



<p>ソフトウェアが生活のインフラとなった今、開発者が担う責任もまた、社会的なものになってきています。「自分はコードだけ書いていればいい」と思っていた時代は、もはや過去のもの。</p>



<p>コードを書く手が、人の命や財産、あるいは企業の信用に直結することもある。そうした認識のもと、最低限の法律知識を身につけ、法的リスクと技術的責任のバランスを取れるエンジニアが、今後ますます求められるでしょう。</p>



<p>そのとき、あなたのコードが「法廷に立つ」日が来たとしても、自信を持って「自分の責任はここまでです」と語れるように——。</p>



<p>それが、現代のプロフェッショナルエンジニアの新しい条件なのかもしれません</p>



<p></p>
]]></content:encoded>
					
					<wfw:commentRss>https://blog.takeho.com/software-liability-that-engineers-should-know/feed/</wfw:commentRss>
			<slash:comments>0</slash:comments>
		
		
			</item>
	</channel>
</rss>
