Re: [Qemu-devel] Re: Spice project is now open

[Andrea Arcangeli]

Hi everyone,

On Fri, Dec 11, 2009 at 09:44:02PM -0600, Anthony Liguori wrote:
> A typical scenario is someone develops a closed source plugin, but does 
> not distribute it with the original piece of software thinking that they 
> aren't creating a derived work because there's no combination.

Creation of derived work of a GPL'd program isn't defined like
this. You can ask confirmation to IBM lawyers. Even ignoring the
explicit allow Linus gave (initially for already existing x86 drivers
coming from other proprietary OS that had more drivers than linux at
the time), it was meant for software written for other OS and ported
over to be dynamic linked into the kernel, so clearly not creating a
derivative work as the binary existed already for other OS.

This has been abused, and later EXPORT_MODULE_GPL was added
too... Even if anybody can remove the _GPL tag with any GPL'd patch,
without necessarily creating a derivative work or breaking the GPL by
removing that _GPL suffix. However if your module only works after you
remove a couple of _GPL suffixes that rings an huge bell that you are
breaking the GPL and everyone will look if that really is a derivative
work or not.

> GCC is not the best example since it's support for plugins are 
> relatively new.  It's bad for users.  They start using a plugin for one 
> version and they really like it, they want to update to a new version of 
> the base program and now their plugin no longer works.  The plugin has 
> gone unmaintained and now they have to choose between the plugin and 
> updating the base program.

If plugin is dead and unmaintained I guess it wasn't so useful after
all... besides it's all GPL so he can maintain it himself.

Libs APIs also are upgraded and they stop building and you got to
upgrade the program too in order to use the new lib. It doesn't matter
if this is called a plugin, static or dynamic lib, in raw terms it's
just a function that changed its arguments, how the function .text is
loaded into the address space is technicality.

> I don't think the kernel is an example of it working smoothly.  It's a 
> constant source of frustration for users and people are constantly doing 
> ugly things wrt licensing.

There are lots of less stable GPL'd module drivers too, it's not just
nvidia, so what? Besides the tainting flag that avoids some of the
time waste of the few abuses of the interface, CONFIG_MODULE=y is
clearly a net win and removing pluggable modules would be insanity. In
life few things are black and white and 100% improvements, but when
the benefit greatly exceeds the downsides, it's fairly silly to use
the few downsides as an argument to reject it. It'd be like refusing
to catch a plane because it could crash in the middle of the ocean.

In a previous email you said:

--
Historically, we have not supported multiple display mechanisms
favoring making one mechanism as good as it can be.

Supporting both Spice and VNC would go against this policy.  It's not
--

There's no such thing as a policy in open source, this is not a
committee, code rulez in GPL'd world, everything else is irrelevant.


About the discussion of improving VNC, this code has to change and
move so fast (you can see already requests from Alexander to split the
features to allow remote usb from remote qlx, it's expectable code to
change for the better to support more obscure features than 99% of
userbase cares about as it goes open), it's huge, it's unreasonable to
pretend to make official modifications to VNC protocol every time we
do a small change to the protocol to please Alexander or anybody other
reasonable wishes of the day, even vnc could eventually reach
equivalent speedup (which is debatable too). Going the vnc route and
official feature requests to extend the protocol is a dead hand IMHO,
all you can argue is spice or something else separate from vnc.

Likely the spice protocol should be left free to float for a while so
all graphics people can put their hands on it and improve it. Open
sourcing it is going to inevitably improve spice protocol. There is no
hardware involvement, no lock-in, no lack of specs, this is an area
where open source can shine against proprietary world. But policies,
licenses and in general political arguments must be left void and
irrelevant and we must stick to technical discussions about code.

Once things settled down and protocol is stable it is very reasonable
to expect a VNC export to enable/disable so legacy vnc clients can
still be used on qlx guest even if they will lose most of the
benefits. But worrying and discussing it now is too early. It would be
like pretending to provide a git-svn importer before git was actually
usable...

Overall, it's awesome SPICE has been finally released Open Source,
even if in only in tarball form so far.  I hope splitting the tarball
in patches is also feasible... ;) and it will be done, but clearly
it's a clumsy work and so I guess it will take a bit of time so
there's no particular reason to worry about that. You know it's not
worth fighting about tarball issues but hey we're all humans so it can
happen, get over it. The tarball allows first open technical review of
the technology and to get all the bits sorted out. We believe in Open
Source to shine in the long term, and this opens the way for real open
source efficient desktop virtualization. Let's stick to that and
technical arguments ;). Which probably means this thread should stop
temporarily and everyone should wait first possibly "mergeable"
patches to come to list. And my hope is that soon enough we can enjoy
some performance higher than vnc could ever deliver!