On Mon, 28 May 2012, Rayson Ho wrote:
...
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.
...
Fair enough, but please note that I'm not advocating any particular
license here, I'm just trying to understand the issues around copyright
assignment of contributions. I'm still in the dark about why OGS wants it.
...
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.
Is this why OGS is asking for copyright assignment - to replace the execd
and shepherd? What's the problem you're trying to solve here?
It still sounds like a large job. I can imagine that the 30,000 lines of
dedicated execd code can be replaced with something rather smaller these
days, but there's all the libraries like the CULL and GDI that it depends
on. Rather you than me: I hope it's worth it.
...
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.
Is this the gridscheduler-developers sourceforge list?
I tried looking for a button to push or address to email to join it, but
didn't have any luck. The web frontend doesn't show anything posted to it
recently - is archiving turned off?
If you were willing to let me on, I'd very much appreciate it.
...
(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.
Is this the reason why people don't seem to like SISSL?
IANALL, but I'm not sure they had much choice: it was a modification to
existing SISSL-licensed files.
...
[actually, that conversation with them went stale... must pick it up
again].
What's that code BTW??
Rayson
It's in an email from me to [email protected], dated 9/12/2011 with
subject "[PATCH] Fix PE task array job failure due to missing job script
on execd".
I'm happy for any of the gridengine forks to take it (hint).
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
