「GPL」を含む日記 RSS

はてなキーワード: GPLとは

2017-09-08

消したらダメなんて初めて聞いたぞ

https://anond.hatelabo.jp/20170908074507

えーーーーーーー、そうなの?

そんなの、GPLにうるさいWordPress界隈でも聞いたことないぞ。

anond:20170908073503

GPL制限の多い厳しいライセンスなんだよ。

当然、消したらダメ

GPL制限しちゃいかんだろ

https://thk.kanzae.net/wp/page-3176/

GPL ライセンスなのでソース内の著作権表示は消したらアカン」

こんなの初めて聞いたぞ。

消しちゃいかんとか、制限したらGPLにならんのでは?

2017-07-07

リーフのバッテリ劣化技術的に早すぎる

https://news.yahoo.co.jp/byline/kunisawamitsuhiro/20170707-00073002/

スマホ電池は2-3年で40%程度まで劣化することも珍しくないので、リチウムイオン劣化するもんだという観念は広く染み渡っている。ところがそこは設計次第という面があって、放電深度によっては3年/500サイクルより長持ちさせることはできる。らしい。

ネットを見ていると、中古リーフ関連のテンプレには必ずバッテリ満充電容量を確認しろ可能なら軽く劣化させて保証交換に持ち込め、と書かれている。テスラ関連の掲示板は常に社長の人柄(渡邉美樹に似たタイプだ)とOSアップデートの話をしていて、「バッテリ劣化」と口に出すと「テスラのバッテリは劣化しない」と言って叩き出される。「エアコンの航続距離への影響」も「知らん」の一言で終わる。走行20kmで残容量93%というデータ(?)もあって、6万kmで90%を割っていると外れ値扱いになる世界なので、車の寿命まで持つから心配いらないというのも一定事実を含むのかとは思う。

リチウムイオン電池は高価だ。概ね2万円/kWhで、低下傾向にある。つまりリーフの24kWhバッテリには原価が60万円ほどかかっている。リーフの定価は300万円前後なので、1/5がバッテリの原材料費ということになる(分数だ!!!!)。これをテスラ並みの48kWhや72kWhにすれば、24kWhでの公称航続距離は228kmから、72kWhあれば650kmは走れるだろう。そうするとガソリン車の満タン感覚とも近くなってくるだろうし、仮に1/2や1/3に劣化しても燃費が悪くなったと言って済ませられるのではないだろうか。

もちろんバッテリの容量を2倍3倍に増やせば体積が2倍3倍になるのみならず、実質的ヴィッツとかフィット価値しかない車が360万円や420万円といった価格帯になる(これはかけ算だ)。BMW 3が候補に入る価格帯だ。電池は重量がある。パワートレインを強化しよう。リチウムイオン電池劣化は冷却によって抑えられる。冷却システム改善しよう。そうして技術的に適切な解決を図っていくと、例えば48kWh, 10年後の航続距離が300km、辛うじてコンパクトの車がわずか520万円といった感覚になってくるだろう。そのような車は、東京名古屋間を無充電で走行し、現地で少し急速充電した後、帰ってくることができるだろう。

同じことがトヨタ カローラにもできる。カローラ新車価格は150万円であるカローラ3.5台分の日本円を用意すると、その機能を保ったまま内燃機関電池と電動機で置き換えることができる。多くの日本人は今やカローラを購入することに難しさを覚えるようになっている。すると、機能を保たずに新車価格を保つほうがビジネス的に理にかなっている。バッテリの劣化は納車後しばらく、クルマに対する情熱があるうちは明らかにはならない。であれば、技術には涙をのんでもらってバッテリを最大限にしばき倒し、主に都心を動かすシティカーだが頑張ればノートと同等の動きもできるといった宣伝で、うるさい人だけ保証や実費交換で黙らせていけばよいという判断があり、そしてそのようにしているというのがリーフのバッテリ劣化をめぐる状況なのではないだろうか。

何が言いたいかというとテスラモデル3が欲しい。0-100km/hは5秒を切ってきそうだし、GeForce GTX 1060の搭載が決まっているし、GPLを盛大にぶっちぎってGNU/Linuxで動いているし、量産開始がアナウンスされている。別にどこかから金をもらっているわけではないが。くれるならRC版の3をくれ。

2017-02-26

anond:20170225195916

"Google翻訳オープンソースプロジェクトに使うのはダメなのか? " についての反論

いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。

GPLコンパイラの例

このGPLコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。

確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェア著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。

ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。

詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。

https://www.gnu.org/philosophy/free-sw.html

ほとんどの自由ソフトウェアライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアライセンスは、契約を元にするもので、契約もっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。

わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンス利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由である結論づけるかもしれません。

また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフト保護されたソフトウェアでも、それによって作成された著作物GPLにならない(つまりコンパイラやパーサーのライセンス継承しない)ことを根拠考察しているようだが、実はbisonやGCCGPLにはライセンスに対する例外付属していることを考慮すべきである

GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアライセンスが影響しないことを確実にするためにこれらの例外規定しているのではないか

この二つの理由から、元記事議論世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。

フェアユースについて

フェアユース規定は例えば日本では存在しない、

