On Tue, Jul 26, 2016 at 3:01 AM, Albert van der Horst wrote: > It has been published, the generic system is GPL as well. > It is on the net since ages > http://home.hccnet.nl/a.w.m.van.der.horst/ciforth-5.0.tar.gz and > http://home.hccnet.nl/a.w.m.van.der.horst/cifgen.html > > I doubt that any one has downloaded this in a dozen years ;-( .
I see. > Indeed not in VCS , but we should not be dogmatic about tarballs that > provide a source that is feasible to change, i.e. they are Open Source in > actual practice. There is a difference between "I can modify this" and "Open Source". After all, it is possible to modify ELF binaries with a hex editor, objdump or IDA Pro. It is possible to modify minified JavaScript using a text editor. That doesn't make individual ELF files or minified JavaScript files "source". The important thing is equality of access to the work between upstream developers, Debian package maintainers, Debian users, users of Debian derivatives and every other person touching the software in some way. I have included here some links to articles about what "source" or the "preferred form for modification" is: http://www.inventati.org/frx/essays/softfrdm/whatissource.html https://b.mtjm.eu/source-code-data-fonts-free-distros.html https://wiki.freedesktop.org/www/Games/Upstream/#source > I should have used the word separate, not private. Ah, that is fine, as long as both are packaged for Debian and appropriate build and runtime dependencies declared. > Let us keep in mind why we want open source. The freedom to add e.g. an > ``unsigned less than or equal comparison'' to lina is better served by > an assembler source. It is actually doable by a moderately skilled > assembler programmer. ( Compare this with tinkering with GNU c by the > way. I have once modified GNU c to change the calling convention > for 68000 assembler code. Not for the faint of heart.) Hmm, that sounds more complicated than what I am used to: a "source" form of the work in the upstream tarball and files automatically generated from that in the Debian binary package. It sounds like you are automatically generating some assembler from forth code and then hand-tweaking the assembler? Could you explain the development workflow here? > There is a document contained in ciforth-5.0.tar that discusses when you > want to modify at the assembler level, and when at the generic level. > It is useful to provide both. I assume you are talking about README.ciforth here? > This is partly based on experience. In the 70's Forth systems were > generated by existing Forth systems. This didn't spread well, and only the > high priest of Forth could generate a system. It was not until > the systems were translated to assembler source that were widely > understood and could be build by widely available tools, that lead to the > Forth boom in early personal computing.(The famous FIG-Forth) That sounds suboptimal indeed. > I do want to have this system on a public VCS. It is now in CVS > on my private server. Any advice of how to move with the history > intact is welcome. I would suggest switching to the git VCS and a public Free Software hosting service. git is much more popular than CVS these days and existing hosting services are less likely to go down if you stop working on this project for some reason. https://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities -- bye, pabs https://wiki.debian.org/PaulWise
