Dear Matthias, Let's not lose our cool :-)
Changes to your kernel I make constantly public (amforth-shadow on github) but "my dishwasher code" which a customer pays to develop I cannot disclose. My customer is obliged to maintain and upload my code separately to each board they produce, boards that run amforth-shadow. My research puts me on a very solid legal ground as currently AmForth is declared GPLv2. As you are the sole copyright holder you can put extra conditions on the use of your code (such as a requirement to disclose non-derived/indepedndent "diswasher code"). You will force me to fork immediately -- it's your call -- I will regret such a decision very much. By the way, amforth-shadow started out due to your refusal to incorporate to the kernel Second-Level Interrupt Handlers (SLIH) and Interrupt based DTR/RTS/CTS serial communication. Both, I think, a detriment to the users. At least you liked my wordlist scope idea ;-) Sincerely, Enoch. <daruf...@gmail.com> writes: > Matthias, > > > > > I am new to this list, so you can ignore me as you like, but I have been > around this industry for a very long time. I have discussed this topic and > how it relates to Forth all too often, but in the > end, it really doesn't matter what you and I think, or who is on the “right” > side of the law. You are correct that there have been many cases where GPL > has won, but after all the lawyers have been > paid, it's the customer who has lost. This is NOT a battle you want to play, > and in the end, no one can win. > > > > > You are only one of 3 alternatives in the Forth market for AVR: > > > > > http://www.offete.com/328eForth.html and > > http://www.forth.com/downloads/SwiftX-Eval-AVR-3.7.1-f4qbm8hnnrg5r42ko.exe > > > > > Are both viable alternatives. I'm working on a project for Maker Faire right > now that I hope will run on all 3, although I only have eForth working at the > moment. I hope to make it public domain, > but your words might end up making me not want to even mention your product. > While it is not difficult to be compatible across multiple versions of Forth, > it is exceedingly difficult to take any of > us to court, since only a very few have ever made anything off the language > itself. It would also not be very difficult to produce a closed system that > would be extremely difficult to tell was using > yours or anyone else’s Forth. They are just libraries, and it's doesn't take > much to obfuscate them enough so they are no longer recognizable. Been > there, done that! > > > > > Now, as far as removing the heads from the executable object, I would highly > recommend that Enoch look at the SwiftX model. It does that from the start, > and as someone who has worked at Forth, Inc., > I highly recommend their tethered model rather than those that have to > support a built in compiler model, like yours and eForth. I also did my own > separate head model back in the 80's from a > polyForth or F83 model (;I really can't remember which anymore;). I really > liked the idea of being able to remove the heads once I finished the project. > I never actually did anything with it because > Forth, Inc. hired me shortly after that, but it was certainly a fun learning > project. > > > > > People said it couldn't be done back then too, so be careful what you say is > impossible. > > > You are about to loose a customer! > > > DaR > > > > > > From: Sam Putman > Sent: Monday, February 17, 2014 12:20 PM > To: Everything around amforth > > > > > > On Mon, Feb 17, 2014 at 11:52 AM, Matthias Trute <mtr...@web.de> wrote: > >> Hi Sam, > >> I am concerned about part of what you appear to be implying here. Do you >> > consider Forth words loaded into the AmForth environment to constitute >> > 'derived works', and hence subject to the GPL? >> >> Definitely. Any program includes the amforth system (GPL'ed). So it is >> a derived work (amforth is not *L*GPL). But IANAL... >> >> > That would make me uncomfortable, as someone who favors the public domain >> > and BSD/MIT style permissive licenses for my own work. >> >> I'll never understand the *BSD people. They give away their work for >> free and could not even pay the energy bill for their development >> systems (happened just recently in Canada). *I* value my work much >> higher, and I've expressed earlier how I see my payment: Code, Success >> stories and cooperation/acknowledgement. I do understand, that others >> have different goals in mind, but such are the rules. (I considered the >> Affero-GPL, it would be nice too). >> >> I'd say that a man-year of work went into amforth by now, so feel >> free to start your own forth. With a more permissive license, if you >> like. It's doable and it's fun. And a lot of work. And up to you. >> >> > Hmm, y'know, I just might. But certainly not to spite your good work or > detract from it. > > I'm no good spokesperson for those who designed the permissive licenses. > For me, it comes down to the presumption of goodwill, which I am willing to > make in my own work. I'm old enough to have seen a few iterations of this > discussion, and harbor no hostility to either camp. > > By the same token. If I distribute a file which runs only on AmForth, under > only a permissive license, I don't see where the GPL affects it. If someone > else wanted to port it to eForth, for example, and sell the resulting > product (a washing machine, right? ;-), any claims that loading it into > AmForth contaminates the original code license would be on shaky ground. > > I hope this is not the case that would make you mad, rather, someone > writing a 'proprietary' extension to AmForth and distributing it in an > image-only fashion or as firmware. IANAL, but I do know the consensus on > this one, and it favors your interpretation. Irrelevant to my purposes, > happily. > > As a total aside, supporting Dr. Ting if you need a proprietary Forth might > be a good idea. I'd hate to see either Matthias or Enoch's customers be > unhappy. > > cheers, > -Sam. > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