加えて言えば、たとえフェアユース規定が全世界的に利用できて、営利目的でなければ利用できたとしても、

フリーソフトウェア/オープンソース定義の中に

自由.0: どんな目的に対しても、プログラムを望むままに実行する自由

(i.e. オープンソース定義 6項 利用する分野に対する差別禁止)

がある限り、そのような制限ディストリビューションは受け入れられないだろう。

またOracle vs GoogleJavaAPI訴訟はケースとしてはかなり特例であり、

一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、

これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか

Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか

少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である

というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである

Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーコンピューター計算コントロール

つべであるという自由ソフトウェア思想と明らかに相容れないものである

このようなサービスを利用することの弊害として、(例えば)Google翻訳翻訳処理の計算依存することにより、ユーザー入力Googleが常に把握することが挙げられます

もちろんこれはあまり良いことではない。

多くのFLOSSシステムディストリビューション自由ソフトウェアを主に入れるというガイドラインを持っている。

アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、

これは事実上妥協産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者異論を挟まないだろう。

また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物依存する場合、contribというセクションに閉じ込めており、それは公式システムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)

Ubuntuコミュニティ新規に作られた著作物コミュニティ哲学に反する物に依存するというのは、かなり致命的である

たとえ奇跡が起こり、例外的Google翻訳や一部のプロ翻訳ツールBSDライセンス(Launchpad上での翻訳ライセンス)での出力を許したとしても決して褒められたものではない。

Ubuntubug#1に"Ubuntuソフトウェア自由である。常にそうであったし、今後も常にそうである自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである

https://bugs.launchpad.net/ubuntu/+bug/1

この反論を読んだ読者の中にはあまりGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、

いわゆる"Linuxディストリビューション"の中には数多くの重要GNUソフトウェアシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)

またUbuntu派生元となったDebianの成立経緯にはやはりFSFが関わっている。

さらに言えば、システム保守を手伝う人の中にはシステムフリーからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)

のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。

追記

Ubuntu Japanse Teamの関係者に読まれたようなので満足しました。(2017/2/27 22時)

2017-02-25

http://anond.hatelabo.jp/20170225195916

AをBに変換するというルールを作るにあたって、

そのルールとはつまり英和辞書を見てることに他ならない。

英和辞書を見ながら人力翻訳するのは普通だろうが、

英和辞書表現をそのままパクれば無害とは言い切れない。

良い英和辞書は長文の使用例を載せていたりする。

gccの出力結果がGPLのものを含まないかと言えば、100%含んでるだろ当然。

GPL辞書を使ってるわけなんだから

でもその辞書に特例を設けることによって、

gccアウトプットにはGPL適用されないような配慮がされてる。

法ではなく、製作者の配慮によって自由担保されている。

OSS文書Google翻訳で生成する件について、

Google自体著作権問題が無いかもしれないが、

WIndowsMSゴシックのように第三者プロダクトを利用していた場合

例えば、辞書出版社から訴えられる可能性はある。

Google翻訳オープンソースプロジェクトに使うのはダメなのか?

免責: これは法律専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。

最近プログラマの間で

Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話」

http://blog.goo.ne.jp/ikunya/e/37e5a52e10ab26fcbd4f7ff867e9eace

が、話題になってますね。

Ubuntu翻訳プロジェクトで発生したトラブルの話です。

この話では、「もちろん、利用規約的に問題なければWeb翻訳の結果をOSS翻訳に突っ込んでも*ライセンス的には*問題ありません。」という追記がされてます

ですが、プログラマの間で単にWeb翻訳OSSに使ってはいけないんだという認識が広まってるように見えます個人的には、この認識が広まってしまうのはいやだなと感じたのでこの文を書いています

どういう話かというと、自分個人で開発しているオープンソースソフトウェア(OSS)のドキュメントの日英訳をするにあたってGoogle翻訳を利用するか検討して権利まわりの情報をしらべた結果、これは白に近いグレーだろうという判断したので下訳に使ったという話です。(日英両方についてのドキュメント自体も、オープンソースライセンスで公開しています)

注意書き

念のため言っておきますが、これは元記事問題になっている人を擁護するようなものではありません。翻訳コミュニティの人たちが自分たちのものにグレーなものを入れたくないと思うのは当然でしょうし、権利問題以外にも翻訳クオリティやその他の問題行動の話もあります

コミュニティ思想にそぐわない人が、そのコミュニティの中で作業していくのは難しいでしょう。

Google翻訳利用規約について

もとの記事のとおり、Excite翻訳利用規約には私的利用を超えた利用についての禁止が明記されています。こういった明確に禁止されているものについての話はここではしません。

ここでは、Google翻訳に焦点を当てた話をします。Google翻訳利用規約はどうか?というと、Google利用規約については翻訳結果の利用についての記載がありません。

https://www.google.com/intl/ja/policies/terms/

記載がないということは、使用してよいのか?使用してはいけないのか?いったいどちらなのでしょうか?

GPLコンパイラの例

機械翻訳権利問題と似た構造の話に、GPLGNU一般公衆ライセンス)で許諾されたコンパイラによってコンパイルした結果の利用があります

GPLの本文には、GPLプログラムの出力結果自体GPLのものを含む場合にのみその出力結果にGPL適用されることについての記述がありますが、GPLのものを含まない出力結果についてどういう許諾がされているか記載はありません。

これについては、コンパイラによるコンパイル結果に対して、コンパイラ著作者はなんら権利を持たないと考えるのが一般的です。

GNU自体もそういう見解を持っています

https://www.gnu.org/licenses/gpl-faq.ja.html#GPLOutput

著作権法は人々があなたプログラムとかれらのデータを使って作った出力結果の利用に関して、あなたに何の発言権も与えていません。

コンパイラ機械翻訳ツールとの違いが、対象が人工の言語であるか、自然言語かので違いしかないと考えるならば、Google翻訳の結果をOSSに利用することも問題ないということになります

ウィキメディア財団見解

ウィキメディア財団法務チームは、Google翻訳した文書ウィキペディア内での利用についての見解を公開しています

https://meta.wikimedia.org/wiki/Wikilegal/Copyright_for_Google_Translations

これはアメリカ法律に基づく話ですが、CC-BY-SA 3.0やそれに類似するライセンスコンテンツGoogle翻訳翻訳してウィキペディア使用してもGoogle著作権侵害する可能性はとても低い(very unlikely)と結論づけています

要点をまとめると以下の通りです。

ウィキメディア財団見解には含まれていませんがアメリカ法律でいえば、さらにもう一つ「フェアユース」にあたるのではという話があります。これはGoogle自体がよく知っている話かもしれません。

Oracle vs GoogleJava API訴訟

これはAndroidAPIJavaAPIが流用されていることについて、OracleGoogle訴訟したものです。

これについて、Java APIについての著作権が認められたものの、Androidでの使用は「フェアユース」に該当するとGoogleは主張し、カリフォルニア州サンフランシスコ地裁では著作権使用料支払いの対象にはならないという判決が下っています

(この裁判自体はまだ続いているようです)

フェアユース」というのは、アメリカ著作権法上の概念で、以下の4要素を判断指針として考えて公正な利用と認められれば、著作権侵害とはしないと考えるものです。

Google翻訳結果のOSSでの利用をこれに当てはめると

ということになり、4つの要素どれをとっても、フェアユースであると認めることに対して有利に働きます。これは、AndroidJava APIの流用と比べても、さらにフェアな利用であるように見えます

さて、ここまではアメリカ法律での話でした。

(ちなみにGoogle利用規約には、「カリフォルニア州抵触法を除き、本規約または本サービスに起因するまたは関連するいかなる紛争に関しても、アメリカ合衆国カリフォルニア州法律適用されます。」と書かれています)

文化庁見解

今度は日本法律に基づく話です。

著作権情報センターサイトに、 コンピュータ創作物についての文化庁報告書記載されています

http://www.cric.or.jp/db/report/h5_11_2/h5_11_2_main.html

この報告書は、機械翻訳ユーザー機械翻訳システム使用するために行う原文の編集や出力の編集創作的寄与となりうることを認めている一方で、機械翻訳開発者翻訳物の著作者になるということについては否定的です。

なお、原文解析等のプログラム作成者及び汎用的な辞書データベース作成者は、一般的翻訳物の作成の精度、正確度等を高めることに寄与することとなるが、特定翻訳物の作成自体にかかわっているわけではないので、その著作者とはなり得ないと考えられる。

これは平成5年とかなり昔に書かれた報告書であり、それから機械翻訳技術は大幅に進歩しましたが、創造個性表現を目指して作られているもので無い機械翻訳であれば、やはり翻訳の結果の利用について問題がないようにみえます

これにしたがえば、単純に文章をそのまま機械翻訳に投げ入れた出力結果は、原文の著作者著作物機械翻訳に投げ入れる前や後に十分な編集をしていれば、加えてその編集した人間二次著作物になるということになりそうです。

白に近いグレー

これまで、どうしてGoogle翻訳の結果をOSSに使うことが白に近いと言っているか説明してきました。

では、どうしてグレーなのかというと、新しい種類の権利問題なので判例がないからです。実際に訴えられたら負けました、ということもまったくありえない話ではないでしょう。

グレーなものを作ることの良し悪し

だいたい、ここまでが話したいことの半分です。ここからはグレーなものの良し悪しの話をします。

著作権などの権利問題についてグレーなことをやっているOSSというのはそれほど珍しいわけではありません。

有名なところでいうと、Monoが思いつきますAndroidDalvikJavaAPIを真似したものであるのと同じように、MonoMicrosoft.NETフレームワークを真似しています。つまりMonoについても訴訟リスクはあっただろうということです。

しかし、OracleGoogle対立したのとは対照的な道をMonoはたどります

2016年Monoプロジェクト運営していたXamarin社は、そのMicrosoft自身によって買収されました。権利的にグレーだったMonoMicrosoft公認プロジェクトになったというわけです。

権利的にグレーだからといって、プロジェクトとして失敗に終わるわけではありません。

Ubuntu日本語化プロジェクトでの良し悪し

すこし元の記事に話をもどします。冒頭にも書いた通り、Ubuntu日本語化プロジェクトに対してWeb翻訳の結果を突っ込むという行為は、批判されるべきだと思っています

