「プロプライエタリ」を含む日記 RSS

はてなキーワード: プロプライエタリとは

2020-05-21

いまいちLinuxが好きになれない

いや、もうコンテナ技術とかLinuxに非ずんコンテナに在らずなのはしゃーねーかなーとか思ってはいる。

たださー、なんかオープンソース代表みたいな感じで扱われてるのが気にくわないんだよね。大体のドライバなんてプロプライエタリなもんだし。モノシリックからLSBとか使ってるし。

なにが嫌なのかなと思ってたら昨日のMicrosoftの発表を知って気づいた。DirectX12移植とか、WSL2とかやっほーと思う反面、なんでそんなことしてんのって思うんだわ。

WSL2とかWindowsに同居しすぎだろ。cygwinくらいでいいよ。なんか変に壊れそうで嫌だし、DirectX 12ってAndroidへの移植念頭なのか知らんがなんでそんなことしてんのと思うのだ。

まぁ、メンバーみたら大企業ばっかだからLPICみたいな感じになるのは仕方がないけど、なんかまだ言葉に出来ないけど気持ちわりーんだよなぁ。

高々カーネルなんだけどなぁ。

2020-02-22

独断偏見によるOS組み合わせで見るユーザーの傾向

複数端末持ちは考慮してない。

Windows x iOS/iPadOS

もっと無難な組み合わせ。

製品を選ぶことすら面倒。それどころか「無難さも性能の一部だろ」くらいに思っている。保守的な傾向があり女性率が高い。

macOSユーザーによる「iPhone使っているならMac使えば?」という言葉が大変ウザいと考えていて「ハードの縛りキツイし、もう少しコスパが良くなれば検討する」という評価

AppleによるIntel Mac移行期にマーケティングへ失敗しクリエイター需要Windowsへ移ってしまったため、クリエイターがこの組み合わせであることも多い。

Androidクリエイティブアプリケーションライナップが少なく性能も微妙なのでiOS/iPadOSを使わざる得ないという事情もある。

情報技術者が使っている場合「WSL2便利すぎワロタw」と喜んでいる。

Windows x Android

コスパ重視で多少の使いにくさも我慢できるという人の組み合わせ。

クリエイティブ用途はあまり考えておらず、価格対性能のコスパを重視する傾向にある。

Windows x iOS/iPadOS場合と同様に何も考えずこの組み合わせになっている年配がかなり多いが、IT技術者やゲーマーなどが採用することの多い組み合わせでもある。

手前勝手イメージだが圧倒的に若年〜中年男性率が高い。

Googleが大好きで何故かmacOS x iOS/iPadOSAppleユーザーを敵視していることもある。

好きな言葉は「最強」。

macOS x iOS/iPadOS

Appleの囲い込みによる製品連携シナジー恩恵を最大限に得ている。

MaciPhone/iPadどころかAirPodsApple Watch、HomePod、Apple TVも持っている。

意識高い系」と言われるのが大嫌いで、大抵の場合は「ユーザービリティを考えたら〜」と反論するものの、そのユーザービリティ自分個人のみを指すことが多い。

情報技術者の場合「安定したPOSIX互換機」という評価をしていて「iOS/iPadOS Appsが開発が完結できてプロプライエタリソフトが充実するならLinuxでも良い。あとサウンド周りな」と思ってる。

クリエイターがこの組み合わせの場合絵描きであることが多く、3DCGDTM場合Intel Macへの移行に遅れてしまった人が大半。

macOS x Android

一見して変な組み合わせ。実際ちょっと変わった人。

自分価値観にこだわりがあり、Androidが好きというよりも制限の多いiOS/iPadOSが嫌いと言った方が実態に近い。iTunesも嫌い。

データのやり取りはクラウドを経由するし意外とそこまで問題ないよ」が口癖。

Apple製品が好きだがGoogle製品も好き。何ならAmazon製品も好き。

Linux x iOS/iPadOS

しろiOS/iPadOS制限を開放することが目的の人。

正攻法では使いにくすぎるこの組み合わせにこだわるユーザーmacOS x Androidよりも物凄く変わっている。

iOS/iPadOS脱獄は当たり前、ていうかそうしないとLinuxではまともにiOS/iPadOSが使えない。

