「BSDライセンス」を含む日記 RSS

はてなキーワード: BSDライセンスとは

2023-08-06

anond:20230806145401

もしかしてお前OSSを使って自社ソフトを作ったら、無条件でその自社ソフトOSSとして外部に公開しなきゃいけないとか勘違いしてねえか?

Apache2ライセンスMITライセンスBSDライセンスOSSなら、それらのOSSを使って自社ソフトを作っても、外部公開せずに自社のためだけに独占的に使えるぞ。

いま話題AIだってデファクトスタンダードライブラリ(PyTorch)がBSDライセンスOSSで、これを使って多くの会社が外部非公開の自社ソフトOSSを使って開発してるぞ。

OSSを使って開発するってのは、自社ソフトOSSとして公開することと同じじゃねーんだよ。

2021-09-18

革新的で軽量なブラウザー(自称)、Floorpブラウザを引き続きこき下ろす

Kinzaパッチが当たった正式版が公開されたので、引き続きこき下ろす

この間 https://anond.hatelabo.jp/20210828113740 を書いたが、DuckDuckGo経由で無事作者に見つかってしまったらしく、ここで指摘を入れた誤字、インストール場所、公開ソースコードのREADMEが全てではないが直ってた。ここ以外にもアンチがそれなりにいるみたいで、作者のTwitterを見る限りメンタルが削られていたようだ。(あれだけTwitterアンチコメントがあったのを知ってたのに、中途半端覚悟エゴサたからじゃないの?と言いたいが)

アンチあんなにいるのは人気がある証拠ではないかもっといろんな人に知ってもらうまたとないチャンスだ。

誤解しないでほしいのは、こき下ろしているのは学生の合間に作った革新的で軽量なブラウザー自称ではなく価値あるブラウザになることも期待しているかであるブラウザ作る奴なんてほとんどいないから。

利用規約が長すぎる

以前利用規約での遊びがひどすぎてふざけてんのかと書いたせいかは知らないが、アップグレードちゃんアップロードになっている、個人の感想がなくなっているなど、おふざけはなくなった。しかし、利用規約が以前と比べて長すぎる文章になってしまっている。しか利用規約に書くべきではない内容はそのままどころか増えているし、もう少し整理できたのでは?

以前、「Ablazeの利用規約に沿って」という文に対してAblazeの利用規約をここに載せろと言ったが、掲載されたのはその利用規約ではなくプライバシーポリシーだった。「Ablazeの利用規約」は「Albazeのプライバシーポリシー」のことなのか?「Ablazeの利用規約」はホームページにも掲載されていないので、結局の所それに何が書かれているのかわからない。何が書かれているかからない「Ablazeの利用規約」に同意しようがないので、この利用規約に真面目に従えばAblazeの関係者と同団体に盲信する人を除いてFloorpブラウザ規約上誰も使えない代物である。どうせ誰も見ないでスルーして使っているだろうが、きっちり書くべきところがきっちりできていないのは問題である

所々「書いとけばいいんでしょ」感が出てしまっていて、ただでさえ読まれない利用規約さらに読む気のしないものになっている。ここまで長くなったのなら、規約本文の見直しをした上でその中にあるプライバシーポリシーを分けた方が良くないか?工夫・配慮が足りない。リリース予定日に追われて、利用規約に割く時間がなかったのだろう。

それにしても、あれだけ長くなってもChromiumライセンス情報が未だに書かれていないのはどういうことだろうか。著作権表示と許諾表示をドキュメントに書くことが条件になっているので、「BSDライセンスに従って」という書き方ではダメ。その表記で済ませるなら、ドキュメントファイルとかURLとかを明記しないと。Kinzaパッチのことよりも憂慮するべきことではないのか(これも結構長いのでChromiumと同じようにすればよいのでは?)。

Chromiumバージョンが89に大幅ダウン

Kinzaパッチをそのまま当てられるようにしたことで、バージョンがDevチャネル相当の95から89に大幅ダウン。Kinzaパッチが公開されてからわずか2週間でリリースできたのはこれが理由だろう。Kinzaの言ってるとおり古いバージョンのままでは危険で、常用は避けるべきである