まずは質の問題です。現在Google翻訳などは、UI翻訳に向いていません。UIほとんどは、意味合い文脈依存する単語や短文です。UI翻訳は、実際にその機能を動かしながら、動作にあった訳語を割り当てていくべきです。

Google翻訳などを使って一括で、訳語を割り当てても良いUI翻訳はできません。

UIにとっての良い訳については、元記事のいくやさんがとても良い話を書いています: https://github.com/ikunya/howtotranslatelibo/blob/master/howtotranslatelibo.md#ふさわしい翻訳の考え方 )

次に、白に近かろうがリスクのあるものを入れることになるということです。Ubuntu日本語化ローカライズであれば、すでに多くのユーザー使用しているでしょうし、そういうものについてリスクのあるものを後から入れることになります

そういったことを独断で黙ってやるというのは、歓迎されたものではありません。少なくとも、コミュニティに対して事前に方針を聞いたりすべきだったでしょう。

まりクオリティが低い上にリスクのあることを黙ってやったわけで、もちろん批判されるべきでしょう。

自分場合

はいえ、OSSには個々の事情があります。次は自分場合の話をしてみます

まずは質の話です。

自分プロジェクト場合Google翻訳を使ったのはドキュメントです。日本語で書いたドキュメントをあたらしいGoogle翻訳に入れてみたところ、そこそこのクオリティ翻訳が出力されており、自分ゼロから翻訳するよりも、原文を翻訳やす修正したり結果に対して修正を加えていったほうが質と速さの両面でよいと判断したので、Google翻訳使用しました。

次にリスクの話です。

OSS企業権利問題訴訟されるということはめったにありません。OSS公益性の高いものなので、むやみに訴えれば社会からの反感を買いますし、ほとんどの場合は訴えても大した金になりません。

訴えられるとすれば、そのOSSが十分に儲かっている場合です。もしOSS大金が儲かったらGoogleから訴えられてしまう!どうしよう!と考えるのは、宝くじに当たったら強盗におそわれてしまう!どうしよう!と考えるのに似ています

まず宝くじは当たらないですし、宝くじが当たったらそのお金対策を行えば良いだけの話です。

実際Linuxでは、特許周りの対策としてOpen Invention Network(OIN)を設立していますLinuxなどソフトウェアに対して特許を主張しないことに同意した企業から特許を買収して、そういった企業に対してロイヤルティー・フリーで許諾を行っている会社です。

これによって、Linux関連のソフトウェアに対して訴訟をしてきた、いわゆる「パテント・トロール」に対して訴訟をやり返すなどの対抗手段を得ているわけです。

別の視点でのリスク

それにOSSにまた別の角度のリスクがあります

権利問題訴訟されたことによって失敗に終わったOSSというのはほとんどありません。多くのOSSは、作者が飽きたり、面倒な作業うんざりしたり、誰にも使われなかったり、競合に勝てなかったりしたことで、フェードアウトしていきます

そういったこともまた、OSSリスクなわけです。

結局のところ、自分場合Google翻訳をつかったところで、Googleにも、自分にも、ユーザーにも、世間にも不利益はなく、むしろドキュメントの質は上がって、Google翻訳改善するためのデータを得られます

わずかなリスクを避けるために、時間を割いた上、質を落とすというのはくだらないですし、そんなことに時間を使うくらいならコードを書いていたいものです。

Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか

結局、Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか?というのは個別の話でしかなく、ひとまとめにWeb翻訳の結果をオープンソースソフトウェア翻訳にいれてはいけないとか、使うべきとかそう簡単には言えません。

質が悪いしリスクがあるのであれば単純に禁止で済む話ですが、機械翻訳が向上して、質が良いがリスクのある例が増えると話はさらにややこしくなります

OSS翻訳者コミュニティ機械翻訳の利用についてそのプロジェクトで使って良いか方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合コミュニティ方針確認した上でやっていくしかないんだろうなあと思うところです。

2016-12-21

しょぼんのアクションスマホアプリ化されている件について調べた

2010年ごろにニコニコ動画上で有名になったしょぼんのアクションってゲームがあるんだけど今どうなってるのか調べてみた。

そうしたらとんでもないことになっていた。

結論から言えばあからさまに怪しいデベロッパー二次配布のソースコードを使って

原作者許可無く勝手スマホゲーにしていた。

itunes.apple.com/jp/app/shobonnoakushon-orijinaru/id894330337?mt=8

サポートURL (工事中扱い)

www.gatobros.com/

play.google.com/store/apps/details?id=com.gorkaramirez.syobonactionhalloween

サポートURL (工事中扱い)

www.pipletas.com/syobon/syobon.html

デベロッパーは『Gorka Ramirez Olabarrieta』というらしい。 ドメインWhoisガード適応済みで情報漁れず。

で、サポートURLのページをよく見るとOpenSource扱いになっていた

Original Source. Ported by @jezng using Emscripten.

sourceforge.net/projects/opensyobon/

Mathew Velasquezと呼ばれる人物が作者に許可無くSourceForgeアップロードしたようだ。

sourceforge.net/u/twoscomplement/profile/

