ちょっと話題の記事

Listed Providerに対するSPLAライセンス改定に関する私見

2022.12.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。

先日サーバーワークスさんのブログで興味深い記事が公開されました。

社内で日々Microsoftライセンスと格闘してる私としてもこのライセンス改定に関して私見を述べたいと思います。

はじめに (免責事項)

Microsoftライセンスの話をするので例によって免責事項をば。

極力間違いの無い様に努めて書いていますが、あくまでもいち個人の私見にすぎず、本記事の内容はライセンスに対する記述の正確さを保証しません。
仮に本記事の内容に誤りがあり、それによりいかなる不利益を被ったとしても一切の責任を負えませんので予めご了承ください。

ライセンスに関する正式な判断が必要になる場合は必ず Microsoft および AWS に確認してください。

これから詳細を述べますが事の発端はMicrosoft社のライセンス改定でありAWSはその影響を受けた形となっています。

何が起きるのか?

サーバーワークスさんの記事にもありますが、2025年9月30日以降はAWS上で 独自のSPLA を利用できなくなります。

Microsoft の 2022 年 10 月のライセンス変更により、サービスプロバイダーは 2025 年 9 月 30 日までしか AWS 上で独自の SPLA を使用することができません。それ以降は、これらのお客様は、最新化するか、AWS ライセンス付き製品に移行する必要があります。

(下線は筆者が追記)

これにより現在AWS上で独自のSPLAを利用しているユーザーはAWS自身が提供しているサービスへ切り替える等の対応を行う必要があります。

発端となるMicrosoft社のライセンス改定

上記の内容は突然増えたわけでは無く、実際には2022年8月末に公表され2022年10月1日から適用されたMicrosoft社のライセンス改定が基になっています。

こちらの内容は基本的にはAzureリセールのためのCloud Solution Provider(CSP)プログラムの改定がメインなのですが、文章の最後の方にSPLAに対する改定も含まれており、

ホスティング事業者のエコシステムを強化し、従来のアウトソーサーやデータセンター事業者を奨励するため、SPLAの条件を変更し、Listed Provider のデータセンターでSPLAライセンスをアウトソーシングする機能を削除する予定です。
この変更により、従来のアウトソーサーやデータセンター プロバイダーは恩恵を受け、ホスティング パートナー様のエコシステムを促進することができるでしょう。
この変更の影響を受けるSPLAパートナー様は、2025年9月30日までに、SPLAアウトソース ホスティングのListed Provider から移行するか、SPLA外のListed Providerからライセンスを直接取得する必要があります。

(日本語記事より引用)

To strengthen the hoster ecosystem by focusing the program on breadth hosters and encourage traditional outsourcers and datacenter providers, we are changing the SPLA terms to remove the ability to outsource SPLA licenses on Listed Provider datacenters.
Traditional outsourcers and datacenter providers will benefit from this change, and it will help foster the hosting partner ecosystem.
Any SPLA partner impacted by this change has until September 30, 2025 to transition from a Listed Provider for SPLA outsourced hosting or to license directly from the Listed Provider outside of their SPLA.

(日本語だと異常にわかりにくかったので英語版の引用も併記)

と記載されています。

Microsoft社の意図としては「Microsoftパートナーのホスティング事業者に対するMicrosoft製品展開の条件を緩和する」とされていますが、同時に「AWS等のListed Provider *1に対する締め出し」も含まれています。

この改定に至る経緯については以下の記事が詳しいので是非ご一読ください。
(Microsoftライセンス周りの読み物として非常に面白く参考になります)

影響を受ける条件

このライセンス改定でSPLAに関する影響を受ける条件は

  • Listed Providerのデータセンターを利用している
  • アウトソーシングによるSPLAを利用している

の2つを満たす場合となります。

AWSのサイト上では「独自のSPLA」という表現をされていますが、SPLAに慣れてない方にはちょっと分かりにくいと思うので解説をしておきます。

そもそもSPLAとは?

SPLA(スプラ)はMicrosoft Services Provider License Agreementの略であり、Microsoft製品を使ったサービスを公開する事業者向けのライセンス体系となります。

Microsoft製品のライセンスは通常組織が自社内での利用のために購入(契約)するのを前提としていますが、SPLAの場合は「事業者がMicrosoft製品を使ったサービスを第三者に公開する」場合のものとなります。
この事業者のことをService Provider(SP)と呼び、基本的にはホスティング事業者を指すのですが、アプリケーションを公開するサービス事業者やシステムインテグレーターの場合もあります。

SPLAの重要な点として挙げられのは「サービス利用者はあくまでもSPのサービスを利用する契約をしており、Microsoft製品を直接購入(契約)していない」点になります。
たとえばEC2の場合であれば「AWSが提供するWindows Server入りの仮想マシンを時間課金で利用する契約をAWSとしている」に過ぎず「利用者がWindows ServerのライセンスをMicrosoftから借りているわけでは無い」といった感じです。

とはいえ利用者はSPから提供されるMicrosoft製品を無制限に使えるわけでは無くSPUR(Services Provider Use Rights)という規約を遵守する *2必要があります。

