【あんまり使ったことのない言語でもイケる!?】「piece」のリクエスト~サルでもネコでも使える~売り方&買い方

現在ご覧いただいている「piece」は、プログラム売買をメインとしています。

ちょうどいま、販売されているプログラムを眺めながら「こんなことやりたいんだけど、いま並んでるソースでできそうかどうかが良く分からないや」ってこと、ありませんか?



今回は、pieceのリクエスト:https://www.piece.cool/requests を効果的に使いこなすためのチェックポイント~「リクエスト」の時の売り方&買い方について考えてみました。







ソースコードをやり取りして何かを組み立てるというプログラムの作り方は、昔からありました

たとえばPerlに対するCPAN(シーパン、Comprehensive Perl Archive Network)や、JavaScriptの各種アーカイブやフォーラムなどの利用での技術やソースコード入手。あるいはショッピングカートやチャットなど、Webサイトなどで公開されている出来合いのスクリプトを既存のサーバに展開したり、プログラム中に組み込んでる人は多いかもしれません。

WordPressなんかも、今では主流の、デザインだけ決めたらあとは自動でサーバ内展開してくれるタイプが、一般向けにも法人利用向けにも増えています。でも、プログラムをあとから改変したり追加するとなると、結構このタイプは制約が多いですよね。

本当に欲しい機能やサービスを使いたい、「使えるパーツ」のバリエーションを多く確保しておきたいなら、自分で展開して普通に機能設定やデザインを入れていくようにしたほうが柔軟に組み込みやすいっていうのは、やや多いほうかもしれません。
(##正直、自分で一度展開してみないと、細部の改変を行ったとき、何を使いたいなら何を犠牲に、両方それなりに時間がかかっても動かしたいならどんなものを作ったらいいかなんてのが理解できないっていう部分もあります)

いま多くの企業などで利用しているWebや各種のシステムでも、出来上がったプログラムの中には、さまざまなサーバ技術や、OSとOS内部で利用しているサービスとその設定、NW構成とその制御方法、サーバ自体の位置関係やバックアップなどの構成など・・・・とあるプログラムを動かしたいのに、必要とされているものが複雑に入り組んでいるケースも結構あります。





実は「うちはサーバOSに◎◎利用してる」だけを条件にしていても、実際触り始めるといろいろと改変や、どんな技術を使っているかが異なっていたり、既存のプログラム内部の条件を改めて整理しなければならなかったりで、「こんなはずではなかった」ということも結構頻繁に発生したりします。



そんなとき、自社で手に負えないなら、普通はどこかに丸投げして作ってもらったり、改変してもらって送り返してもらったりといったプロセスを経るわけですが・・・

そもそもPieceのプログラムリクエストの場合は、一般的で汎用性の高いシステム条件を想定したコードが作ってもらえるだけでなく、たとえば「◎◎の 」に相当するリクエスト時の条件の出し方次第では、もうそのままもらって組み込んだら使えるレベルにまで作りこんでもらえる可能性だってあるわけです。

となると、オーダーメイド感覚、しかも、直接顔を合わせる必要がないので、作り手はもちろん、売り手にも時短で経費節減効果だって!けっこう使えるサービスだと思いませんか?







【リクエストの出し方】






【言語についての情報】



一応リクエストに際しては、Web系、プラグインなどのジャンルと、その実装に利用するJava、C++、JavaScript、PHP、Python、Rubyといった言語は、記載することになっています。

現在利用している技術によっては、機能拡張などでその言語ソースがそのまま使えないケースもあるので、ここは大事です。

加えて、言語によっては、現在利用中のプログラム言語のVersionもとても重要。

しっかり書き込んでおきましょう。





【利用しているフレームワークについて】



現在あまりリクエストされる側の方は記載しないことが多いのですが、開発に使用しているフレームワークなどは、場合によっては結構重要。

Web専用ツールから作成し始めて、その他の業務用のツールなどに改変されたソース(たとえば社内システムのフロントエンドだけWeb利用だが、クライアントサイドでの処理工程を増やしたいケース)などについては、どんなフレームワークで作っているのかによって、プログラムを追加してからの動作のために新たにコーディングする量なども違ってきますし。



また近年日本や各国では、納品した後のプログラムやその派生加工品に、出来合いのOSSである程度著作権放棄されていたはずの物が、その後形を変えてパッケージや有償サービスとして提供されたときに発生した著作権やその他技術問題などが散見されます。

大手が社内開発品には、完全オリジナルの自社フレームを使うのはそのためですが、開発時に既存のおーぷんそーすやフレームワークを使っているなら、いまの利用方法では現行著作権抵触が無いにしても、種別やバージョン情報、あるいは開発時期やリリース時期がわかるように文書を配布しておきましょう。

万が一の時、自らの技術や資金ではデコード解析証明が出来ないときでも『その企業や、そのうちaiと収集でなんとかしてくれるかもしれません』←他力本願





【NWやサーバ構成、OSなどについての情報】



Webや業務データ、決済データなどを扱う際には、サーバやNW側構成や、OSで利用しているサービスの一部を利用できなくしていたり。

あるいは、セキュリティ関連のプログラムや、セキュリティ配慮された階層構造などによって、プログラム実行時の各ファイルへのアクセス権設定他に一定の条件があるケースもあります。

せっかく書いてもらったプログラムでも、いざ使うとき、それが自社環境においてのケースでは、組み込みにかなりの手を加える必要があるケースもありますし、ほかの技術とあわせて使うために時間や負荷が多く発生するケースもあります。

すっきりとした処理のコードを求めたいなら、またあまり手を加えず使えるコードを求めるなら、階層構造や一部のサービスなどについての特筆すべき情報を付加しておくほうがよいでしょう。







いずれも、書いてもらったソースをそのまま使うわけではなく、自分でしっかり改変していくならあまり関係ないのですが、購入してすぐ組み込める=使いやすいプログラムであること=売れるかどうかにも関わる部分で重要なポイントです。

個人で自作ソースを販売しているサイトと比較して、購入前にみられる添付文書やファイルの構造、動きなどについての画像などが少ない状態で販売されているかたがたが多いです。





たとえば、以前に良く個人や大手プログラムソース販売サイトで売買されていたときのWebCGIや、バッチ処理のデータ処理系プログラムなどでは、購入前に

「プログラムの階層やファイル、動いている部分などが見られる」
「動作自体の絵や、実際のテスト稼働での所要時間や、生成されたデータの正確さを数値化したチャートや、稼働させたときのシステム負荷状況なども見られた」
「組み込み時、もっとも一般的なベースとなるプログラムにそのまま組み込んだだけ程度のときの作業時間などが表示」 されていたものでした。

これらもしっかり確認できるほうが、たとえば社内で作るシステムに組み込むソースを求めているような「一度購入してみて、良しあしを決めるということが難しい」人には、決済しやすいといった利点もあるわけです。



売り手側も、「販売者サポートオプション」の有無などが選べますが、これがなくても買ってもいいかなと思わせるには、それなりに、購入前に確認できる文書類の充実も必要です。







【最後に著作権についてちょっとだけ】





よくサイトで使う無料画像その他には、クリエイティブコモンズライセンスとよばれる「CC【数字】」という表示や、昔からあらゆるメディアで見られる「©、丸の中にPD」 なんかが入ったものがあります。

詳しくはこちら →https://creativecommons.jp/licenses/



また、プログラム関連で、2010年以後の下部でとくに良く見られるのが「MITライセンス」。2015年3月のGitHubによる、ソースコード公開で利用されているライセンスでは、このMITライセンスがTOP。
【1:https://github.com/blog/1964-open-source-license-usage-on-github-com】



MITライセンスのキモ部分は、
  • 誰でも無償で無制限で利用できる。
  • 著作権表示および本許諾表示をソフトウェアのすべての複製または重要な部分に記載しなければならない。
  • 作者または著作権者は、ソフトウェアに関してなんら責任を負わない。

・・・などなど。

特にGithub利用者自体がこの7~8年、増えたななんて実感されている方も多いと思います。GitHubでは、もともと何かライセンスを利用していたのが2008年段階で60%以上ありました。ですが、その後、大きな地球規模の技術者流出などがあったりしたことや、若い世代の技術者が増えたこと、大きな発明などであっても、権利主張されないことを是とした風潮があったりしたことも影響したのか、ソフトウェアでも、GitHub上、ライセンスを利用する人の割合が低下しました。

その後、ライセンス利用の周知を図る https://choosealicense.com/ などを、GitHubが展開したことで、2015年には全数の20%ほどにまで伸びています。









ちなみにその他のライセンスの利用状況は・・・

  1. MIT 44.69%
  2. Other 15.68%
  3. GPLv2 12.96%
  4. Apache 11.19%
  5. GPLv3 8.88%
  6. BSD 3-clause 4.53%
  7. Unlicense 1.87%
  8. BSD 2-clause 1.70%
  9. LGPLv3 1.30%
  10. AGPLv3 1.05%


本Pieceで販売しているソースコードは、ライセンス固定で

① ソースコード 複製権:許諾 頒布権:許諾しない(※再販禁止)
② 改変後のソースコード 複製権:許諾 頒布権:許諾
③ ソフトウェア 複製権:許諾 頒布権:許諾

と、割合ゆるめの感じで、ピースで購入したソースコードを使用する際は、ソースコード内に、必ずコピーライト(マーク)、西暦、著作権者の表示が必要です。

「Copyright (c) <year> <copyright holders>」





正直、ソフトウェア開発では、その分量比や主要な機能のどの程度前をそのソースに依存しているかなどで多少扱いを分けるべきケースなどもあります。



またGitHubにあった年代の前後には、小規模に販売していたはずのソフトが実は自分の開発していた部分の技術などについて非常に大きく評価がされたからといったことでの「事後の」権利争いや、「その対価に見合った著作権料や著作者とりあつかいであるか」などの事例も多く見られました。

こうした事例を受けると、ソースコードの購入利用者側から見れば、仮に改変部分を加えたのちの大規模なパッケージ発売への移行などについては、個別に改めて契約などについて申し入れを行うといったのがBetterかもしれません。

## 販売数比などに合わせた対応なども、ある程度類型化されて出回っている部分もありますし




また、とくに技術に依存する部分が多いIT系。そして個人で作ってたように思ってた人が、意外にも神足で、時代の寵児としてクローズアップされることも少なくないIT系。

技術者個人が販売するサイトを通じたこうした契約への移行は、その技術者を育成し世に出すための社会的貢献としても評価されます。その本人がその後大きなものを手掛けた際、「先見の明があった」なんていう報道が見られることも・・・。

小さなことなんですが、このあたりの配慮も、利用者と技術者の両得感につながります。





Additional Images




Comments

Loading…

We use cookies and other technologies to improve your experience on our website and to analyze our traffic. By browsing our website, you consent to our use of cookies and other tracking technologies.

Accept cookies and close this message