で、SourceForgeプロジェクト開設日が下記のとおりになっているが

Registered 2010-05-16

原作者サイトにはもっと過去の時点でゲームが公開されている。下記のInternet Archiveのもの

wayback.archive.org/web/20091223043445/http://www.geocities.jp/z_gundam_tanosii/home/Main.html

で、問題はここから

このSourceForgeプロジェクト、再配布人が下記のライセンスで公開している。

License GNU General Public License version 2.0 (GPLv2)

www.gnu.org/licenses/old-licenses/gpl-2.0-faq.ja.html#DoesTheGPLAllowMoney によると

はいGPLは、誰もが販売することを許可しています。複製を販売する権利自由ソフトウェア定義の一部です。

としている。

SourceForgeに公開されているプロジェクトGPLv2で公開されているので、どうやらスマホアプリとして登場したようだ。

が、まずこれ色々と問題がある

プロジェクトで配布されているソースコード内にはDXライブラリがそのまま含まれているが、規約を守っていない可能性が高い。

dxlib.o.oo7.jp/dxlicense.html より引用する。

<<DXライブラリライブラリファイルソースコードの再配布について>>

 DXライブラリライブラリファイル( 拡張子lib や a のファイル )や、プログラムソースファイル( DxGraphics.cpp や DxLib.h などのファイル )を配布する場合は一部、全部問わず

以下の著作権表記を配布物とともに提供される文書、または他の資料に含めて下さい。

DX Library Copyright (C) 2001-2016 Takumi Yamada.

クレジット表示は探した限り見つからなかった。検証ファイル:SyobonAction_v0.9_src.tar.gz

なお、作者のサイトに商用利用に関する規約が無いとはいえ、さすがに普通に連絡するべきではないだろうか?

(配布ソースコード内には改変可という言葉はあるが商用利用可とは書いていない。)

なお、実行ファイル形式で配布されている物の英語のReadMeには原作者クレジットなし。

どうやらゲームファイルソースコード転載されたようだが、少々違和感がある。

Internet Archive内にあるソースコードSourceForge内のソースコードが違う。

tiku氏のそのまま配布するなを遵守したのだろうか? (配布されているソースコードには日本語が混じっているので非常に怪しいけど)

原作者の動向も分からないし、真実は分からない。

ただ、言えることはしょぼんのアクションスマホアプリとして公開されたのはGPLv2辺りのライセンスになっていたからだということ。

ここまで書いておいてなんなんだけど飽きた。

2016-12-09

から気になってたんだけど。。。

Linux/Unixの開発してるんだけど

GPLソース改変しなくても、ライブラリを静的リンクして配付したら、GPL適用しないといか

という説あるけどホントかな?

そういう説があるんで、上司にいま開発してるやつ、ソースオープンにしなきゃいかんのじゃないですか?

って聞いたら、

ソース改変してなきゃ、GPL適用しなくて大丈夫っていわれた。

GPLってそんなライセンスじゃないよね。

Linux/Unixのの標準ライブラリはかなりGPLが多い。

何も考えずに開発していたら、標準ライブラリ使っちゃうし、

開発している製品GPL適用しなくちゃいか自体って

知らずにいろんなところで発生してそう(特に中小)。

大手はそれなりにチェックしてるだろうけど、

あれだけ膨大にあるライブラリ

全部GPLライセンスかチェックして、

静的リンクしないでorソースオープンにしてるんだろうか?

ちゃんと調査すると、

大手GPL違反はかなり多いんじゃないかなぁ

2016-09-05

自由ソフトウェアフリーソフトって呼ぶやつ消え失せねーかなー

Copyrightと表示しているフリーソフトを調べてみた。

http://togetter.com/li/1020412

マジで消えねーかな、こういう輩。

バカGNU GPLに噛み付いてる「よくあるやつ」以前の程度の低い内容を自分でまとめてる無様さもさることながら、このタイトル

フリーソフトって書くんじゃねーよスカタン無料ソフトウェアじゃねーんだよ、GIMPはよぉー。

でもこういう輩に「自由ソフトって書け」って言っても伝わらないだろうし、消えてくんねーかなー。

次に消えてほしいのが自由ソフトウェアフリーソフトウェアって書くやつな。てめーらも同罪だよ。

なんのためにGNUがあちこちに「ビール飲み放題ではなく言論の自由」って書いてると思ってんの?

わざわざフリーソフトウェアってカタカナで書いて意味曖昧にしてんじゃねーよ。

自由ソフトウェア」でいいじゃねーか。ここにも載ってるし。https://www.gnu.org/philosophy/fs-translations.ja.html

こんな優れた訳語があるのに、なんで無料という意味にとられかねないフリー(free)の語を使うのか。

特に自由ソフト依存症雑誌ライター共な。てめーらがフリーフリー言ってるからいつまでも自由って意味が伝わんねーんだよノミどもがよ。

慣れ以上の理由が無いならさっさと「フリーソフトウェア」と呼ぶのを止めろ。もしくはライター辞めちまえ。

自由ソフトウェアなら自由ソフト自由ウェアと省略されても、無料ソフトウェアって意味にはならない。明確な利があるじゃねーか。