ちなみに、https://developers-jp.googleblog.com/2021/04/chrome.htmlの通り、Chrome94からメジャーバージョンアップの頻度が6週間から4週間になるらしいが、メジャーバージョンアップについて来られるのかが疑問であるメジャーバージョンアップした正式版に期待が寄せられると思ったが・・・(次節に続く)

(!) Kinzaパッチ適用2022年まで

Kinzaパッチは何回も言うけど2022年までしかサポートしない。

というツイートが。あれ?このブラウザって「Kinza派生ブラウザ」だよね?たった1年ちょっとで終わりなの?

Chromiumメジャーバージョンアップにかかる手間のことを全く考えていなかったようだ。Kinzaが終了した理由に開発継続に対するコスト問題があるって書いてあったのに。その意味理解できていなかったのか。2022年まではやると言っているようだが、パッチ適用時のエラー量が多すぎて挫折しているのではないか本業学生なんだし、本業を優先するゆえにKinzaの後釜になれないのも仕方のないことだろう。というより、ブラウザ開発は本業と両立できるほど甘くないのでは?

2022年までの理由は、受験を控えているかららしい。受験は作者の人生を左右する大事ことなのでしょうがない面もあるが、Ablazeという非営利団体(?)にはそれをカバーする人が今はいないということも言える。要するに、2022年を過ぎるとメンテナンスする人が誰もいないことになる。早くもFloorpの将来性が危うい。

"(見せかけの)" メモリ使用量は、他ブラウザと比べ、最大で75%削減されました。

Fireminによる見せかけのメモリ使用しか見ていないのは相変わらずのようで、大変残念。あれだけこき下ろしたのに懲りないね

以前

メモリ使用量が少ないのは見せかけ

なんて書いたら某動画で「変なこと言ってる」と言われたが、その動画でもやっぱりWindowsタスクマネージャーの一部分しか見てなくてお前もかよ。恥ずかしい人は作者だけじゃなかったわけだ。まあ仕方ないよ。Floorp軽い!って先に体感してしまってろくに検証せずそれで終わりにしたんだから

しかメモリ圧縮効果はあるからメモリ不足気味な低スペックPCなら有効かもしれない。けどな、Fireminを他のブラウザでも有効にしたら同じ効果が得られるぞ。ChromeなんかもWindowsタスクマネージャーメモリの所を見たら数MBになるから。実際そこまで減らないけどな。

落書きに書いてある

メモリリーク解消した!」と勘違いしてる馬鹿にはピッタリ

は全くその通り。そう思い込む奴が出てきた一因はこの間裁判に負けたギガなんとかが記事を書いたせい。あと前に言い忘れたけど、ページアウトするってことは、ページファイルへの書き込み頻度が上がってディスク寿命を縮めるからメモリに余裕がある人はFireminは止めとけとだけ言っておく。

FLoCはまだ削除されていない

次のバージョンに持ち越しか

ソフトウェア特許無頓着

FloorpにはFFmpegH.264AACデコーダが入っているが、それらは特許技術保護されている。特許の入ったコードバイナリで配布することに関して、FFmpeg特許侵害の責任は一切持たない方針をとっているので、一部の例外を除いて特許ライセンス管理しているMPEG LAVia Licensingとライセンス契約を結ばなければ特許侵害になる。

非商用ならライセンス料がかからないが、個人もしくは非営利団体からライセンス料がかからないとは限らない。広告収入を得ている場合は非商用と見なされない可能性がある。将来ライセンス管理会社からライセンス料を請求される、最悪の場合特許侵害で裁判沙汰になるので覚悟しよう。ちなみにこれがKinzaが当初はH.264AAC(と当時はまだ特許有効だったMP3)の再生ができなかった理由であり、独自実装となった理由である

一番軽量は譲る気なし

以前言ったことが直ったものもあるが直ってないのもいくつかあって、特にhttps://github.com/Ablaze-MIRAI/Floorp-Browserの一文

Chromiumで一番軽量なブラウザの一部のソースコードです。