彼らの存在によってiOS/iPadOS脆弱性は明るみになりApple新製品情報も内部コードから発見してしまう。

Appleもっと自由にするべきだ」がスローガン

Linux x Android

完全にギーク不具合自分でなんとかするDIY精神にあふれる組み合わせ。

他所の良いものは悪びれもなくパクり、他所より良いものを開発したらドヤる。

何か言われても「ランレベルを1にして〜」とか「sudo pacman -Sy archlinux-keyring」とかおおよそのユーザーには理解できない呪言を吐く。

おおよそのユーザーそもそもそういうのが面倒なわけだが、そういう細かい心理は気にしない。

MicrosoftAppleをイジり倒すのも趣味にしており、彼らの口から一般人に知られていない面白い過去エピソードが飛び出すことが結構ある。

裏を返せば「お前ら何で他のOSがそんな詳しいんだwMicrosoftApple好きすぎるだろwww」ということなのだが、それは公然の秘密である

Chromebookは安く買えるLinux向けハードウェアだと思ってる。

2018-11-18

anond:20181117114626

2018-11-16

Java界隈はまた一私企業の打算に乗り換えて船出するらしい

Sun MicrosystemsOracleと一私企業の打算に乗っかり、彼らのリソースを食い潰してグズグズ文句たれて、Oracleギブアップして捨てられそうになって悲鳴を上げてたら、ギリギリになって乗り換え先の打算が見つかって大喝采

オープンソースJDKは既にあるのにそれを自分たちメンテしながら一私企業方針転換に振り回されない仕組み作りを作る方向には全然かわない。

どこまで行ってもプロプライエタリ文化がこびりついてる世界なんだな、Java界隈って。

2018-08-17

anond:20180817105012

linuxから分岐したプロダクトなのに突然どこかでプロプライエタリになったらペンギン集団でついばみにくるだろ。そういうことや。

分岐前の規約は最低限守れ。

2018-07-17

anond:20180717093647

Mastodon

そういやプロプライエタリ邪教視する江添っちも一枚噛んでいたような

2018-06-13

はじめてのパソコンOSとしてLinux子供に与えるのは虐待

現在では事実上、結果だけを見るのであればWindowsMacUNIXLinuxなどで実現可能課題は変わらない。

ただ、商業的に一定予算を持って開発されたプロプライエタリアプリケーションソフトウェアの中には、その実現可能課題までの手順を省力化できるものが多い。

システム実装の違いがあれどPOSIX基準実装され(サブシステムとしてPOSIX基準実装している場合もある)、操作性はCommonUserAccessを参考として実装されていることが大半でOSが違ってもほぼ迷わず操作することが可能だ。

これまで、こう言った話題類似したものに「iPhoneを求める子供Android端末を買い与えるのは虐待か?」などがある。

今回の話題の発端となったエントリでは娘さんはCLIP STUDIO PAINTを求めるまで、Linuxディストリビューションの1つであるUbuntuをある程度は使えていた様子が見て取れる。

更にUbuntuではファイルドラッグドロップによる移動操作などが当然可能であるが、娘さんはCLIの基礎的な操作まで行えるようになっており、PCスキルは同年代の子供よりも「できるほう」のようだ。

学校教育ではWindowsに触れていたようだが、Linux特性デスクトップ環境を変更することによって見た目や操作性を著しく変化させることが可能で、娘さんからすると「パソコンによって見た目や操作性に多少の違いはあるもの」という認識だったようで、WindowsLinuxOSプラットフォームとしての違いをそこまで気にしていなかったようだ。

娘さんは今回の件でWindowsLinuxの違いを認識していくようになるであろうが、この違いを経験することがプラスになるのかマイナスになるのかは、まだまだ稀少な事例過ぎて判別が難しいように思われる。

ただ、少なくともWindowsLinuxの違いに良くも悪くもストレスは感じるのではないかと推測できる。

例を挙げれば、よく言われるようにLinuxにはPhotoshopIllustrator提供されておらず、ゲーム選択肢も少ない。逆にGIMPなどX Window Systemを前提に実装されているGIMPなどのアプリケーションLinuxの方が軽く、パッケージ管理システムによるアプリケーション管理の容易さなどがある。

