[Soc-coordination] GSoC 2014: mhonarc replacement for lists.debian.org
Nicolas Dandrimont
olasd at debian.org
Wed Mar 5 14:35:29 UTC 2014
* Pali Rohár <pali.rohar at gmail.com> [2014-03-05 14:40:51 +0100]:
> 2014-03-05 14:14 GMT+01:00 Nicolas Dandrimont <olasd at debian.org>:
> > * Pali Rohár <pali.rohar at gmail.com> [2014-03-05 11:24:19 +0100]:
> >
> >> Hello,
> >>
> >> I already wrote that I'm interesting in project for archiving and
> >> formatting emails from mailinglists. I asked confirmed mentor formorer
> >> for this project [1] and he wrote me that he would happy to accept
> >> this application.
> >>
> >> But there is one important thing about it. For my bachelor thesis I
> >> have already started doing something similar/same. So I need to know
> >> if I can to participate with this project [1] for GSoC 2014 and reuse
> >> my bachelor project code or continue working on it for GSoC. In my
> >> opinion according to this Google GSoC FAQ [2] it is allowed. But is it
> >> OK for Debian as mentoring organization? Or are there any other
> >> problems?
> >
> > As an org admin I have no problem with that, provided that the original
> > software is free and published in some way, and that your modifications stay
> > that way. All the more so if the project mentor already ACKed that the software
> > would fit. Software reuse and adaptation is perfectly fine, all the more so in
> > a distribution where doing just that is our "core" line of work.
> >
> > Obviously you'll have to go through the normal student application process and
> > get ranked using the same criteria as other students would be, but you won't be
> > forced to build everything from scratch, if your mentor says it's OK. And if
> > the code is published free software, then any student is free to do the same
> > and build their application upon that same base.
> >
> > (As an aside, having some software written already proves, to some extent, your
> > worth as a GSoC student, and therefore can only help the mentor evaluate your
> > application in a favorable light)
>
> I understood project proposal [1] as not to extend any existing SW
> (like mhonarc), but create new one, because there is no good one. My
> bachelor project is not public yet (because it not working now and
> hard to use), but there is no problem to make it free. So it is needed
> to do some (non-working) code drop now (in the time of student
> application period) of my project under free license and mark it as
> original? Or it is enough to do that after I have something working?
> Note that I do not expect working executable code before end of
> student application period.
>
> [1] - https://wiki.debian.org/SummerOfCode2014/ProjectProposals/ListArchive
We need to evaluate the realism of *your* project application. The proposal is
just that, a proposal. You need to discuss *your* application with the mentor,
and tailor that to the way you both want to do things. Nothing is set in stone,
and even during the program things can be fluid: if the mentor and yourself can
agree on a base project, a set of quantifiable goals, and a timeline to achieve
those goals, then there is no issue about your application per se.
There are a few requirements for a GSoC project:
- Google needs to be allowed to do business with the student (think embargo)
- organization admins need to request and allocate a slot for the project
- the work needs to be completed by the student without depending on something else
- the resulting code must be published under a free software license
To assess whether we will request and allocate a slot for the project, we need
to make sure, as admins, that the set of goals is achievable, that the timeline
is realistic, and that the base you're working on is sound. Obviously, for the
most part, we defer to our mentors as we are not the "clients" of the GSoC
projects, merely facilitators for the relationship between Google, Debian, your
mentor and you.
I don't see how your mentor can assess that the work can be done if he doesn't
see the code you will be working on. And that code needs to be free software at
the end of GSoC. I wouldn't want to have to throw your GSoC's worth of work in
a fire because of a licensing issue. Having a released, free software codebase
beforehand swiftly solves both of the problems, and I would strongly prefer it
that way. And that's how we usually do things in Debian, out in the open, under
the scrutiny of our peers (and yes, we can spot whether a student blatantly
reuses someone else's proposal without making it its own). So, really, the
question is simple:
Do you own the copyright to that lump of code you wrote during your bachelor
thesis, and can you license it freely? Could you do that now?
[I'll put a disclaimer here: making your code free software doesn't give you
any advantage over other potential applications for that project: applications
and students will be ranked according to their own merit. Having experience in
software development gives you an edge, but not a definitive one, as the
quality of student applications improves each and every year]
Cheers,
--
Nicolas Dandrimont
BOFH excuse #297:
Too many interrupts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20140305/19a7ff7a/attachment.sig>
More information about the Soc-coordination
mailing list