  |
はてなキーワード: プロプライエタリとは
現在では事実上、結果だけを見るのであればWindowsやMac、UNIX、Linuxなどで実現可能な課題は変わらない。
ただ、商業的に一定の予算を持って開発されたプロプライエタリなアプリケーションソフトウェアの中には、その実現可能な課題までの手順を省力化できるものが多い。
システムは実装の違いがあれどPOSIXを基準に実装され(サブシステムとしてPOSIX基準を実装している場合もある)、操作性はCommonUserAccessを参考として実装されていることが大半でOSが違ってもほぼ迷わず操作することが可能だ。
これまで、こう言った話題の類似したものに「iPhoneを求める子供へAndroid端末を買い与えるのは虐待か？」などがある。
今回の話題の発端となったエントリでは娘さんはCLIP STUDIO PAINTを求めるまで、Linuxディストリビューションの1つであるUbuntuをある程度は使えていた様子が見て取れる。
更にUbuntuではファイルのドラッグ＆ドロップによる移動操作などが当然可能であるが、娘さんはCLIの基礎的な操作まで行えるようになっており、PCスキルは同年代の子供よりも「できるほう」のようだ。
学校教育ではWindowsに触れていたようだが、Linuxの特性上デスクトップ環境を変更することによって見た目や操作性を著しく変化させることが可能で、娘さんからすると「パソコンによって見た目や操作性に多少の違いはあるもの」という認識だったようで、WindowsとLinuxのOSプラットフォームとしての違いをそこまで気にしていなかったようだ。
娘さんは今回の件でWindowsとLinuxの違いを認識していくようになるであろうが、この違いを経験することがプラスになるのかマイナスになるのかは、まだまだ稀少な事例過ぎて判別が難しいように思われる。
ただ、少なくともWindowsとLinuxの違いに良くも悪くもストレスは感じるのではないかと推測できる。
例を挙げれば、よく言われるようにLinuxにはPhotoshopやIllustratorは提供されておらず、ゲームの選択肢も少ない。逆にGIMPなどX Window Systemを前提に実装されているGIMPなどのアプリケーションはLinuxの方が軽く、パッケージ管理システムによるアプリケーション管理の容易さなどがある。
ちなみに父親はWindowsは高価なので誕生日プレゼントとしてならばWindowsを買える(おそらくCLIP STUDIO PAINTも同時購入)という道を示していた。
githubがmicrosoftに買収されることに対して江添が
「みんなgithubを利用するのはやめるんだ」的なことを言っていたんだが、（ここまではちょっと痛い程度なのでまだいい）
「成長性が…」「プロプライエタリが…」みたいなかなりフニャっとしたコメントしか挙げられてなかったのでやっぱりというか流石にというかインチキ認定せざるを得ない。
そもそも企業買収ごときで運営者が変わるわけじゃないんだからなんも変わらんだろ。
サービスとその親企業を紐づけんなや。そういうのをやってていいのはガキだけだぞ。
Made in Chinaの服着て中国製品の輸入にNOを唱えるアメリカ人じゃないんだからさ…
いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。
このGPLのコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。
確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェアの著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。
ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。
詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。
https://www.gnu.org/philosophy/free-sw.html
ほとんどの自由ソフトウェアのライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由を尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアのライセンスは、契約を元にするもので、契約はもっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。
わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンスが利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由であると結論づけるかもしれません。
また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフトで保護されたソフトウェアでも、それによって作成された著作物はGPLにならない(つまりコンパイラやパーサーのライセンスを継承しない)ことを根拠に考察しているようだが、実はbisonやGCCのGPLにはライセンスに対する例外が付属していることを考慮すべきである。
GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアのライセンスが影響しないことを確実にするためにこれらの例外を規定しているのではないか。
この二つの理由から、元記事の議論は世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。
加えて言えば、たとえフェアユースの規定が全世界的に利用できて、営利目的でなければ利用できたとしても、
自由.0: どんな目的に対しても、プログラムを望むままに実行する自由
(i.e. オープンソースの定義 6項 利用する分野に対する差別の禁止)
がある限り、そのような制限をディストリビューションは受け入れられないだろう。
またOracle vs GoogleのJavaのAPI訴訟はケースとしてはかなり特例であり、
一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、
これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか。
少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である。
というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである。
Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーがコンピューターの計算のコントロールを
持つべきであるという自由ソフトウェアの思想と明らかに相容れないものである。
このようなサービスを利用することの弊害として、(例えば)Google翻訳に翻訳処理の計算を依存することにより、ユーザーの入力をGoogleが常に把握することが挙げられます。
もちろんこれはあまり良いことではない。
多くのFLOSSシステムディストリビューションは自由なソフトウェアを主に入れるというガイドラインを持っている。
アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、
これは事実上妥協の産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者は異論を挟まないだろう。
また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物に依存する場合、contribというセクションに閉じ込めており、それは公式のシステムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)
Ubuntuコミュニティで新規に作られた著作物がコミュニティの哲学に反する物に依存するというのは、かなり致命的である。
たとえ奇跡が起こり、例外的にGoogle翻訳や一部のプロ用翻訳ツールがBSDライセンス(Launchpad上での翻訳用ライセンス)での出力を許したとしても決して褒められたものではない。
Ubuntuのbug#1に"Ubuntuソフトウェアは自由である。常にそうであったし、今後も常にそうである。自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである。
https://bugs.launchpad.net/ubuntu/+bug/1
この反論を読んだ読者の中にはあまりにGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、
いわゆる"Linuxディストリビューション"の中には数多くの重要なGNUソフトウェアがシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)
またUbuntuの派生元となったDebianの成立経緯にはやはりFSFが関わっている。
さらに言えば、システムの保守を手伝う人の中にはシステムがフリーだからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)
のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。
http://anond.hatelabo.jp/20140722001658
上で意味不明なことを言ってるので指摘しておく。
こういう勘違いする奴が多いが、これはMySQLサーバーが、デュアルライセンスだから大丈夫だという話。
ちなみにMySQLのGPLはv2なので、そもそも間違ってるが、内容は対して変わらんので、細かい指摘は無し。
クライアントにある。
MySQLの接続は独自でドライバでも実装しない限り、limbysqlclient.soやそれをリンクしたConnectorを利用することになる。
・商用ライセンス
商用ラインセンスを選ばない場合、GPL(FOSS除外規定)になるが、これを選択した場合、お前らの納品物はGPL適用になる。
もしお前らの納品物に、プロプライエタリのライブラリとの結合があれば、その時点でライセンス違反だし、そもそも納品物を勝手にGPL適用してよいか確認して契約しないと完全にもめる。
これは、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
そもそもFOSS除外規定で使えてるケースが多いのに、GPLで縛っちゃダメだろ。という無粋なアレは置いといて
今後絶対に、プロプライエタリなライブラリとリンクしない前提の
超小規模案件なら、ライセンシーの意図とは異なるが選択肢にはなるけど
webシステムでも絶対にソースコードが流出したらダメな場合はライセンスを買った方が良いです。
http://anond.hatelabo.jp/20140722001658
「Webシステムなのが問題なんだ。システムを使う人にソースコードを公開しないといけないんだよ。TOPページとかにリンクを貼るの？ソースコードはこちら、みたいなの。ありえないよね？」
これは大丈夫です。
GPLではソフトウェアの配布時に関係してくるので関係ないです。
これはグレーです。
なんとも言えません。
というのが脅し文句。
ようするに「裁判でどういう判決が出るのか（俺は）分からないので、怖かったら買え」ということ。
でもよく考えるとMySQLが出て長い年月が経ってるのにそういう事例が無い（少なくとも俺は知らない）って時点でリスクなんて無いと思う。
でもいまだにwebシステムでも前者の勘違いをして買ってくれる人が意外に多い。
http://anond.hatelabo.jp/20140722034243
これはMySQLクライアントを利用してDBに接続する多くのwebシステムではグレー。
MySQLに同梱されているクライアントソフトを使わずに自前でクライアントを作って接続してる場合は確実にGPL汚染しない。
前述の通りグレー。わからない。
一端GPL汚染したバージョンが出回った後でライセンスを変更するのは不可能だけど、
次のバージョンからGPL汚染しないように作り直して、ライセンスを変更すれば、
http://anond.hatelabo.jp/20140722143245
有益な話だし、GPL関係でググってこのページを見た人のために勝手に補足と個人的な疑問を放流してみる。
適当に調べてた知識を記憶をたよりに書いているので、間違いがあれば容赦なく指摘して欲しい。
# どうでもいいけど、元増田の話でOSがLinuxだったりしたら笑うw
GPLは元増田で書かれている通りで、WEBシステムを閲覧しただけではソースコードを請求することはできない。RMSらもこれには気づいていて、この穴を塞ぐためにAGPLというライセンスができた。このライセンスのソフトウェアを利用した場合、WEBシステムであろうと利用できる人はソースコードの請求を行えるようになる。
これは別にWEBシステムに限らず、ユーザーが何らかの形で利用できるシステムなら、ソースコードの請求が行える。
申し訳ないが詳しい所は知識不足でよくわからない。だけど、下記の記事の通り現在の開発元のOracleの見解である。すなわち、MyODBC(GPLのMySQL用ODBCドライバ)を使わず、GPLでないドライバを用いて接続してしまえば、開発したソフトウェアがGPLにならない。
http://plaza.rakuten.co.jp/matsunopage/diary/201011300000/
# 個人的にGPLがRMSの著作権Hackなら、OracleのコレはGPL Crackだと思っている。「GPL汚染が嫌なら有償ライセンスで契約しろ」と言われた話を聞いた事があるからだ。
おそらく持ち帰れないのではないかと思う。なぜそう思うかというと、普通、プログラマが書いたコードの著作権は会社に取られるし、GPLでライセンスされたソフトウェアを受け取ったのは会社であってプログラマ個人ではない。GPLでライセンスされたソフトウェアを物理的にもっていく事は可能でも、きちんとライセンスを受けた訳ではないので機密情報の漏洩にしかならないと思う。
単純な興味なのだけど、例えば最初はGPLだったが途中からはプロプライエタリ(ないし、GPL非互換なライセンス)に変更可能なのか知りたい。個人的な考えでは、著作権者全員の合意がとれれば可能という結論。著作物をGPLに書かれた通りに扱ってよいとしただけで、著作権者によって著作物の扱い方は変更可能だという考えから。無論、GPLでライセンスされたプログラムを受け取った人はソースコードの請求は依然として可能。
http://nippondanji.blogspot.jp/2010/06/gpl.html
http://d.hatena.ne.jp/karasuyamatengu/20110126/1296004598
なんで、グレーなのか。なんで、無理なのか。どのような考えでグレー、無理という結論を出しているのかきちんと書いてもらえますか？ 私の考えが間違っているならなぜ間違っているか指摘していただけますか？ あるいは、下記の増田さんのように具体事例を出してもらえますか？ プロプライエタリに戻せないというのなら下記の具体事例はどのようにお考えですか？
http://anond.hatelabo.jp/20140722071548
とした場合に、PHPを飛び越えて(間接的にしか接続していないにも関わらず)開発したシステムにGPLが適用されるということですか？ その場合、PHPにもGPL汚染が発生するということになると思いますが、間違いありませんか？(FOSS除外規定を設けているのはMySQLであって、FOSS除外規定と無関係な開発したシステムがGPLになってしまうと、開発したシステム側からGPL汚染が発生するという考えから。)
元のパラグラフは下記の通りです。
あと、MySQLのデータベースサーバに接続しただけではGPL汚染は発生しません(AGPLはそのためのものなのは前述の通り)。また、PHPは接続するクライアントになりますよね。ということは、MySQLと一緒に開発システムを一つのパッケージとして納品しない限りはGPL汚染は発生しないのではないでしょうか？(WEBシステムでそんなこと普通しませんよね。yumとかでインストールするし)
根本的な問題として、FOSS除外規定はGPLソフトウェアと他のFLOSSをリンクする際の問題を解決する物であって、MySQLのデータベースサーバに接続する場合には関係のない話だと思います。おそらく、問題だとお考えなのは、PHPのドライバがOracle製のGPLプログラムをリンクしていたためPHPのドライバを利用すればそのような問題が発生するという事だと思います(さらに追記。この通り書かれていますね。よく読んでおらず、失礼いたしました)。現状、PHPライセンスとなっているMySQL Native Driverを利用すればそのような問題は発生しないはずです。
http://php.net/manual/ja/mysqlnd.overview.php
かりに、おっしゃる通り、開発システムもFOSS除外規定に含まれるFLOSSにしなければGPLになってしまうとした場合、それはMySQL独自の問題であり、他のFLOSSに一律で当てはまる問題ではないということでよいでしょうか？ なぜこのような質問をするかというとMongoDBが同じような問題を抱えているからです。下記のURLの通り、MongoDBのコアサーバはAGPLですが、ドライバにApache licenseを適用し、開発システムにAGPL感染が発生しないようにしています。
http://www.mongodb.jp/mongo/licence
上記の様なケースにも実用的に対応する為、（AGPLを採用しつつも）我々はあなた方の（MongoDBを利用する）クライアントアプリケーションは（MongoDBとは）別物扱いする事を約束します。これを円滑に行う為、mongodb.orgサポートのドライバー（あなたのアプリケーションとリンクする部分）はApache licnese（コピーレフト）の元公開します。
返信お待ちしております。
冒頭に書いた通り、間違いがあれば容赦なく指摘してください。
https://www.gnu.org/licenses/gpl-faq.ja.html
GPLのプログラムをプロプライエタリのシステム・ライブラリとリンクしてよいでしょうか? (#SystemLibraryException)
GPLの両方のバージョンがコピーレフトに対する例外を有しています。一般にシステムライブラリ例外と呼ばれるものです。使いたいGPLと両立しないライブラリがこのシステムライブラリの範疇にある場合、これを使うのになにか特別のことは必要ありません。たとえこのライブラリを含むリンクされた実行形式を配布したとしても、全体のプログラムのソースコードを配布する要求にはこのライブラリは含まれません。
「システムライブラリ」になにがあたるかという範疇はGPLの異なるバージョン間で異なります。GPLv3は「システムライブラリ」を第一節で明確に定義して、「対応するソース」の定義から除外しています。GPLv2では第3節の終わり近くで少し違ったやり方でこの問題を扱っています。
というかこの例外事項がなったから おっしゃっているApacheライセンスなんかも成り立たないものが殆どになる。
ヘッダに書かれているライセンス条項や、リンクされるシステムライブラリは、それ自体を改変しない限りは、GNUライセンスは及ばない。というかそうでなかったら意味が無い。
主要論点でもなければ各論の話ではありますが、当該テレビドラマは表現が過激にすぎるし、放送時間帯からして様々な人に視聴可能性があり、実写で現実社会を舞台設定にしていることからイジメや誤解の原因になる可能性が高いものだと、私は思います。連続テレビドラマであっても毎話ごとに一本のコンテンツであって、いちいち毎話見続ける人ばかりではありませんから、「最後まで見てくれれば真意がわかります」というのは正当化する理由にはならないとも私は思っています。「あまり知られていないので啓発したい」という理由であっても、最初から最後まで見るのが想定されているような一本の映画などとは異なり、シリーズもののテレビドラマやテレビアニメなどでは一話単体で見られたときにどうなるか、という観点が必要です。
さてそれで、論点はそこではなくて、視聴率で測るのをやめたらどうか、という話ですが。
いわゆる民放で広告主がいるということになると、広告料を定め広告効果を測定するということが、少なくとも現在の業界では行われています。定量的に測定不可能だと、広告主を説得することが難しくなります。いまどきの企業は大概は、広告効果がないとやらない、カネにならないとやらない、と言います。費用対効果が適当でなければ経営者の責任問題にもなりますし、広告を打つ担当者や管理職の責任問題にもなります。そういうショボい社会ですので、「視聴率やめるべきだ」といった主張はずっと有力でありながら現実化していません。端的にいえば、いわゆる「民放」をやめて、視聴者がスポンサーになり、さらに言えば後払い方式にすればよいのかもしれませんが、それで売上が確保されるのかどうかというと、ショボい社会（ぶっちゃけて言えばみんなバカ）ですのでボランタリーに視聴料が払われてビジネスモデルとして成りたたたせることは難しいでしょうね。（それができるんだったら、例えば、ソフトウェアもプロプライエタリである必要はなく、Windowsなんかがデファクトスタンダードではなくなっているでしょう。強制徴収制度にしないとビジネスモデルとして成りたたないわけですよ。）。
あと、地上波デジタルと双方向という話ですが、そもそも地上波デジタルと双方向化ということがもともと論理的必然性がないものです。地上波デジタル化という結論が先にありきで（剛力彩芽でもないが）ゴリ押しし、その言いわけとして「双方向性」を主張してきただけのことです。そしてなぜデジタルテレビのリモコンの四色ボタンなんかいまほとんど活用されていないかというと、そもそもテレビというのが受動的なメディアだから見られてきたということと、言いたいことがあってもそんなボタンじゃ使えねーということなのでしょう。だから、言いたいことはメールやツイートで送るわけでしょう。まあ昔から、テレビ番組の双方向といえば、電話、ファックス、ハガキでしたよね。
こういう、一見正反対の記事が同時期に出てくるのはやはり面白い。
前者は、オープンイノベーションにより年々進化が加速するソフトウェアの世界で、停滞を選んだ技術に何が起こるかを象徴していて非常に興味深い。
Seasar2が冒険しないことによって、適切な大きさの問題は生まれなくなり、開発者が離れ、Seasar関連プロダクトが生まれなくなり、Seasarユーザも離れていく。使われないSeasarからさらに開発者が離れていく。
なぜ人はオープンソースプロジェクトに集まるか。そこに解決すべき課題があるからだろう。解決すべき課題が無ければ、人はプロジェクトから離れていく。
では、やはりカネでプロジェクトの求心力を維持できるプロプライエタリこそ一番信頼できる、無責任なオープンソースに依存するべきではないということになるだろうか？ しかし、ここ十年のソフトウェア技術の進化の大半が、プロプライエタリではなくオープンソースプロジェクトの成果であることを考えれば、もはやそのような選択肢はないだろう。
そして、単に人が居なくなるだけなら良いが、問題は、人が居なくなり進化が止まった技術は陳腐化して価値を失うことだ。
よく、「流行の技術が出てくるたびに次々と乗り換えるのは軽薄だ。枯れた技術こそ最後に生き残る」みたいなことを言いたがる人がいる。けど、一見、次々に現れるバズワードで似たようなバカ騒ぎを繰り返しているように見えても、なんだかんだで、一周した時点で世の中は前に進んでいるし、そのサイクルは年を追うごとに短くなっている。
で、それを象徴しているのが後者の記事だと思う。つまり、「枯れた技術は堅実」とか言って余裕ぶっていると、XaaSによって仕事そのものが消滅するケースが増えている。あるいは、そう簡単に自動化できない仕事を請けるにせよ、要求される技術水準は確実に上がってしまっている。
でだ…これらの台頭もあって、いわゆるインフラを全部外部まかせにすることになったとする。その場合、Webサービスの運用であったり足回りの整備であったりツール開発であったりを担当しているおれの主業務はほとんど奪われることになる。
昔から「技術者たるもの勉強し続けなければならない」みたいなことは言われていたが、今や、その言葉が意味するシビアさは格段に上がっている。泳ぎ続けなければ自身の生命を保てないマグロのように、先端技術へのキャッチアップを続けられない者は、速やかに技術者生命を失うことになるだろう。
我々の業界は、すでにオープンイノベーションを核とする過酷なエコシステムに組み込まれてしまっている。もはや、逃れることはできない。
市販ゲームをやりたくなった経験、プロプライエタリなソフトを使いたくなった経験が無いので答えられません。ゲームはゲーム機またはゲーセンでするものだとしか考えられないので。
そもそもOSセットアップとカスタマイズを上回る興奮を与えてくれる市販ゲームが地球上に存在したことがあるのでしょうか？あったら是非教えていただきたい。
Linux、*BSD、Un*x使いの人に質問。ゲームやりたいときってどうするんですか？ 自分はWindows使ってるから問題ないけど、すごく気になる。
rogueとかNetHackってのは無しでｗ いわゆる市販ゲームがやりたくなったときが知りたい。プロプライエタリなソフトなんて使わないの？
ぶっちゃけ、ゲームはWindowsが唯一凌駕している分野で、かつユーザの使い道としては最大の領域なんだと思うよ。俺もゲームさえしなければよろこんでFreeBSDにするんだけど、躊躇するんだよね。
