Re: Making MzScheme extensions using VC++ 5.0?

[Paul Fernhout <pdfernhout@kurtz-fernhout.com>]

Matthias Felleisen wrote:
> 
> Why don't you build the software first and then worry about the licensing
> deal? If you really dislike one, I bet there is a way to re-build the
> software in a slightly different context. -- Matthias

Good point. Its certainly a way to move forward quickly and that has a
lot of merit.

However, in general, I still like to get the licensing issues out of the
way at the start since porting often does take time -- if for no other
reason than because of all the retesting that is required. However,
often as not there are also subtle differences that can be
time-consuming to resolve. Deals are also usually worse when you are
already committed to something. Also, for copyright reasons, I also like
to minimize "contamination" (in the legal copyright infringement sense)
by avoiding even looking at source code if I don't want to deal with its
license. (While it is true you cannot copyright an idea or algorithm,
there are other aspects of the code, such as organization that the
copyright also extends to.)

That's also one thing I like about Scheme itself. Since there are so
many implementations (several fairly unencumbered of licensing
restrictions like Elk), one can develop under one and with reasonable
effort port it to another system with a different license if desired. Or
as SIOD shows (Scheme in one day / defun) one can make a limited Scheme
oneself with a reasonable effort.
Obviously, something with the sophistication and stability of MrEd for
example is going to take a lot more effort than that.

In regards to MzScheme and LGPL, I still might decide I don't like the
LGPL restriction of also shipping separate object files so an end user
can relink against the library (or other related licensing issues in
section 6.). I have no problem with submitting changes made to the core
-- it's this specific issue that creates an extra awkwardness on
deployment. So for example, under the LGPL, if I use the technique
Matthew Flatt explains in "new stand-alone executeable trick":
  http://www.cs.utah.edu/plt/mailarch/plt-scheme-2000/msg00661.html
I believe I would still need to make available seperately the *.zo files
for each module to end users. I can probably live with this, but I find
it awkward. Some libraries work differently -- for example, the
wxWindows 2 licence is essentially the L-GPL (Library General Public
Licence), with an exception stating that derived works in binary form
may be distributed on the user's own terms.
  http://www.wxwindows.org/newlicen.htm

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com