mossjp - Tumblr blog

mossjp · 1 year ago

Text

MOSS15開催決定！

MOSS15の開催に向けて株式会社インプリムさんから会場をご提供いただきました。ご厚意に深く感謝いたします。

参加申し込みはこちらです。

https://moss.connpass.com/event/315545/

概要

MOSSでは医療現場で役に立つ技術、広く使える実装とは何か、そしてオープンソースソフトウェアがどのように活用できるのかをテーマとしてきました。

2020年から2023年までCOVID-19のパンデミックのため、オープンソースソフトウェアやオープンデータはデジタル公共善(Digital public goods) として対策に大きく貢献しました。人類の英知と善意の勝利です。

この数年間、MOSSとして活動休止しておりましたが、再開します。私自身もこの数年間、公私ともに苦しい時期ではありましたが、みなさまのご厚意により、なんとか立て直しつつあります。

MOSS15の開催に際しても株式会社インプリムさんのご厚意で会場を提供していただきました。感謝しております。

みなさまのご来場を心からお待ちしております。懇親会もどうぞ！

日時・場所

日時：2024年6月22日（土）14:00-18:00

場所：東京都中野区中野2-30-5 中野アーバンビル7F Pleasanter Lounge

演題

基調講演 (小林慎治）(14:00-14:20)

IPAが10年ぶりにオープンソースを推すわけ、羽鳥健太郎（IPA専門委員） (14:20-14:50)

国際協力におけるオープンソースソフトウェアの活用の可能性について、吉田友哉(JICA人間開発部) (14:50-15:20)

OSSで加速するオープンデータの社会実装とシビックテック、福野泰介（新型コロナウイルス対策ダッシュボード開発者 / IchigoJam開発者 / Code for FUKUI 代表）(15:20-15:50)

休憩(15:50-16:00)

OSSのノーコード・ローコード開発ツール「プリザンター」、内田太志（株式会社インプリム）(16:00-16:30)

OSSを活用した産学共同でのHL7 FHIR JP Core実装ガイドの作成について、宮川力(株式会社ファインデックス) (16:30-17:00)

Node-REDを中核としたオープンソースによるコンセプチュアル仮想マシン(In-Process Clinical Intelligence)の作成と運用、鳥飼幸太（群馬大学医学部附属病院システム統合センター） (17:00-17:30)

LT（各自5分、飛び込み歓迎）(17:30-18:00)

LTの演者は募集中です。お話ししたい方がいらっしゃったら是非ご連絡ください。

懇親会の申込みは下記からどうぞ！ https://moss.connpass.com/event/316736/

0 notes

mossjp · 1 year ago

Text

Resume!

諸事情により活動停止状態でありましたが、このたび活動を再開します。

セミナー企画中です。

0 notes

mossjp · 5 years ago

Text

CIVIC Tech challenges to COVID-19

Due to the pre-pandemic of COVID-19, Open Source Conference Tokyo 2020 Spring was canceled, and we had to call off our session in that, crisis of free/open source software in healthcare.

COVID-19 is an emerging threat of healthcare, and making the world confused. There are too much information and fluid people by demagogues. This is the first "Infodemic" in the human history.

What we can do is to think wise with good enough reliable data and information. Civic tech challenge to COVID-19 started on the 3rd March in Tokyo with the subsidy from Tokyo government.

https://stopcovid19.metro.tokyo.lg.jp/

This site visualizes data and guides citizens to proper web sites with good scientific knowledges by experts. The source codes were published on GitHub with MIT-license, and they use open data from the government.

https://github.com/tokyo-metropolitan-gov/covid19

More than 1000 commitments were contributed from all over the world. 372 issues were opened and 266 were closed in these 10 days. One of the many pull requests was from Audrey Tang, the digital minister of Taiwan.

I think this approach is the modern and the future way of human beings against infectious disease pandemics.

Shinji Kobayashi

0 notes

mossjp · 5 years ago

Text

GNU HealthのLuis FalconとOSC 2020 Tokyo/Springに登壇します

2014年10月に来日され、MOSS9とOSC 2014 Tokyoで講演していただき反響の大きかったLuis Falcon氏が再来日されます。開発についての打ち合わせ、検討のほか、京都大学で特別講義をしていただき、2月22日15時15分からOSC 2020 Tokyo/Springでも講演していただく予定です。

医療分野でのOSS動向と解決すべき課題についてお話する予定です。例のごとく情熱たっぷりなお話となると思いますので、ぜひ皆様ご参加ください。

https://www.ospn.jp/osc2020-spring/modules/eguide/event.php?eid=43

2020-02-22 (土) 15時15分

医療分野におけるデジタル化の現状とFLOSSによる挑戦

講師：小林慎治（医療オープンソースソフトウェア協議会）・Luis Falcon(GNU Solidario, GNU Health)

担当：医療オープンソースソフトウェア協議会、GNU Health Federation

レベル：入門編

対象者：医療分野でのソフトウェア開発について興味のある方。低開発諸国での医療ITの現状について興味のあるかた。GNU Healthについて興味のあるかた。

前提知識：熱い心を持っている人ならどなたでもOKです。

効率よく、安全な医療を提供することを目的として医療分野においてもデジタル化が進められてきた。一方で、電子カルテのユーザーインターフェースが悪いことで、現場が疲弊し、医療事故にもつながっているとの報告もある。

質の高いソフトウェアを流通させるために、国家レベルで医療分野のソフトウェアを規制しようとする動きもあり、実際に医療画像処理ソフトウェアがその対処となっている。結果として、これまでFLOSSとして開発されていた医療画像処理用ソフトウェアがクローズととなった事例もある。

低開発諸国でも国民の健康を守るために情報を収集し、対策するための情報化が進められている。OpenMRS, DHIS2, GNU HealthなどのFLOSSが現場で活躍しており、多くの成果をあげつつある。このような状況を概観して、FLOSSがどのように医療分野で活用していくのか、ソフトウェアについてどこまで規制されるべきなのか、本セミナーで議論を深める。

0 notes

mossjp · 6 years ago

Text

OSC京都2019に登壇します

これまでも、OSCには何かと関わってきており、MOSS6はOSCの中での開催でした。

今回は久々に演題を出しましたので、よろしければご参加ください。

https://www.ospn.jp/osc2019-kyoto/

2 notes · View notes

mossjp · 6 years ago

Text

OsiriX MDの国内医療機器認証取得について

0. まずはおめでとうございます

まずは、FLOSS由来のソフトウェアが初めて国内で医療機器認証を取得できたことを喜びたい。

http://www.newton-graphics.co.jp/archives/2636

取得がいかに大変だったかについては、ニュートングラフィクス社の菅野社長からお伺いしていた。取得までのご健闘に敬意を評するとともにその成果を心から賞賛し祝福する。

残念ながら、��でにOsiriX MDはFLOSSとは呼べないものではあるが、FLOSSが元になったことは経過から明らかである。OsiriXがFLOSS版の更新をほぼ中止したこと、そしてPACS（薬機法での届出は画像診断用ワークステーションプログラム）がクラス２の管理医療機器として認証をうけなければならないものであるのかという点について論考する。

1. 薬機法改正の背景

医薬品および医療機器の許認可のために制定されていた「薬事法」が、2013年に「薬機法」に改正され、ソフトウェアも管理対象とされた。この背景にはアメリカFDAが2010年にPACSを510(k)で管理対象のクラス２医療機器として分類したことにある。この動きにはPACSをCTなどの画像撮影装置に付属するおまけのようなものではなく、画像処理をするきちんとした製品として、ソフトウェアとして独立した存在として高めていくべきだという考えがあったとその働きかけをした人物からきいたことがある。

医薬品や医療機器は国際的に流通するものであり、その管理や取締は国際的な協力のもとで行われている。PACSもまた、ほかの医薬品や医療機器と同様に国際的に販売されるものであるため、日本でもFDA 510(k)同様の規制を設ける必要があり、薬機法の改正につながっている。

同様の規制はヨーロッパ、カナダなどの先進国を中心に波及し、PACSの販売にはそれぞれの地域で機器認定を取ることが必要となっている。

2. FLOSSへの影響

2004年からOsman RatibらによりFLOSSとして開発されていたOsiriXは市販されている高額なPACSに負けないような性能があったことから、高く評価されていた。日本でも杉本真樹医師が積極的に普及活動を行っていた。しかし、前述の通り2010年にFDAによる認証を受けなければアメリカでPACSを流通させることができなくなったため、pixmeo社を設立しOsiriX MDの販売を行うこととなり、無料でダウンロードして使うこともできていたOsiriX liteは医療用途には使わないという前提での公開となった。公開されているソースコードはLGPL3に準拠しているが、その時点を持って、Version 5.8のままほぼ更新されることがなくなっている。

OsiriX MDはソースコードが非公開となった上で、10万円以上もすることからユーザーの反発を招いたが米国FDAでの認証を取るためにかかるコストが数百万円単位でかかること、そしてヨーロッパや各国で認定を取るために同様の経費がかかることを考えれば、ボランティア主体のFLOSSコミュニティで負担する金額とは言い難く、妥当な路線変更と言わざるを得ない。

OsiriXのsource codeを利用して、FLOSSでの開発継続のためforkしたHoros projectは100,000USDを目標に寄付を集めており、2019年3月8日時点で69,110USDを集めている。今後の発展に期待したい。

3. PACSのクラス2機器分類は妥当か

薬機法が定める医療機器は「人若しくは動物の疾病の診断、治療若しくは予防に使用されること、又は人若しくは動物の身体の構造若しくは機能に影響を及ぼすことが目的とされている機械器具等（再生医療等製品を除く。）であって、政令で定めるものをいう。」である。さらに、人体に与える影響をもとに医療機器をクラス1から4までに分類している。製造販売に認証が必要となるのはクラス2以上の管理医療機器である。PACSはクラス2に分類されている。薬機法は289条からなり、さらに施行令と施行規則からなる膨大な法体系である。なかなか素人には理解しづらいものではあるが、人命を左右する医薬品、医療機器は適正に公的機関により管理される必要があるという趣旨は否定のしようがない。心室細動で作動しないようなAEDなど市場に流通してもらっては害悪でしかないし、インチキ医薬品や危険薬物の流通も取り締まる必要がある。

PACSが単独で医療機器認定されたことでよいこともある。CTなどの画像機器の付属品であった時代は、PACSが動作しているOSに脆弱性が見つかってOSをアップデートしようにも、そのためにCTの機器認証を更新する必要があるため、更新がなかなか進まないといった問題があった。それがPACSが独立したことで、比較的容易にアップデートをすることが可能となった。

しかしながら、なぜ、PACSがクラス2の管理医療機器と分類されているのかについては疑問が残る。PACSは画像を表示することで、診断や治療計画に使用されることは間違いがなくその点で言えば、確かに医療機器である。しかし、その理屈から言えば電子カルテもまた医療機器であるが、クラス２には分類されていない。

それならば電子カルテも薬機法で規制しようとなるような動きが出るような、藪蛇をつついてしまうことにもなりかねないのが怖くてこれまで言及を避けてきたが、画像を表示するPACSがクラス２であれば文書を表示する電子カルテもまたクラス２ではないかと思われる。

いずれにしても、PACSや電子カルテが診断のために使われるとしても、それを判断するのは医師であり、直接患者に害を及ぼすことはあまりない。今の所、電子カルテまで規制する動きはないが、規制が増えることは良いことばかりでもない。

自分の診療や院内業務を円滑に進めるため、医療従事者がちょっとしたソフトウェアを作って使うということもあり、そうしたソフトウェアがFLOSSとして広まることもある。どこまでが薬機法の対象となるのかならないのかが、分かりづらいのは��きな問題点である。

医療分野へのAI応用が期待される中、どこまでが研究開発として許されるのか、どこからが薬機法の対象となるのか不明である現状では、たとえそれが自分の個人的な診療のために使うものであっても研究開発にたいして抑制的な態度をとらざるをえない。医療分野でのソフトウェア開発と流通が、許認可についてのコストがまかなえる資本を持つ大企業だけに独占されることに健全な未来を展望することはできない。

Tivoization?

GPL2はソフトウェアの改変と再配布をライセンスの範囲内で認めている。しかし、ほかの制約により改変したソフトウェアが利用できなくなる事例が報告され、Tivoization と呼ばれている。薬機法によりFLOSSの流通に制約がかかるのは、Tivoizationとも考えられるが、適正な手続きを踏めばFLOSSであっても薬機法を遵守して利用することも可能ではある。したがって、薬機法での規制はTivoizationとまではいえない。認証にかかる手間とお金があればだが。

GPLは配布に関するコストを適正な価格で徴収することは否定していないが、それはソフトウェアを配布するためのメディア代程度であるとされている。配布のためのコストとして、ソフトウェアの認定に関するコストを転嫁することが許されるのかということについてはFSFとも議論が必要だろう。FLOSSであっても保守などのサービスの対価を求めることも同様に認めている。しかし、すべての利用者と保守契約を結ぶことはFLOSSとして配布の形態上困難である。

OsiriXのようにFLOSS版と商用版の2つのライセンスを用意して、商用版の利用には料金を徴収するソフトウェアはMySQLなど多くある。すべての著作権者の同意があれば、この形態をとって許認可にかかるコストを転嫁することも可能ではある。OsiriXの場合であれば、pixmeo社から商用版の再配布の許諾を得てライセンス費用を払えば、Newton Graphics社のように薬機法の認定を取った上で商用ライセンスでOsiriXを配布することも可能である。ただし、現在公開されているLGPL3版のOsiriXのコードを利用する場合、再配布にはLGPL3の規定に従わなければならず、OsiriXのLGPL3版から派生したHorosも同様にLGPL3の規定に従う必要がある。したがって、商用版であってもソースコードを動作する形で設定ファイルを含めて提供する義務があり、改変や再配布もLGPL3の規定通りに認める必要がある。

公正で安全な医療ソフトウェアの流通のために

何よりも重視しなければいけないのは、質の高いソフトウェアにより人体の安全を確保することである。人体への影響は時に不可逆的な転帰をたどることがあるため、人体に害を及ぼすようなソフトウェアの流通は予防的に阻止する必要がある。しかし、その区分についてどこまでが妥当なのかについては、臨床現場での利用方法を含めて議論を重ねる必要がある。

FLOSSはライセンス上、その動作については開発者に一切の保証を認めていない。したがって、その使用はユーザーが自己責任で行うものであるが、だからといって薬機法を無視していい訳でもない。薬機法での認証にコストがかかるのはFLOSSだからというわけでもなく、FLOSSだからといって薬機法の認証を受けないで良い理由とはならない。法律として定め��れたルールがある以上、それに従うのは当然のことであり公正な競争なくしてソフトウェアの発展もまた見込めない。

公正なルールのもとでソフトウェアを開発し、流通させていくことは医療の進歩のために欠くことができないものである。そのためには妥当なルール設定と明確な基準が必要となる。PACSが規制の対象となることが妥当であるかどうか、医療分野でのFLOSSと規制については今後も国際的な議論を深めていく必要がある。

今年8月に開催されるMEDINFO2019では、医療分野でのFLOSSが直面する課題として、FLOSSと規制に関するワークショップを提案した。そろそろ採択されるかどうかの結果が出る。乞うご期待。

小林慎治医療オープンソースソフトウェア協議会代表 IMIA Open Source Working Group, Chair

0 notes

mossjp · 6 years ago

Text

アジア地域における医療分野へのオープンソースソフトウェア活用

0.概要

アジア・アフリカ地域でも医療分野へのOSS活用は進められている。AeHIN(Asia eHealth Information Network)はASEAN地域で医療分野へのIT活用を推進する団体で、DHIS2とOpenHIEをASEANでの医療情報基盤として普及させるようと取り組んでいます。これらの取り組みについて紹介すると同時に日本の医療支援における問題点について論考する。

1. アジア地域でのヘルスケア上の問題点とオープンソースソフトウェア

アジア地域では低開発国での感染症の蔓延や貧困に伴う諸問題がヘルスケア上の大きな課題であったが、急速な経済発展に伴い先進諸国型の生活習慣病も問題となりつつある。

感染症を地域でコントロールしていくためには、罹患者の把握とフォローアップが重要である。OpenMRSは当初チリで開発されていたHIV感染および結核の治療のための電子カルテを元にして、ケニアで新たにオープンソースソフトウェアとして開発された。OpenMRSはサブサハラアフリカで普及し、アジア諸国でも取り入れられている。OpenMRSといくつかのオープンソースソフトウェアを組み合わせて、マイクロサービスで連携させるBahmniはThought Works社によりインドBahmniで開発された。

同様に地域保健と電子カルテを組みあせてた機能を持つGNU Healthも南米に広がりつつあり、アジアでもラオスが国レベルでの導入を行っている。

もちろん、他の地域と同様にオープンではない医療ソフトウェアもアジア、アフリカで普及している。しかし、導入コストが低いというアドバンテージに��りエンジニアや医療機関だけではなく、行政レベルでのオープンソースソフトウェア導入のモチベーションとなっている。

また、低開発国での医療に大いに貢献している国境なき医師団が2015年に地域患者リポジトリ、レポーティングシステムであるDHIS2を組織的に導入していくことを決めたことも広く影響を与えている。WHOはDHIS2をツールとして活用するための文書や疾患ごとに分析するモジュールを公開している。

2. AeHINとオープンソースソフトウェア

AeHIN(Asia eHealth Information Network)はタイのBoonchai Kijsanayotin氏とフィリピンのAlvin Marcelo氏が中心となり、WHOやADBの協力のもとでAsia地域でのeHealthの導入のイニシアチブをとっている。ASEAN諸国および周辺には影響力があり、1-2年に一度開催される総会には各国の保健医療行政でIT導入、活用の担当者が集まり、省庁の次官級の官僚や閣僚も参加する。

AeHINでは2016年にDHIS2とOpenHIEを地域の基盤として普及させていくと宣言しており、ASEANをはじめアジア地域での導入と活用を支援している。DHIS2も、OpenHIEもともにオープンソースソフトウェアであり、それを基盤としていく方針が明示されたことで、WHOはじめアジア地域での保健行政がオープンソースソフトウェアを活用していくという基本路線が明示されたこととなった。

3. 日本の医療支援とオープンソースソフトウェア

2018年にスリランカで行われたAeHINの総会では各国でのDHIS2への取り組みが紹介されていた。しかし、状況は国ごとに異なり、オープンソースソフトウェアの扱いに習熟したエンジニアがいない地域では活用がなかなか進んでいないという問題点も明らかとなっていた。

日本の医療支援はJICAを中心にアジアでは貢献してきており、その積み重ねによりAeHINの総会に参加すると日本から来たというだけでありがたがられるという経験をしてきた。安倍政権がうちだした、UHC(Universal Health Coverage)への支援は高く評価されており、WPROのDirectorに日本出身の葛西氏が選出されたのは日本がこれまで行ってきた貢献への信頼の現れだろう。JICAを支える国際保健については産学官のネットワークも充実している。しかし、医療ICTの支援、しかもオープンソースソフトウェアを中心とした支援については苦労されているようであった。

日本で医療関連のソフトウェアを開発している大手ベンダーは会社としてはオープンソースソフトウェアを担当している部門があり人材も充実しているが、医療部門ではオープンソースソフトウェア活動に縁がある人をあまりみかけない。日頃ORCAを扱っていて、オープンソースソフトウェアに馴染みのあるベンダーは零細、中小が多く国際支援の枠組みにはなかなか入りづらく、ここに大きなギャップがある。

DHIS2のアーキテクチャは一般的なJavaEEであり、日本の企業でも導入支援や活用は可能であると思われる。が、そもそも事業として採算にあうかどうか��からないような国際医療支援で、さらに自社開発でもないオープンソースソフトウェアを利用していくことは、今の医療系ベンダーにはハードルが高いのかもしれない。

日本の医療分野でも新興ベンチャーの参入が活発となってきており、そうしたベンチャー企業が、今あるギャップを埋めてくれるかもしれない。

しかし、IBMがRedHatを買収し、GitHubがMicrosoftの傘下に入り、Androidが携帯端末を含めたコンピューティングプラットフォームのシェアトップとなった現在ではオープンソースソフトウェアはソフトウェア開発の基盤であることは疑いようもない事実である。今までオープンソースソフトウェアに馴染みが薄かった日本の医療ベンダーにもオープンソースソフトウェアへの関心を深めてもらうためにはどのようにしたらいいのか、これまでも大きな難問であったが、いよいよ喫緊の課題となってきたと思う。

Shinji Kobayashi, IMIA OSWG Chair

0 notes

mossjp · 7 years ago

Text

OpenOceanによるGPL違反事例について

0. 問題の概要

OpenOceanにおけるGPL違反事例については、当該関係者(air-h-128k-il)に対して違反内容を指摘してきたにもかかわらず何ら修正に応じてきませんでした。重大かつ悪質な違反であり、放置しておくことは医療分野でのFree/Libre/Open Source Software(FLOSS)活動に悪影響を及ぼしかねませんので、医療オープンソースソフトウェア協議会代表、IMIA Open Source Working Group議長としての立場から改めて是正勧告を行います。

この文書に法的拘束力はありませんが、OpenOceanが行っていることはGPL違反であり、著作権法違反にもつながっており、FLOSSコミュニティーを毀損してしまうものです。できるだけ早期の解決を望んでおります。

以下、GNU General Public Licence version 2をGPL2とし、同 version 3をGPL3とします。

1. 経緯について

1) 2018年6月7日air-h-128k-il氏がOpen DolphinのGitHub repositoryからfork(正確にはforkのforkのfork)してOpenOceanと名前を変えたプロジェクトを立ち上げた。

