Combining Open Source Programs in a "Suite" of Independent Programs*
Randy Kramer
rhkramer at gmail.com
Mon Feb 28 21:06:37 UTC 2005
* For at least one definition of independent. ;-)
I'm not sure this is an appropriate question for this list--if not suggestions
for a more appropriate list are welcome.
I'm writing (trying to write ;-) something I think I'll call an application
suite, because it will consist of a number of independent programs, sometimes
working together for a common end.
To give one aspect: I plan to wrap (probably) several different editors so
that (among other things) they can communicate with a "supervisory" program.
The wrapping may be done in Qt (oops, may need to rethink this part, but let
me continue with the question on the assumption that Qt can be used for a
"proprietary" program--I'm not 100% sure based on the recent licensing change
for Windows, although I guess the free approach on Windows is an option, not
a requirement).
Let's assume I create the supervisory program and some new editor as
proprietary programs:
The supervisory program, among other things, would be aware of which file(s)
are open in every instance of the editor and, if I wanted to edit one of
those open files, would (on command) shift the focus to the instance of the
editor with that open file.
However, the editor and supervisory program would be completely independent in
the sense that a crash (or intentional closure) of either one would not close
the other). Communication between the programs would, in the case of Qt, be
by their signals and slots mechanism, and the nice tutorial at
http://developer.kde.org/language-bindings/ruby/kde3tutorial/p9.html
demonstrates this kind of communication between programs with that kind of
independence--try running instances of p7 and p8.
So far, I have an application that can be licensed with a proprietary closed
source license.
Now let's say I take an editor with an open source license (nedit, for
example), and manage to wrap it in Qt to achieve the same behavior discussed
above (for the editor).
I would believe that I could still keep the supervisory program and the
"proprietary" editor as closed source / proprietary, and only treat the
wrapper around nedit as an improvement to nedit which would need to be
distributed as open source under the same license as nedit. (Although
perhaps I'd need to actually distribute the proprietary stuff and the open
source stuff as separate packages (but, maybe not).)
Note: I haven't decided how I want to license the "suite" so far, but I have
made (small scale) efforts to solicit other volunteers to help, and have
thoughts about making a consensus decision on the license after a group of
volunteers exists. I do need to find a way to make a living, and writing
software is a preferred approach for me. I am aware (I've (mostly) lurked on
this list (and the fsb list) for quite a while) that there are ways to make
money with open source software. I want to know what my options are and
leave them open as long as possible.
regards,
Randy Kramer
More information about the License-discuss
mailing list