すべての開発者は法的事項について何を知っておくべきですか？
今日 私はひどい驚きがありました GPLライセンスの含意について学びました。主に思ったほど自由に使用できませんでした。
今私は知っている。
私が他に知っておくべきこと、そしてもっと広く、すべての開発者はそのような法的事項について何を知っておくべきですか？
従業員、フリーランサー、オープンソースプロジェクトの貢献者（など）を分離したり、より広範な回答を提供したりできます。
ソフトウェア開発に関する12の法的考慮事項
一般に公開されているソフトウェアは著作権で保護されています。アプリケーションまたはソースコードに著作権表示を置く必要はなくなりました。著作権の所有者は、著者または著者を支払う会社です。
ソフトウェアの著作権は、著作権の所有者が割り当てることも、所有者が保持し、所有者がソフトウェアをユーザーにライセンスすることもできます。
開発で使用されるライブラリには、おそらくその使用と配布に制限があります。 GPLはライブラリをパブリックドメインにせず、ライブラリに開発プラットフォームが付属しているという事実もありません。アプリケーションを配布する前に、ライセンスを読んで理解する必要があります。一部の図書館では、ロイヤルティの支払いが必要ですが、これは近年ではあまり一般的ではありません。
ソフトウェア特許訴訟はくだらないシュートです。もちろん、ソフトウェア特許を故意に侵害するべきではありません。ただし、一部の企業が特許侵害であなたを訴える可能性はわずかですがあります。これは、ソフトウェアを独自に開発し、特許について聞いたことがない場合でも発生する可能性があり、特許は直感的に明白であり、ソフトウェアとほとんど完全に無関係な技術を対象としています。現在のUSPTOのポリシーを考えると、保険を購入する以外に、これを避けるためにできることはあまりありません。良いニュースは、パテントトロールが一般的に大企業を多額の資金で訴えていることです。
従業員またはフリーランサーを使用してソフトウェアを開発する場合、ソースコードを含むアプリケーションの著作権の所有者を書面で明確にする必要があります。一部のフリーランサーや契約開発会社は、ソースコードを独自の所有物と見なし、会社を元の開発者に依存させています。開発契約にある場合、これは合法です。
「勤務時間外」にソフトウェアを開発する従業員がいる場合、そのソフトウェアの所有者と、従業員が社外で作成および配布できるソフトウェアの種類を明確にする必要があります。
あなたがソフトウェアを開発している従業員またはフリーランサーである場合、開発を始める前に、アプリケーションの著作権を誰が所有するかを明確にする必要があります。また、自分で書いたソフトウェアの所有者を自分の時間に知っているか、明確にする必要があります。一部の企業は、雇用契約において、在宅であろうと職場であろうと、雇用期間中に開発者が作成したソフトウェアの所有権を主張する条項を持っています。多くの企業では、従業員が会社外への配布用に作成できるソフトウェアを制限する雇用契約に非競争条項があります。これらの制限はかなり広い場合があります。
商標は名前または記号であり、ソフトウェア自体ではありません。ソフトウェアを配布する場合は、（a）アプリケーション名と「マーク」または名前のデザインが他のアプリケーションと「紛らわしいほど類似していない」ことを確認し、（b）商標を登録する必要があります。競合の解決には最初の使用日が重要であるため、アプリケーションが商業で最初に使用される時期を文書化する必要があります。
アプリケーションに名前を付けるときは、登録商標を確認するだけでなく、Googleも確認してください。名前を最初に使用するアプリケーションは、たとえ商標を登録しておらず、あなたが所有していても、申請が成功した後にあなたの名前と商標を取得できる場合があります。
契約または契約を使用または署名するときは、両者がそれを理解していることを確認してください。雇用契約において、潜在的に影響を受けやすいエリアを前もって言及することで、後で多くの問題を防ぐことができます。開発契約では、ソースコードの所有者、アップグレードの責任者、メンテナンスプロジェクトの責任者などが開発プロジェクトに参加することを両当事者が知っている場合、申請後の訴訟の可能性ははるかに低くなります。完了しました。販売契約では、販売代理店が契約の責任と期間を理解していることを確認してください。
すべての重要なアプリケーションにはバグ（または「設計上の考慮事項」:-)）があります。ユーザー同意書または配布同意書は、バグのないソフトウェアに対して責任を負わないこと、およびすべてのバグを修正することは期待できないことを明確にする必要があります。変更、修正、およびアップグレードが開発者のオプション（または最善の努力）で行われることを明確にし、修正とアップグレードの費用を誰が支払うかを明確にします。
ソフトウェア開発および配布契約について弁護士に相談した後でも、他のソフトウェア会社からの契約を読み、弁護士が何を思いついたのかを確認する必要があります。
私は弁護士ではなく、これは法的助言ではありません。
疑わしい場合は、弁護士に連絡してください。
私は弁護士ではありませんが、時間が経つにつれて、時間を節約するために使用できる法的な人々からいくつかの経験則を集めました。
- GPLライセンスは「コピーレフト」または「バイラル」です。つまり、GPLコンポーネントに依存するコードを記述する場合は、GPLの下でもリリースする必要があります。目安として、ソフトウェアのコンパイルにGPLコンポーネントが必要な場合は、GPLライセンスでソフトウェアをリリースする必要があります。
- ソフトウェアを配布しない場合、ソースを利用可能にする義務はありません。たとえば、内部目的またはWebサーバーでソフトウェアを実行する場合、ソースをリリースする必要はありません。そのため、GoogleはGPLライブラリを使用するソフトウェアをリリースする必要はありません。これは、GPL v3の主要な競合ポイントでした。
- LGPL（ライブラリまたはLesser GPL）では、LGPLで編集されたライブラリをかけがえのない方法で組み込む場合にのみ、独自のソースコードをGPLする必要があります。ライブラリを「使用する」だけの場合、独自のソフトウェアはGPLである必要はありません。ヘッダーファイルを含めて、ライブラリの
.dll/.soにリンクすることは、適切な著作権表示を除き、LGPLコードを義務なく「使用」できる方法の1つです。 - BSDライセンス（Apacheライセンスは非常に似ています）を使用すると、オープンソースコンポーネントを使用する商用の拡張機能を作成できます。だからこそApple= OSXのカーネルとしてLinuxよりもFreeBSDを選んだ。
- MPLは、ライセンスが書かれた時点でMozillaからお金を稼ぐかもしれないとNetscapeが考えていたため、非常に商業的に使いやすいです。
多くの場合、オープンソースプロジェクトのメンテナーに連絡するのに役立ちます。彼らは、ライセンスの本来の意図とオープンソースに関する彼ら自身の見解についてアドバイスするのに最適な立場にあります。時々、メンテナーはあなたを助けるために複数のライセンスの下でソフトウェアをリリースすることをいとわないでしょう。しばしばそうではありません。著作権の所有者に依存します。
KDEプロジェクトには 便利な行列 があります
Webおよびソフトウェア開発の法的ガイド Stephen Fishman弁護士があなたが探しているものだと思います。
レビュー
素晴らしい本！あなたが想像できるほとんどすべての法的質問とあなたが考えもしなかったであろういくつかに答えます。 -ジョン・ドヴォラック、PC Magazine
このように急速に成長している無形の媒体にとって重要なあらゆる想像可能な詳細を網羅しています。 -起業家
この本は、他のどの法的ガイドよりも高い点数で、法的ガイドの私個人のテストに合格しています。 -ジェフ・ダンテマン、PC Techniques Magazine編集者
製品の説明
あなたの権利とあなたの努力を守ってください！
ウェブサイトとソフトウェア開発をカバーする法律は複雑でわかりにくいですが、もしあなたがそれらを解かなければ、弁護士費用と訴訟で何千ドルもかかる可能性があります。
幸いなことに、Web＆ソフトウェア開発のリーガルガイドは、法律のこの複雑な領域を、読みやすい英語で徹底的に解読しています。また、CD-ROMの契約書、契約書、法的フォームに記入手順を説明しているため、弁護士の身代金を支払うことなくソフトウェアとWebサイトを保護できます。
Webおよびソフトウェア開発のリーガルガイドを使用して以下を学習します。
- どのような法的保護が必要ですか
- 各種保護の長所と制限
- 侵害を避ける方法
- 契約の起草時に必要な規定
- 他の人の資料を使用する許可を得る方法
草案を作成するための完全なステップバイステップの手順があります。
- 雇用契約
- 請負業者とコンサルタントの契約
- 開発契約
- ライセンス契約
Webおよびソフトウェア開発の法務ガイドの第5版は、最新の判例法および法定改訂を提供するために完全に更新されています。
その他の提案：
- 自分のために働く：独立請負業者、フリーランサー、コンサルタントの法律と税金 （同じ著者）。
- コンサルタントおよび独立契約者契約 （同じ著者）。
- ソフトウェアライセンスハンドブック by Jeffrey I. Gordon。
- ライセンシーおよびライセンサー向けのソフトウェアライセンスの実践ガイド H. Ward Classen著。
- 技術契約ポケットガイド：営業担当者、契約管理者、ビジネス開発者、弁護士向けのソフトウェアおよびサービス契約 David Tollen。
フリーランサーまたは請負業者の場合：良好な賠償責任保険に加入していることを確認し、保険の対象を確認します。
たとえば、私のものは、クレジットカード番号を公開する可能性のあるコードの間違いに対する責任をカバーしていません。だから私はもうそのようなものには触れない！
1つの答えは、法律はコードのようなものではないと断言しています。同意しません。
初期の頃、IBMは命令によってプログラマーに支払いをしていました。 （この方法で金持ちになったプログラマーと仕事をしたと私が知っていた人がいます。どうやらその男はマシンのインデックスレジスタの使用方法を知らなかったようです。彼は各メモリアドレスにゼロを手動で格納するメモリゼロルーチンを作成しました。）
弁護士がみことばによって支払われた時代もありました。これは、人々を「最も高く評価されているそのような」およびその他の冗長性として扱うなどの慣行の普及に役立ちました。
私はSO VV.NET 2008は行番号をまだ許可していると言ったという答え）を読んだばかりです。現代のPCでのDOSジョークには、すべてのCOBOLプログラムが共通の祖先から漸進的な変更によって決定されるという多くの真実があり、後方互換性と「歴史的理由」が私たちの分野に広がっています。
これは法の領域に匹敵します。他の法律に小さな（または大きな）変更を加える法律があります。依存関係のようなものがあります。いくつかのばかげた歴史的法律があります（タスマニア州ホバートでは、男性が日没後に女性のドレスを着ることは違法です-かつて、囚人は女性やマグカップの人として服を着るので）ソフトウェアには、もはや誰も使用していない歴史的な機能がいくつかあります。
法律には、意図しないコンセキューエンス（バグ！）、創造的な方法での使用（ハック！）、抜け穴（セキュリティの脆弱性！）、意図的なもの（バックドア！）、変更（パッチ！）または覆された（アンインストール！） 。
はい、法律は（コードとは異なり）解釈の対象です。しかし、これはむしろコード保守のようなものだと思います。法律を新しい社会規範に適合させるのに役立ちます。
質問に直接答えるには、すべての開発者が、法律が何百年も開発されてきたとんでもないほど巨大なソフトウェアプロジェクトのようなものであることを知っておく必要があります。 （実際、各国には独自のプロジェクトがあり、さまざまな方法で問題を解決しています。）理論的には、ライセンスを読んだ後、コードでできることとできないことを知ることができます。しかし、有能なプログラマーがコードを読むだけでコード内のすべてのバグを見つけることができない場合、non-lawyerが分析する可能性はどのくらいでしょうか法的文書のコーナーケースと灰色の領域？
ソフトウェアのソースコードと同様に、通常、法律文書の要点を読むことで取得できますが、何か特定のことを知る必要がある場合は、専門家に尋ねる。
従業員の場合：クライアントに必要なコンポーネントを使用できるように、クライアントに最初のアドバイスを提供できる必要がありますか？
フリーランサーの場合：クライアントに強力なアドバイスを提供できる必要があります。開発するアプリケーションに使用できるコンポーネントを選択します。
もちろん、あなたの言葉は、弁護士があなたに得るアドバイスほど良くありません。しかし、あなたはすでに最初のラウンドのために助けることができます;たとえば、「これは...という意味になるので間違いなく使用できません」と言うには
最後に、弁護士は角の事件について多くを知るでしょう-しかし、あなたが少し助けることができるならば...
OSS貢献者の場合：人々があなたのコードで何ができるかを気にするなら、無料ライセンスの違いを知ることは重要です（再配布、修正、商用アプリケーションで使用、独自のアプリケーションで使用）。
NOLO（私は彼らのために働いていません）は、素人向けの合法的な本の良いセットを公開しています。
http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html
「すべての弁護士がプログラミングについて知っておくべきこと」と答えるのと同じ方法でこれに答えます。つまり、最も単純なこと以上のことを行うのに十分なほど詳細なフィールドを知ることができる方法はないことを知っておいてください。専門家になってください。
- 開発者よりも弁護士が多い国では働きません。
- すべての（米国の）ソフトウェア特許の非常に大きな割合は偽物ですが、それらを無効にするまで支払うことも待つこともできません。
- オープンソースソフトウェアを使用/開発する場合は、既存のライセンスを使用し、変更しないでください。ライセンスが意味するものの境界線の近くに行かないでください。
私はいつも、プロジェクトの開発者が、自分の作品を使用しているソフトウェアをまったく同じライセンスでリリースすることを望んでいると思います。詳細については、よくある質問と法律のページをご覧ください。不明な点がある場合は、お気軽に開発者/保守担当者にお問い合わせください。
ライセンス契約の詳細を理解したい場合は、弁護士に相談してください。
使用するライセンスの基本的な権利と義務を知っておく必要があります。それほど難しくはありません。それらがたくさんある場合でも、使用またはタッチするものだけを注意深く読む必要があります。それらを読むだけで、ほとんどの場合、それらは非常に明確です。
あなたが必要とする他のものは、まあ、それは依存します。特許取得？商標？これらのものが必要な場合、あなたは会社にいて、あなたのためにこれを行う法務部を持っている可能性があります。
6.「時間外」にソフトウェアを開発する従業員がいる場合、そのソフトウェアの所有者と、従業員がどのようなソフトウェアを作成して社外に配布できるかを明確にする必要があります。
ほとんどの憲法で規定されている言論の自由（特に、開発者が24時間無料でソフトウェアを作成している場合）は、裁判所でそのような条件が悲惨に失敗する可能性があります
優れた知財弁護士の名前。