象徴的。「大部分の」は直ったが、どうやら「一番軽量」は直す気がないらしい。その誇大広告を直す気が無いのなら、なぜ一番軽量と言い切れるのか証拠を出しましょう。まさかあのメモリカスタマイザーが同梱してるからどの派生ブラウザよりも軽いんだよ、とか言い放つ気ではないだろうな?他のブラウザにFireminを入れてもなお軽いことを示してみてね。頑張って♪

Chromium派生ブラウザを初めてインストールした時に軽いとかほざく奴がいるけど、あれ何も入ってないまっさら状態のせいだからな。履歴とかクッキーとかキャッシュとかがたまりにたまったブラウザと比べるから軽いって錯覚するだけで、地道なChromiumコード改造とかしない限りメモリの使い方もパフォーマンスほとんど同じ。改造以外に差があるとしたらビルドの仕方ぐらい。比べるのはプロファイルを全部コピーして同じにしてからだ。

その思想危険

Floorpは他のブラウザ拡張機能インストールする!!危険!!!

って意見を持つ必要はありません。FloorpはChromeウェブストアの審査を通過した場合のみ、その機能採用します。Googleの厳しい審査を受けている為、安全です

というTwitter発言大事なことを忘れている。Chromeウェブストア経由でインストールするのはGoogle審査があるという意味では安全だが、ストア外からインストール安全とは言ってない。審査の通ったファイルが変化なくFloorpに入っている保証ができるのか?Floorpを信用するならインストールすればいいと思う。ソフトウェア署名がないか改ざんされてないか検証できないけどな。サーバーが乗っ取られて偽ファイルダウンロードされるような事態を想定できている?何のためにストア外の拡張機能インストール管理者権限が必要になったか理由わかってる?

まあ学生が作ったブラウザを信頼するかしないか問題だな。どうなっても誰も責任は取ってくれない。

ほか

今の段階だと、Chromiumバージョンが古くてセキュリティが怪しいFloorpをわざわざ入れるまでもないんじゃないのか?FloorpSyncというxBrowserSyncベースブラウザ同期の機能はxBrowserSync拡張機能さえ入れればどのブラウザでも使えるし、そんなに(見せかけの)メモリ使用量削減効果を見たいならFireminを入れればよいわけだし。

FloorpSyncはxBrowserSyncから名前変えただけじゃないの?まあ日本語対応ブラウザの作者がやったらしくそのことは評価できるが、Floorp自体はまだこれといった特徴がない。特徴がないのは開発が始まったばかりで仕方のないことだが、Kinzaパッチ適用した後どうするかが特になく、将来どうしたいのかがよくわからない。挙げ句の果てにKinza派生系は2022年までという期限が付いてるし。

まあめんどくさがりにはいいんじゃない?同期やらメモリ節約やらを勝手に入れてくれるんだから

何で批判多いのか自覚がないのは痛い。そういう厚かましさと根拠のない自信がアンチを生んでるんじゃないのか。もうエゴサしてないらしいからこれを見ることはもうないだろうがな。これを書いた屑なアンチを乗り越えてこそ本物だからメンタル崩壊してる暇はない。しっかりしろ

オープンソースソフトウェア名前を変えて、それらを寄せ集めただけのブラウザで終わるのか、このブラウザならではの特徴を持ったブラウザに成長するかは作者次第。今のところは前者で開発終了になるのが目に見えている。いろいろな人から期待されている割には軽い気持ちで作っているように見受けられ、ブラウザ開発の覚悟が足りていない。

2021-08-28

革新的で軽量なブラウザー(自称)、Floorpブラウザこき下ろす

Floorp ウェブブラウザと名乗るブラウザ最近出てきて、開発が終了したKinzaパッチが公開されたら取り入れると宣言してKinzaの後釜を狙ってるらしい。中の人学生(中学生高校生?)らしく、使っていくうちにチャラさ、痛々しさが目立ってきたのでこき下ろしていきたい。

このブラウザが気になってしょうがない人はTwitterアカウントに行けばダウンロードリンクがあるのでダウンロードして確かめればよい。

