Re: The FreeRDP fork

Peter Åstrand <[email protected]>
Newsgroups gmane.network.rdesktop.devel
Message-ID <[email protected]>
>> Well, Cendio has not agreed to this license change. If you think that all of
>> our code has been replaced, why are Cendio developers still listed in the
>> AUTHORS file? Assuming that the GIT version is the correct one...
>
> The plan from the beginning was to remove Cendio code.  Remember Peter
> it is because of you that FreeRDP exists in the first place.

No, I don't remember that. In fact, I haven't seen any motivation why the 
FreeRDP project was created in the first place. I've looked at 
http://www.freerdp.com but I don't see any background information there 
either. IMHO, if you were unhappy about any aspect of the rdesktop 
project, I think it would have been much better to discuss this *before* 
creating a fork. I also fail to understand why it was an explicit goal to 
"remove Cendio code".


> We have made some amazing progress in FreeRDP.  We have some of the 
> hardest working, talented developers I've ever worked with.

Sad that you/they do not want to contribute to rdesktop then. With two 
projects, I think we are duplicating efforts. In general, unless the goal 
of two projects are fundamentally different, I think you can achieve more 
by working together.

The license question could be such an issue, but again, I haven't seen the 
motivation. Things would have been much clearer if FreeRDP had announced 
itself with an Open Letter or something like that, like we did with 
TigerVNC: http://article.gmane.org/gmane.network.tight-vnc.general/8610/


> I'm the longest running contributors to open source RDP software via 
> rdesktop, xrdp, and FreeRDP.  From my experience, this is a necessary 
> change.  The GPL does not work well in the situations an RDP client 
> needs to run.  The rdesktop plugins design is one example, running 
> FreeRDP as a web browser plugin is another.  The OpenSSL exception is 
> another. The list goes on and on.
>
> I want to develop the best RDP client possible and the GPL does not 
> allow that.

I don't agree. Wrt plugins, there's really no reason why these cannot run 
out of process. Running native code such as RDP clients as browser plugins 
is IMHO generally a bad idea, but I don't think that GPL would prevent 
this. Compare with VLC, which is also GPL. We can also deal with OpenSSL. 
I mean, this is not a new problem. There are tons of GPL code out there 
that needs encryption. This can be handled. Saying that "we cannot use GPL 
because we need encryption" seems strange to me.


I think that GPL is the best license for a rdesktop-like project. rdesktop 
unfortunately has a history where many people and organizations are using 
the code, but very few give something back. Many terminal vendors, for 
example IGEL, and shipping a heavily modifed version of rdesktop. They are 
not contributing these changes back to the rdesktop project, but due to 
the GPL license, end users *are* able to retrieve the source and 
modifications. With an Apache-style license, the development done by such 
vendors will never be released and thus will never reach the upstream / 
Open Source project. I fail to see how helps you to "develop the best RDP 
client possible". Instead, you will end up with not just one but multiple 
more or less incompatible forks, one from every vendor.


Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d

_______________________________________________
rdesktop-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rdesktop-devel
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.