アカウント名:
パスワード:
意外に簡単です。昔ソフトハウスで裁判沙汰を起こした際の 話しなのですが、パクッた側が『ちゃんと機能設計をした オリジナル』と主張しているにもかかわらず、その機能設計 からは絶対に導き出されるはずのないバグや冗長性が オリジナルのコードと同じ形で存在していたからです。
ある程度の規模になったら、絶対にこの問題は避けて通れなく なります。誠意ある態度が見られなければ、堂々とそういう 証拠を順次提示して差し上げればよろしいでしょう。
まあ、ちゃんと解析されたら一発で終わりですけどね。それなりに馬鹿避けにはなる・なってるようです。
LAMEというのは私とかが開発しているソフトです。先日もProGがぱくったかも [srad.jp]、という話が出た奴です。
まるで世間の人が皆LAMEを知っているかのような書き込みになってしまいごめんなさい。
まず要件定義を開示させ、次にその実装状況をレビュー させます。
オリジナルを作った人間なら、開発の経緯によるデバッグ コードや実装の変更などの痕跡として、バグや冗長な コードが残存していることを説明することが可能ですが、 パクッた側にはそれがうまく説明できません。
ごめん。上の書き方だけだと、充分に分かりにくいかも。
例えば、A ←→ B ←→ C という状態遷移を当初設計していて、 実装してみたら、C からは直接 A に遷移して問題ないことが 判明したので C → A という遷移の経路を新設したとする。
にも、かかわらず C → B → A という経路が残っていた場合、 それがなぜなのかは、開発した人間にしか説明できないで しょ?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
オリジナルの証明 (スコア:3, 参考になる)
意外に簡単です。昔ソフトハウスで裁判沙汰を起こした際の 話しなのですが、パクッた側が『ちゃんと機能設計をした オリジナル』と主張しているにもかかわらず、その機能設計 からは絶対に導き出されるはずのないバグや冗長性が オリジナルのコードと同じ形で存在していたからです。
ある程度の規模になったら、絶対にこの問題は避けて通れなく なります。誠意ある態度が見られなければ、堂々とそういう 証拠を順次提示して差し上げればよろしいでしょう。
--- Toshiboumi bugbird Ohta
パクられないために (スコア:1)
鍵を使うと証明が出てくるような仕組みを入れることって
できないですかね。
例えば、本当の作者の名前が出てくるとか。
uchachaの日記 [hatena.ne.jp]
Re:パクられないために (スコア:3, 参考になる)
まあ、ちゃんと解析されたら一発で終わりですけどね。それなりに馬鹿避けにはなる・なってるようです。
-- Takehiro TOMINAGA // may the source be with you!
Re:パクられないために (スコア:1)
LAMEというのは私とかが開発しているソフトです。先日もProGがぱくったかも [srad.jp]、という話が出た奴です。
まるで世間の人が皆LAMEを知っているかのような書き込みになってしまいごめんなさい。
-- Takehiro TOMINAGA // may the source be with you!
Re:オリジナルの証明 (スコア:1)
> かかわらず、その機能設計からは絶対に導き出されるはずの
> ないバグや冗長性がオリジナルのコードと同じ形で存在して
> いたからです。
この 物語 [fujigoko.tv]を思い出しました。
# 最初から読むか、本を探した方がよさげ。
Re:オリジナルの証明 (スコア:0)
Re:オリジナルの証明 (スコア:0)
「順次」示した所かなあ。
Re:オリジナルの証明 (スコア:1)
まず要件定義を開示させ、次にその実装状況をレビュー させます。
オリジナルを作った人間なら、開発の経緯によるデバッグ コードや実装の変更などの痕跡として、バグや冗長な コードが残存していることを説明することが可能ですが、 パクッた側にはそれがうまく説明できません。
--- Toshiboumi bugbird Ohta
Re:オリジナルの証明 (スコア:1)
自分の古傷(笑)を思い返して…
きちんと成されていると良かったんだがなあ…(とおい目…
スパゲティ要件定義でも、証拠としては意味有りなんでしょうか?
日本語で(藁)うまく説明できないほどのスパゲティを、どうやって証拠として認めてもらえるのかは、気がかりです。
>開発の経緯によるデバッグコードや実装の変更などの痕跡として、バグや冗長なコードが残存
>していることを説明することが可能ですが
オリジナル側が「リファクタリングしました」「古い糞コードの事なんて忘れました」
なんてなことになると、どうなんでしょうね?
#ハンコ(笑)やオリジナリティって、技術(=品質)そのものに対しては何の足しにもならないんで、どうにも好きになれないG7
#やっぱ巨人の肩でしょ。OpenSource万歳。
Re:オリジナルの証明 (スコア:1)
ごめん。上の書き方だけだと、充分に分かりにくいかも。
例えば、A ←→ B ←→ C という状態遷移を当初設計していて、 実装してみたら、C からは直接 A に遷移して問題ないことが 判明したので C → A という遷移の経路を新設したとする。
にも、かかわらず C → B → A という経路が残っていた場合、 それがなぜなのかは、開発した人間にしか説明できないで しょ?
--- Toshiboumi bugbird Ohta