https://github.com/air-h-128k-il/OpenOcean/commit/d80294f4fdbe3d30a0c0971f3c4cf8888f30ade1

　ソフトウェア開発でソースコードを継承して、分岐した独自の開発を行うことをforkといいます。FLOSSではforkというのはよくあることであり、OpenDolphinはLSC社による登録商標なので、名称を変えたことについても別に問題��はありません。

2) 2018年6月8日OpenOceanの著作権表示から原著作権者らの表記を削除し、air-h-128k-ilの表記だけにした。

https://github.com/air-h-128k-il/OpenOcean/commit/ecb93256255143433d00b6f0f6152d50fb39099d

https://github.com/air-h-128k-il/OpenOcean/commit/221727da305fd2e110f41cb6c73830fa5a0f9c37#diff-9879d6db96fd29134fc802214163b95a

　LICENSEドキュメントにあったOpenDolphinの著作者である、"Kazushi Minagawa, Digital Globe(inc)“の表記を削除して、 “air-h-128k-il"のみを表記するようにした。

　それに先駆けて、READMEに書いてあった皆川和史をはじめすべての著作権者表示も削除している。

https://github.com/air-h-128k-il/OpenOcean/commit/8b1b653e1b887661392a38e4eae2746b3235029f#diff-04c6e90faac2675aa89e2176d2eec7d8

