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!
