Menu
▾
▴
[rdesktop-devel] [ rdesktop-Patches-1472969 ] Patch to add API for Virtual Channels
|
From: SourceForge.net <no...@so...> - 2006-05-05 21:48:31
|
Patches item #1472969, was opened at 2006-04-19 13:17 Message generated for change (Comment added) made by incarnis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381349&aid=1472969&group_id=24366 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Simon Guerrero (incarnis) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to add API for Virtual Channels Initial Comment: This patch makes the virtual channel capability in rdesktop visible to third parties, so that applications which extend RDP using the virtual channels can "plug in" to rdesktop by supplying a shared object. A new variant of the "-r" option has been implemented, namely: -r soname.so:opt1:opt2:opt3...optn where soname.so is the name (fully qualified if need be) of the third party shared object. opt1 to optn are optional arguments which will be passed to the shared object if needed. The API is implemented as follows: * All third party shared object must implement two named functions, rdesktop_init and rdesktop_cleanup. * A new function called "init_external_vchannel" has been added to channels.c. Whenever a shared object is specified in the parameters, a handle is opened using dlopen and this handle is added to an array for use later. The rdesktop_init function is located and called, passing in the addresses of the virtual channel functions in rdesktop (channel_register, channel_init, channel_send) and any arguments which were passed in on the command line. The third party app can then use these functions to send and receive data on virtual channels, just like sound, cut and paste etc. The rdesktop_cleanup address is then located and stored. * At the end of the RDP session, rdesktop calls the rdesktop_cleanup function for each third party shared object. ---------------------------------------------------------------------- >Comment By: Simon Guerrero (incarnis) Date: 2006-05-05 21:48 Message: Logged In: YES user_id=1368449 I figured the exception clause would be OK, since copyright notices appear (to specific individuals) at the top of each piece of source code! I agree absolutely and without reserve that proliferation of non-free VC apps is a _bad_ thing. But I think that support for existing non-free VC apps to encourage the proliferation of Linux-based thin clients to be a good thing. If we take it as given that ISV's won't want to make their VC app implementations public, is there any way out of this? ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2006-05-05 20:44 Message: Logged In: YES user_id=335423 Re "exception clause": That is indeed possible, if each and every person whose lines of code reside in rdesktop would agree. When we checked in code supplied to us by contributors, we never asked them to assign copyright to any single body. Re "part and parcel", indeed - Virtual Channels and extensibility are an integral part of the RDP architecture. However, mstsc's licensing model is not, so it's not obvious that we should leverage it just as we leverage mstsc's technical features. I'm not convinced that distinct virtual channel implementations are a case of "linkage", rather than a case of "program running on a platform", and if so, that it couldn't be made under the terms of the CURRENT license. This might deserve another thought. However, I am convinced that the proliferation of non-free virtual channel implementations is against my personal interest in the long run. ---------------------------------------------------------------------- Comment By: Alon Bar-Lev (alonbl) Date: 2006-05-05 20:29 Message: Logged In: YES user_id=1157530 The whole point of rdesktop is to provide a free open-source RDP client. I as a user think this is an important advantage... Providing some of the functionality in binary form is not something we want to encourage. So if the intention of the plugin patch was to bypass the GPL it is indeed bad idea. When I first commented in favor of the plugin interface is to allow GPLed plugins to work with rdesktop. Using none GPLed plugin designed specific for GPL application is GPL violation. It is exactly as taking the rdesktop code and adding a propreitary code. When someone chooses to violate the license of open-source application he can do that very easily, with or without a plugin interface. An exception of this is a plugin like a PKCS#11 provider which is not application/implementation specific that may be loaded by GPL application (I had a long discussion with FSF regarding this issue). ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2006-05-05 20:20 Message: Logged In: YES user_id=1368449 The ISV we're talking about doesn't have "community demand" - it has a userbase on Windows clients that it wants to supply with Linux-based ones instead. In fact, both ISV's I am specifically aware of have the same requirement. The problem is not with them not wanting to have their client-side work shipped with every distro - I'm sure they love that idea. The problem is that by making the Linux versions of their existing Windows virtual channel extensions open source, they expose critical details of their protocol implementations and "tricks" which loses them their commercial advantage over all platforms. I'm not just guessing at this - this is why the need for this kind of API arose. With regard to the licence - other GPL'd apps have got around this by adding an "..except for plugins" clause to their licence text. But I see how that would grate with some of you guys. I really do think this is *missing* functionality from rdesktop. It's part and parcel of RDP client functionality. ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2006-05-05 20:09 Message: Logged In: YES user_id=335423 If there wasn't enough community demand for a free implementation for this ISV's plugin, why would a non-free implementation create that demand? After all, the demand steems from server installation of the said product (which requires said modification to RDP clients). And it's not like a rdesktop-based plugin is easier to reverse engineer... How about they work *with* us instead, and have their client-side part built-in in every Linux distro around? Regarding leveraging functionality from mstsc, that functionality being "Virtual channel API", cool - but we cannot leverage the licensing terms at the same opportunity; we cannot make rdesktop legally eat non-GPL plugins. As to reading the "language of the license" and figuring out what the GPL authors intended, I think they pretty much saw it coming. The naive approach is to think of the GPL as a protection against "don't make a small improvement and release it as yours, non-free". However, the real scope of the GPL is also about "we strive so all software we use will be free cause it's useful to us and makes our lives more comfortable -- we have a vested interest in that; chose our side of the fence and benefit from our assets". ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2006-05-05 19:53 Message: Logged In: YES user_id=1368449 I've had a long, close look at the GPL (including the FAQs), specifically with regard to plugins, but the way I see it is this: Basically, this change isn't the "classic" plug-ins case (modifying rdesktop to work with a specific non-free app by means of dynamic linking). This is allowing rdesktop to take on the functionality of the very technology it was reverse-engineered from ( another thorny legal issue ;-] ). RDP on windows includes a virtual channel API - it's part of RDP. But like I say, this is IMHO. I know this is frequently argued elsewhere. With regard to the market for this, I have two real names of real ISVs who are desperate for this - one of whom is a seriously big player, with a contract to supply for a 10,000+ user base. I don't think they'd be happy with me posting their name as I'm under an NDA with them for other Linux work, but they are big, and they were all set to just violate GPL on this. Regarding your final point about "bribing us to give up our convenience for the opportunity to use their product" - that's an alternative view. But I figure if companies really start doing that kind of thing with rdesktop, as soon as a useful non-free plugin appears that gets reasonably popular, you can bet someone will create a GPL version of it. I see it only doing good. I didn't intend to get the "everything should be free" community up in arms with this change. I was kind of hoping to implement something that would keep everyone happy... :-/ ---------------------------------------------------------------------- Comment By: Ilya Konstantinov (ikonst) Date: 2006-05-05 19:25 Message: Logged In: YES user_id=335423 Since rdesktop is licensed under the GPL, rather than under the LGPL, it would be illegal to make rdesktop link, even in runtime, with a non-free virtual channel shared library. rdesktop could be relicensed but since there wasn't any copyright assignment process, the authors of every bit of code we have would need to agree to that. (Correct me if I'm wrong on any of the above points.) Do we already have any ISV who'd produce a non-free plugin as soon as this API goes in, or is the market you describe theoretical? Last but not least, I feel that adding non-free code into the process space of rdesktop would be disadvantegous for us, the users and the developers. Instead of seeing this as "we'll benefit once we'll have non-free feature X", one can see it as "they're bribing us to give up the convenience we're used to, in exchange for the "opportunity" use their product". ---------------------------------------------------------------------- Comment By: Simon Guerrero (incarnis) Date: 2006-05-05 19:13 Message: Logged In: YES user_id=1368449 Hi I submitted this patch after long discussions with Matt Chapman, who suggested this means of exposing the virtual channel functionality. While I understand the suggestion this is a way of getting around the GPL, and everyone who wants to add something to rdesktop ought to make their code open source too, I don't agree. The ability to expose the virtual channel functionality is a fundamental component of Citrix and RDP on Windows, for example, and as a result there are multiple commercial users of Citrix (and RDP) who have produced commercial offerings to add functionality which isn't natively available in those technologies as they stand. While I would agree wholeheartedly that new technology developed purely to extend rdesktop should naturally be GPL'd, I would point out that there are a huge number of commercial Windows products for RDP virtual channels which simply aren't being implemented on Linux because they don't want to go ahead and GPL all their code. And because they don't make it available for Linux, customers go with Windows solutions. Or providers of the technology go ahead and violate the GPL - which is what some of my commercial clients will just go and do if they don't have this. I know because that's what they wanted to do first. I would be glad to discuss technical issues with this solution to make it technically "good", as I really think rdesktop is missing this. But I think rejecting it out of hand because it might encourage people to create non-GPL virtual channel solutions is taking a pretty narrow view, IMHO. Simon ---------------------------------------------------------------------- Comment By: Alon Bar-Lev (alonbl) Date: 2006-05-05 14:44 Message: Logged In: YES user_id=1157530 Well... I thought the kernel is a good known example... But there are many more GPLed projects with plugins... But it is your call. I think that virtual channel is a good example where such interface is required... But I understand your position to merge all into your project. ---------------------------------------------------------------------- Comment By: Pierre Ossman (ossman_) Date: 2006-05-05 14:31 Message: Logged In: YES user_id=1469081 The comparison to kernel modules is flawed. Kernel modules are there to reduce the footprint of the kernel, not to allow out-of-tree drivers. Like this project, the Linux project does not cater to external add-ons (which is why the kernel doesn't have a stable module API). It adds complexity and reduces flexibility, so you need to present a strong case for setting up such a system. ---------------------------------------------------------------------- Comment By: Peter à strand (astrand) Date: 2006-05-05 14:25 Message: Logged In: YES user_id=344921 >Just wanted to note that the same issue exists with kernel >models... And we have modules. But not without problems. For example, the kernel has a "tainted" mechanism, which can show if you have loaded binary-only modules. This patch contains no such support, right? >This is not a good reason why a plugin interface should not >be added. The question should rather be: "Why *should* a plugin interface be added?". Why isn't it acceptible to contribute the plugins you are developing to the rdesktop project? ---------------------------------------------------------------------- Comment By: Alon Bar-Lev (alonbl) Date: 2006-05-05 14:09 Message: Logged In: YES user_id=1157530 Hello, Just wanted to note that the same issue exists with kernel models... And we have modules. And why bother... One can get the source of rdesktop and add whatever he wishes and violate GPL. This is not a good reason why a plugin interface should not be added. Best Regards, Alon Bar-Lev. ---------------------------------------------------------------------- Comment By: Peter à strand (astrand) Date: 2006-05-05 13:53 Message: Logged In: YES user_id=344921 A mechanism like this one has been discussed and also rejected before. Using plugins this way violates the GPL, unless the plugin is also GPL (or compatible). In that case, it's better to submit it for inclusion into the rdesktop project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381349&aid=1472969&group_id=24366 |