※以下の話は、断りのない限り8/28に公開された公開ベータ版(v1.1.3)のことである

使用許諾契約書に突っ込みどころが多すぎる (v1.1.3)

インストーラーを実行するとまず使用許諾契約書が出てくる。

*Floorpブラウザ利用規約

---------------------------------------------------------------------------------------------------------------------------------------------

Floorp デベロッパープレビュー利用規約

1.Floorpをお選びいただきありがとうございます。高速で軽量なブラウジングをお楽しみください。

2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、ChromiumライセンスBSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。

3.Dev Previewエディションの場合TwitterなどのSNSスクリーンショットなどをアップグレードしないでください。

4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。

5.Ablazeの利用規約に沿って本ソフトをご利用ください。

6.以下に表示されている利用したオープンソースソフトウェア感謝しましょう。Floorpはこれがなければ実現しませんでした。

7.開発者はあまりすごいことをしていないことに気づきましょう

8.ソースこちhttps://github.com/Ablaze-MIRAI/Floorp-Browser

---------------------------------------------------------------------------------------------------------------------------------------------

利用したオープンソースソフトウェア

[※以下略]

さて、どこから突っ込もうか。

Floorp デベロッパープレビュー利用規約
いやこれ、公開ベータ版でしょ?
Floorpをお選びいただきありがとうございます。高速で軽量なブラウジングをお楽しみください。
これ、規約内に組み入れる必要あります
スクリーンショットなどをアップグレードしないでください
アップグレードwwwwwどうやったらアップグレードできますかね?めっちゃ草生えたわ。
感想やご不明な点がございましたら、お聞かせください。これは義務です。
あったら教えてなのに義務と言い切る。どっちなんだよ。
Ablazeの利用規約に沿って本ソフトをご利用ください。
それなら「Ablazeの利用規約」とやらをここに載せろよ。超不親切。
開発者はあまりすごいことをしていないことに気づきましょう
これ、規約内に組み入れる必要あります

8/29公開版(v1.2.4)の使用許諾契約書は遊びすぎ

*Floorpブラウザ利用規約

---------------------------------------------------------------------------------------------------------------------------------------------

あああああああああああああああああああああああああああああああ開発つかれた

1.Floorpをお選びいただきありがとうございます。高速で軽量なブラウジングをお楽しみください。

2.Floorpのソースコードは一部をAblazeのGithubにて公開しています。また、ChromiumライセンスBSDライセンス」に基づき、作成者は本ソフトウェア(Floorp)によって発生した損害は保証できません。

3.Dev Previewエディションの場合TwitterなどのSNSスクリーンショットなどをアップグレードしないでください。

4.感想やご不明な点がございましたら、お聞かせください。これは義務です。Floorpの改善に協力してください。

5.Ablazeの利用規約に沿って本ソフトをご利用ください。

6.以下に表示されている利用したオープンソースソフトウェア感謝しましょう。Floorpはこれがなければ実現しませんでした。

7.開発者はあまりすごいことをしていないことに気づきましょう。後眠いんだけどどうしよう?癒してください!彼女ください()

8.Floorpは有志によって無料提供されています寄付は受け付けますのでダイレクトメッセージ https://Twitter.com/Floorp_Browser へお越しください

9.ソースこちhttps://github.com/Ablaze-MIRAI/Floorp-Browser

[※以下略]

利用規約をなんだと思っているんだ。「利用規約は楽しく、ユーモアにありふれさせたい」とか「Floorpの利用規約最後に・彼女になることに同意しますか?って書けば同意させられんじゃん」とかつぶやいてる時点でなめてるしふざけてる。

公開されているソースコードタイトルが痛い

Ablaze-MIRAI/Floorp-Browser: Chromiumで一番軽量なブラウザの大部分のソースコードです。

というタイトルなのに、実際に公開されているのはブラウザコンポーネントに比べてかなり少ない。これのどこが「大部分」なの?

あと何の根拠もなく「Chromiumで一番軽量」って言い切ってるだけで相当痛い。一番軽量かどうかは知らんが、メモリ使用量が少ない=軽量と思い込んでる節がある。ほか、