ちなみに父親Windowsは高価なので誕生日プレゼントとしてならばWindowsを買える(おそらくCLIP STUDIO PAINTも同時購入)という道を示していた。

2018-06-08

anond:20180608170838

そこそこ遡るとGNUがそんな思想なんだっけ?

でも結局プロプライエタリものが幅を利かせる結果になってるっつーか

2018-06-05

やっぱり江添インチキ

githubmicrosoftに買収されることに対して江添が

「みんなgithubを利用するのはやめるんだ」的なことを言っていたんだが、(ここまではちょっと痛い程度なのでまだいい)

それに対して「何故だ?」と聞かれたときコメントとして

「成長性が…」「プロプライエタリが…」みたいなかなりフニャっとしたコメントしか挙げられてなかったのでやっぱりというか流石にというかインチキ認定せざるを得ない。

そもそも企業買収とき運営者が変わるわけじゃないんだからなんも変わらんだろ。

サービスとその親企業を紐づけんなや。そういうのをやってていいのはガキだけだぞ。

Made in Chinaの服着て中国製品の輸入にNOを唱えるアメリカ人じゃないんだからさ…

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時)

2016-03-18

http://anond.hatelabo.jp/20160318220026

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

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

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

2014-07-22

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だけど持ち出し禁止にすれば問題ないとか言う人が居まして。。。

http://anond.hatelabo.jp/20140722001658

有益な話だし、GPL関係でググってこのページを見た人のために勝手に補足と個人的な疑問を放流してみる。

適当に調べてた知識を記憶をたよりに書いているので、間違いがあれば容赦なく指摘して欲しい。

# どうでもいいけど、元増田の話でOSLinuxだったりしたら笑うw

WEBシステムを閲覧した人がソースコードをよこせと言えるライセンスはAGPL

GPL元増田で書かれている通りで、WEBシステムを閲覧しただけではソースコードを請求することはできない。RMSらもこれには気づいていて、この穴を塞ぐためにAGPLというライセンスができた。このライセンスソフトウェアを利用した場合WEBシステムであろうと利用できる人はソースコードの請求を行えるようになる。

これは別にWEBシステムに限らず、ユーザーが何らかの形で利用できるシステムなら、ソースコードの請求が行える。

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

申し訳ないが詳しい所は知識不足でよくわからない。だけど、下記の記事の通り現在の開発元のOracle見解である。すなわち、MyODBC(GPLMySQLODBCドライバ)を使わずGPLでないドライバを用いて接続してしまえば、開発したソフトウェアGPLにならない。

http://plaza.rakuten.co.jp/matsunopage/diary/201011300000/

# 個人的にGPLRMS著作権Hackなら、OracleのコレはGPL Crackだと思っている。「GPL汚染が嫌なら有償ライセンス契約しろ」と言われた話を聞いた事があるからだ。

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

おそらく持ち帰れないのではないかと思う。なぜそう思うかというと、普通プログラマが書いたコード著作権会社に取られるし、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/20140722142248

なんで、グレーなのか。なんで、無理なのか。どのような考えでグレー、無理という結論を出しているのかきちんと書いてもらえますか? 私の考えが間違っているならなぜ間違っているか指摘していただけますか? あるいは、下記の増田さんのように具体事例を出してもらえますか? プロプライエタリに戻せないというのなら下記の具体事例はどのようにお考えですか?

http://anond.hatelabo.jp/20140722071548

http://anond.hatelabo.jp/20140722143245
FOSS除外規定のところ

開発したシステム<ー>PHP<ー>MySQL

とした場合に、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(コピーレフト)の元公開します。


返信お待ちしております

冒頭に書いた通り、間違いがあれば容赦なく指摘してください。

また、具体事例を上げていただいた増田さんありがとうございました。

2014-02-25

http://anond.hatelabo.jp/20140225112514

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

