タグ付けされた質問 「open-source」

100件のコミットがあるプライベートプロジェクトがあるとします。101回目のコミットまでソフトウェアライセンスを追加しません。プロジェクトをオープンソースにした場合、最初の100件のコミットはすべて、101回目のコミットのソフトウェアライセンスに拘束されないということですか？ ライセンスが追加されたときにプロジェクトをリベースする必要がありますか？

13 licensing  open-source 

A、B、Cの3つのソフトウェアプロジェクトがあります。 Aは誰にでも公開され、GPLの下でライセンスされています。 BはAを拡張し、公開されていますが、ライセンス情報がないか、LGPLの下で誤ってライセンスされています。基本的に、GPLではないため、Aのライセンスに違反します。Bのソースコードは引き続き利用可能です。 CはBを拡張します。CはGPLで公開できますか？動機は「AはGPLであり、派生物もGPLでなければならないため、BはGPLであり、CもGPLになり得る」です。

13 licensing  open-source  gpl 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 最近、Microsoft Visual Studio用のいくつかのクールなオープンソースアドオンツールとライブラリについて学びました。ツールは、生産性の向上に役立ちます。ライブラリは企業コードベースにリンクされます。 これらのすべてのクールなツールとライブラリをスプレッドシートにリストしました。それぞれが所有するライセンスの種類を実行します。これまでのところ、私のクールなライブラリの中には、MIT、BSD、Apache License Version 2.0があります。ただし、今後さらに増える可能性があります。 社内での使用と互換性のない（社外に配布しない）人気のあるライセンスをどのように見つけることができますか（または、さらに良いのですが、リストに載せますか）。そして、追加の感謝を述べて、あなたは説明を言ったり指摘したりすることができます。私は弁護士ではないので、これらのライセンスの細かい活字を読むと頭痛がします。 許可されたライセンスを使用しても問題ない理由を説明できるようにしたいと思います。

13 licensing  open-source 

私はこのGPLプロジェクトを持っています、それは1年ほど行き詰まりました、私はアイデアが本当に好きです、そして誰かがそれを分岐させ、同じ名前を使用しましたが、コードを気にしません（結局GPLでした）しかし、私は名前が好きです。この種の状況のエチケットは何ですか？ このプロジェクトは自分自身に利益をもたらすでしょう。私は気に入っていますが、その名前は売り物ではありませんでした。 編集：著者に連絡して名前を理解して変更するかどうかはわかりますが、今はそのプロジェクトに取り組む時間がないので、私は人々の「名前トロール」になりたくないです（小さなコミュニティ）、私はそれを今回にします、私の質問はフォークのエチケットについてです。プロジェクトが明らかに放棄された場合、彼らはフォークして同じ名前を使用できますか、または新しい名前を取得する必要がありますか？

13 open-source  etiquette  forking 

