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

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

2019-04-05

世間的には同じSIerといわれる目立つ企業の話を書く

anond:20190326233147

に触発されて似たような記事を書く。

おそらく世間的には元増田SIerといわれる某目立つ会社の話をしよう。

この目立つ会社世間的には同じと見られているようだけど、意外と過ごしやす場所もある。

あくまで半径5m以内の話であって、もちろん環境の悪いところも結構ある。

開発環境普通

8GB i5のSurface Proとi7 16GBの開発用PCを使っている。営業メインの人はシンクライアントのみらしいが、開発部署なら

これぐらいは「頼めば」くれる。自動的にくれるわけではないのでそのへんは流行りのWeb系に比べると微妙かもしれない。

Windowsなのがクソといわれるかもしれないけどアルゴリズム関係の開発なので正直それほどこまってはいない。

Ubuntu環境必要場合は社内クラウドインスタンス立てるのも自由。また社員自由に使えるOpenStackクラウドとか

Slack風のチャットシステムGitLabもある。

上環境も普通

流石にアーロンチェアは買ってくれないが椅子はイトーキの5万円クラスのを支給される。机は個室やパーティションはくれないが

普通事務である

事務環境はだめ

流石に電話会議を自席でエンジニアが全員やるなんて光景は見たことない。

が、イヤホン音楽聞いてる人は基本的にいない。怒られはしないと思うのだが、雰囲気的に不可。

あとしょっちゅうしかけてくる人が多いのは結構うざい。

評価制度の納得感はない

完全に上司に気に入られるかどうかにかかっている。

古い方法へのこだわりはない

開発基準はあるが、「ちゃんと開発できる実力があるのならば」自由に開発できる。いつもチケット駆動で開発して

ユニットテストコードと同時に書いているが怒られたことはない。

ユニットテストコードと同時に書いて怒られる」という言葉意味がわからない人に説明すると、

SIerではユニットテストでN件以上バグが出ないと品質が悪いとみなされ、バグが出るまで延々とデバッグさせられる、

という文化がある。そのため、ユニットテストコードを同時に書いた場合ユニットテストの摘出バグ件数が0件と

認定されてしまい、追加でバグが出るまでひたすらデバッグさせられるという恐れがあるのだ。

ただそのようなプロジェクトは単にPL/PM無能なだけであり、最近ではそういう人は淘汰されてきた。

新しい方法技術の導入の難しさ

少なくとも開発部署として新しい導入の壁はほぼない。本人が開発できるのなら新しい技術でもどんどん使えという感じである

ただし、間接部署がとても足を引っ張る傾向がある。特に社内情シスは糞中の糞で、フリーソフトの導入ですら

1週間コース手続き強要してくる。MSDNライセンスを開発で購入しても、MSDNからダウンロードしたVisual Studio

情シスに無断でインストールしようものなら目の色を変えて説教しに来る。

残業時間評価

先程評価制度は気に入られるかどうか、という話をしたが、気に入られるかどうかに残業時間は大いに関係がある。

まり残業時間評価に直結する。なので私は去年度の月平均残業時間は-10時間程度である

何を言っているのか分からないという人もいるだろう。つまり、毎月の残業時間が60時間を超えるような人は

評価が下がるのだ。残業時間が60時間や80時間を超える場合上司幹部承認というとてもめんどくさい作業

しなければならなくなる。そんなのを毎月やってしまうような部下は当然だが評価は低い。

ちなみに残業は下命だからそれはおかしいという人もいるかも知れない。しかし、その目立つ会社はほぼすべての社員

裁量労働制採用しており、残業するかしないかはすべて個人裁量なのである

また当然だが残業代なんてもの存在せず、(たとえその月の残業時間が-50時間であろうとも)数十時間分の残業代相当が固定で支払われる。

スキル無関係の異動

業績のよい部署であればそれなりにやりたいことをやらしてくれるし、海外異動も基本は本人希望による。

ただし、業績が悪いところが解散するために徐々に人を無関係のところに放り出す、というのはよくある。

外資なら部署ごと売り払われることを思うとまだマシなのではないかとは思う。

社内技術への関心のなさ

社内でしか使われてない技術はみんな嫌いである。もちろんプロプライエタリソフトウェア製品をいくつか作ってはいるが、

出来が悪いものはことごとく嫌われている。その結果、糞アプリを量産していた部署の業績が悪くなったと

聞くが知ったことではない。余談ではあるがGitが使えないのは論外だし、SIerの標準言語であるJavaとその周辺技術は当然として、

若手はだいたいPythonの基本は一通りマスターしている。分析チームではそれに加え基本的Python分析ライブラリ

の使い方は大体マスターしているようである。40↑のおっさん連中は流石にそこまでではないが。

なんちゃってフレックス

コアタイム10から15時ぐらいである。そのため、私は12時ぐらいに出社している。

何をいっているのかわからないと思うが、コアタイム適用されるのは入社2年目までで、それ以降は

裁量労働制になるためコアタイムすら関係なくなるのである。ちなみに退社は19時ぐらいである。

リモートワークは予定さえあいていれば自由可能であるわたしは自宅にいることが結構ある。

人が均質的だがたまにすごいのがいる

尊敬できる人が少ないのはある。ただしたまにCVPRに通してる研究員や、現代的なReactのWebさらっと書いてしまうような

フロントエンド技術者、数千ノード分散システム開発者、競プロバリバリやってる人などを100人に1人ぐらいの割合ですごいのはいる。

未来のほの暗さ

これはイケイケのWeb企業でなければどこでも似たような感じなのではないかと思う。今の年収40歳手前で諸々込み1100万程度であるが、

かなりITバブル的な要素が多く、来年ぐらいまでは良いかと思うけど20201年以降はガクッと下がる可能性は高い。

転職可能

これだけ見るとSIerとしてはだいぶ恵まれいるかもしれないが、それでもやはり転職してしまう人が増えてきたのは確かである

今はITエンジニアバブルなこともあり、私と似たようなスキルの人では最高1500万のオファー結構あるときく。

大抵は1200万ぐらいでメガベンチャーあたりに行く人が多いらしいのだが、やはり年収と言うよりも

足を引っ張らない間接部署や、マネジメント業務なしの開発に集中できる環境を求めて出ていくようである

もちろんこの目立つ会社では、事務ソフトOfficeOutlookであるし、社内システムもクソで

MacBookなんて夢のまた夢だし、社内Proxyにいじめられる環境ではあるのだが労働時間の半分以上は開発に当てられており

残業時間マイナス年収もそこそこということを考えるとあまり転職モチベーションが沸かない。

一方で、一回ぐらい転職経験しないとスキル的にだめになってしまうのではないかという懸念はかなりあるので、

周りに転職者が出るたびに少し焦りがあるのも事実である

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しかないよね。クリエイターはどうするの?

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