3) 2018年10月29日、OpenOceanの著作権者表示が適切にされていない点がGPL違反であるとGitHubのissueで指摘された。

https://github.com/air-h-128k-il/OpenOcean/issues/1

しかし、このIssueは著作権表示について修正されることなくair-h-128k氏により説明もないままclose（解決済み）とされてしまいました。

2. OpenOceanにおけるGPLに関連する問題点

2.1. READMEとLICENSEでのGPLのバージョンの違い。

　もともと、OpenDolphinのREADMEではGPL2に従うとしていて、LICENSEではGPL2 or laterとされていました。（現在はGPL3で統一)

　OpenOceanでは、LICENSEにはGPL2 or laterとしていながら、README.mdではGPL3と書かれています。

　以下はGPL3がOpenOceanに適用されたライセンスであるとして話を進めますが、GPL2でも大筋は変わりません。

2.2. 適切な著作権表示がなされていない

　GPL3では第4条で、以下のように適切な著作権表示をすることを求めています。

4. Conveying Verbatim Copies.

You may convey verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

FLOSSプロジェクトでforkしてプロジェクト名称や開発団体が異なっても元の著作権者表示は残ります。どのFLOSSライセンスでも著作権者の適切な表示を求めているからです。

　OpenDolphinの原著作者は皆川和史氏であり、戸村(王)勝偉氏が共同著作権者��して挙げられています。更に下記の著作権者が協力者としとREADMEに記載されています。

