なんとかなるさね

マイコンをネタにブログを始めてみました


スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

--/--/--   blog-entry-   category: スポンサー広告

go page top

Arduino IDE|GadgetRenesas基板用IDE4GR 1.6.5(のようなもの)を作るには? 考え直し中(10) 

前のエントリでKURUMI基板でやったことを今度はSAKURA基板でやろうとしていて困ったことに気付きました。
KURUMI基板ではルネサス提供の再配布可能なライセンスではないと思われるファイルはカスタムライブラリに
のみ含まれていましたが、SAKURA基板ではカスタムライブラリだけでなくコアライブラリにも含まれています。
例えば内蔵USB関連や内蔵Ethernet関連です。そのこと自体は分かっていましたが、いざファイルを除外して
みて初めて、スケッチでUSBやEthernetを使用していなくてもリンクエラーになってしまうことに気付きました。
(それに対し、含まれているのがカスタムライブラリであれば、スケッチで使用していなければリンクエラーには
なりません。) KURUMI基板で使った手がSAKURA基板では使えず、どうしたものだろうかというところです。

追記 : 前のエントリに書いた(時系列的には後で気付いた)ことから考えると、コアライブラリの方は再配布可能
なのかも知れません。LGPLで配布されているArduino coreを改変したものという扱いになると思われる為です。
同様に、SAKURA基板のEEPROMライブラリも、LGPLで配布されているArduino librariesに含まれているものを
改変したものという扱いになると思われますので、再配布可能なのかも知れません。(なお、KURUMI基板では
EEPROMライブラリはArduino libraries由来のソースが使われていないようでした。API仕様からフルスクラッチ
されたソースのようでした。)

追記その2 : 最初から考え直してみると、LGPLのものを改変したものは、LGPLか、GPLか、(ライセンス違反か、)
にしかならないので、再配布可能ではないと思ってしまったことが、そもそも早トチリだったような気がします。

なお、コアライブラリに含まれていた内蔵USB関連ソースは以下の通りでした。

cores\arduino\usb_cdc.c
cores\arduino\usb_cdc.h
cores\arduino\usb_common.h
cores\arduino\usb_core.c
cores\arduino\usb_core.h
cores\arduino\usb_hal.c
cores\arduino\usb_hal.h
cores\arduino\usbdescriptors.c
cores\arduino\usbdescriptors.h

また、コアライブラリに含まれていた内蔵Ethernet関連ソースは以下の通りでした。

cores\arduino\utility\driver\phy.c
cores\arduino\utility\driver\phy.h
cores\arduino\utility\driver\r_ether_local.h
cores\arduino\utility\driver\r_ether.c
cores\arduino\utility\driver\r_ether.h
cores\arduino\utility\driver\t4_driver.c
cores\arduino\utility\driver\timer.c
cores\arduino\utility\driver\timer.h
cores\arduino\utility\r_byteq_v1.30\r_byteq.c
cores\arduino\utility\r_byteq_v1.30\r_byteq_config.h
cores\arduino\utility\r_byteq_v1.30\r_byteq_config_reference.h
cores\arduino\utility\r_byteq_v1.30\r_byteq_if.h
cores\arduino\utility\r_byteq_v1.30\r_byteq_private.h
cores\arduino\utility\r_config\r_t4_dhcp_client_rx_config.h
cores\arduino\utility\r_config\r_t4_dns_client_rx_config.h
cores\arduino\utility\r_config\r_t4_ftp_server_rx_config.h
cores\arduino\utility\r_config\r_t4_http_server_rx_config.h
cores\arduino\utility\r_config\r_t4_rx_config.h
cores\arduino\utility\T4_src\config_tcpudp.c
cores\arduino\utility\T4_src\ether.c
cores\arduino\utility\T4_src\ether.h
cores\arduino\utility\T4_src\ip.c
cores\arduino\utility\T4_src\ip.h
cores\arduino\utility\T4_src\r_dns_client.c
cores\arduino\utility\T4_src\r_dns_client.h
cores\arduino\utility\T4_src\r_dhcp_client.h
cores\arduino\utility\T4_src\r_t4_dhcp_client_rx_if.h
cores\arduino\utility\T4_src\r_t4_dns_client_rx_if.h
cores\arduino\utility\T4_src\T4_Version.c
cores\arduino\utility\T4_src\tcp.c
cores\arduino\utility\T4_src\tcp.h
cores\arduino\utility\T4_src\tcp_api.c
cores\arduino\utility\T4_src\type.h
cores\arduino\utility\T4_src\udp.c
cores\arduino\utility\T4_src\udp.h

他方、カスタムライブラリに含まれていたソースは以下の通りでした。

libraries\DSP\utility\r_dsp_complex.h
libraries\DSP\utility\r_dsp_filters.h
libraries\DSP\utility\r_dsp_matrix.h
libraries\DSP\utility\r_dsp_statistical.h
libraries\DSP\utility\r_dsp_transform.h
libraries\DSP\utility\r_dsp_typedefs.h
libraries\DSP\utility\r_dsp_types.h

libraries\EEPROM\utility\r_flash_api_rx600.c
libraries\EEPROM\utility\r_flash_api_rx600.h (これはGadgetRenesasの中の人によるソースのようです。)

e2 studioでビルドを試してみた時の画面は以下の通りでした。

コアライブラリのソースをビルドから除外するとビルド出来なくなる


カスタムライブラリのソースならビルドから除外してもビルド出来る


追記 : 雑感

もし、KURUMI基板のEEPROMライブラリのライセンスがLGPLであると帰結されるような記載がどこかにあった
場合、pfdl.aのソースやビルド手順が不明なことはLGPLのライセンス違反になってしまうのかな? (逆に言えば、
ライブラリとしてのライセンスについてどこにも記載がなければ、ライブラリ内にLGPLのソースとpfdl.aが共に
含まれていてもLGPLのライセンス違反にはならないことになるのかな?)

そう書いた後で気付いたのですが、ライブラリのトップレベルのEEPROM.cppとEEPROM.hに以下の記載があり
ましたので、ライブラリ内でソースやビルド手順が不明なpfdl.aが使われていることは、LGPLのライセンス違反
(というかLGPLとするのに必要な条件をそもそも満たしていない)ような気もします、、、
(追記 : 1次配布の時点でソースやビルド手順が不明なライブラリが含まれているのは良いのかも?? 2016/05/08)
(追記その2 : でも、自分達はソース非公開にしておきながら他者にソース公開を要求しているということになり、
悪く言えば、眉をひそめること、だと言えなくもないような、、、 2016/05/09)
(追記その3 : しかし、そもそも、ライブラリを改良して公開しようとする人がそのことを気にしない(あるいは、
気にはなるが別に構わないと考える)のであれば、結局、それならそれで別に構わないことなのではないかと思う
ようになりました。もしそれが自分自身であったとしたら、自分自身も、気になるけれども別にそれで構わない、
と考えると思いますし。 2016/05/30)
これは、ライブラリとしてのライセンスが他のOSSライセンスになっていれば良かったのかな? (ソースの主要な
部分が非公開なのにOSSライセンスというのはちょっと矛盾しているような気もしますが。)
2016/05/30

ファイル: EEPROM.cpp
ファイル: EEPROM.h
内容(該当箇所):

 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.

追記 : メモ

ちなみに、Arduino librariesのEEPROMライブラリの仕様/実装が昨年(2015年)にV2.0へ変わっていたようです。
(USB周りもPluggableUSBというものに変わっているようですし。)

EEPROM Library V2.0 for Arduino - GitHub
https://github.com/arduino/Arduino/tree/master/hardware/arduino/avr/libraries/EEPROM

追記 : メモ

あと、SAKURA基板のDSPライブラリも、ライブラリのトップレベルのDSP.cppとDSP.hに以下の記載がありま
したので、ライブラリ内でソースやビルド手順が不明なlibGNU_RX_DSP_Little.aが使われていることは、LGPL
のライセンス違反(というかLGPLとするのに必要な条件をそもそも満たしていない)ような気もします、、、
(追記 : 1次配布の時点でソースやビルド手順が不明なライブラリが含まれているのは良いのかも?? 2016/05/08)
(追記その2 : でも、自分達はソース非公開にしておきながら他者にソース公開を要求しているということになり、
悪く言えば、眉をひそめること、だと言えなくもないような、、、 2016/05/09)
(追記その3 : しかし、そもそも、ライブラリを改良して公開しようとする人がそのことを気にしない(あるいは、
気にはなるが別に構わないと考える)のであれば、結局、それならそれで別に構わないことなのではないかと思う
ようになりました。もしそれが自分自身であったとしたら、自分自身も、気になるけれども別にそれで構わない、
と考えると思いますし。 2016/05/30)
これも、ライブラリとしてのライセンスが他のOSSライセンスになっていれば良かったのかな? (ソースの主要な
部分が非公開なのにOSSライセンスというのはちょっと矛盾しているような気もしますが。)
2016/05/30

ファイル: DSP.cpp
ファイル: DSP.h
内容(該当箇所):

 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.

追記 : メモ

他にも、KURUMI基板のPicalicoFreeライブラリも同様な気がするのですが、PicalicoFreeライブラリはIDE4GR
0.7.0では無くなっていました。(picalicoFree.aは残っていましたが。) (COTTON基板の方でも同じでした。)

追記 : メモ

LGPL - Wikipedia
https://ja.wikipedia.org/wiki/GNU_Lesser_General_Public_License

GPL - Wikipedia
https://ja.wikipedia.org/wiki/GNU_General_Public_License

追記 : メモ

ライセンス違反にライセンス変更で対処することはよくあることなのかな?

FSF、LinuxとZFSと組み合わせはライセンス違反と指摘 - マイナビニュース
http://news.mynavi.jp/news/2016/04/13/115

追記 : メモ

著作権所有者による1次配布では、GPL/LGPLによる2次配布では許容されない条件を加える以下の例があります。
(2次配布でも著作権所有者(複数なら全員)から個別に了解を取っていれば条件を加えることは可能でしょうが。)

* FreeRTOSのModified GPL

* TOPPERSのGPLとTOPPERSライセンスのデュアルライセンス方式

追記 : 雑感

2年ほど前のエントリで当時のKURUMIスケッチ環境 V1.04のソースコードのライセンスをファイル毎に調べて
みたことがあったのですが、その時はGPLと非GPLの混在でモヤモヤしていたことを思い出しました。(なお、
結局今回は、1次配布の時点でLGPLのライブラリにソースやビルド手順が不明なライブラリが含まれているのは
良いのかどうか、ということでモヤモヤしていることになりそうです。)

ちなみに、2年前の時点で以下のウェブページ(というかライセンス)が存在していたのかどうか分からないです。
でも、今は、この存在により以下のURLを含むGadgetRenesasのソースは自動的にLGPLの扱いになりそうです。
私には、『Open Source Codeと一緒に、あるいはOpen Source Codeに組み込まれて、提供されている場合は、
そのOpen Source Codeのライセンス条項が優先される』ということが書かれているように読めましたので。

ソースに記載されたURL
http://www.renesas.com/disclaimer

アクセスすると以下のウェブページが表示されます
http://www.renesas.com/disclaimers/disclaimer20.htm

該当箇所: 2-(4)の次のセンテンスから

あと、KURUMI基板のEEPROMライブラリやSAKURA基板のDSPライブラリがLGPLの扱いになるとして、その
場合には、pfdl.aがEEPROMライブラリフォルダの下にある場合やlibGNU_RX_DSP_Little.aがDSPライブラリ
フォルダの下にある場合には、これらも再配布可能ということになるのかな? (IDE4GRでもe2studio用スケッチ
環境でもそうなっていましたし、IDE4GRではvariantsフォルダの下との2重持ちになってましたし。)

追記 : 雑感

逆に、このウェブページ(というかライセンス)(免責事項だけではない)を読んで、今後、どうしようかと思った
ことが、このURLを含むソースはOpen Source Codeの場合以外はconfidential(機密事項)として扱う必要がある
ように読めたことです。『配布(distribute)してはいけません』ではなく『開示(disclose)してはいけません』に
なっていて、その後の方で『機密保持義務(confidentiality obligations)』だの『機密性(confidentiality)』だの
どうのこうのと書かれているからです。今までソース上にconfidentialの記載があったソースは避けていたのです
が、今後はこのURLを含むソースも避けることになりそうです。(もっとも、もっと緩やかな別の使用許諾が指定
されていればそちらを優先することで避けなくても済むでしょうし、ユーザーズマニュアルは誰でも見ることが
出来る形で公開されていることが少なくないですのでそれを基にすることで避けなくても済むでしょうし、、、)

該当箇所: 4-(a)

ただ、誰でも作成出来るMy Renesasのユーザアカウントで誰でもダウンロード出来るようなものもconfidential
(機密事項)という扱いになることには、ちょっと腑に落ちないところが無い訳ではありませんが、、、

追記 : 雑感

あと、このURLを含むソースを使用したソフトウェアのバイナリ(HEXやMOTも含まれると思います)は、製品に
組み込んだ形でしか配布してはいけない、ようです。(工場などで)製品に組み込む為のコピーを作るのは可。

該当箇所: 2-(4)と2-(3)

これだと、インターネット経由のファームウェアの配布(アップデート含む)は許諾されないことになりそうです。

関連記事

2016/05/02   blog-entry-759   category: Arduino Lib & CrossGCC

go page top

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。