Re: [ox-en] Germ of a new form of society or germ of a new form of business?
- From: "Niall Douglas" <s_fsfeurope2 nedprod.com>
- Date: Wed, 04 Feb 2004 01:58:18 -0000
On 3 Feb 2004 at 17:32, Robin Green wrote:
Any lengthy propaganda piece by the FSF or those associated with
them will illustrate how "lesser" licenses than the GPL don't offer
the same protection. What the LGPL preamble says they apply to all
non- GPL free licenses when no one asks if commercialisation is
really a bad thing? Sure, if a company steals your work and markets
it ruthlessly you have a right to be bothered, but a company could
also integrate your work and return enhancements it makes back to
the communal fold. It's too easy to see dragons everywhere and
worse, to scare people into thinking there are more dragons than
there are.
So what _exactly_ are you implying here? That the situations the GPL
is designed to prevent are unlikely? OK, but then what's the harm in
licensing under the GPL anyway?
What I'm implying is that the logical default free software license
for the FSF is the LGPL which via clause 3 can be converted to the
GPL if the need arises.
The fact this isn't the standard advice speaks volumes about what the
FSF really want.
eg; acceptance and use of copyright
when it's a bad law and should be replaced.
We have to live in the real world, Niall - even the FSF does. What do
you _suggest_ to replace copyright, and how do you suggest we should
go about getting it replaced?
There are many schemes. Canada got round the p2p file sharing problem
by levying recordable media. Of course while copyright stands one
must work with it, but one should equally try to get the law
reformed.
I'd personally support a fifty year maximum statute on all laws,
force them to be completely rewritten every 50 years.
I do agree that the notion of derivative work is confusing and
problematic, however. It seems clear to me that if there exist a GPL
implementation and a non-GPL implementation (which allows free
linking) of the same API, then a package which links against the GPL
library is no longer a derivative work of it (as long as it only links
to the common public API) because it does not depend on the GPL code
in any way. The GPL code may offer various advantages such as freedom
and performance, but as long as there is no longer a dependency there
is no longer a derivative work.
It seems to me that if an interface has generic traits (eg; designed
to be general-purpose) then client code is not derived. If the client
code relies on internal state of the library, then it is derived -
but any well designed library won't have that.
More problematically, I don't quite see where to draw the line between
in-process linking and inter-process communication. Why should the
operating system notion of process have any bearing on copyright law?
For example, why is running an executable which involves *identical*
steps to loading in a DLL treated differently? Executables are just
DLL's without the relocation info on any platform.
It may be that the GPL reduces to the LGPL in some jurisdictions. But
that is very very different from what some clueless observers are
speculating in the SCO case: that the GPL might be reduced to public
domain. That is nonsense.
Well, SCO are up their arse anyway.
Were they mistaken? I'm not sure. But I think they had what they
thought were very valid reasons for spending all that effort. Don't
you?
If you took even half those developers and set them to work on the
"D" programming language, wouldn't it be better for everyone? Or even
better, a Haskell which isn't so obtuse?
The same probably goes for all other seriously large software
projects. GNOME, for example, is preferred by some developers because
(a) they don't want to learn C++, or more importantly (b) because they
perceived that g++ and Qt still waste a lot of space (although this is
being worked on for the next version of Qt). And I say this as a KDE
fan.
That really is a debate which makes me shake my head. Qt is a little
bloaty sure, a little inefficient in other places too, but in general
it uses the right algorithm in the right place which most user code
does not.
I will say however that FOX is much more lightweight than Qt and I've
been pleasantly surprised with its efficiency.
"The vast, vast majority of this work in unpaid and therefore lost
productivity to the economy." -- Niall Douglas' view of volunteering
You're quoting me out of context here! :(
Cheers,
Niall
_______________________
http://www.oekonux.org/