まあ、私はそれをオープンソースにしたくない！それが問題です。しかし、私は現在の仕事でそれを使いたいです。会社は私と代替ライセンスに署名することに同意せず、所有権を得るためにすべてをゼロから書き直すように私に言った。:( どうすれば安全な方法でそれを行うことができますか？後で会社に戻って来て、私が書いたコードを使用していると言ってはいけません。私の個人的なプロジェクトや別の仕事でも？ ハッシュマップの最初のバージョンのように見せずに、ハッシュマップの2番目のバージョンをどのように書き換えますか？これは私にはちょっと難しいように思えます。:(

13 licensing  open-source  intellectual-property 

分岐コードを回転させる適切なベストプラクティスについて質問があります。 Creative Commons Attribution-NonCommercial-ShareAlike 3.0の下でライセンスされたコードベースを取得し、私のニーズに合わせて大幅な変更を加えました。私のバージョンは他の人に利益をもたらし、再配布したいと思っています。 再配布に関してどのような自由があるのか​​、またはどのような許容範囲があるのか​​はわかりません。プロジェクトの名前を変更できますか？新しいv.1を開始するか、元のバージョン番号から続行する必要がありますか？元の著者に適切な帰属を与えると考えられるものは何ですか？リリースする前に著者に相談し、許可を求める必要があります（ただし、彼は既に認識しています）。

13 open-source  forking  creative-commons 

私は最近、自分のアプリケーションに統合したオープンソースソフトウェアパッケージで、かなり厄介な（確認済みの）バグに遭遇しました。パブリックイシュートラッカーによると、このバグはソフトウェアの最新リリースで解決されています。 特定のモジュールの高価なリファクタリングを避けるためにバグ修正が必要になる場合がありますが、技術的および/または政治的な理由により、最新リリースにアップグレードすることはできません。 行われたコードの変更を調べると、修正は非常に簡単に思えるので、実行可能なオプションは自分でコードにパッチを当て、現在承認されているバージョンのソフトウェアを再コンパイルすることだと感じますが、中傷者はこれがほとんど常に悪い考えだと主張したいそれは危険であり、面倒な複雑さをもたらします。 彼らの目には、このコードの変更は私たちが使用するためだけに行われたため、コードベースの一部である必要があります。つまり、オープンソースソフトウェアをサードパーティの依存関係として導入するのではなく、新しいプロジェクトとして導入して組み込む必要がありますビルドプロセスへの自動ビルド。 私にとっては、ソース管理リポジトリからコードをソース管理リポジトリにプルするため、これは間違っていると思います。その前に行われたコード変更の背後にある歴史を失います。また、実行する必要のあるこのような小さなコードの変更には、非常に複雑すぎるもののように思えます。 この場合、上記を行うのは悪い考えでしょうか？もしそうなら、オープンソースを変更する必要があるとき、理想的な状況は何ですか？

13 open-source  builds  software-patches 

複数のファイルホスト間でDropBoxにファイルをアップロードするオープンソースプロジェクトがあります。現在、DropBoxの画面スクレイピングをしています。APIを使用するには、OAuth認証用に提供された秘密キーをハードコードする必要があります。しかし、だれでも見ることができるように見えれば、鍵は秘密ではないのではないかと思います。 悪意のある誰かが私のキーを使用してウイルスをユーザーのアカウント（すでに私のアプリへのアクセスを許可している）にアップロードし、PC（デスクトップ同期が有効になっている場合）および他のPC（彼らは共有フォルダを持っていた）など。：O 私と同じ問題を抱えているこの未回答の質問を見つけました。 しかし、私は一般に、オープンソースプロジェクトで機密データを隠す方法を知りたいと思います。 アイデアが一つあります。 ソースコードに「<SECRET KEY HERE>」などのプレースホルダーを用意し、リリース用のバイナリをビルドするときにのみ埋めます。（うん！） 適切なアイデアはありますか？

13 open-source 

私の会社（Acme Technologyと呼びます）には、元々Acme Labsの研究グループから来た数千のソースファイルのライブラリがあり、開発グループで数年間インキュベートされ、最近では少数の顧客に提供されています非開示。Acmeは、おそらくコードの75％をオープンソースコミュニティにリリースする準備をしています。他の25％は後でリリースされますが、現在のところ、顧客が使用する準備ができていないか、競合他社の手に渡らないようにする必要がある将来のイノベーションに関連するコードが含まれています。 現在、コードは#ifdefsでフォーマットされており、同じコードベースを、大学の研究者やはるかに広範な商業顧客がオープンソースに移行する前に利用できるプリプロダクションプラットフォームと連携することができます。実験とプロトタイピング、および将来のプラットフォームとの前方互換性テストに利用できます。単一のコードベースを維持することは、2つのコピーを並行して維持するのが困難な私のグループの経済性（および健全性）にとって不可欠であると考えられています。 現在のベースのファイルは次のようになります。 > // Copyright 2012 (C) Acme Technology, All Rights Reserved. > // Very large, often varied and restrictive copyright license in English and French, > // sometimes also embedded in make files and shell scripts with varied > // comment styles. > > > ... …

13 open-source  licensing  version-control  parsing 

私は、githubsを介してオープンソースとしてリリースする予定のプロジェクトに取り組む予定です。公開前にプロジェクトが動作状態になるまで待つのではなく、最初からgithubにコードを配置することの利点は何ですか。 問題があれば、この特定のプロジェクトはC＃アプリ/サービスであり、無料のgithubアカウントしか持っていません（そのため、非公開にして後でカバーを取り戻すことはできません）

13 open-source  github 

ASP.NET Webアプリ（特にdapper）でオープンソースコードを使用することを検討しています。経営陣はファンではありません。なぜなら、オープンソースは以前私たちに噛み付いたリスクと見なされているからです。どうやら、以前の開発者は、オープンソースのコンポーネントが失敗した後、物事を書き直さなければならなかったようです。 プロのようです： それ以外の点では、ボイラープレートコードの多くまたはマイクロソフトが推奨するが低速なソリューション（Entity Framework）のいずれかが含まれることになります。 短所： 本番環境で突然失敗した場合、それを修正するのが難しいほど複雑です。ただし、私のサイトよりもはるかにトラフィックの多いサイトで使用されているため、最終的にプロジェクトのリスクの高い部分になるとは思わない。 ここでのコンセンサスは何ですか？自分のコードと同じように、私が知らない/理解していないプロジェクトでオープンソースコードを使用するのは賢明ではありませんか？

13 open-source  management  risk-assesment 

参照すべてを始めた投稿 挑発的な方法で尋ねた元の質問を解決するために、この質問を提起しました。 オープンソースプロジェクトからアルゴリズムを学ぶ場合、そのアルゴリズムを別のクローズドソースプロジェクトで使用しても大丈夫ですか？そうでない場合、それはその知識を再び使用できないことを意味しますか？使用できる場合、どのような状況になりますか？ 明確にするために、私はライセンスを回避しようとはしていません。

13 licensing  open-source  gpl  mit-license 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私は最近、数か月前に始めたプロジェクトをハッキングしています。簡単なアイデアでした。Githubで共有したコードの成果を収集できるようにします。 そこで私はこの高貴な努力を始めました。コーディングを手伝ってもらうために友人を掻き集めようとしました。私はこれを取得して実行し、構築するために、自由な時間を費やしました。 音楽の時間経過を入力してください 私の友人たちは、彼らができたときにピッチングしました。ご想像のとおり、私はその成功に非常に執着しました。 その後、リリースに向けて準備を進めていたように、ある会社が非常によく似た製品をリリースします。私の小さなプロジェクトが他の誰かによってリリースされたと聞いたとき、私は非常に落胆しましたが、そのアイデアに対する権利を持っていたようではありませんでした。私は自分のプライドを飲み込んで、彼らにメールを送って、 ねえ、私は似たようなことに取り組んできました。我々は話をする必要があります！とてもクールなものです。 私たちは話します、私は彼が本当に協力したくないという感じがしますが、心からお互いのサイトへのアクセスを許可しています。 数日経つと、私の業績の説明の一部が業績サイトに表示されていることがわかります。最初に彼に話しかけた後、私は彼らに私の達成システムの私の計画の概要を説明したわかりやすいメールを送って、それをやめると言っていました。自分の業績の説明がサイトに表示されたら、それを手放すことはできませんでした。私は反撃することにしました。 私はプロジェクトをオープンソース化して、競技場を平準化しただけで、パートタイムでしか取り組んでいなかったので、競争に対処する必要がなくなりました。 これは毎回行うことができるアクションではありません。将来この位置にいる場合、どのような選択肢があるのでしょうか。訴訟？厳しいメール？ ヘッドアップとして、私は弁護士なしでこれに対処する方法に関するアドバイスを探しています。または、これは現実の世界で物事が展開する方法ですか？

13 open-source  ethics 

LGPLは、MIT、BSD、Apacheのような寛容なライセンスだと思いました。しかし、今日は、LGPL（ライブラリなど）へのリンクのみがクローズドソースコードから許可されていることを読みました。 LGPLプログラムに基づいた雇用主向けのプログラムを作成しましたが、かなりの修正が加えられています。もちろん、その変更されたソースコードをそこに置くことは許可されていません。同時に、私はそれを配布する必要があります（そうですか？）。 だから私はこれに回避策があるのだろうかと思うので、私はこのクローズドソースを維持することができます（ソースを公開できるといいのですが）-提案はありますか？ 私のアイデア：オリジナルのLGPLアプリのほとんどの機能を外部ライブラリに入れて、最初からコア実行可能ファイルを記述できますが、変更していないすべての機能についてはライブラリを参照できますか？ 現在、すべてが.jarファイルにあります（Java / Swingです）。あなたが私の考えが法的に/技術的に実行可能であると思うなら-私が書いたものとオリジナルが何であるかを分離するのにどれだけの労力がかかるでしょうか？私はJavaに精通していません。

13 open-source  licensing  lgpl  closed-source 

私のチームは、code.google.comでホストされている古いオープンソースプロジェクトのメンバーに連絡を取りました。私たちは彼らのプロジェクトに参加して、少なくともそのブランチにコミットしたいと言いましたが、誰も私たちに応答しませんでした。全員、所有者、コミッターを試しました。誰もアクティブではなく、誰も応答しませんでした。 しかし、コミットするコードがいくつかあり、そのプロジェクトの作業を続けたいと思っています。したがって、新しいプロジェクトを作成する必要があります。継承したいプロジェクトの名前に近いが重複していない名前を思いつきました。最初のコミットをどのように行う必要があり、コミットメッセージはどうあるべきですか？「このコードを継承しました。このようなライセンスの下でここに見つかりました...今、このより厳格なライセンスにアップグレードしています...」などのコメントを付けてコードをリポジトリにコピーする必要がありますか？または、コードを最初のコミットとして使用し、「継承しました...そうした変更を行いました...」などの更新を行う必要がありますか？

13 project-management  open-source