Google、Java APIの宣言が著作権保護の対象にならないとの主張を繰り返す 57
まだまだ争いは続く 部門より
headless曰く、
Googleは6日、GoogleがJava SE API（ライブラリ）からコピーした宣言は著作権保護の対象にならないとの主張を連邦最高裁に提出した文書で繰り返した（裁判所文書PDF、The Keyword、Register、Computing）。
この裁判はJavaの知的財産を侵害されたとしてOracleが2010年にGoogleを訴えたものだ。連邦最高裁ではGoogleによるJava APIの使用がフェアユースに当たるかどうかが審理され、GoogleがJava SE APIからコピーした宣言部分が著作権保護の対象になるという二審判決は確定しているのだが、Googleは宣言が著作権保護の対象にならないとの主張に連邦最高裁に提出した文書の相当量を費やしている。
そもそもAPIの宣言のように短いフレーズは著作権保護の対象とならないが、二審の連邦巡回区控訴裁判所では構造・順序・構成（SSO）を含めて著作権保護の対象になると判断した。しかし、Googleは本件について、あるアイディアを実現するのに使用できる表現の数が少ない場合、その表現は著作権保護の対象にならないというマージ理論が適用され、Java SE APIの宣言部分も著作権保護の対象にならないと主張している。
つまり、開発者がJava APIをコールする場合、パッケージで宣言された通りに記述する必要があるため、宣言をGoogleが勝手に変えることはできないということだ。Androidに実装されているのはJava SE APIの一部だが、基本的なAPIの宣言を変更してしまえばJava開発者も学習しなおす必要が出てくるのでJava言語を使用するメリットが失われる。そのため、二審判決は現代的で相互運用可能なコンピューターソフトウェアの開発を阻害するとして、判決を覆すよう求めている。
判決出てからもごねるって裁判の意味がない (スコア:0)
> 基本的なAPIの宣言を変更してしまえばJava開発者も学習しなおす必要が出てくるのでJava言語を使用するメリットが失われる。
同感。
>そのため、二審判決は現代的で相互運用可能なコンピューターソフトウェアの開発を阻害する
同感。
> として、判決を覆すよう求めている。
判決出ちゃったんだから、Oracleと相談して使用料払うのが筋。
＃そろそろjava使わせるのやめてもらいたい
Re:判決出てからもごねるって裁判の意味がない (スコア:1)
>> として、判決を覆すよう求めている。
> 判決出ちゃったんだから、Oracleと相談して使用料払うのが筋。
うーん、言語仕様とかAPIとかは著作権保護対象とはならないというのがJava API 以外のこれまでの判例だったはずで、
むしろ Java API の件が例外的だったので、この件については判決覆す方が筋じゃないかって気が。
API互換な実装を許さなくなると、Linux kernel や glibc とかだってアウトみたいな話になっちゃっうので弊害が大き過ぎますし。
(どちらも AT&T による UNIX 実装に対する API 互換品なので)
Re: (スコア:0)
>API互換な実装を許さなくなると、Linux kernel や glibc とかだってアウトみたいな話になっちゃっうので弊害が大き過ぎますし。
Androidの開始時点ではJava API互換からはじめたけど、いまはJava API互換を目指していない別物だからこういう話になってるのでは？
Re: (スコア:0)
> Androidの開始時点ではJava API互換からはじめたけど、いまはJava API互換を目指していない別物だから
なんの話をしてますか？
最初から Oracle が定めている Java API 全てに互換ってのは目指してなかったですよ。
今でも当時から互換だった部分は、互換性をキープしているのでは？
Re: (スコア:0)
宣言コードは実装コードの一部で不可分、よって宣言コードにのみ著作権が発生しないという解釈はできない。
という、単純明快かつ筋の通った判決だぞ。
同一ソースファイル内で、定義なのか宣言なのかによって著作権の有無が変わるほうがおかしいだろ。
API互換な実装をしたければ、宣言コードのコピペせず互換性を保つ範囲で自分なりの書き方をすればいいんだよ。
Re: (スコア:0)
Java使いたかったらJavaMEでも入れれば良かったのに。
Re: (スコア:0)
MicrosoftとJ++でもめてたの知らないわけじゃないだろうにな
採用する前にちゃんと調整しておくべきだった
Re: (スコア:0)
最高裁判決は出てないのだから主張するのは当然では？
Re:判決出てからもごねるって裁判の意味がない (スコア:1)
・著作権で保護されるか
・フェアユースか
という2つの論点があり、前者は確定、今は後者を争っている段階。
だのに後者の裁判の準備書面でGoogleが前者の話を蒸し返してきたので「何言ってんだこいつ」ってのがストーリーの主旨。
Re: (スコア:0)
最高裁は上告を退けたからもう確定してるよ。
Re: (スコア:0)
もうGoogleは無理筋な感があるけど、相手がOracleなのでもにょってしょうがない。
Re: (スコア:0)
逆ギレしてGoogleがアンチJavaに突き進んでくれた方が「現代的で相互運用可能なコンピューターソフトウェアの開発」には貢献してくれそう
Re: (スコア:0)
次はぜひSwiftのパクりでお願いします。
Re: (スコア:0)
そこがGoogleの相変わらずの傲慢なところよ。
どう考えても理不尽な判決のままで確定してしまった判例なんて世にわんさかあるのに、
Googleのためだけに司法制度を曲げてやり直すなんてできるはずがなかろうに。
パンドラの箱を開けるようなもので、「俺の裁判もやり直せ」的な蒸し返しが溢れかえって
社会が大混乱に陥り収拾がつかなくなる。
社会全体に多大な悪影響を及ぼすのが明白なのに、それでもGoogleの都合のために
無理を通せというのだから、傲慢ここに極まれりというものだ。
どうしても受け入れられんというなら、アメリカから出て行って自分の国でも作るんだな。
そこで思うように法を定めればいいｗ
Re: (スコア:0)
ホリエモンみたいに屁理屈でゴネ続けてれば
「勝負に勝って試合に負けた」ことにできて
信者が後々まで擁護してくれるからな
Amazon S3互換性API (スコア:0)
互換についてどうなってるの [oracle.com]
報道がよくわからない (スコア:0)
このニュース、
API仕様の話をしているのか、
コードの話をしているのか
両方なのかよくわからない。
もし、VM等のヘッダファイルの話なら、さすがにそのままコピーするのはNGだと思う。
C だって処理系によって内容は違う。
ただ、これまでのニュース見てもどっちかわかる記事が無い。
Re: (スコア:0)
> コードの話をしているのか
これ
今回は、だれがどうやっても同じにしか書きようがないから、著作権による保護の対象からはずしてくだちい、とグーグルが主張しているという話
マージ理論というのがあって、それがその根拠
Re: (スコア:0)
コードの話なんだけど、実装コードじゃなくて宣言コードの話なので、ほとんどAPI仕様の話といってもいい。「仕様」というアイデアに著作権は認められないので、苦し紛れに「宣言コード」が思想の表現物だと主張したら、認められちゃったという感じ。
例えば、最大値を返すJava API「java.lang.Math.max」の構造、順序、構成は「java.num.compare.high」としてもいいし、ベタに「max」としてもいいのだから、そこは開発者によって千差万別で、マージ理論は適用されないでしょってこと。
Re: (スコア:0)
public String substr(String str,int pos,int length);
(違った気がするが)
ってAPIがあったのをGoogleがAndroid向けに再実装したらダメって言ってるのでトンデモ案件なんだけど
高裁が認めちゃって最高裁も棄却しちゃったから頭抱えてる案件
Re: (スコア:0)
public String substr(String str,int length,int pos);
なら OK だって認められたほうが世の中の弊害は多くなりそう
Re: (スコア:0)
SQLですらPOSの位置が1始まりで混同するのにな
Re: (スコア:0)
String str じゃなくて String s にするとかスペースの数が違うとかなら通ったのではないだろうか、という気はするが。
コードの比較とかしてるページないかな。 実際のところどの程度の相似具合だったんだろうか。
Re: (スコア:0)
そんな低次元の話ではないと思われ。
AndroidはUIスレッドからはネットワークIO出せないが、GoogleはASyncTaskとかいうクソAPIしか実装できなかった。
そして、OracleがExecutorService作ったら丸パクリ。
もうちょと高度なAPIの話。
# いい加減あきらめてカネ払えよ。
Re: (スコア:0)
＞そして、OracleがExecutorService作ったら丸パクリ。
順番が違っている。ExecutorServiceはJava5だから、パクるも何もAndroid最初期からある（Javaそのものをパクったことは置いといて）。
AsyncTaskのパクリ元は、SwingのSwingWorker。
Re: (スコア:0)
その例は逆に「著作権保護の対象とならない」と認められてる範囲だろ
他人に解説したいならタレコミくらいちゃんと読めよ
Re: (スコア:0)
お前こそ資料ちゃんと読めよ
上はただ単に例として書いただけで正確に書けばsubstrであれば
java.lang.String.substring(int beginIndex, int endIndex);
は、保護の対象な
Javaの正確なクラス覚えてないから多分間違ってるけどこんな感じで書いただけで
資料読めば
java.lang.Math.max(int a, int b);とかで書いてあるよ？
Re: (スコア:0)
さすがにそのままコピーするのはNGだと思う。
C だって処理系によって内容は違う。
これはこれでかなりまずい。
もしも「互換性を損なわない程度に内容が違う」で著作権違反にならないということになるとMinifierや難読化ツールのようなコンバータでも著作権違反を回避できるということになり、ソースが公開されているものはパクり放題。
オープンソースライセンスは事実上パブリックドメインと同等になるんじゃない？
Re: (スコア:0)
> もしも「互換性を損なわない程度に内容が違う」で著作権違反にならないということになるとMinifierや難読化ツールのようなコンバータでも著作権違反を回避できるということになり、ソースが公開されているものはパクり放題。
それは実装のコピーの話でしょう。
APIのコピーとは話が違うんですよ。
Re: (スコア:0)
APIの宣言の実装のコピーの話だよ。
Re: (スコア:0)
> APIの宣言の実装のコピーの話だよ。
「APIの宣言の実装」っていうと宣言の話をしているのか実装の話をしているのか分かりづらいので
「APIの宣言のコード」っていう言い方をしましょうよ。
で「API宣言のためのコードのコピーの話」をしてるっていうのは確かにその通りなんですが
これに対し #3744965 が話しているのは「宣言のためのコード」じゃなくて
「Minifierや難読化ツールのようなコンバータで実装のためのコードをコピーする」話なので
話が違うっていう指摘です。
Re: (スコア:0)
#3744965だけどそれは違う。
「宣言のためのコード」をコンバータを使って互換性を維持できる範囲で変換したものはセーフなの？って話。
「C だって処理系によって内容は違う」の違いもそういうのと大差ないわけだし。
難読化ツールなどはたとえとして出したのだけど、かえって誤解を招いてしまったのは反省している。
Re: (スコア:0)
>「宣言のためのコード」をコンバータを使って互換性を維持できる範囲で変換したものはセーフなの？って話。
なるほど。
既存のコンバーター使った場合、宣言順序とかは同じになるしアウトになる可能性がありそうです。
人手で意図的に似ないように書けばセーフになるのは確実なので、
それと同レベルで似なくできる自動変換ソフトをカスタムで作って秘密裏に使えば
バレない限りは大丈夫()ではないかとw
Re: (スコア:0)
何を言っているのかと思ったら、宣言に対する定義のことを実装って言ってるんだね。
どのあたりの用語なんですか?
Wineや互換OSやらは死亡？ (スコア:0)
APIに著作権があるなら著作権違反だよね
Re: (スコア:0)
訴えられなければ問題ない。AWSにしても。
MSは.NET互換でさえ容認の方針なので訴えられることはないでしょう。気が変わらんともいえんけど。
Re: (スコア:0)
Linusはそうは思っていないそうだ。
いつ訴えらるかわからんようなものはマージしねぇ！
https://kuenishi.hatenadiary.jp/entry/2020/01/13/231033 [hatenadiary.jp]
Re: (スコア:0)
この業界、ステルス特許はよくあることですから常識的な対応でしょ。
Re: (スコア:0)
.NET互換に容認どころか、1.0の頃からISOやECMAに仕様も全部投げてて、別実装大歓迎。実装してくれるなら、どこにでも金も出しますよってやってきたんですよ
最近、ECMAのほうは本家の更新に全く追従してないし、独自実装してたところもオープンソースじゃ事業がなりたたんってことでMSが買い取ったけど。
最近は、それぞれの実装を統合する流れになってるけど、新規に互換環境実装するってことになったら、今でも金だしてくれるよ
それ通用するの？ (スコア:0)
> そもそもAPIの宣言のように短いフレーズは著作権保護の対象とならない
じゃあ長い文章も一文ずつ分ければ短いフレーズだから著作権保護しなくていいし、
データベースとかも1レコードずつ分けて単なる事実の記載ってことにすりゃいいし、
デジタル画像なんて1ピクセルごとにすりゃただの色付きの四角なんだから、
どれも著作権保護しなくていいやってことになんじゃねーの？
なんか筋の悪い主張に思えるけど、法学的な議論では通るの？
典型的な詭弁 (スコア:0)
「生きている人間を殺せば死者になるから人権保護しなくていい」みたいな話はやめてくれ。
> じゃあ長い文章も一文ずつ分ければ短いフレーズだから著作権保護しなくていいし、
「長い文章」の著作性は否定されないので、「一文ずつ分け」ることが複製権・翻案権の侵害。「短いフレーズ」は著作権保護の対象とならない。
> データベースとかも1レコードずつ分けて単なる事実の記載ってことにすりゃいいし、
「データベース」の著作性は否定されないので、「1レコードずつ分け」ることが複製権・翻案権の侵害。「単なる事実の記載」は著作権保護の対象とならない。
> デジタル画像なんて1ピクセルごとにすりゃただの色付きの四角なんだから、
「デジタル画像」の著作性は否定されないので、「1ピクセルごとにす」ることが複製権・翻案権の侵害。「色付きの四角」は著作権保護の対象とならない。
Re: (スコア:0)
> 「長い文章」や「データベース」には全体の著作性があるから部分を取り出すのは複製権・翻案権の侵害
Googleが主張してるのは、部分であるAPIの宣言には著作性がないから全体の著作性がないって理屈じゃん？
今してくれた説明は全体の著作性があるから部分を取り出すのは著作権違反って理屈じゃん？
その説明じゃどっちが頭でどっちが尻尾なんだかって感想にしかなんないわ
JavaAPIには全体の著作性とかいうのはあるの？ないの？ないとしたらそれはなぜ？
JavaAPI全体は「API宣言のように短いフレーズ」じゃないから、プログラマ的には全体の著作性とかいうのが成立しそうにしか思えないんだけど。
Re: (スコア:0)
JavaAPIに全体の著作性があると認められたのは関連リンクの通りだよ。
https://developers.srad.jp/story/14/05/10/1356257/Ja [developers.srad.jp]
Re: (スコア:0)
たった一つの関数（API）宣言だけだったらまだしも、APIセット丸ごとだし。主張するのは自由だけど普通に考えて通るものじゃないよね。
Re: (スコア:0)
> たった一つの関数（API）宣言だけだったらまだしも、APIセット丸ごとだし。主張するのは自由だけど普通に考えて通るものじゃないよね。
Linux kernel も glibc も、UNIXの APIセット丸ごとコピーしてますよ。
Re: (スコア:0)
それはIEEEが標準化してたりで権利者が使うことを許可してるものだから丸ごとコピーしてようが問題ない。
今回のは権利者が許可していないものに対して、googleが無料で使わせろと言っているものでしょ。
Re:それ通用するの？ (スコア:1)
> それはIEEEが標準化してたりで権利者が使うことを許可してるものだから
その理由は誤りです。
米国においては、APIには著作権がないという判例が確立してます。
Javaの件はその理由で一審ではGoogleが勝ってますし
二審でGoogleが負けたのはAPIが同じだったからではなく
APIを表現するコードをコピーしていたからです。
Re: (スコア:0)
API標準化したときの理念が「広めるためにみんなで使いましょ」の精神だからだよ。そのあとで今回の裁判のように議論されて権利の有無が確定しようがそれは無関係でしょう。
Re: (スコア:0)
> API標準化したときの理念が「広めるためにみんなで使いましょ」の精神だからだよ。
違いますよ。
たとえば MS-DOS 1.0 は、Digital Research の CP/M の API をほぼ丸パクに近い形で含んでおり
それは少なくとも Windows ME までは残ってましたが、CP/M を作ってた Digital Research は
Microsoft に API を使って欲しいなんて思ってませんでした。そもそも「標準化」もしてませんし
自社の知的財産だと思ってました。
APIに著作権を認めない理由は、建前としては著作性に疑義があるからですが、それ以上に大きな理由は
独占の弊害を防ぎ競争を促進するためでしょう。一度広まった API に排他的な権利を与えると、
囲い込みと独占の弊害を生むからです。
Re: (スコア:0)
ms-dosではなくlinuxの話では？
linuxは例えばIEEE Std 1003.1で標準化されてたりする。