Re: [Texmacs-dev] Double licensing or exceptional clauses

[Joris van der Hoeven]

> > I was thinking about double (multiple) licensing: the whole software
> > falls under the GPL in any case and any second license will make
> > clear that the whole software is available under this license too.
> > However, this license permits nobody (including ourselves)
> > to distribute and/or sell binaries based on (e.g.) Windows/Qt.
> > We will ask any contributor to agree with the fact that
> > I, we, he or she (we have to think about this) are allowed to
> > distribute TeXmacs under a different license which permits
> > the distribution of binary versions when this is necessary to
> > make the software work on a given platform, under the condition
> > that these binaries may be freely copied and sold. Hence,
> > every *particular* binary distribution is as free as it can be.
> 
> I really do not see the point here.
> 
> The GPL already authorize linking against proprietary system
> libraries. I think that precisely addresses the needs of making the
> software work on a give platform. Using proprietary non-system
> libraries like Qt is *not* a requirement to use win32.

No, but if we want to do it, then we are stuck. I have a broader
interpretation of "getting it to run" on another OS than the FSF:
I want to see graphical toolkits as part of the system libraries.
For most modern applications, involving a GUI frontend,
this is a reasonable broadening.

> > In other words, this process somehow cleanly automizes
> > the process of making exceptions whenever needed.
> > Each possible exception is ensured to be as free as possible
> > on its own, but we have the privilege of deciding when
> > exceptions can be made.
> 
> I do not understand what you want to do.
> 
> I am not fundamentally opposed to a dual licensing schemes, especially
> if that can make organizations like the CNRS and the ANVAR more
> comfortable. However, the whole problem of software licensing is not
> very clear, especially with free software, and especially in Europe.
> So I would rather prefer not to make anything fancy before we have IP
> lawyers to help us secure that kind of things.

I agree, but does not prevent us from thinking on our own for a while.

> > > Really, I think we should keep off Qt/win32. However I really would
> > > not like to have to program a user interface on raw MFC; as it is
> > > probably as bad as Xlib. Maybe then we would be able to use wxWindows
> > > for the win32 port.
> > 
> > The problem with wxWindows seems to be that we can not customize
> > the menus very much. We should check this for Qt too though.
> 
> As long as you can make the symbol menus (which is maybe a bit tricky)
> and update the menus on the fly (which any half-decent toolkit can
> do), I do not see what is the problem.

Yes, but these things may already be problematic: in wxWindows,
they only seem to support latin string labels and bitmaps (under Windows).
This is also a problem for supporting Russian.

> METAFONT-rendered menus are not a feature. They are disruptive of
> look-and-feel policies and even if they are cute, they are *not* to be
> kept with other toolkits.

I do not agree with you; I will keep this as a default option, at least on X.
Many users like the application for this single reason and I am not going
to change that. But I do agree on making other types of menus an option.
Many people don't care about disruptive look-and-feel policies:
they maximize the TeXmacs window on the screen and want something
as nice and beautiful as possible. Under GNU/Linux there is no
coherent look-and-feel policy anyway.

I also want to keep the possibility open to render formulas and
other material in the menus. Think of a menu of frequently used
formulas selected by the user (a wish). Also, a good GUI should
allow me to do this ANYWAY. The METAFONT-rendered menus in TeXmacs
are not a "cute" and "isolated" particularity. They are both a piece
of modern GUI design and recognized as being esthaetically superior
by many users. I am willing to throw away virtually anything in
the current GUI, but not this FEATURE.