GPLプログラムプロプライエタリシステムライブラリリンクしてよいでしょうか? (#SystemLibraryException)

GPLの両方のバージョンコピーレフトに対する例外を有しています。一般にシステムライブラリ例外と呼ばれるものです。使いたいGPLと両立しないライブラリがこのシステムライブラリ範疇にある場合、これを使うのになにか特別のことは必要ありません。たとえこライブラリを含むリンクされた実行形式を配布したとしても、全体のプログラムソースコードを配布する要求にはこのライブラリは含まれません。

システムライブラリ」になにがあたるかという範疇GPLの異なるバージョン間で異なりますGPLv3は「システムライブラリ」を第一節で明確に定義して、「対応するソース」の定義から除外していますGPLv2では第3節の終わり近くで少し違ったやり方でこの問題を扱っています

システムライブラリはそれ単体を改変しない限り特例事項で例外

というかこの例外事項がなったから おっしゃっているApacheライセンスなんかも成り立たないもの殆どになる。

ヘッダに書かれているライセンス条項や、リンクされるシステムライブラリは、それ自体を改変しない限りは、GNUライセンスは及ばない。というかそうでなかったら意味が無い。

GPLの両方のバージョンコピーレフトに対する例外を有しています。一般にシステムライブラリ例外と呼ばれるものです

全体のプログラムソースコードを配布する要求にはこのライブラリは含まれません。

2014-01-17

http://anond.hatelabo.jp/20140117164316

主要論点でもなければ各論の話ではありますが、当該テレビドラマ表現が過激にすぎるし、放送時間からして様々な人に視聴可能性があり、実写で現実社会舞台設定にしていることからイジメや誤解の原因になる可能性が高いものだと、私は思います連続テレビドラマであっても毎話ごとに一本のコンテンツであって、いちいち毎話見続ける人ばかりではありませんから、「最後まで見てくれれば真意がわかります」というのは正当化する理由にはならないとも私は思っています。「あまり知られていないので啓発したい」という理由であっても、最初から最後まで見るのが想定されているような一本の映画などとは異なり、シリーズものテレビドラマテレビアニメなどでは一話単体で見られたときにどうなるか、という観点必要です。

さてそれで、論点はそこではなくて、視聴率で測るのをやめたらどうか、という話ですが。

いわゆる民放広告主がいるということになると、広告料を定め広告効果を測定するということが、少なくとも現在業界では行われています定量的に測定不可能だと、広告主を説得することが難しくなります。いまどきの企業は大概は、広告効果がないとやらない、カネにならないとやらない、と言います費用効果適当でなければ経営者責任問題にもなりますし、広告を打つ担当者管理職責任問題にもなります。そういうショボい社会ですので、「視聴率やめるべきだ」といった主張はずっと有力でありながら現実化していません。端的にいえば、いわゆる「民放」をやめて、視聴者スポンサーになり、さらに言えば後払い方式にすればよいのかもしれませんが、それで売上が確保されるのかどうかというと、ショボい社会ぶっちゃけて言えばみんなバカ)ですのでボランタリー視聴料が払われてビジネスモデルとして成りたたたせることは難しいでしょうね。(それができるんだったら、例えば、ソフトウェアプロプライエタリである必要はなく、Windowsなんかがデファクトスタンダードではなくなっているでしょう。強制徴収制度にしないとビジネスモデルとして成りたたないわけですよ。)。

あと、地上波デジタル双方向という話ですが、そもそも地上波デジタル双方向化ということがもともと論理的必然性がないものです。地上波デジタル化という結論が先にありきで(剛力彩芽でもないが)ゴリ押しし、その言いわけとして「双方向性」を主張してきただけのことです。そしてなぜデジタルテレビリモコンの四色ボタンなんかいほとんど活用されていないかというと、そもそもテレビというのが受動的なメディアから見られてきたということと、言いたいことがあってもそんなボタンじゃ使えねーということなのでしょう。だから、言いたいことはメールツイートで送るわけでしょう。まあ昔からテレビ番組双方向といえば、電話ファックスハガキでしたよね。

2013-11-09

ソフトウェア技術者マグロ、泳ぎ続けなければ死ぬ

こういう、一見正反対の記事が同時期に出てくるのはやはり面白い

前者は、オープンイノベーションにより年々進化が加速するソフトウェア世界で、停滞を選んだ技術に何が起こるかを象徴していて非常に興味深い。

一番の問題は、ユーザーコミュニティが消えてしまったということです。

Seasar2冒険しないことによって、適切な大きさの問題は生まれなくなり、開発者が離れ、Seasar関連プロダクトが生まれなくなり、Seasarユーザも離れていく。使われないSeasarからさら開発者が離れていく。

