タグ

ライセンスに関するAkinekoのブックマーク (16)

  • Golangでバイナリを配布するとき、go-licensesとgoxzを使って利用モジュールのLICENSE、NOTICEを同梱する - 理系学生日記

    Golangで作ったプロダクトを公開・配布するとき、課題となるのが利用するモジュールのライセンスです。 MITライセンスであれ、MPLライセンスであれ、利用するモジュールのLICENSEやNOTICEファイルを同梱することになるでしょう。 goxzとgo-licensesを使うと、クロスビルドした実行バイナリと利用モジュールのLICENSE等を含め頒布物を作成できるようになります。 最終イメージ 同梱されていることの確認 go-licenses ハマりポイント goxz まとめ 最終イメージ 最終イメージですが、以下のようなMakefileを用意しました。 プロダクトに設定したライセンスで利用できないモジュールがあるかどうかをlicense-checkで確認した後、cross-build.shを呼び出します。 .PHONY: license-check license-check: go-

    Golangでバイナリを配布するとき、go-licensesとgoxzを使って利用モジュールのLICENSE、NOTICEを同梱する - 理系学生日記
  • OSS ライセンスの最近の潮流: PolyForm License について

    まえがき開発中のソフトウェアのライセンスを策定するため、現時点でのベストプラクティスについて探っていたところ、ここ数年の OSS ライセンスの動向が面白かったので復習も兼ねてまとめました。 特に、Umbrel が採用したという PolyForm という新しいライセンス形態が面白かったので、これについて詳しく述べます。 なぜ今ライセンスについてまとめるのか私はソフトウェアやサービスをマネタイズする方法について興味があり、特にビットコインの応用について調べたりしています。 ビットコイン (Lightning Network) を HTTP で利用することで、Web API の課金方法の可能性は大きく広がることは間違いないのですが、これはあくまで単なる支払いの手法であって、広く使われる事を前提としたソフトウェアの開発を支える手法にすることは(それだけでは)難しいという問題があります。 ソフトウェ

    OSS ライセンスの最近の潮流: PolyForm License について
  • たくさんあるオープンソースライセンスのそれぞれの特徴のまとめ

    GitHubが、どのオープンソースライセンスを選択すればよいのか指針となるサイトを公開したので、それぞれの特徴を翻訳してまとめてみました。 Choosing an OSS license Apache v2 License GPL v2 MIT License Mozilla Public License Version 2.0 LGPL v2.1 BSD (3-Clause) License Artistic License 2.0 GPL v3 LGPL v3 Affero GPL Public Domain (Unlicense) No License Eclipse Public License v1.0 BSD 2-Clause license 備考:各項目の補足説明 最後の「備考:各項目の補足説明」に各項目の補足となる説明をまとめました。 Apache v2 License ソ

  • 「OSSライセンスの教科書」を読んだ - 覚書

    タイトル通りオープンソースソフトウェア(Open Source Software, OSS)のライセンスについて扱ったです。難解なことを筆者の経験を踏まえて平易に解説してくれているので、この手のことを知りたいと相談された場合は「これを読んでみてください」と勧められるでした。 OSSのライセンスについての知識は近年のソフトウェア開発者には避けては通れません。しかしこれを十分に理解している開発者は多くはありませんし、(とくに「コードだけ書いていたい」というタイプの人には)それほど興味をひく題材ではないというのが実情ではないでしょうか。この状況をなんとかしようと長年OSSに関わってこられた筆者が一石を投じたのが書です(多分)。筆者が技術者の目線だけ解説するだけではなく、弁護士のかたの監修を受けることによって法律家の目線からも解説しているという点で書は貴重です。私はこのようなを少なくとも

    「OSSライセンスの教科書」を読んだ - 覚書
  • OSSのライセンスを理解する(「使用」と「利用」の違い、知っていますか?) - Qiita

    最近、私的にDockerで遊んでいるのですが、Dockerを使っていると様々なライセンスを有したオープンソースソフトウェア(OSS)と遭遇します。自分が知らない間に著作権に抵触してしまうことが怖かったので、OSSのライセンスについて以下の流れでまとめてみました。 「ライセンス関連用語」を理解する 「オープンソースの定義」を理解する 「コピーレフト」を理解する 「主要ライセンス」を理解する 1.「ライセンス関連用語」を理解する OSSを理解するにあたって、まずは主要なライセンス関連用語の定義を理解することが重要です。私の場合は、「使用」と「利用」の違いや「オープンソースソフトウェア」と「フリーウェア」の違いについて、恥ずかしながら明確に理解できていませんでした。。。 【オープンソース・ソフトウェア(Open Source Software, OSS)】 ソースコードが無償で公開されており、誰

    OSSのライセンスを理解する(「使用」と「利用」の違い、知っていますか?) - Qiita
  • OSSライセンス参考資料 - $shibayu36->blog;

    OSSライセンスについて調べてたのだけど、毎回どこ見たら良いか分からなくなるのでメモ。OSSライセンスまじむずい。 Githubによる、オープンソースライセンスの選び方 | オープンソース・ライセンスの談話室 ざっと把握するための参考 たくさんあるオープンソースライセンスのそれぞれの特徴のまとめ | コリス いろんなライセンスの特徴知るために 自作ソースコードに、MITライセンスを適用する3つのやり方 | オープンソース・ライセンスの談話室 MITライセンスの適用方法 図解:Apache License2.0の特許条項 | オープンソース・ライセンスの談話室 Apacheライセンスについて オープンソース法 詳しくは

    OSSライセンス参考資料 - $shibayu36->blog;
  • Facebookの特許条項付きBSDライセンスが炎上している件について|こんぴゅ

    先月あたりから、オープンソースソフトウェア(以下、OSS)のライセンスのあり方について、Facebookを火種にして侃々諤々の議論が起こっているので解説してみる。 ASFがFacebookにNOをつきつけることの始まりは、Apache Software Foundation(以下、ASF)という著名OSSプロジェクトを多数保有する非営利団体が、Facebookが自社OSSに付加している独自ライセンス Facebook BSD+Patents license を「Category-X」リスト(禁忌リスト)に追加したことだ。 ASFプロジェクトは、Category-Xに含まれるOSSに依存してはいけない決まりがあるため、Facebook製のOSSに依存しているプロジェクトは、8月31日以降はそれらの依存を取り除いてからではないと新しいリリースが出来ない。影響を受けたプロジェクトは少なくとも C

    Facebookの特許条項付きBSDライセンスが炎上している件について|こんぴゅ
  • MITライセンスを1行1行読んでいく | POSTD

    全てのプログラマが理解すべき171語の文章 MITライセンス は、最も有名なオープンソースソフトウェアのライセンスです。この記事では、その内容を一行一行読んでいきます。 ライセンスを読む オープンソースソフトウェアを利用しているものの、これまでライセンス全文(原文:171語)を読む機会がなかった方は、大した量ではないので、今すぐ読んでください。あなたにとってライセンスが身近なものでないなら尚更です。理解できない箇所などがあれば、その部分は心に留めておき、明確にするようにしてください。これから背景や解説とともに、全文を分割して順番に紹介していきますが、大事なことは全容を頭に入れておくことです。 MITライセンス(MIT) Copyright (c) <年> <著作権保持者> ソフトウェアおよび関連文書ファイル(以下「ソフトウェア」)のコピーを入手する全ての人に対し、それらに関する無償のライ

    MITライセンスを1行1行読んでいく | POSTD
  • ライセンスの選択を恐れる必要はありません - Qiita

    この記事はCC BY 3.0に基いて公開されてゐるWebサイトChoosing an OSS license doesn’t need to be scary - ChooseALicense.comのコンテンツ各ページを翻訳し、単一記事として再構成、訳者による補足を追加したものです。 2017年5月9日に開示されたコミュニティガイドラインに伴って、記事の翻訳部分につきましては削除いたしました。 (この記事が削除または非公開化されない限り、編集履歴からお読みいただくことは可能です。) (訳註: この「はじめに」及び末尾の「訳者による補足」の章は原文にはなく、翻訳者(@tadsan)によるものです。記事の著作権表示及び元Webサイトの利用規約、免責事項、そしてこの記事についての訳者の見解について記します) (この記事の一部または全て ——ただしコメント欄は含まれない—— はCC BY-SA

    ライセンスの選択を恐れる必要はありません - Qiita
  • java-ja 第1.9.2回 チキチキ ライセンスって何ですか?

    7594591200220899443 @shyouhei 初参加なのでよく解らんのですが何持ってきゃいいの Check out "第1.9.2回 チキチキ ライセンスって何ですか?" on Sep 15th. RSVP at http://twvt.us/ruby192 #javaja22 #twvt 2010-09-15 15:38:48

    java-ja 第1.9.2回 チキチキ ライセンスって何ですか?
  • 開発ライセンスとプログラマーの自由

    2010年7月31日、虎ノ門にて開催された LL Tiger のセッション「開発ライセンスとプログラマーの自由」の発表資料です。Read less

    開発ライセンスとプログラマーの自由
  • 受託開発とGPL

    GPLに対する代表的な誤解・・・というかむしろ謎のひとつに、受託開発(SI)におけるライセンスの扱いがある。この点が明確になっていないため、受託開発において無意味にGPLを回避しようとしたり、GPLに対するFUDを流布することに対する原因になっていたりするように思う。フリーソフトウェアおよびオープンソースソフトウェアを愛する者として、そのような状況は断じて見過ごすことができない!!というわけで、今日はGPLを受託開発(SI)において用いる場合の注意事項を説明しよう。 GPLの使いどころ受託開発においてGPL(とその仲間たち=LGPL、AGPL)が登場するのは、第三者、つまり発注側でも受託側でもない者が作成したGPLのソフトウェアを利用する場合である。例えばGPLが適用されたライブラリなどだ。周知の通り、GPLのソフトウェアをリンクしたソフトウェアを再配布する場合は、そのソフトウェア全体に対

    受託開発とGPL
  • LGPLと商用利用にまつわる話 - kaisehのブログ

    商用アプリケーションにLGPLライブラリを組み込むにあたって、いろいろ問題があるらしいということは知っていましたが、それが具体的に何なのかは良く分かっていませんでした。 Javalobbyに2004年にポストされた「LGPL and Java」という以下のトピックと、そこで繰り広げられているFSF支持派(以下肯定派)とLGPLうざい派(以下否定派)のバトルを読んで、少し状況が理解できました。 LGPL and Java - FSF clarifies この論争で主に槍玉にあげられているのは、LGPLが定めている以下の点です(この原則自体、あまり正確には把握されていないんじゃないかな。特に3とか)。これらは、LGPLライブラリの商用利用の障害になる可能性があります。 LGPLライブラリにリンクするアプリケーションは、そのリンクの形態がいかなるものであれ、LGPLライブラリの派生物になる。した

    LGPLと商用利用にまつわる話 - kaisehのブログ
  • さまざまなオープンソースライセンスをまとめてみた。 - (apply-generic op . args)

    オープンソースライセンスをまとめてみました。 GNUのどや顔が好きです。 でも、自分ならBSDライセンスを使います。 <追記> 2010/05/09 19:00 はてブでApache Licenseもお願いします、とあったので追記しました。 unagiameさん、ご指摘ありがとうございますm(_ _)m MITまたはXコンソーシアムライセンス 要約すると、MIT Licenseとは次のようなライセンスである。 1.このソフトウェアを誰でも無償で無制限に扱って良い。但し、著作権表示および許諾表示を、ソフトウェアのすべての複製または重要な部分に記載しなければならない。 2.作者または著作権者は、ソフトウェアに関してなんら責任を負わない。 テンプレート BSD License(Berkeley Software Distribution License) 「無保証」であることの明記と著作権およ

    さまざまなオープンソースライセンスをまとめてみた。 - (apply-generic op . args)
  • GPLの境界線

    GPLを利用するにあたって度々議論されるのが「プログラムの境界」という問題である。GPLソフトウェアを改良または組み込んで別のソフトウェアを作成すると、頒布する際に新しく作成したソフトウェアのライセンスもGPLにしなければならない。ここで注意しなければいけないのは、どこまでがそのソフトウェアの「境界」なのかということである。言い換えると、どこまでが「GPLソフトウェアを組み込んだ」状態なのかということである。自分のソフトウェアをGPLで頒布しようと考えている人にとっては、境界線はあまり意識しなくてもいいテーマである。優れたGPLソフトウェア資産は利用し放題のワンダーランドである。しかしGPL以外のライセンスを利用したいと考えている人にとっては、どこまでならGPLのソフトウェアを利用しても構わないのか?ということを明確に把握していないと、後で著作権法違反で訴えられることになってしまうので注意

    GPLの境界線
  • OSI承認ライセンス 日本語参考訳 - Open Source Group Japan Wiki

    プロジェクトの全コンテンツは、オープンソース・グループ・ジャパンのサイトおよびGitHubサイトへ移動しました。 このWikiは、Open Source Group Japanが運営しています。Open Source Group JapanのWebはこちらへどうぞ。 リソースオープンソースの定義 オープンソースライセンス日語訳 GPLv3情報 ドキュメントライセンス 日語訳 最近の更新2020-10-12SIL_Open_Font_License_1.1 FontLicenses 2020-10-10licenses/zlib_libpng_license licenses/Zope_Public_License licenses/X.Net_License サイドバーサイドバーの編集 プロジェクトの全コンテンツは、オープンソース・グループ・ジャパンのWebサイトおよびGitHub

    OSI承認ライセンス 日本語参考訳 - Open Source Group Japan Wiki
  • 1