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

Patrick Mauritz <[email protected]>
Newsgroups gmane.comp.video.fresco.devel
Message-ID <[email protected]>
On Sat, Nov 23, 2002 at 03:38:35PM -0700, M. Evans wrote:
> 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.
you may do whatever you want with the binaries (like LGPL)
you may modify the code and still reuse it binary only (not like LGPL)
but you may not relicense the source (not like BSD/...).

is that a proper paraphrasing of their exception to lgpl?

I don't think such a broad exception is necessary for fresco,
just explicitely allowing subclassing as non-derivative work
should be enough

> 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.
no problem to add some clarification, like it's done for parts of glibc and
other things... like "deriving a new class and specializing it without
actually modifying original source code does not count as derivative work"

> 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.
and looser licenses drive away other people. why should any company contribute
to an opensource project just to see that the competitor closes down the original 
code + their code + the competitor's code?

> 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.
this is ignoring the author's point. I'm not sure about stefan's
reasons to do the stuff here

> 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 :-).
that's why there are more people working on *bsd than on linux, right?
same goes for companies... how many companies are actively working on
improving the *bsds and how many doing the same on linux? the gpl actually
gives them security (see above)

> 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.
why shouldn't it end in CVS, except if it's poorly designed or implemented?
(which might still attract some devs to reimplement it better, which is
an advantage for the original dev as well)

> 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.
IMHO and IANAL etcpp:
if you extend a kit or parts of it, it's derivative work
if you write your own kit, that's based on other kits, that's your stuff
if you write a client without using lgpl'd code, that again is your stuff

now where's the problem, that you can't change the core APIs without
disclosing them?

> 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).
the fear/confusion thing is just more easy to explain to people who
think in "B.Gates - how to build a monopoly; successful ways to build
a software shop" terms than more complex scenarios like "working together
with your competitors, your customers and everyone else"

> 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.
to a) it's anti-exploit-friendly, why should I work for free for some company?
to b) given the confusion around the "viral" nature of *GPL, I don't think
      they really understand it. or are they just angry that they don't get
      blowjobs for free?
to c) they have done that because it helped them immediately, not just for
      fun - otherwise they weren't "thinking rationally". so if it helped them
      then, why should "we" (the "open source world") be thankful for that
      forever?

looser licenses have their use as well: take OggVorbis as example. providing
a reference library under a license allowing companies to specialize it to
their hardware (mobile players) without releasing the modifications helps
spreading the format.

I fail to see why anybody would want to do something like that with fresco 
though

> 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
then it should be clearly defined, *GPL wasn't written with CORBA-like
stuff in mind, so it might be a good idea to clarify that stuff

> world, leaving only the business to support it, but without code rights;
once they rewrote every foreign part, they're free to relicense it...
before, why should they? after all they use external stuff under the
conditions the author defined...

> the risk that the open-source project will not accept changes, thus
haven't seen that large-scale in any open-source project, except spin-offs 
of commercial applications

> requiring the business to configure its own source distribution;
> and on and on.
"configure its own source distribution" means adding another file to every 
release, big deal...

> 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.
see above, *GPL might even be an advantage, esp. when it comes to
hard-to-do work and fresco is a whole lot of software design
making it hard to "just hack" stuff together
do you really think GCC would exist, when being released under BSD license,
every company contributing would lock down their stuff and probably 
cross-license without going to the source pool. harris didn't publish their
gcc-stuff just because of that (teaching gcc to work with a stack machine
isn't easy), but they couldn't sell it either...

> 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.
I think it's important to make clear what's possible under LGPL + our
interpretation (which needs to be documented then) and what's not possible


--oxygene
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.