こういうスパイラルが発生するかもしれないことについては、どう考えますか?

なぜ人はオープンソースプロジェクトに集まるか。そこに解決すべき課題があるからだろう。解決すべき課題が無ければ、人はプロジェクトから離れていく。

では、やはりカネでプロジェクト求心力を維持できるプロプライエタリこそ一番信頼できる、無責任オープンソース依存するべきではないということになるだろうか? しかし、ここ十年のソフトウェア技術進化の大半が、プロプライエタリではなくオープンソースプロジェクトの成果であることを考えれば、もはやそのような選択肢はないだろう。

そして、単に人が居なくなるだけなら良いが、問題は、人が居なくなり進化が止まった技術陳腐化して価値を失うことだ。

よく、「流行技術が出てくるたびに次々と乗り換えるのは軽薄だ。枯れた技術こそ最後に生き残る」みたいなことを言いたがる人がいる。けど、一見、次々に現れるバズワードで似たようなバカ騒ぎを繰り返しているように見えても、なんだかんだで、一周した時点で世の中は前に進んでいるし、そのサイクルは年を追うごとに短くなっている。

で、それを象徴しているのが後者の記事だと思う。つまり、「枯れた技術は堅実」とか言って余裕ぶっていると、XaaSによって仕事のものが消滅するケースが増えている。あるいは、そう簡単に自動化できない仕事を請けるにせよ、要求される技術水準は確実に上がってしまっている。

でだ…これらの台頭もあって、いわゆるインフラを全部外部まかせにすることになったとする。その場合Webサービス運用であったり足回りの整備であったりツール開発であったりを担当しているおれの主業務はほとんど奪われることになる。

から技術者たるもの勉強し続けなければならない」みたいなことは言われていたが、今や、その言葉意味するシビアさは格段に上がっている。泳ぎ続けなければ自身の生命を保てないマグロのように、先端技術へのキャッチアップを続けられない者は、速やかに技術者生命を失うことになるだろう。

我々の業界は、すでにオープンイノベーションを核とする過酷エコシステムに組み込まれてしまっている。もはや、逃れることはできない。

2013-06-24

http://anond.hatelabo.jp/20130624130010

ブランチを作ってそこへの編集は許可するがマスターへのコミット権を与えない。

つか、そういうのがいるからPerforceとかのプロプライエタリコード管理ツールが有るんだけどね。

テストを通らないコードマージ拒否。

 

というか、コントリビューターとコミッタの明確な住み分け

過去のすべてのとはいわないが、過去の大多数のテストを通せない人間コミッタになる資格はない

2010-01-18

http://anond.hatelabo.jp/20100117225006

アプリが専用かどうかって話は、オープンソース関係で言われるところのプロプライエタリかどうかって話と一緒のような気がする。

それを言い始めたらオープンソースじゃないものはなんでもガラパゴスってことになってしまう。

2009-04-04

Qualcommプロプライエタリと思われるソースネットで見つけちゃったっぽいんだがどうすればいいんだ?

2007-06-22

anond:20070622174427

いわゆる市販ゲームがやりたくなったときが知りたい。プロプライエタリソフトなんて使わないの?

市販ゲームをやりたくなった経験、プロプライエタリソフトを使いたくなった経験が無いので答えられません。ゲームゲーム機またはゲーセンでするものだとしか考えられないので。

そもそもOSセットアップとカスタマイズを上回る興奮を与えてくれる市販ゲーム地球上に存在したことがあるのでしょうか?あったら是非教えていただきたい。

ここに書くような内容じゃないかもしれないけれど

Linux、*BSDUn*x使いの人に質問。ゲームやりたいときってどうするんですか? 自分はWindows使ってるから問題ないけど、すごく気になる。

rogueとかNetHackってのは無しでw いわゆる市販ゲームがやりたくなったときが知りたい。プロプライエタリソフトなんて使わないの?

ぶっちゃけゲームWindowsが唯一凌駕している分野で、かつユーザの使い道としては最大の領域なんだと思うよ。俺もゲームさえしなければよろこんでFreeBSDにするんだけど、躊躇するんだよね。

あー、Photoshopオープンじゃないよね。GIMPしかないよね。クリエイターはどうするの?

ログイン ユーザー登録
ようこそ ゲスト さん