札幌市元町皮ふ科の松��先生

和歌山市増田内科の増田先生

新宿ヒロクリニック

日本RedHat Takayoshi KimuraさんのJBoss as7 へのポーティング

GPL3の “appropriate copyright notice” は形式までは具体的に定めていないので、様々な表示形式が見られております。いろいろなやり方があると思いますが、上記はすべて著作権者であり、OpenOceanはOpenDolphinのソースコードの大部分を利用している以上、GPL-HowToに記載されているように上記著作権者をすべて適切に表示する必要があります。

著作権法によれば、著作者の名前を表示するかしないかも著作者の権利とされておりますので、適切な著作権表記というのは「著作権者と合意が得られた」形式と考えるのが自然で、forkした場合でも大本の著作権表記がそのまま使われるのは、原著作者が合意した形式であるからと考えられます。逆に言えば、著作権表記を変更する際にはライセンスに定めがなければ、原著作者の合意を得る必要があります。

2.3. GPL3 ドキュメントが含まれていない。

同じく、GPL3の第4条で"give all recipients a copy of this License along with the Program"としていますので、GPL3のライセンスドキュメントをソースコードツリーおよびバイナリパッケージに含めておく必要があります。通常はCOPYINGというファイルです。

これは、もともとのOpenDolphinプロジェクトもそうでした。どこでGPLの文書が入手できるかを示しておけばよいともされており、あまり問題とはなりませんが、厳密にはこれもGPL3の第4条違反です。

2.4. GPL違反まとめ

OpenOceanはGPL3の第4条に違反しており、GPL3の第8条に基づき、OpenDolphin著作権者によるGPL3で許可された利用許諾は終了されるとみなすことができます。したがって、著作権法に定められている、著作者人格権に基づき、OpenDolphinに対する一切の改変が認められませんし、第三者にその製品を提供することは著作権法が定める頒布権の侵害であり、公衆の場であるGitHubにソースコードを置くことは著作権法が定める公衆送信権侵害です。

3. air-h-128k-il氏の著作権についての認識の間違い

こちらでも書きましたが、air-h-128k-il氏の著作権の認識には大きな間違いがあります。

Free/Libre/Open Source Softwareと著作権、特許権、商標権

air-h-128k-il氏は「著作権が認められるのは、高度の思想を伴うプログラムだけである」というような独自の主張をされています。

さきのの記事にも記載しましたが、一般的には著作権法第2条の10の2が示すように一定の機能を有するプログラムは思想性の有無にかかわらず著作権の対象となる著作物です。

百歩譲ってair-h-128k-il氏の主張が正しいと仮定したとしても、OpenDolphinはどこからどう見ても、皆川氏の思想を反映したものであり、それが認められないようでしたらair-h-128k-il氏が書かれた数十行程度のOpenOceanのコードも同様に著作権が認められることはないでしょう。

4. ユーザーの意図しない動作をするコードの是非

OpenOceanで公開されているコードには2018年6月11日に下記のようなコードが入っております。

https://github.com/air-h-128k-il/OpenOcean/commit/e21b21f032421f981f0a836eb99cb988c2680a58

https://github.com/air-h-128k-il/OpenOcean/blob/master/client/src/main/java/open/dolphin/client/Dolphin.java

以下に問題点を抜粋

public static int expired(){ //試用版ぽく期限を設定する by air //Date expireddate = new Date(1000 * 60 * 60 * 24 * 365 * 120 ) ; Date expireddate = new Date(2018 - 1900,12-1,31) ; Date datenow = new Date(); if(datenow.after(expireddate)) { return 1; } return 0; } /** * OpnDolphin entry point. * @param args project name */ public static void main(String[] args) { if (expired()==1){ System.exit(0); }

OpenOceanのWebには2018年12月までの試用期間であると記載とされています。ユーザーはこの指示に従うべきものとも考えられますが、このままだと使用期限が近づいてもクライアントに何の警告も表示されずに2019年1月以降起動しなくなってしまいます。GUIなインタラクティブメニューを持つソフトウェアであれば、1ヶ月以上前から警告を表示しておくのが親切ではないでしょうか。

Webに記載される試用期間を見落とすほうが悪いのかもしれませんが、使用期限を過ぎて起動しないソフトウェアに対してどのように対処すべきかも書かれていませんので、ユーザーである医師には対応できずに医療事故につながる危険性があります。

5. 問題の深��さと影響について

まず、air-h-128k-il氏にまったく違反をしているという認識がないところが問題点です。軽微なFLOSSライセンス違反は珍しくはないもので、指摘をうけてすぐに是正されればGPL8条に記載されているように問題とならないことが多いのですが、再三の指摘を無視し続けているのは悪質と言わざるを得ません。

FLOSSライセンスはユーザーや開発者を差別することを禁止しておりますので、このような悪質な開発者の利用でも止める方法はなく、著作権を行使して訴訟をしかけるか、FLOSS自体をやめてクローズドソフトウェアに移行するしかありません。

一般的なエンジニアは訴訟まですることを望んでいませんので、FLOSSとしての公開を止める選択肢を選ぶことになります。それは、FLOSSにとって滅びの道です。

ユーザーが望まない機能を盛り込むことについては様々な考え方があろうかと思います。FLOSS版を試用版として、商用版を別に設定してお金を得ることは別にGPL的にも間違ったことではありません。��だし、商用版のソフトウェアがGPLで許諾されたソフトウェアをもとにしていれば、商用版のソフトウェアのソースコードにはGPLが定める通り、開示義務があります。

世の中にはGPL準拠として書かれたマルウェアも存在しており、著作権者が何を書いてどのようなライセンスのもとで提供するかは著作権者が決めることではあります。GPLでも、著作者はユーザーの使用について起こる不具合には一切保証しないとしております。FLOSSはユーザーの自己責任で使うものではあり、ソフトウェアに不満があれば使わなければいいだけです。ただ、電子カルテを乗り換えるにはそれなりにユーザーにも準備が必要です。ユーザーに使用をやめるための選択肢を与えることは義務ではありませんが、医療分野でソフトウェア開発をして広めて行くにはユーザーフレンドリーであることは前提として求められると思います。

医療分野のソフトウェアについては、FDAやPMDAによる規制が始まっており、ユーザーの意図と反するソフトウェアが存在することを根拠に、その規制の範囲が広がる危険性があります。現在のところは画像系ソフトウェアについて、規制が行われており、それに伴ってPACS系のFLOSSにも大きな影響が出ております。

医療分野のFLOSSに関しても10年前くらいまでは信頼性について疑問視されることも多かったのですが、FLOSSコミュニティの献身的な努力により信頼性を積み重ねてきました。このようなことで、医療系のソフトウェア、FLOSSの信頼性が損なわれ、医療分野でのソフトウェア規制が強まっていくことを私は大いに懸念しております。

医療分野でのFLOSSの発展のため、GPLをはじめとしたFLOSSライセンスおよびFLOSS文化について何卒ご理解の上、air-h-128k-il氏により然るべきが処置なされることを心から願っております。

本件についての問い合わせは、小林慎治([email protected])本人までお願いします。

注記：本文書は2018年11月26日に公開し、同日から27日にかけて、文書の内容をわかりやすくするため加筆修正を行った。

1 note · View note

mossjp · 7 years ago

Text

Free/Libre/Open Source Softwareと著作権、特許権、商標権

オープンソースと知財権に関するちょっと小難しい話に著作権についてのよくある誤解とFLOSSについての誤解があるようですので、補足します。

このような誤解はよくあるものですので、誰でも疑問に感じるものですからこの際にまとめておきます。ただし、このテーマ自体で本が1冊はゆうにかけるくらいの大きな内容ですので長文となっておりますことをご容赦ください。誤りなどございましたらご指摘ください。

ソフトウェアと著作権

著作権法では著作物と著作者を第２条で定義しています。

一　著作物思想又は感情を創作的に表現したものであつて、文芸、学術、美術又は音楽の範囲に属するものをいう。

二　著作者著作物を創作する者をいう。

もともとの著作権の保護対象であった文芸は「思想や感情」を表現し��ものですが、コンピュータプログラムには思想性や感情を伴うものではないので、同２条、十の二に追加で定義されています。

十の二　プログラム電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したものをいう。

コンピュータを機能させて、一定の結果を得られる指令の組み合わせですから、著作権法の保護対象として第２条で定義されている「プログラム」には思想性を必ずしも求めていません。著作権法に後付で、ソフトウェアが対象となった経緯については以下をご参照ください。

Wikipedia:ソフトウェア著作権

従いまして、OpenDolphinは間違いなく著作物であり、それを構成する機能を実装した人たちが著作者です。ご指摘のように、「単なる事実の伝達」は著作権の保護対象ではありませんが、コンピュータプログラムでは一定程度の機能を持っていれば十分に著作物たる要件を備えていると考えます。

なお、著作権の対象となるのはあくまで、ソースコードであってアイデアや意匠（デザイン）は対象ではありません。同じような画面や機能があるソフトウェアはたくさんありますが、別途作成されたものであって、ソースコードを共有していなければ著作権上は違法ではありません。（例：GNU toolsはUNIXコマンドを再実装したものであり、機能は元のコマンドに類似するが、ソースコードは別個に作成したものであり著作権法上の問題をクリアしている）

逆に機能や見た目が異なっても、一部でもソースコードが流用されていれば著作権法違反です。（例：インターネットルータにおけるLinux kernelの利用）

著作権とFLOSSライセンス

コンピュータプログラムが著作物である以上、著作権法の保護を受けます。著作権法が示す著作者の権利には以下のようなものがあります。

著作者人格権

氏名表示権：著作者の氏名を表示させるあるいはさせないことができる。

同一性保持権：著作物を不当な理由で改変されることを禁止する。

複製権：著作物を複製する権利

公衆送信権：公衆に著作物を送信する権利

頒布権：著作物を第三者に頒布する権利

二次著作物に対する権利：第三者により原著作物より派生して作成された二次著作物に対しても上記の権利を有する。

コンピュータプログラムをダウンロードしてその機能を使うことについては何の制限もありませんが、プログラムに新たな機能を付け足そうと、ソースコードに手を加えることは同一性保持権の問題があり、いわゆるバグ対応以外は著作権法では認められていません。

バグを修正しようとしてもソースコードを提供する義務は著作権法上、著作権者にはありませんので、実際にはなかなかできません。

ソフトウェア技術の健全な発達のためにはソースコードをいつでも入手できて、それが改良できるような環境が必要であるという思想のもとで、FLOSSライセンスは生み出されました。

FLOSSライセンスとは

上記のように著作権法のものでは、ソースコードを入手したとしても改変すらできません。しかし、著作者が自己の持つ著作権のもとでプログラムの改変を許すように許諾していれば、可能となります。これが、FLOSSライセンスです。したがって、著作者の示すライセンスに従わずに、改変、再配布などを行うことは著作権法違反となりえます。

FLOSSライセンスにはGNU GPL(GNU General Public License)、BSD License、MIT licenseなどがあります。それぞれの規定についてはそれぞれのライセンスドキュメントをご参照ください。

なお、GPLではバイナリの配布元に対して、ソースコードを提供することを義務付けております。しかし、公開することまでは義務付けてはおりません。GPL準拠のプログラムを第三者に提供するにあたって、ソースコードを求めに応じて提供する必要はありますが、プログラムを提供されていない第三者に対してまでソースコードを提供することはGPLでは求められておりません。

なお、提供に際しては必要なコストを請求することは可能とされています。

GPLでは著作者の適切な表示と、GPLドキュメントを一緒に提供することを求めています。

FLOSSと商標権、特許権

FLOSSライセンスは著作権によるものですから、それ以外を保証しません。そのため、「Perl」や「Apache」などのオープンソースソフトウェアについて商標が第三者に取られるなどのトラブルがありました。コミュニティベースで成り立っているFLOSSで商標を取り返すことは容易ではないため、対抗策として商標権の確保は各プロジェクトで行われています。

著作権はベルヌ条約で国際的に保護されており、今、日本で書かれたプログラムはアメリカやヨーロッパでも同様に著作権で保護されます。しかし、商標権や特許権はそれぞれの国で登録する必要があります。

OpenDolphinはDolphinプロジェクトのクライアントとして開発されましたが、独自に発展しました。Dolphinプロジェクト自体も、今は千年カルテプロジェクトに移行しています。

開発元が商標登録するのはFLOSSプロジェクトでよくあることです。また、FLOSSがforkすることもあり、それで名前が変わることもよくあります。MySQLから派生したMaria DBなどはその例です。ただし、forkする際も著作権が消えるわけではないので、ライセンスには従う必要があります。

アイデアや方法についての特許は、ユーザーが使用することまで制限がありますが、著作権は使用については制限がありません。利用して、再配布したり改変したりすることについての制限があるだけです。むしろ、FLOSSライセンスでは特定のユーザーや特定の用途に使えなくすることを禁じています。

ソフトウェア特許やその他の法律のため、FLOSSとして実装はされたものの、制約があって配布できないことはよくありました。GIFについての特許は切れるまで、実装されてもそのコードを使用することはできませんでした。1990年代には暗号関連のFLOSS実装がアメリカの規制で輸出できなく、直接入手できませんでした。

医療分野のソフトウェアについても規制が加わりつつあり、FLOSSでの実装がどこまで制限されるのか、されないのかについては今後の議論次第なところがあります。

なお、この記事は小林慎治個人の見解によるものであり、意見や問い合わせは [email protected]までお願いします。

0 notes

mossjp · 7 years ago

Text

医療分野でのオープンソースソフトウェアを通じた国際活動

この記事は、第14回医療オープンソースソフトウェア協議会セミナーのLT兼クロージングでお話したあとで、メドレーの平山さんに「この話ってまとまった資料とかあるんですか？」と聞かれたのがきっかけで書きました。そういや、これまで総説を13年前に書いたっきりで、その間をまとめてなかったなと思い、アジア地域のオープンソースソフトウェアについてまとめをし��うとしました。けれども、その前にどうしてアジア地域をはじめ、国際的に活動を広げてきたのかということについても説明しないとうまく話がつながりません。国内での活動はMOSS1-14までの話に書いたので、ここでは国際活動を中心にお話します。長くなりすぎたので、アジア地域のオープンソースソフトウェアについてはまた別のまとめをすることとします。

はじめに

オープンソースソフトウェアを通じて、アジア圏のみならず世界的なつながりを得てきました。2017年からは国際医療情報学会(IMIA; International Medical Informatics Association)のOpen Source Working Groupの議長（Chair)に就任しております。まずは、その経緯について説明します。

MOSSをはじめた経緯については、先日の記事に書いたとおりです。未踏を終えて、博士論文仕上げたあたりのころ、いやその以前から国内の医療情報学会にはもう、飽き足らなくなっていました。そういや海外はどうなっているんだろうというのが気になって、参加したのが2007年にブリスベンで開催されたMEDINFOでした。MEDINFOというのは当時3年おきに開催されていた国際的な医療情報学の大会です。開催されることに気づいたときには、論文投稿などの締切は過ぎていたのですが、事務局に問い合わせたら「ポスターだったら出してもいいよ」と返事がきたので未踏の仕事をベースにポスターセッションに応募して、無事に採択されたので参加しました。その時辺りからオーストラリアとも縁の深いopenEHRにも興味を持つようになっていましたので、その情報を収集しようと意気込んでおりました。

MEDINFO2007

海外学会に参加したのは1997年のアメリカ血液学会でサンディエゴに行って以来で、海外渡航も久々でした。当時、血液腫瘍内科医として一般病院に勤務しておりましたので忙しい日々を過ごしており、準備も大変でした。出張中のフォローや海外渡航費の補助など勤務先にも支援してもらいました。

その前から、openEHRコミュニティとは連絡をとっていて、いろいろなセッションや彼ら主催のパーティーで交流を深めました。勤務先から半額補助はでているとはいえ、安くはない渡航費をかけ、参加費も高いこのMEDINFOに行ったからには、少しでも情報を収集しようといろんなセッションに出ました。しかし、いかんせん付け焼き刃の英語では込み入った議論を展開するということもままなりませんでした。けれども、英語というハンデがあってもまだ、日本国内よりも、「言葉が通じた」のが嬉しくて、それが国際学会に参加するモチベーションとなりました。

国際学会の懇親会では英語が話せる人がだいたい中央に集まって、話せない人がその周りにちっていく感じになるので、だいたい自分の隣はアジアアフリカ関係者が多く、アジア地域のつながりができました。その頃から、アフリカ・アジアに普及し��つあったOpenMRSのお話を聞いたのがこのMEDINFOだったと記憶しています。

OSS2010, MOSC2010, MEDINFO2010

2009年に愛媛大学に移った翌年の2010年は今考えると大変な年でした。このちょっと前から関わりのあったOpen Source Conferenceつながりで、島根大学の野田先生から誘われて、アメリカノートルダムで5月に開かれたOSS2010に参加して、日本のORCAプロジェクトを始めとした医療分野のオープンソースソフトウェア活動について発表しました。帰ってきて一息つく間もなく、さらに、国連大学からの要請で6月に開催されたMalaysia Open Source Conferenceで日本の医療分野でのオープンソースソフトウェア活動について講演しました。日本医師会が率先して自分たちのために開発したオープンソースソフトウェアプロジェクトがあるというのは、比較的に驚きを持って好意的にうけとられました。

医師会というのはどこの国でも、お固くてとっつきにくい団体のようで、そういう団体がオープンソースソフトウェアに取り組むというのは先進国でもありえないことのようでした。

9月に南アフリカのケープタウンで開催されたMEDINFO2010では、Open Source Working Groupのワークショップに出て、日本の事例を紹介したり、海外との共同研究の話をしたりしました。

Open Source EHR Summit 2011

2011年にOpen Source EHR Summitが開かれるというニュースが飛びこんできました。医療分野のオープンソースソフトウェアで有名なVistAを運用しているアメリカ退役軍人病院とその管理をしている国防総省が支援していて、制服組の軍人が発表していたのが印象に残っています。ただし、日程を下手に組んでしまい、到着翌日に口演発表という日程なので時差ボケの影響か、登壇した途端に英語が完全に飛んでしまって、口がろくに動かず最悪な発表となりました。以後、国際学会ではかならず一日前に現地入りして時差調整をするようにしています。

このときの縁で、OSEHRAの創設者のSeon Ki Mun氏とつながりができて、韓国に里帰りする途中で日本によってもらってMOSSで講演してもらったり、MEDINFOでお話してもらったり、そのお返してAPAMIでお話したりと交流が続いています。

MEDINFO2013