もしなんらかの主義主張があって「フリーソフトウェア」という語を使ってるなら、ごめんなさい。

2016-03-18

http://anond.hatelabo.jp/20160318220026

GPLは、ソフトバイナリ使用者しか公開義務はない

大企業プロプライエタリに組み込んだからといって、公開義務が発生するのは、それを買った顧客企業に対してだけ

不特定多数の手元にソフトが届くゲームソフトとかだと痛いが

http://anond.hatelabo.jp/20160318220026

その場合GPLのもの無効になるのではなく、

「悪意を持ってこっそりライセンスを変更してユーザーを陥れる」

という行動様式けが判決において否定されると思われるので、

あなた危険人物として雇われなくなるだけで目的達成できないよ。

有名ライブラリの作者になりたい

最初MITApacheみたいなゆるいライセンスにしたい。

ユーザー意見真摯に聞いて毎日コミットしてゆきたい。

Githubスターも1000や2000を楽に超えてゆきたい。

そしてある日、ライセンスGPLにする変更をいつものコミットの中にコッソリ入れたい。

それに気づかず更新してそのままストアに公開してるマヌケアプリを探したい。

うん千万うん億円かけたような企業アプリならとても良い。

そして使用している証拠を保存してからソース公開を要求したい。

そして当然のように拒否されたい。

そこから流れるように裁判に持ち込みたい。

そしてまた当然のように棄却されたい。

最終的に日本におけるGPLライセンス事実上無効となり、他国必死にそれを順守している一方で日本の全てのプロパライエタリソフトは当然のようにGPLコードを組み込むようになり、日本けが全てのIT技術において独走する世の中となるという、そんな終わらない黄金時代を作った最も偉大な愛国者として名を刻みたい。

2015-11-12

http://anond.hatelabo.jp/20151112000631

FSFGPLソフトだって勝手フォークして公開してプルレク受け付けられるよ (GPLでさえあれば。派生物に追加の著作者が増えてくだけ)。

それにGPL以外のOSSライセンスだって法的にbindingなライセンスには違いなかろう。(NO WARRANTY項目が有効かどうか、ってのはまだ議論があるんだっけ?)。あと、他者特許および知的財産権侵害してません、と一筆取っとくのは企業にとっては重要だね。FSF場合によってはその文書も求めることがある。結局、本家が法的係争に備えて同意を集めておきたいとする点では同じでしょ。

紙にサインしてスキャンして送れ、なんて言われたら面倒だから貢献する人が減るだろうってのはその通りだと思うけどね。

http://anond.hatelabo.jp/20151111224806

FSFのはGPL違反した奴を訴えることができるのが著作権保持者だけだからフリーソフトウェアまもるならFSF著作権を持っている必要があるという事情のためでしょう。

フリーソフトウェアでなしにオープンソースソフトウェアだったら関係なくない?

このソフトウェア機能追加したかったら、勝手フォークして公開すればいい。

ついでに、同意書がなくてもプルリクを受け付けるぜとすればそっちがメインラインになる。

2015-10-30

鉄道Nowはどこから時刻表データを入手しているのか?

3年ほど前、鉄道Nowというシステム話題になった。

http://www.demap.info/tetsudonow/

確認したところ、今年3月に開通した北陸新幹線が走っているので、今になってもデータメンテナンスされているようである

ところで、列車を走らせるにあたり時刻表データ必要なはずだが、そのデータはどこから入手しているのだろうか?

まさか日本全国およそ9000の駅に全て訪問し、時刻表撮影してデータ化しているわけではあるまい。

どこからか入手しているはずなのだ

誰でも思いつくのは、駅探ジョルダンNAVITIMEYahoo乗換案内など、公共サービスに備わっている時刻表検索サービス機械的に収集して時刻表抽出する方法である

確かにこの方法日本全国のデータを網羅できる。しかし、このデータをもとにサービスを行ったり、商売を始めるのはNGである

なぜなら、上記のサービスベンダーは「JR時刻表」と「JTB時刻表」の内容を交通新聞社およびJTBに許諾をもらって掲載している。

このデータを無断で拝借すれば、いわゆる無断転載である

https://www.navitime.co.jp/pcstorage/html/help/etc01.html

上記リンク先にある「弘承平成14年82号」という記述交通新聞社(旧弘済出版社)の承諾済みであること、「(J)02-7」という記述JTBの承諾済みであるということである

これが無いということは、少なくとも交通新聞社JTBのいずれの承諾も得ていないということである

そして自力時刻表データを作り上げたわけでもない。

無断転載でないとすれば、いったいどうやってデータを作ったのか?

=

鉄道Nowは、時刻表データを直接売買しておらず、広告掲載することによって間接的に金銭を得ているのだから問題ない」という意見もあるだろう。

確かにその通りかもしれない。

しかし、仮に無断転載禁止データをもとに作成したサービス広告収入を得ているのだとしたら、それはいわゆる「アフィカス」なのではないか?

時刻表無断転載有無など誰も知らないから大丈夫」とタカを括られているのであれば、なおさら悪質な部類に入るのではないか?

ソースコードで言うならばGPL違反と同等かそれ以上の悪質さではないか?

