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