Re: [Fresco-devel] Re: Cross-platformability

On Fri, Nov 22, 2002 at 01:12:46AM -0700, M. Evans wrote:
> 
> >> I'm a newbie and curious about the cross-platform possibilities of
> >> Fresco.  (1) What technical hurdles, if any, would have to be
> >> overcome to make Fresco run on Mac OS X, Win32, as well as Linux?
> 
> fdrfo> there are basically two big pieces that need to be ported / provided:
> fdrfo> one is a system / platform abstraction. Our 'Prague' sub-project
> fdrfo> provides an interface to (mostly) POSIX (file system access, inter-
> fdrfo> process communication, threading, etc.). Second, we need an interface
> fdrfo> to the i/o of the machine, i.e. input events, and graphical output.
> fdrfo> We call this a 'console', and rely on third party libraries to
> fdrfo> provide us this functionality.  Right now we have support for two
> fdrfo> such tools: GGI, and SDL (more about them on our homepage).
> 
> Well OK, fair enough.  Conceptually then Prague deals with "kernel level"
> issues while third-party libraries handle what you call "console"
> issues.

Well, Prague deals with system level stuff, and the Console layer
deals with graphical IO; it happens that our current Console
implementations use 3rd party libraries.

> By the way -- "console" connotes command-line programs.  It's a bad
> term.  Many compiler manuals talk about "console programs."  Maybe
> "graphics device context" or some similar term would serve better.

Eh, maybe; I was never terribly happy with the name either.  The
Console handles both input and output, though; it isn't just a
"graphics device context".

> I know about GGI and SDL.  GGI is a bit lower-level than SDL, and I
> think SDL can run with GGI as a "back end."

I believe they can each use each other as a back end :-) SDL does have
lots of "higher level" goodies we don't use (things like sound, etc.,
befitting its role as a games library), but AFAIK the only real
difference between SDL and GGI in terms of what their graphics API
provides is that SDL has GLX support.  Dunno if that makes it higher
level or not.

> fdrfo> All the rest is pretty high level and very portable.
> 
> OK, but it sounds like no one has actually tested on anything but
> Linux.  Is that true?

I know Patrick Mauritz has been working on getting things working on
Solaris, but not sure the status of that effort.  Some people have
periodically tried to get it working on BSD or cygwin, but in
the past have failed because of sucky threading libraries; possibly
these issues are fixed by now.

> Anyway I am encouraged by the possibilities.
> 
> >> Also -- (2) does Fresco deal at all with DisplayPDF?  (This is the
> >> graphics system used in Mac OS X.)
> 
> fdrfo> I guess this is a high level language to talk to the graphics
> fdrfo> engine. To run on that system we'd either need to provide a console
> fdrfo> that outputs 'DisplayPDF', or we'd need to interface directly with
> fdrfo> a lower level of the graphics system, which sounds more likely.
> 
> My question was not really "can Fresco run on DisplayPDF" but rather
> "does Fresco bear any relation to DisplayPDF."  DisplayPDF is simply a
> resolution-independent graphics API.  Apple adopted it for their Mac
> OS X.  The Scientific Python Chaco project uses it too.  My question
> arose from a curiosity about the design of Fresco.  It shares with
> DisplayPDF the resolution independence aspect.
> 
> I assume from your answer that Fresco is an ab initio design bearing
> no relation to DisplayPDF.

Our API isn't DisplayPDF, that's for sure.  In fact, we don't really
expose any drawing API at all.  (Technically, we do, but this may
change, and it's only accessible if you do things that are a bad idea
for other reasons.)  Our client level API is more along the lines of
"put some buttons in an hbox, and tell me when they get clicked".
This is really quite different from Aqua, where clients use DisplayPDF
internally to render to a bitmap, and then the server composites that
bitmap to the screen; it's somewhat closer to the original DisplayPS
stuff, where uploaded PS code was actually used to create rich
server-side behaviour.  (We don't currently have any way for clients
to upload custom code, but the idea of having rich behaviour in the
server is the same.)

Our API follows roughly the same imaging model as PDF, though, as far
as I know.  (Currently this probably breaks down in terms of things
like fonts and color management, but I don't know enough about PDF
internals to say for sure.)  And DisplayPDF, AFAICT, is just a set of
API calls that let you render using the PDF imaging model.

[snip]
> >> All I would add is that the LGPL license will drive away commercial
> >> developers.  Most of the ones I know completely avoid xGPL
> 
> fdrfo> There is nothing 'unfriendly' in the LGPL. All it does is to ensure
> fdrfo> that our work remains free. It is liberal enough to permit our libraries
> fdrfo> to be linked with proprietary pieces of code. All it does not allow is
> fdrfo> people to grab our code and repackage it into their own non-free code.
> fdrfo> What you may be thinking of is the GPL, which is 'viral' in the sense
> fdrfo> that it requires all code it is linked with to be free (according to
> fdrfo> some appropriate definition of 'free').
> 
> OK, let me clarify.  I know quite a lot about GPL, LGPL, and other
> licensing.  Briefly:  LGPL is a reasonable license for a project
> like Fresco.  It's just not the ideal thing for any project hoping
> to attract commercial developers.  This is why the wxWindows project
> came up with a slightly modified LGPL; wxWindows permits commercial
> sale of binaries without source requirements on library modifications.
> 
> The reality of business code is that it almost always involves some
> library modification.  So raw linkage as defined by LGPL doesn't cut it.
> Think about using a widget library like wxWindows.  There is an extremely
> strong likelihood that *any* application will subclass some widgets.
> 
> Even the idealized world postulated by LGPL doesn't work out.
> Assume an ideal businessman really wants to help the LGPL project.
> So he submits all his modifications back to the project.  There is
> still a potential headache.  What if the project *rejects* his
> changes?  Now, the businessman is under obligation to create his *own*
> mechanism for source code distribution!  He must offer end users
> a means to re-link the application using his particular variant of
> the LGPL code.  He must offer source code to his version of the LGPL
> library.  It all gets very sticky.

