[Fresco-devel] Re: Cross-platformability

>> 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.

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.

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."

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?

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.

fdrfo> This project is run by volunteers who do it in their (often scarse)
fdrfo> spare time.
fdrfo> Who cares may consider contributing and thus make us progress faster.

I am involved with open-source projects and that is how my
interest in Fresco came about; there may be some overlap.  I am always
interested in saving everybody's development time, yours and mine.

>> 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.

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.

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.

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).

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.

Mark