Chromium本体BSDにのっとって公開なし

という文は誤解を生むから今すぐ止めろ。これだとBSDライセンス違反するぜ!と宣言してるような解釈もできるから利用規約OSS感謝しましょうとか言っておいてこの扱いひどくないか

ブログ記事も痛い

このブラウザ自己紹介記事(https://blog.ablaze.one/573/2021-08-16/)が先週公開されていたが、ここに書かれてる内容も相当痛々しい。

メモリ使用量が少ないのは見せかけ

ブラウザインストールするとメモリカスタマイザーなるものが同時にインストールされる。これが動作することでFloorpブラウザメモリ使用量が劇的に減ってるから軽い、ということらしい。

しかし、ブラウザを起動したまま放置してみてから、実際のWindowsタスクマネージャーの様子をよく見てほしい。メモリ使用量が数MBとありえないぐらいまで減っているのがわかるだろう。Windowsタスクマネージャー上ではメモリ使用量が減っているように見えるが、ブラウザタスクマネージャーで表示されるメモリ使用量はそれほど減っていない。では何が起こっているのか?

メモリカスタマイザーの正体はFireminである名前の通り元々はFirefox用で、仮想メモリにページアウトさせて物理メモリ使用量を減らすものらしい(実際の動作は細かく見てないのでよくは知らない)。Fireminの名称変更、起動時にFloorpを自動的対象にするといった改造を施している。FireminによってWindows10の途中の大型アップデートから搭載されたメモリ圧縮がより積極的にかかるようになり、物理メモリ使用量も減らせるメリットはあるようだ。YouTubeトップページを開いてしばらく待った時、メモリカスタマイザーの使用時と未使用時で約0.1GBの差はあるのは確認できた。ただし、メモリ圧縮の代償はパフォーマンスの低下。特にページアウトによりディスクI/Oが増える。ディスクI/Oが足を引っ張って重くなる場合があるので、必ずしも軽いとは言えない。

結局の所、Chromiumを改造するなどの根本的な解決策を取っているのかは疑問である(もししているならTwitterなりに書いているだろう。技術アピールができるし)。Floorpブラウザの作者はWindowsタスクマネージャーに出てくる見せかけの数値だけを見て「えっ、Floorp軽っ、、、、、」とか言ってるのだから、実に恥ずかしい。いつ気がつくか見物である

メモリ節約(?)のせいでパフォーマンスが落ちる

500ms単位メモリ節約機能動作するせいで、Speedometer 2.0ベンチマーク結果がさえない。未使用時と比べて7%ぐらいスコアが落ちてる。Edgeよりもスコアが良くない。メモリ使用量のことばかり気を取られて、速度のことには関心がないのかもしれない。

インストールされる拡張機能が他のChromium派生ブラウザに影響を与える

Chrome Web Store外から拡張機能(Deepl翻訳と同期機能)をインストールさせるためにレジストリ使用した結果、他のChromium派生ブラウザ(SRWare Ironで確認済)でも拡張機能インストールされたという通知が表示されるようになってしまう。

その他

インストール先がCドライブ直下

Cドライブ直下フォルダー作ってそこに入れるとか、いつの時代ソフトだよ。Program Filesに入れてやれよ。

FloorpLuncher.exe

スペルミスウケるwwwこれじゃ昼飯食う奴じゃんwww

Wikipediaの該当記事が早々に削除されそうになる事態

https://ja.wikipedia.org/wiki/Wikipedia:%E5%89%8A%E9%99%A4%E4%BE%9D%E9%A0%BC/Floorp

https://twitter.com/surapunoyousei/status/1431961462734352385

作者から依頼されて書かれた記事客観的証明なんてどうやってするんだろうね。

本番はこれから

まあKinzaパッチが出てからが本番っぽいし、それまではこれぐらいにしておこうか。

メモ

Uniant Browser → Floorp Browser? UniantとAblazeの関係がよくわからん個人で開発してるのか寄り集まって開発してるのかもよくわからん

2022/2/8 追記

中の人Twitter中学生と書かれていたことがあったので、高校生ではないかもしれない。高校生表記から学生(中学生高校生?)」に変更した。

2021-01-15

web

web

web

web

web

web

web

元々、10年前からアプリに組み込むアイコンInkscapefontforgeを使ってfontを作っていたので、この作業自体は苦ではなかったんですけど、本来適当ロゴを作りたいという所からするとかなり無駄作業です。

クリエイターってそんなもんですよね。一応 覚悟を決めて半日ぐらいで全ての工程を終わらせるという目標はありましたけども…

(因みにこの半日というのは、個人的に飽き性なのと、時間がかかると最初最後クオリティが変わってしまったりして「沼」に嵌ってバイナリ化せずに終わってしまいそうだったからです。

カーニングとかちゃんとやりだしたら絶対半日じゃ終わらないと思いますorz)

結果、すんごく微妙ものができあがってしまう…

うん、短時間で頑張った割りになんか微妙な感じになってしまった…(ヘッダー画像をご覧になれば分かると思います

普通に使うと下のような感じなのでサンレッドっぽいですね。

画像2

fontを作ろうと思った理由(の後付け)

クォリティは別として、私が働いているBrewusは「MONOZUKURI Platform」を掲げています

その上でエンジニアライブラリデザイナーは素材やfontを使うことが多々ありますが、とは言え「ないもの」が存在するのも事実です。

で、単純な話「なければ作ればいいわけ」ですし、作れる技術知識を身につければいいわけです。

使ってるツールInkscapeだったりfontforgeなので、Windows/Mac/Linuxどの環境でも「無料」で作ることができます

たかだかこんなもののためにお金払うのって微妙だったりしますよね?(というか有料ソフトウェアあり気だとその時点で学生の方とかにハードル高すぎると思います。)

間口は広くしておくことも大事です。

念のためDLページ用意してます

ここまで読んでもらった方ありがとうございます

こんなfontでも使ってみようと思う方は、Githubにおいています

気が向いたら更新しますが、これは作り切りだと思っています

fontforgeで生成したものBSDライセンスになるはずなので、一応権利作成者の私に帰属するはずですが、他はご自由に使ってください。使って面白いと思った方はこの記事ハートマークでも押してもらえると幸いです。

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-09-09

国産ブラウザKinzaこき下ろす - ThinkIT記事

突然、宣伝インタビュー記事(https://thinkit.co.jp/article/10488)という燃料を投下してきたので、http://anond.hatelabo.jp/20160616172213に引き続きこき下ろす

なぜ「国産」にこだわるのか

これは上記記事とあまり関係ないのだが、ホームページなどで特に目立っているので、あえて書くことにする。

メジャーブラウザであるIEEdgeFirefoxChromeSafari国産ではない。そのせいなのか知らないが、やたらと「国産」を強調している。

しかし、国産であることのメリットはあまりない。あるとすれば、要望バグ報告などのサポートが(製作者にとって)やりやすい、要望が通りやすいぐらいである。ただ、国産でなくても、サポート体制がしっかり整っているところは少なくなく、国産の優位性はさほどない。

エンジン国産ではなく、ただのChromium派生ブラウザであるセキュリティ問題報告に対して報奨金制度を出して安全にすると言いたいのだろうが、国産から安全というわけでもない。国産ブラウザは全体的に多機能・重量級な傾向にあり、それを嫌う人には全くメリットにはならない。

たったこれだけのメリットのためだけに、なぜ国産と強調することにこだわるのだろうか。

ローカライズ認識が甘い

機能ローカライズがそこまで必要ないので、日本で認められれば海外でもヒットする可能性が十分あると考えています

これは認識が甘い、と言わざるを得ない。というか、無理だろうと言いたい。

ユーザーの声で進化するブラウザ」を謳うのであればサポート体制の強化が必要である

しかし、いくらサポート体制を万全にしても、地理的に離れていることもあり文化が異なる。国が変われば求められていることも変わるが、もし特定の国を優先するならば、世界中ユーザーの声を聞くことは不可能である。無理に行うと妥協点を探すことになり、下手をすれば誰も求めていない機能が出来上がる恐れがある。ローカライズすると妥協点を探すことが多くなり、日本国内だけを相手にしていた時より困難になりそうだ。

その上、ユーザー要望機能を揃えただけではただの器用貧乏であるブラウザの将来性が感じられない。それでは海外では受けないのではないだろうか。

ブラウザの将来(1) ユーザーメディアの橋渡し?

意味不明。これはつまり、将来的にはアドウェアになる、ということを遠回しに言いたいのか?(たぶん違う)

例示した「セキュリティ問題になる危険リンク自動排除する」は非常に危険。これが実現すると、一企業恣意的操作できるので、よほどD社への信頼がない限り不可能ではないだろうか。「中国系外資系社員が作ったブラウザ?」と勘ぐられているのでは道のりは長いだろう。

ブラウザの将来(2) 法人向け展開だけ具体的

特定業界法人向けに専用ブラウザを開発していくプランもあります」というビジネス展望があるそうだ。私企業なので、こうした利潤追求は当然であるしかし、この文脈だけだと、コンシューマー向けには具体的な話がない。似たようなスタンスであるVivaldiのような期待はしてくれるな、ということか。

ブラウザの将来(3) モバイルファースト断念

マネタイズが難しく、市場的にも先細りな将来しか見えてこない(MSがやめたくてしょうがない)デスクトップアプリよりも、マネタイズのやりやすスマホ向けに力を入れるほうがよいはずなのに、可能性を自ら捨てている。

アプリストアのリジェクト不安からやめたって、規約が厳しいiOSならともかく、ゆるゆるなAndroid向けをやらないのは意味不明。これでは「うちには全然技術がないから無理」と言っているようなもの。あるいは、できる人を入れる余裕がないということだろう。

OSSではない理由が表面的すぎる

先に断っておくが、元になっているChromium修正BSDライセンスなので、そのライセンスの条件を守っていればChromium派生ブラウザソースコードを公開する義務はない。Google Chromeがその例である

さて、この記事ではOSSにしない理由

ブラウザを開発できる人はそんなに多くないと考えたか

と回答したが、本音を言いたくなくて言い訳しているように聞こえてしまう。ブラウザを開発できる人数で公開するかどうかを判断したの?これでは開発者が多いほど外部の貢献者にバグ修正してもらえる可能性が高くなるので、バグ修正にかかる開発コストを0でやってくれることが期待できるという本音が透けているのだが。そういう本音事実かどうかはわからないが、ほかに考えられることは、外部の貢献者が増えることで発生するであろうD社内部で決めた方針のブレを防ぎたいからとか、パクられるのが嫌とかの理由晒したくないからとか、特に理由はないけどとりあえず言い訳しといたとか。


やはり、ブラウザの将来そのものについて具体的なことは何も書かれていなかった。ユーザー要望依存した受動的な開発体制から何も出ないのではないか。こんなことで国内シェアを増やすことができると思っているのだろうか。

Vivaldiでいいじゃん、Cent Browserでいいじゃんという人に対しては全然効果がないだろう。むしろ、墓穴を掘ったような感じである

2014-02-25

http://anond.hatelabo.jp/20140225111037

BSDライセンスのほうが有難いのは確かだけど、

実際問題になるのは、ゲームだったり、家電だったり、ソフトウェア不特定多数に配布される場合だけじゃん。

2013-10-15

LGPLライセンスの孫ライブラリを使う場合はどうなる?

LGPLライセンスライブラリを動的リンクする場合リバースエンジニアリングを許可しなくてはいけないらしい。

しかし、次の場合はどうなるのだろう?

アプリケーションAはライブラリBを動的リンクし、ライブラリBはライブラリCを動的リンクする」

CがLGPLライセンスで、BはBSDライセンス

この場合、Bはリバースエンジニアリングを許可しないといけないが、Aはどうなのだろう? AはCを間接的に利用するが、LGPLリバースエンジニアリング許可の強制力がAにも及ぶのだろうか?

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