I think this argument is confused.  Fresco isn't a widget library;
Fresco is a windowing system.  It's like you're arguing that
businesspeople cannot write applications for X (or for MS Windows, for
that matter), because the reality of business code is that it almost
always requires modifications to the X server or xlib, except in the
case of X this is okay, because the business can ship binary only X
servers that can run their application...

Granted, we can probably do better the LGPL for the stuff that is used
client side -- in particular, I'd be happy to make all client helper
libraries MIT-licensed, and perhaps the IDL interfaces too (though I
really fail to see why anyone would need to modify the IDL interfaces
to let their app run -- if you do, then you can't talk to the server
anymore!)

I haven't seen businesspeople running screaming from GTK+ or Motif, or
including special modified versions with every app, either.

> Businessmen appreciate some other things that open source folks fail
> to ponder.  Many of these legal software definitions are not settled
> in case law.  This fact creates further ambiguity from a businessman's
> standpoint.  What is "linkage"?  What is "executable"?  Is a
> "subclass" considered a "modification"?  Courts can be arbitrary,
> and a competitor with a smart lawyer can do real damage.  So from a
> business standpoint there is a built-in legal risk with LGPL.
> 
> The point is that yes, LGPL is more friendly than GPL, but not
> friendly enough.  It permits linkage with proprietary code.  However
> it can also cause massive problems as outlined above.
> 
> When you think about it, it's much more polite to ask business to
> contribute what it is willing/able to contribute, than to demand,
> up-front, surrender of all library changes.

I don't even understand what you mean here.  You think MIT = "ask
business to contribute what it is willing/able to contribute", and is
more polite? I think letting businesses take my code closed source is
rude.  And I don't see that businesses particularly need to be making
changes to the Fresco server, unless they're trying to build a
proprietary implementation, which is fine, but I don't think they need
to steal our code when doing so.

> If you read some of the xGPL philosophy papers, they espouse the
> notion of driving commercial software out of business in no
> uncertain terms.  This is not a goal that I share.  My attitude
> is that commercial and open-source efforts can complement each
> other.  Open source should be willing to accept what business
> can/will contribute, without making stringent legal demands.
> Business should understand (and generally does) that it can
> leverage the volunteer labor pool by contributing pieces of its
> work back into the pool.  I don't think of LGPL as the win-win
> ideal.

I sorta object to the feeling I'm getting here, that we should just
give business whatever it wants, and hope that out of the kindness of
their hearts the businesspeople will give something back, and us poor
open-sourcers should be be grateful for the chance to hope.  I also
don't see what any of this means in practical terms.  If a company
wants to contribute work to Fresco, then bully for them; the only real
reasons I can see them wanting to do this is that they use Fresco and
need the improvements (in which case they shouldn't mind giving their
code an open license), or that they want to write a competing server
implementation (in which case they certainly won't be giving anything
back, it would defeat the whole purpose of writing a competing
commercial implementation).

> Open source is hurt more than helped by LGPL; commercial folks
> are scared away from it, and that hurts open source because it
> diminishes the labor pool.  It's better to take what you can get than
> to scare people away completely (so that you get nothing at all).

Arguable -- for instance, the reason the open source world can use
Objective C (and, eg, GNUstep can exist) is the GPL license on gcc;
Apple wanted an Objective C compiler, would have been happy to keep it
closed, but decided that the benefits of leveraging the gcc codebase
were worth freeing the result.  But this is the sort of philosophical
point that probably isn't worth arguing about, except late at night
after a few beers :-).

> For that reason I prefer to volunteer my labor on projects licensed
> under X or BSD.  This is just my personal position and philosophy;
> I am not interested in lobbying Fresco or holding a long debate.
> Different people have different feelings and I respect all
> points of view.  I just wanted to clarify my earlier remark and
> perhaps disrupt some common misconceptions about the friendliness
> of LGPL.

You are of course welcome to your personal philosophy, but I'm not
convinced by your arguments :-).  Hopefully my responses can help
clarify why I think they don't apply here, and if they calm your
worries enough that you can overcome your natural repugnance (;-)) to
the LGPL, then we'd still be happy to have your help.  :-)

-- Nathaniel

-- 
"Lull'd in the countless chambers of the brain,
Our thoughts are link'd by many a hidden chain:
Awake but one, and lo! what myriads rise!
Each stamps its image as the other flies"
  -- Ann Ward Radcliffe, The Mysteries of Udolpho

This email may be read aloud.