私は別に鉄道Nowを潰したいのではなく、あれだけ注目されたサービスなのだから権利関係について袖を正すこと提案しているのだ。

当たり前だが、時刻表けがあってもあのサービス提供できない。なかなか苦労して開発したはずである

権利関係とき敬遠されては勿体ないではないか。

=

ところで、駅.lockyという、「日本全国およそ9000の駅に全て訪問し、時刻表撮影してデータ化」を地で行くサービス存在する。

http://eki.locky.jp/site/top

このサービスを端的に表現するなら「時刻表Wikipediaである時刻表データ作成しているのは有志である

このデータ交通新聞社JTB作成したものではないため、駅.locky内で利用する限りにおいては交通新聞社JTBの束縛を受けない。

ありがたいことに誰でも閲覧できる状態になっている。

しかしだからといって権利フリーではなく、有償無償を問わず、再配布することは禁じられている。

http://eki.locky.jp/site/about

=

東京メトロが公開したオープンデータAPIでも、時刻表データが入手できる。

もちろんこのデータ商業目的利用NGである

https://developer.tokyometroapp.jp/terms.html

=

線路に沿わせて列車を走らせる動きを再現するにあたり、線路形状データ国土地理院データを使っているのであれば、これも商用利用NGである

http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-N05.html

=

以上をもって鉄道Nowへの公開質問状とする。

回答をお待ちしております

2015-07-27

jqueryバージョンが古すぎて死にたい

アサインされた案件jqueryバージョンが古すぎて死にたい

/*
 * jQuery JavaScript Library v1.3.2
 * http://jquery.com/
 *
 * Copyright (c) 2009 John Resig
 * Dual licensed under the MIT and GPL licenses.
 * http://docs.jquery.com/License
 *
 * Date: 2009-02-19 17:34:21 -0500 (Thu, 19 Feb 2009)
 * Revision: 6246
 */

6年更新してない・・・

jqueryバージョンが古すぎて死にたい

アサインされた案件jqueryバージョンが古すぎて死にたい

/*
 * jQuery JavaScript Library v1.3.2
 * http://jquery.com/
 *
 * Copyright (c) 2009 John Resig
 * Dual licensed under the MIT and GPL licenses.
 * http://docs.jquery.com/License
 *
 * Date: 2009-02-19 17:34:21 -0500 (Thu, 19 Feb 2009)
 * Revision: 6246
 */

6年更新してない・・・

2014-10-18

http://anond.hatelabo.jp/20141018070809

サンクス

おれんちのbash大丈夫だった

$ wget http://www.redtubelive.com/ -O - 2>/dev/null | awk -F'"'  '{ if ( $4 ~ /http:\/\/www.redtubelive.com\/cam\/[A-z0-9]*\//) print $4 }' | sort -u | sed -e 's|^|open |g' | head -n 15 | bash
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console
Couldn't get a file descriptor referring to the console

 

$ wget http://www.redtubelive.com/ -O - 2>/dev/null | awk -F'"'  '{ if ( $4 ~ /http:\/\/www.redtubelive.com\/cam\/[A-z0-9]*\//) print $4 }' | sort -u | sed -e 's|^|open |g' | head -n 15
open http://www.redtubelive.com/cam/AlexiLynn/
open http://www.redtubelive.com/cam/AliceX/
open http://www.redtubelive.com/cam/Aliza_Love/
open http://www.redtubelive.com/cam/AnnaMariaXO/
open http://www.redtubelive.com/cam/Ashley_Haze/
open http://www.redtubelive.com/cam/AsiaFairchild/
open http://www.redtubelive.com/cam/AspenPeeks/
open http://www.redtubelive.com/cam/BelleDaisy/
open http://www.redtubelive.com/cam/BelleMarce/
open http://www.redtubelive.com/cam/BriannaStarr/
open http://www.redtubelive.com/cam/Britini/
open http://www.redtubelive.com/cam/CRISTAL_EVANSS/
open http://www.redtubelive.com/cam/Canella/
open http://www.redtubelive.com/cam/CarleyTaylor/
open http://www.redtubelive.com/cam/CelestialTorres/

 