独自のSPLA

SPLAの基本は下図の様にSP一社でサービス一式を提供する形です。
「AWSでWindows Server License IncludedのEC2を提供する」「RDS for SQL Serverを提供する」といったものが該当します。

(SPLAライセンスガイドブック P18より引用)

この他にSPがデータセンター事業者(別SP)のサーバー上にMicrosoftソフトウェアをインストールし利用者に提供する形も許可されています。
たとえば「インフラにAWSを使っているが、AWSではOffice入りのEC2が無かった *3のでSPで独自にOfficeをインストールしてサービスとして提供する」といった形がこれになります。

(SPLAライセンスガイドブック P19より引用)

影響を受ける利用者、受けない利用者

AWSの言う「独自のSPLA」はこの後者のパターンにおけるSPのSPLA契約のことであり、Listed Providerのデータセンターを使う場合にこのパターンが禁止されることになりました。

このため、AWS上でMicrosoft製品を使っており、かつ、AWS以外でSPLAを使うSPのサービスを利用している利用者が影響を受けます。

ちなみに前者のパターンはライセンス改定の影響を受けないため、AWSが提供するサービスを直接利用する分には一切影響はありません。
一般的なAWS利用者は影響を受けないと考えて問題ないでしょう。

追記 : 図にまとめました

記事を公開した後、SPLAライセンスガイドブックの図だけだと分かりにくいと思ったので改めて今回の対象範囲について図にまとめました。
これで「独自のSPLA」が指すものが分かりやすくなったと思います。

対応策

ここまでの話で根本原因はMicrosoftのライセンス改定でありAWSやSPはそれに従わざるを得ない状況であることはご理解いただけたと思います。
このためAWSやSPにクレームを上げても無駄であり、利用者もこの変更に従うしかありません。

利用者で打てる対応策としては以下の通りとなります。
なお、サーバーワークスさんの記事の内容とだいたい同じです。ライセンスの話なので「私だけが知ってる特別な抜け道」なんてものは無いのです...

1. AWS謹製サービスを使う

「独自のSPLA」であることが問題であるため、可能であればAWS謹製サービスを使うのが一番良い対応でしょう。

たとえばVisual StudioやMicrosoft Officeの利用であれば先日AMIが提供されましたのでこちらに移行することができます。(若干前提条件が厳しいですが...)

他にもVDI関連であればAmazon WorkSpacesやAmazon AppStream 2.0へ移行することも選択肢として挙げられます。

残念ながら全てのSPLA対象製品がAWSから提供されていないため移行できない場合も多いですし、また、環境面やコスト面で折り合わない事もあるでしょう。
それでも私個人としては面倒なライセンス管理はできるだけAWSにお任せしてしまうのがベストだと考えます。

2. Microsoft製品を捨て代替サービスを使う

当たり前ですが非Microsoft製品であればライセンスの問題はクリアできます。
今回を機にライセンスに縛られない代替サービス切り替えるのも良いと思います。

とはいえこちらも適切な代替を見つけることや環境面、コスト面の問題はついてまわります。

3. MicrosoftライセンスをAWSへBYOLする

一部のMicrosoft製品ではオンプレの自社環境からクラウド環境にライセンスを移動することのできるライセンスモビリティという制度があります。

ライセンスモビリティはソフトウェアアシュアランス(SA)特典の一つであるためSAを利用していることが前提であり、かつ事前にMicrosoftによる審査が必要です。

ライセンスモビリティの対象製品でよく問合せがあるものを例示すると以下の通りとなっています。

  • [NG] Windows Server OS : OSライセンスはライセンスモビリティの対象外です
  • [NG] Microsoft Office : Officeはライセンスモビリティの対象外です
  • [OK] Remote Desktop Service CAL : RDS CALはライセンスモビリティ対象です

他の製品についてはAWSのサイトでご確認ください。

4. Listed Providerでないデータセンターを使う

Listed Provider以外のデータセンター環境であればこれまで通り「独自のSPLA」は利用可能です。
ただ、SPLAでは「契約はあくまでもSPによるサービス提供」のためSPにより利用環境の移行が拒否されることは普通にあり得ますのでご注意ください。

この方法は理屈の上では可能ですが実現性は低いと思います。

私の見立てではおそらくAWSインフラを使うSPの多くが2025年をもってサービスを畳むんじゃないかと予想しています。

最後に

以上となります。

実は私個人としては8月のライセンス改定の記事を見た際に「あれ?話題になってないけど実はかなりヤバい改定では?」と気になっていました。
ただ、AWSなどのListed Providerからの公式声明も無かったのでずっと静観していました。

今回実際にAWSのサイトにも記載される様になりAWSとして正式にライセンス改定に従う形になったのでしょう。
来年以降は利用者からの問合せも増えるでしょうし、公式に正確な情報が多く出てくるものと思われます。

脚注

  1. 2022年12月時点においてAlibaba, Amazon (AWS含む), Google, Microsoft
  2. より正確にはSPが利用者に遵守させる
  3. 今はOffice入りAMIが提供されています