Hello, Xen is under gplv2. After read more explanations about gplv2 on wikipedia. I saw that : if you add something on project under gplv2, you must deliver the new code of your new implemantation. My question is : Why citrix don''t give the code of xen server ? _________________________________________________________________ Téléphonez gratuitement à tous vos proches avec Windows Live Messenger ! Téléchargez-le maintenant ! http://www.windowslive.fr/messenger/1.asp _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> Xen is under gplv2. After read more explanations about gplv2 on wikipedia. > > I saw that : if you add something on project under gplv2, you must deliver > the new code of your new implemantation.Disclaimer: I am not a lawyer ;-) That is true however it is only the case when the new work is a "derived work" of the old code. So if I add some extra features for the Linux Kernel, which is GPL-licensed, I have to distribute my new enhanced kernel under the terms of the GPL. Typically the patch you produced will be GPL-licensed too since it will be inspired heavily by the existing code and therefore considered a "derived work". On the other hand, userspace apps running *on* the Linux kernel are not *part* of it and are not typically considered derived works. For this reason you can write closed-source apps for the Linux kernel (for instance). Many companies do this and it''s generally agreed to be OK. Creating closed-source *drivers* is more of a grey area.> My question is : > > Why citrix don''t give the code of xen server ?The main answer is the same as above: XenServer adds management functionality on top of Xen and some extra drivers but if they are not a *derived work* of Xen itself then they don''t have to be under the GPL. They''re just apps that happen to be running on top of Xen. A second possible answer, although I think it is less of an issue in this case, is that if Citrix/XenSource own the copyright on some GPL-licensed code in Xen they would be within their rights to *also* sell closed-source software derived from this. I''m not aware of them doing this but it is allowed to do this with GPL software *if and only if* you are the copyright holder. Hope that helps, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Williamson wrote:> Disclaimer: I am not a lawyer ;-) > > That is true however it is only the case when the new work is a "derived work" > of the old code. So if I add some extra features for the Linux Kernel, which > is GPL-licensed, I have to distribute my new enhanced kernel under the terms > of the GPL. Typically the patch you produced will be GPL-licensed too since > it will be inspired heavily by the existing code and therefore considered a > "derived work". > > On the other hand, userspace apps running *on* the Linux kernel are not *part* > of it and are not typically considered derived works. For this reason you can > write closed-source apps for the Linux kernel (for instance). Many companies > do this and it''s generally agreed to be OK. Creating closed-source *drivers* > is more of a grey area. > > The main answer is the same as above: XenServer adds management functionality > on top of Xen and some extra drivers but if they are not a *derived work* of > Xen itself then they don''t have to be under the GPL. They''re just apps that > happen to be running on top of Xen. > > A second possible answer, although I think it is less of an issue in this > case, is that if Citrix/XenSource own the copyright on some GPL-licensed code > in Xen they would be within their rights to *also* sell closed-source software > derived from this. I''m not aware of them doing this but it is allowed to do > this with GPL software *if and only if* you are the copyright holder.Im not an lawyer either but I think this has nothing to do with "derived work" and/or kernel vs. userspace but rather with the second answer: the fact that Citrix owns Xen and releases it (kind of) using different licenses, for a more detailed explanation see: http://en.wikipedia.org/wiki/Dual-licensing Best regards, Christian _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Christian Tramnitz <chris.ace@gmx.net> writes:> Mark Williamson wrote: >> Disclaimer: I am not a lawyer ;-) >> >> That is true however it is only the case when the new work is a >> "derived work" of the old code. So if I add some extra features for >> the Linux Kernel, which is GPL-licensed, I have to distribute my new >> enhanced kernel under the terms of the GPL. Typically the patch you >> produced will be GPL-licensed too since it will be inspired heavily >> by the existing code and therefore considered a "derived work". >> >> On the other hand, userspace apps running *on* the Linux kernel are >> not *part* of it and are not typically considered derived works. >> For this reason you can write closed-source apps for the Linux >> kernel (for instance). Many companies do this and it''s generally >> agreed to be OK. Creating closed-source *drivers* is more of a grey >> area. >> >> The main answer is the same as above: XenServer adds management >> functionality on top of Xen and some extra drivers but if they are >> not a *derived work* of Xen itself then they don''t have to be under >> the GPL. They''re just apps that happen to be running on top of Xen. >> >> A second possible answer, although I think it is less of an issue in >> this case, is that if Citrix/XenSource own the copyright on some >> GPL-licensed code in Xen they would be within their rights to *also* >> sell closed-source software derived from this. I''m not aware of >> them doing this but it is allowed to do this with GPL software *if >> and only if* you are the copyright holder. > > Im not an lawyer either but I think this has nothing to do with > "derived work" and/or kernel vs. userspace but rather with the second > answer: the fact that Citrix owns Xen and releases it (kind of) using > different licenses, for a more detailed explanation see: > http://en.wikipedia.org/wiki/Dual-licensingThat only works if they own the copyright to ALL the source. As soon as they add a single GPLed patch to their closed source they must make it all GPL as the author of the patch holds the copyright of that change.> Best regards, > ChristianMfG Goswin _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Mar 8, 2009 at 7:12 PM, Patrick Archibal <bugpb60@hotmail.com> wrote:> Hello, > > Xen is under gplv2. After read more explanations about gplv2 on wikipedia. > I saw that : if you add something on project under gplv2, you must deliver > the new code of your new implemantation. > > My question is : > Why citrix don''t give the code of xen server ?AFAIK (IANAL): Xen is GPL, Xen Server is a package that includes Xen and some other non-free software. -- Javier _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Monday 09 March 2009 10:02:34 Christian Tramnitz wrote:> Im not an lawyer either but I think this has nothing to do with "derived > work" and/or kernel vs. userspace but rather with the second answer: the > fact that Citrix owns Xen and releases it (kind of) using different > licenses, for a more detailed explanation see: > http://en.wikipedia.org/wiki/Dual-licensingWell, I mentioned that possibility for completeness but the reason that I think "derived works" vs "mere aggregation" is important is that Citrix actually do not own the copyrights on all of Xen. Some of the code in the hypervisor comes from Linux, for instance. Some of it comes from external contributors. They did actually rewrite much of the userspace tools (Xend, XenStored) themselves for their closed-source product - therefore they hold all the copyrights on those tools - but the hypervisor they use is still GPL and can''t easily / practically be closed off, even if they wanted to do that. Cheers, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Williamson wrote:> They did actually rewrite much of the userspace tools (Xend, XenStored) > themselves for their closed-source productAny idea what differences between the open source and the closed source version ? Why did they do such thing ? Thomas _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Thomas Goirand wrote:> Mark Williamson wrote: > >> They did actually rewrite much of the userspace tools (Xend, XenStored) >> themselves for their closed-source product >> > > Any idea what differences between the open source and the closed source > version ? Why did they do such thing ? > >So they can make a living. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Miles Fidelman wrote:> Thomas Goirand wrote: >> Mark Williamson wrote: >> >>> They did actually rewrite much of the userspace tools (Xend, >>> XenStored) themselves for their closed-source product >>> >> >> Any idea what differences between the open source and the closed source >> version ? Why did they do such thing ? >> >> > So they can make a living. >That I could guess, but I was wondering about the technical reasons ... Thomas _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
In first, thanks for all these informations. It seems you have a good knowledge of xen. Maybe, you know big mile stone of the project ?? I have just two date : :o( 2003 --> creation of xen 2005-- > xen support virtualisation like intel vt et amd pacifica I dont have more informations. I''m looking for six or seven milestone for my study ? Do you have more informations about that ? Thanks Best regards Patrick> From: mark.williamson@cl.cam.ac.uk > To: xen-users@lists.xensource.com > Subject: Re: [Xen-users] Re: Xen and gnu gpl > Date: Mon, 9 Mar 2009 18:15:11 +0000 > CC: chris.ace@gmx.net > > On Monday 09 March 2009 10:02:34 Christian Tramnitz wrote: > > Im not an lawyer either but I think this has nothing to do with "derived > > work" and/or kernel vs. userspace but rather with the second answer: the > > fact that Citrix owns Xen and releases it (kind of) using different > > licenses, for a more detailed explanation see: > > http://en.wikipedia.org/wiki/Dual-licensing > > Well, I mentioned that possibility for completeness but the reason that I > think "derived works" vs "mere aggregation" is important is that Citrix > actually do not own the copyrights on all of Xen. Some of the code in the > hypervisor comes from Linux, for instance. Some of it comes from external > contributors. > > They did actually rewrite much of the userspace tools (Xend, XenStored) > themselves for their closed-source product - therefore they hold all the > copyrights on those tools - but the hypervisor they use is still GPL and can''t > easily / practically be closed off, even if they wanted to do that. > > Cheers, > Mark > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_________________________________________________________________ Téléphonez gratuitement à tous vos proches avec Windows Live Messenger ! Téléchargez-le maintenant ! http://www.windowslive.fr/messenger/1.asp _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Try digging for the previous release announcements and see what the features in each release were. You might want to search the Slashdot archives (really!) since many of the early releases popped up as articles there. You might also want to look at the tags in the hg repository for Xen, which generally correspond to releases and release candidates. For example: Xen 2.0 introduced the "new IO" model (drivers in guests, not Xen itself), Xen 3.0 introduced SMP. If you dig through the release announcements you should be able to find out where Live Migration was added, where x86_64 support was added, etc etc. Cheers, Mark On Tuesday 10 March 2009 00:58:36 Patrick Archibal wrote:> In first, thanks for all these informations. > > > > It seems you have a good knowledge of xen. Maybe, you know big mile stone > of the project ?? > > I have just two date : :o( > > 2003 --> creation of xen > > 2005-- > xen support virtualisation like intel vt et amd pacifica > > I dont have more informations. I''m looking for six or seven milestone for > my study ? > > Do you have more informations about that ? > > > > Thanks > > Best regards > > Patrick > > > From: mark.williamson@cl.cam.ac.uk > > To: xen-users@lists.xensource.com > > Subject: Re: [Xen-users] Re: Xen and gnu gpl > > Date: Mon, 9 Mar 2009 18:15:11 +0000 > > CC: chris.ace@gmx.net > > > > On Monday 09 March 2009 10:02:34 Christian Tramnitz wrote: > > > Im not an lawyer either but I think this has nothing to do with > > > "derived work" and/or kernel vs. userspace but rather with the second > > > answer: the fact that Citrix owns Xen and releases it (kind of) using > > > different licenses, for a more detailed explanation see: > > > http://en.wikipedia.org/wiki/Dual-licensing > > > > Well, I mentioned that possibility for completeness but the reason that I > > think "derived works" vs "mere aggregation" is important is that Citrix > > actually do not own the copyrights on all of Xen. Some of the code in the > > hypervisor comes from Linux, for instance. Some of it comes from external > > contributors. > > > > They did actually rewrite much of the userspace tools (Xend, XenStored) > > themselves for their closed-source product - therefore they hold all the > > copyrights on those tools - but the hypervisor they use is still GPL and > > can''t easily / practically be closed off, even if they wanted to do that. > > > > Cheers, > > Mark > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > _________________________________________________________________ > Téléphonez gratuitement à tous vos proches avec Windows Live Messenger ! > Téléchargez-le maintenant ! http://www.windowslive.fr/messenger/1.asp_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Monday 09 March 2009 23:23:49 Thomas Goirand wrote:> Miles Fidelman wrote: > > Thomas Goirand wrote: > >> Mark Williamson wrote: > >>> They did actually rewrite much of the userspace tools (Xend, > >>> XenStored) themselves for their closed-source product > >> > >> Any idea what differences between the open source and the closed source > >> version ? Why did they do such thing ? > > > > So they can make a living.Well, that''s part of it but Thomas is right in suspecting it''s a bit more complicated. Much of the user-facing "value add" from buying XenServer is that it has better management tools, either for a single server or for managing a cluster. They *could* get that by building on top of the APIs provided by the existing Xend.> That I could guess, but I was wondering about the technical reasons ...I''m not too clear on the specifics, sadly :-( For Xend: One simple reason could be that the codebase of Xend is not understood by many people - it is a fairly complex piece of code in its own right and was largely written by external contributors. Another possible reason is that they may have wanted to add features that could not easily be added to the existing Xend architecture. Finally, they may have just wanted to create a "better" Xend for purchasers of their software, as well as providing a better management interface, etc. For XenStored: Again, they may have wanted to add some kind of feature they didn''t want in the OSS Xenstored (I think their Xenstored was required for the proprietary PV drivers for Windows to work, for instance). Their Xenstored apparently also handles certain operations better, which makes it harder for malicious domains to abuse. For both: The rewrite of Xenstored and - I assume - Xend was in Ocaml, rather than Python. Ocaml brings certain benefits (static typing, compilation, etc) over Python (which has benefits of its own). Presumably they felt that Ocaml was a better language for this task. Perhaps the programmers also had higher familiarity with it and were therefore able to produce better code more quickly. Anyhow, that''s my speculation on the matter. I don''t know the details but I doubt that there is *that* much difference between the two. Much of XenServer *could* probably have been built on top of the existing Xend / Xenstored and these are all the technical / business reasons I can think of that they didn''t do that. They''ve Open Sourced the Ocaml Xenstored recently, so perhaps it will make its way into OSS Xen. Cheers, Mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users