0

商用 C++ ライブラリの大部分は、テンプレートに依存しています。製品をヘッダー ファイルと動的にリンクされたライブラリ (クローズド ソース) として販売する予定ですが、コード ベースのほとんどがヘッダーに集中しているため、事実上、簡単に交換できる小さなチャンクが欠落しているオープン ソースとしてリリースすることになります。

以下は、ライブラリ インターフェイスからのクラスの 1 つがどのように見えるかの例です。

template<class ItInput, class ItOutput>
struct serialize{
  ItOutput operator() (ItInput first, ItInput last, ItOutput d_first) {
    // operation on pointers (assuming that ++, -- and * operators work as expected for pointers) 
}

テンプレート化されたコードに、通常のコードのコンパイルと同等またはそれ以上のレベルの難読化を提供する方法はありますか (つまり、技術的に元に戻すことはできますが、有益ではなく、最適化することもできません)。

編集: 明確にするために、私たちの目標は、ユーザーが実装を読み取れないようにすることであり、私たちの作品の違法なコピーを防ぐことではありません。質問のために、この要件には正当な理由があると仮定してください。

4

1 に答える 1

7

事実上、オープンソースとしてリリースする予定です

違う。「オープンソース」とは、ライセンスがOSIと互換性があり、そうでない可能性が高いことを意味します。

弁護士に聞いてください。

法的な問題に対する技術的な回答を間違って求めています。

テンプレート化されたコードに、通常のコードのコンパイルと同等またはそれ以上のレベルの難読化を提供する方法はありますか?

時間がある場合は、たとえば、ライブラリ内のすべての識別子を役に立たないジャンクに置き換えることができます。たとえば、secret識別子を使用する場合は、次のようなものを追加します

#define secret s_1eovFxBcc2F

他のコードの前。secret後で、すべての出現箇所をで置き換えるスクリプトを実行することもできますs_1eovFxBcc2F。もちろん、secret使用するシステム ヘッダーには表示されません。

私見、それは時間のロスになりますが、あなたのマネージャーを幸せにするかもしれません.

本当に重要なのは、クライアントに適用されるライセンスです。深刻なビジネスは (もちろん大企業もそうではありませんが)、法律に違反する余裕はありません。

明確にするために、私たちの目標は、ユーザーが実装を読み取れないようにすることです。

次に、ライブラリの公開されたインターフェイスとして、不透明なデータ型のみを使用して、C に似た (そしておそらく宣言されたextern "C") 関数のセットのみを提供します。

ところで、おそらく GPL ライセンスを使用してライブラリをオープン ソースにするという反対のアプローチを検討しましたか (そして、それを使用するすべての (配布された) プログラムも GPL 化する必要があります) 。 (または、拡張性の高い他のライセンスを購入する必要があります)?

（法的な問題には、通常、技術的な解決策しかありません）

于 2017-07-11T16:23:17.453 に答える