$ bash --version
bash --version
GNU bash, バージョン 4.2.25(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
ライセンス GPLv3+: GNU GPL バージョン 3 またはそれ以降 <http://gnu.org/licenses/gpl.html>

2014-07-22

俺がGPLコードを配布する理由

嫌がらせ以外にない

http://anond.hatelabo.jp/20140722222032

有益な話だし、GPL関係でググって・・・増田です。

大元増田にはわるいが、40代後半の担当者の判断はアリだわ

もっとシンプルで分かりやすくならないと

仕事でやる以上、金払ってライセンス安心買うか、GPL避けるか

だと思う。

はっきりいっときますね。


俺もGPL系のライセンスはだいっっっっきらいだ。

MIT LicenseBSD License並にさっぱりした奴がわかりやすくて好きです。

http://anond.hatelabo.jp/20140722034243

すっげ、追加の解説読んでもわっかんねww

大元増田にはわるいが、40代後半の担当者の判断はアリだわ

もっとシンプルで分かりやすくならないと

仕事でやる以上、金払ってライセンス安心買うか、GPL避けるか

だと思う。

MySQLを商用利用で無料で使えるという都市伝説

http://anond.hatelabo.jp/20140722001658

上で意味不明なことを言ってるので指摘しておく。

こういう勘違いする奴が多いが、これはMySQLサーバーが、デュアルライセンスから大丈夫だという話。

ちなみにMySQLGPLv2なので、そもそも間違ってるが、内容は対して変わらんので、細かい指摘は無し。

それより、本当のライセンス問題は、接続する側。

クライアントにある。

MySQL接続は独自でドライバでも実装しない限り、limbysqlclient.soやそれをリンクしたConnectorを利用することになる。

この二つは、サーバーと少し違うがデュアルライセンスだ。

・商用ライセンス

GPL(FOSS除外規定)

商用ラインセンスを選ばない場合GPL(FOSS除外規定)になるが、これを選択した場合、お前らの納品物はGPL適用になる。


もしお前らの納品物に、プロプライエタリライブラリとの結合があれば、その時点でライセンス違反だし、そもそも納品物を勝手GPL適用してよいか確認して契約しないと完全にもめる。

あれ、GPLじゃ他のオープンソースとも組合わせられなくね?

PHPとかPHPとかPHPとか。

そこで、FOSS除外規定関係してくる。

これは、MySQLが許可したオープンソースライセンス適用するならGPLv2にしなくても良いという例外規定だ。

許可一覧はこれ。

http://www.mysql.com/about/legal/licensing/foss-exception/

これはGPL汚染を防ぐための例外規定で、詳しくはここを読め。

http://nippondanji.blogspot.jp/2009/05/foss-license-exception.html

このおかげでPHPからMySQLを使ったりするのはセーフになってる。

ワードプレスなら大丈夫とか言ってる奴らは猛省して死ね

だが、FOSS除外規定は、あくまでもMySQLが許可したオープンソースライセンスに限る。

お前らの納品物をオープンソースライセンスにするなら許す。という意味だ。

結局のところ、

プロプライエタリライブラリとの結合があれば、ほぼ間違いなくライセンス違反だ。

それりなりの規模の案件オープンソースライセンスなんか適用できない。

結局、納品物をプロプライエタリライセンスにするためには、お金を払う必要がある。


ユーザー企業のみなさん、糞Web屋は平気でオープンソースライセンスにして

安心ですと言い切るでしょうが、待ってください。あいつらは作り逃げしようとしてますよ。

ちゃんと契約を確認しましょう。

追記

http://anond.hatelabo.jp/20140722142248

GPLだけど持ち出し禁止にすれば問題ないとか言う人が居まして。。。

そもそもFOSS除外規定で使えてるケースが多いのに、GPLで縛っちゃダメだろ。という無粋なアレは置いといて

今後絶対に、プロプライエタリライブラリリンクしない前提の

超小規模案件なら、ライセンシー意図とは異なるが選択肢にはなるけど

そんなリスク理解して承諾する客がいないから、作り逃げ案件になるわけだな。

MySQLライセンスについて

MySQLライセンス関係する仕事をしてたのでひとこと。

 

webシステムでも絶対にソースコード流出したらダメ場合ライセンスを買った方が良いです。

 

http://anond.hatelabo.jp/20140722001658

Webシステムなのが問題なんだ。システムを使う人にソースコードを公開しないといけないんだよ。TOPページとかにリンクを貼るの?ソースコードはこちら、みたいなの。ありえないよね?」

これは大丈夫です。

GPLではソフトウェアの配布時に関係してくるので関係ないです。

 

システムを使った社員ソースコードを持って帰って公開したらどうなるの?機密情報流出だよ。」

これはグレーです。

なんとも言えません。

からライセンスを買いましょう。

 

というのが脅し文句。

ようするに「裁判でどういう判決が出るのか(俺は)分からないので、怖かったら買え」ということ。

でもよく考えるとMySQLが出て長い年月が経ってるのにそういう事例が無い(少なくとも俺は知らない)って時点でリスクなんて無いと思う。

 

でもいまだにwebシステムでも前者の勘違いをして買ってくれる人が意外に多い。

 

http://anond.hatelabo.jp/20140722034243

MySQLを利用したからといって、スクラッチ開発したソフトウェアライセンスGPLになるわけではない

これはMySQLクライアントを利用してDB接続する多くのwebシステムではグレー。

MySQLに同梱されているクライアントソフトを使わずに自前でクライアントを作って接続してる場合は確実にGPL汚染しない。

 

GPLライセンスされたソフトウェアの改変に関わったプログラマコードを持ち帰れるかという問題

前述の通りグレー。わからない。

 

GPLライセンスしたソフトウェアプロプライエタリに戻せるか

無理。だけどGPL汚染してないバージョンからは可能。

一端GPL汚染したバージョンが出回った後でライセンスを変更するのは不可能だけど、

次のバージョンからGPL汚染しないように作り直して、ライセンスを変更すれば、

そのバージョンからプロプライエタリにできる。

 

http://anond.hatelabo.jp/20140722143245

結局、納品物をプロプライエタリライセンスにするためには、お金を払う必要がある。

GPLだけど持ち出し禁止にすれば問題ないとか言う人が居まして。。。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん