Matthias Trute <mtr...@web.de> writes:
> Hi,
>
>> Now to my reprimand: Changing the software license is a significant
>> decision. I would have expected you to explain/justify the move well to
>> this forum and not just slap it on. Many people have contributed to the
>> success of your project and thus, I consider this to be basic courtesy.
>
> Sorry, you're right. So the formal request: I intent to change the
> license from GPLv2 to GPLv3. Details are available at www.fsf.org
> The reason is that I intent to include a major GPLv3 licensed
> code base. Enoch: you are the only code contributor to the
> assembly sources and the python based amforth-shell (17 commits,
> will double-check) who did not yet tell me under which terms you
> provided your code and patches. Your emails make me think that you
> disagree with the license change, so unless you explicitly
> say "Yes, I agree" I'll remove all of your code and replace
> it, if necessary before I proceed with my plans.
(1) A GPLv3 project can include GPLv2 pieces thus, formally, you don't
need anyone's consent. Also, all my contributions, those that you
accepted (as many more you have rejected) carried the following
spirit: \ Software license: AmForth compliant, see ... which means,
do with it as you please.
(2) Gforth is GPLv3 which is a reasonable license for its use: Gforth is
a lab for Forth inovation, a university tool, and I have yet to see
a commercial hardware product that is Gforth based. AmForth, if you
keep it GPLv2, can be used in commercial products (with certain
precautions). Using GPLv3, by design, that is simply
impossible. Thus, by choosing GPLv3 you are cutting yourself off
from a potential body of developers who, by definition, are more
experienced than the average hobbyist.
(3) I created the amforth-shadow respository
<https://github.com/wexi/amforth-shadow> after a series of patch
rejections which simply baffled me. Let me visit a simple case:
Any text book would tell you that repeated erase/write cycles would
cause an EEPROM cell to wear out. For this reason I changed the
frequently changing EEPROM pointers (DP, HERE and EHERE) with RAM
based copies. What was your response... that none of your boards
show any sign of EEPROM wear-out.
(4) Since I am heavily invested into AmForth code I am forced by your
GPLv3 trunk@1687 decision to turn amforth-shadow into a competing
project. Open source project forking is not good, it dwindles the
number of contributors. I am truly sorry that you force me into
that, but so be it.
Sincerely, Enoch.
------------------------------------------------------------------------------
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel
