On Fri, May 25, 2012 at 4:12 AM, Mark Dixon <[email protected]> wrote: > On Thu, 24 May 2012, Rayson Ho wrote: >> Not trying to launch any GPLv2 vs GPLv3 arguments here, but one of the >> reasons why Linux can't be switched to a newer version of the license >> is that Linus does not own the copyright. > > Or it might have been because he didn't use the optional GPLv2 phrase "any > later version"...
Frankly, I am not sure what license we should use for our own code - but for us we won't use GPL with linking exemption. We want ISVs to be able to keep their own modifications private. > 2) The author keeping hold of their own copyright, but releasing code under > a copyleft license prevents the project from being taken closed-source in > the future, which may or may not be a worthwhile aim. May be it is just me, but to me copyleft ~= GPL, and it can drive companies away. We already have a few ISVs shipping OGS/GE with their products, or using OGS/GE on the cloud to offer higher level services, and if no one can make $ out of OGS/GE, then there would be no commercial interest in it. Note: We at Scalable Logic & the Open Grid Scheduler Project are keeping OGS/GE open source - we need an ecosystem that includes ISVs, system integraters, etc ... and the current OGS/GE ecosystem is already much bigger than the core OGS/GE project. We don't want to drive ISVs away. > As SISSL covers over 500,000 lines of the code base, the project is never > going to be able to do (1) anyway. The whole Grid Engine is large - but the execution side is much smaller. For example, the cgroups integration itself touches a lot of the execution side already. In the end, the main functionalities of the execd are job execution, and host status reporting... having something like cgroups in the Linux kernel can replace lots of PDC code, and with work, host status reporting can be easily replaced as well. And with a few months of work, we can replace the execution side (I usually call it the "execd + shepherd pair"). So if needed, we can release the execution side that speaks the Grid Engine protocol but not have any SISSL restrictions. > Although (2) may not be a consideration now, I observe that companies get > bought and people at the top change. That's why in an email I sent 6 months ago (when I was announcing GE 2011.11), I said that if we were to close source the Open Grid Scheduler project, we will pass it to one of the other guys here: http://sourceforge.net/project/memberlist.php?group_id=343697 The Open Grid Scheduler is not a 2-man show. In fact besides Gridcore, us at Scalable Logic, and Ron Chen (as an independent contractor), we have more people wanting to join the Open Grid Scheduler project, and if we were to add everyone, you would probably see 20 developers or more listed in that SourceForge table. These days, before we add anyone to the list, we ask them to send code to the dev lists first, or at least tell us what their plans are - but we really want to see their code first. Grid Engine is very complex, and if one is not careful and mindful about how things tie together, then he can essentially ship regressions in every single release. > > What license are you using for new code, BTW? In the GE 2011.11 release, we licensed the CUDA GPU load sensor under BSD. I think we will use more BSD, esp. we need the attribution to let others know that who is doing all of the hard work! > I sent a bugfix in Univa's direction, and they just asked me to sign > something saying that I was the copyright holder and was licensing it to > them under the SISSL. Nothing was mentioned about copyright assignment. (Not an FUD) Not sure if they can accept SISSL code... the reason is that SISSL has specific requirements related to product naming, and even if Univa has agreements with Sun, it is the license that imposes that naming requirement. So if you license code under SISSL, then you can ask whoever using your code to change the name of the product. May be the Univa contributor's agreement also have something related to naming?? If not, Univa should add it. > [actually, that conversation with them went stale... must pick it up again]. What's that code BTW?? Rayson > > > Mark > -- > ----------------------------------------------------------------- > Mark Dixon Email : [email protected] > HPC/Grid Systems Support Tel (int): 35429 > Information Systems Services Tel (ext): +44(0)113 343 5429 > University of Leeds, LS2 9JT, UK > ----------------------------------------------------------------- _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
