[Fresco-devel] Re: Cross-platformability

fdrfo> The X Consortium license isn't a good starting place, IMHO.

I think the wxWindows license (listed at opensource.org) is a good
one.  It came about after a full year of debate on their mailing list.

fdrfo> So what ? Put your subclasses into your own library and ship them 
fdrfo> binary-only. But please keep the LPGL library you derive from free.

fdrfo> no ! Well, if you mean by 'customized' modificated versions of libgtk*,
fdrfo> then yes. But nowadays you customize by *deriving* your own classes.
fdrfo> You do that without modifying the original. In fact that's the whole
fdrfo> point of inheritance. No problem at all with the LGPL here...

Like I said -- many of these terms have not been decided in case law
-- where it really matters.  Subclasses are very arguably a derived
work, and thus require source to be divulged under LGPL.  I guarantee you
that if one were litigating, one could pay expert software consultants
to make this argument.

fdrfo> The issue is not about being polite or not. It is my right to require
fdrfo> anybody who uses (and modifies) my code to keep it free.

You have the right to keep it *all* to yourself.  Open source is about
attracting people to contribute.  The GPL attracts certain folks, the LGPL
attracts certain folks; and both of them also *drive away* certain folks.
Somewhere exists a happy medium that maximizes the labor pool.  I happen
to believe that it is not LGPL.

fdrfo> But whoever demands me to use my code, may
fdrfo> do so under the conditions *I* set.

This is ignoring my point -- you must calculate those conditions
mindful of how they will affect who decides whether to use the
code at all.

fdrfo> But anyways, lets not get dragged into a license war here.

I'm not in a war.  What I am saying is that more manpower is
available under looser licensing.  I'm trying to add numbers to your
side :-).

fdrfo> I don't have
fdrfo> any trouble asking for these modifications to remain free, too.

Which assumes that such changes will go straight into CVS -- not
always the case.  If not, the business must manage its own source code
distribution mechanism under LGPL terms.

It also assumes that such changes are easily decoupled from the
proprietary code that the business *must* keep private to survive.
That is not always the case, though IDL interfaces may help a
lot here.

fdrfo> just stating that it is correct doesn't make it so.

But it says that mine is a considered position, not some unfounded
psychological fear/confusion factor (as LGPL advocates often try to
paint it).

fdrfo> yes, lots of business people seem to be confused about any kind of
fdrfo> license that doesn't use the term 'permission' the same way they are
fdrfo> used to.
fdrfo> And yes, this confusion does seem to stem from general fear because
fdrfo> (L)GPL does funky things with the market's own tools to 'defend freedom'.

This armchair psychology discounts (a) the explicit anti-commercial
intent of GPL and (b) the fact that businessmen know how to think
rationally and understand contracts.  It also discounts the fact that
(c) businesses have made huge contributions to the open source world.

Businessmen are paid to manage risks.  It's not a question of confusion
but of risk.  From a legal standpoint, the LGPL causes certain risks
when used in commercial code.  There is the risk that modifications
will be necessary; that "modifications" can be interpreted in many
ways at court; that an LGPL project will be dropped by the open source
world, leaving only the business to support it, but without code rights;
the risk that the open-source project will not accept changes, thus
requiring the business to configure its own source distribution;
and on and on.

The wxWindows license is an example of how to short-circuit all these
risks while not straying far from the LGPL.  The BSD license may
be too loose, but nonetheless its success is quite remarkable and says
to me that xGPL is not the necessity its advocates claim.  In other
words, open source can succeed quite handsomely under BSD, despite all
the xGPL talk about business stealing code, etc.

My overall point is that it's better for an open source project to
attract commercial developers and obtain *some* of their improvements,
than to drive most of them away with stringent demands and get
*nothing* from them.

OK I've spent enough time on the subject, and since war has been
threatened, this will be my last note on the subject.  Thanks everyone
for your consideration.

Mark







fdrfo> --__--__--

fdrfo> Message: 6
fdrfo> From: Tobias Hunger <[email protected]>
fdrfo> To: [email protected], "M. Evans" <[email protected]>
fdrfo> Subject: Re: [Fresco-devel] Re: Cross-platformability
fdrfo> Date: Fri, 22 Nov 2002 21:13:52 +0100
fdrfo> Reply-To: [email protected]

fdrfo> -----BEGIN PGP SIGNED MESSAGE-----
fdrfo> Hash: SHA1

fdrfo> On Friday 22 November 2002 20:16, M. Evans wrote:
>> As for the rest, I am not persuaded by your remarks, and never have
>> been -- though they reflect common attitudes about LGPL.

fdrfo> Mark, feel free to disagree. I do not really consider it an issue though.=
fdrfo>  As I=20
fdrfo> wrote earlier: Using CORBA objects does not (yet?) fall under the term=20
fdrfo> 'linking' and is not covered by either the GPL nor the LGPL. So you can u=
fdrfo> se=20
fdrfo> Fresco (who only exports CORBA interfaces anyway) from proprietary code.=20
fdrfo> Modifying our code is a different issue of course, but in general we cons=
fdrfo> ider=20
fdrfo> Fresco's exported objects to be more of building blocks that are combined=
fdrfo>  to=20
fdrfo> build up complex objects. So you should rarely need to inherit from our=20
fdrfo> objects, usually you just combine them in another way. Inheriting makes y=
fdrfo> ou=20
fdrfo> depend on a certain=20