全部を挙げているときりがないのですが、この間にも、あちこちの国際学会で発表して交流を深めたりしておりました。2013年にデンマークのコペンハーゲンでMEDINFOが開催されるということで、コペンハーゲンといえばDavid H Hansonが生まれたところであり、Ruby on Railsが生まれたところでもあります。Ruby on RailsとopenEHRのarchetypeをつかって15分でEHRを作るデモというのをやったのですが、あまりうまくいかなくて、openEHR仲間からも「MEDINFOでLive codingは聴衆がついていけない」と言われるなど散々でした。けれども、その後の懇親会でHL7のEd Hammondさんから、Railsっていいよね、おもしろそうだから俺もやっていると声をかけてもらえました。80歳近い大先輩がRuby on Railsに興味持っていじっているというのは強烈な刺激になりました。

この時に、フィリピンのAlvin Malcero、タイのBoonchaiの両氏と仲良くなりました。IMIAのOpen Source Working Groupの議長だったドイツのThomas Karopka氏とも連絡を取り合うようになりました。GNU HealthのLuis Falcon氏の話には非常に共感して、翌年MOSSにもおよびしたりしました。今ではお互いに hermano （兄弟）と呼びあっています。

IWEEE2014, MOSS9

MEDINFOからの縁で、Luis Falcon氏が2014年5月に開催されたIWEEE 2014に参加しました。スペインのカナリア諸島にはじめていったのですが、あまりの環境の良さに移住を考えるほどでした。

AeHIN 2014

Alvin氏とはMEIDINFOのあとから、時々連絡をとっていて、フィリピン大学でopenEHRのチュートリアルセミナーを開催したりしておりました。どうも、MEDINFOでは物足りないところがあったようで、医療情報に関してアジアでWHOも巻き込んで新しい会議を開催しているようで、興味があったので、Alvinに参加してもいいかときいたら、快く招いてもらいました。Asia eHealth Network, AeHINと名付けられた会に2014年の第3回総会から参加してきました。その時が3回目でマニラのアジア開発銀行の立派な建物で開催され、日銀の総裁になられた黒田さんから代わったばかりの中尾総裁が基調講演をされたのをおぼえております。

学会とは異なり、ASEAN7カ国を中心にアジア諸国から医療情報について、行政の実務者が集まっておりました。日本でいうと、官僚でも局長級のかたが多いようでしたが、次官や副大臣、大臣が参加している国もありました。ここで話し合われたことが、そのまま各国で政策に反映されるのだろうなと思いました。なるほど、こうしたアプローチは学会でもHIMMSのようなコンベンションでもできないが、アジア諸国にとっては必要だなと感心しました。

AeHINは実践的なプログラムを中心にその時の実情にあわせてよく考えられて構成されていて、勉強になります。アジア諸国が何を求めているのか、どういう取り組みをしているのかリアルな情報を得ることができます。AlvinとBoonchaiさんのコンビもよくこの地域をリードしています。彼らはオープンソースソフトウェアに理解があり、利用してこの地域のeHealthを発展させていこうという戦略をもっています。

MEDINFO2015

この時期からIMIA Open Source Working GroupのChairをされてたThomas Karopka氏が大学を離れたこともあって、学会活動の継続に支障が出てきたということで私にCo-chairになって支援してほしいという依頼がありました。断る理由もないので、Co-chairを引き受けて、サンパウロで開かれたMEDINFO2015からMEDINFOの評議会にもWorking Group代表で出席するようになりました。

MEDINFO2017

この会からいよいよ、Open Source Working Group Chairになりました。中国で開催されたということで、ヨーロッパからの参加者は少なかったのですが、AeHINつながりでIndonesiaのLutfan氏と、openEHRつながりでThaiのChristian Chevalley氏とでopen soruceのworkshopをやりました。Working group paperをIMIAが毎年出しているYearbookに書くというのが一番の仕事で、昨年後半はopen dataについてまとめました。Christian Chevalley氏にはその後も日本に来ていただいてMOSSでも講演してもらいました。

まとめ

医療分野のオープンソースソフトウェアで研究��たり、活動したりしている人はあんまりいないので、国際的な活動をしているとつながりが広がります。この間に訪れた国は、ざっと数えて16カ国ほどです。それがどれだけ人の役に立っているかはわかりませんが、改めてまとめてみるとまだまだいろいろと書きたいことも出てきますね。今日はこれくらいで。長文読んでもらってありがとう。

0 notes

mossjp · 7 years ago

Text

MOSSとCode of Conduct

Code of Conduct(CoC; 行動規範）がFLOSS(Free/Libre/Open Source Software)に導入されてきたのはここ5年位のことでしょうか。

MOSSでもCoCどうしようかと考えたことがありましたが、せいぜい1年に1回セミナーやっている団体で、そこまでする必要性を感じませんでした。いろいろとオープンソースソフトウェア書きなぐってはいますが、ほぼ自分のみの一人コミュニティなので、これも必要ありませんでした。MOSSが嫌であれば参加しないだけの話ですし、目障りになるほどメディアアピールもしていません。

ORCA Projectも普及が進むに連れて、議論も枯れていきました。一度、医療情報学会で論文編集ソフトウェアのライセンス違反を指摘し��ときは炎上一歩手前まで行きましたが、その後は落ち着きました。

医療分野でのオープンソースソフトウェアで紛争が起きた事例は内外ともにあまりありません。ライセンス絡みのトラブルはたまにありました。本来、他人の著作物に対して改変を行ったり、再配布を行うことは著作権法では許されておりません。オープンソースソフトウェアライセンスは、著作者の権利によって改変、再配布を許可しているものであってその条件も示されています。

ライセンスが示す範囲内であれば、forkしようが喧嘩しようが別に構わないと思います。逆に、forkされて本来の意図とは異なるような使われ方をしても、それがライセンスの範囲内であれば認めざるを得ません。

オープンソースソフトウェアにとって、コミュニティの存在が大事なものであるということについては論をまたないのですが、そのコミュニティをどのように維持していくのかについては、さまざまな議論が積み上げられてきました。多くの人がコミュニティに関わってくるようになると、利害関係も発生します。参加者の善意がコミュニティを支えてきましたが、その善意が衝突することも珍しくはありません。CoCを設けるというのは、未然にトラブルを防ぐ方法だといえるでしょう。

数多くの内輪もめも見てきましたが、最終的にみんなが評価したのは粛々とコードを書いて事実関係を明らかにしてきた陣営であったようにも思います。

次のMOSSではそのへんも課題としようかなと思いますが、重くて影響も大きいのであまり気が進まない感じもします。

0 notes