fdrfo> Well, the discussion is pretty premature anyway:-)

fdrfo> - --=20
fdrfo> Gruss,
fdrfo> Tobias

fdrfo> - ------------------------------------------------------------
fdrfo> Tobias Hunger           The box said: 'Windows 95 or better'
fdrfo> [email protected]                      So I installed Linux.
fdrfo> - ------------------------------------------------------------
fdrfo> -----BEGIN PGP SIGNATURE-----
fdrfo> Version: GnuPG v1.2.1 (GNU/Linux)

fdrfo> iD8DBQE93pABv0FZW3NyoqURAmm9AJ49zmSVJoTYUlLLMx82NKDnPqBssgCgjIbD
fdrfo> TXzsop7O6AORqZlpFTs4G74=3D
fdrfo> =3D+Imj
fdrfo> -----END PGP SIGNATURE-----


fdrfo> --__--__--

fdrfo> Message: 7
fdrfo> Date: Fri, 22 Nov 2002 13:05:38 -0800 (PST)
fdrfo> From: C Y <[email protected]>
fdrfo> Subject: Re: [Fresco-devel] Re: Cross-platformability
fdrfo> To: [email protected]
fdrfo> Reply-To: [email protected]


fdrfo> --- "M. Evans" <[email protected]> wrote:
>> 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.  

fdrfo> Really?  Even for something at the level of Fresco?  I would think that
fdrfo> any reasons to modify Fresco would signify weaknesses in Fresco, and
fdrfo> therefore be worth fixing in Fresco itself so other people don't have
fdrfo> to do it in the future.   People don't (can't) modify Microsoft's
fdrfo> graphic system, and seem to do just fine.  Am I missing something?  Did
fdrfo> you have specific examples in mind?

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

fdrfo> Um.  Translation for the newbie - what does subclass a widget mean?

fdrfo> CY

fdrfo> __________________________________________________
fdrfo> Do you Yahoo!?
fdrfo> Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
fdrfo> http://mailplus.yahoo.com


fdrfo> --__--__--

fdrfo> Message: 8
fdrfo> Date: Fri, 22 Nov 2002 17:51:02 -0800
fdrfo> From: Nathaniel Smith <[email protected]>
fdrfo> To: [email protected]
fdrfo> Subject: Re: [Fresco-devel] Re: Cross-platformability
fdrfo> Reply-To: [email protected]

fdrfo> On Fri, Nov 22, 2002 at 09:58:49AM -0800, UNIX savvy Brian Witt wrote:
fdrfo> [snip]
>> The topic of licensing using an "GPL" style license comes up
>> kinda reguarly on various mailing lists.  Is there a newsgroup
>> or ML where things can be dicussed?  Maybe a few wannabe lawyers
>> hanging out rendering a legal prespective?

fdrfo> You might try http://lists.alt.org/mailman/listinfo/fsl-discuss

fdrfo> -- Nathaniel

fdrfo> -- 
fdrfo> Damn the Solar System.  Bad light; planets too distant; pestered with
fdrfo> comets; feeble contrivance; could make a better one myself.
fdrfo>   -- Lord Jeffrey

fdrfo> This email may be read aloud.


fdrfo> --__--__--

fdrfo> Message: 9
fdrfo> Date: Fri, 22 Nov 2002 18:04:06 -0800
fdrfo> From: Nathaniel Smith <[email protected]>
fdrfo> To: [email protected]
fdrfo> Subject: Re: [Fresco-devel] Re: Cross-platformability
fdrfo> Reply-To: [email protected]

fdrfo> On Fri, Nov 22, 2002 at 12:16:57PM -0700, M. Evans wrote:
fdrfo> [snip]
>> You do have a point that lower-level libraries such as Xlib are less
>> worrisome as LGPL code, because they are less likely to require
>> modification.  That's a point which I bring up regularly
>> when decisions are made whether to adopt LGPL code.  As a user
>> interface system, I don't think Fresco falls into that category.
>> (Something like GGI or SDL or Xlib does though.)
fdrfo> [snip]

fdrfo> I'm not going to reply to the rest of this thread; rather get actual
fdrfo> work done than argue about licensing :-) But I think you're confused
fdrfo> about what Fresco is.  Fresco is analogous to the Windows GUI, or to
fdrfo> X, and nobody includes modified X servers or alternate versions of
fdrfo> Windows with their programs.  Xlib is much less lower-level than our
fdrfo> client libraries, in the sense that there are reasons a client might
fdrfo> want to change xlib to work differently (indeed, there are alternate
fdrfo> libraries designed to speak the X protocol, while fixing problems with
fdrfo> xlib).  We, on the other hand, just have IDL, which specifies nothing
fdrfo> more than the protocol itself.  So you're much _more_ likely to want
fdrfo> to change xlib than our stuff.  And yet, I've never encountered a
fdrfo> program that had to include its own version of xlib, just because they
fdrfo> needed some hacks the real version didn't support...

fdrfo> Hopefully that clears up some technical issues.

fdrfo> -- Nathaniel




-- 
Best regards,
 M.                            mailto:[email protected]