It seems to me that the skill sets involved with changing licenses vs. fixing bugs, reducing memory footprint, refactoring code, adding features or otherwise improving the product don't necessarily overlap at all. Perhaps there is enough volunteer manpower to do both without impacting the latter efforts very much.
Posted May 29, 2012 3:32 UTC (Tue) by eru (subscriber, #2753)
[Link]
But weren't there supposed to be many changes all over the LibreOffice source to clean up, remove dead code, translate German comments, etc...? These would have to be somehow patched or redone for the Apache OpenOffice versions of the source files, and this is something that needs programming skills, not just legal. Especially for those Apache OO versions of source files that have their own set of changes, compared to the common starting point.
I fear this idea will set LO development back by years. Just don't do it!
Relicensing and rebasing LibreOffice
Posted May 29, 2012 4:11 UTC (Tue) by dlang (✭ supporter ✭, #313)
[Link]
the first 80% of the work can be a mechanical comparison:
Is the file released by AOO the same as the file that was originally part of OO.O that LO forked from.
if so, "rebase" is complete
if not, further investigation needed (and noteing the size of the diff is a good indication of how much work would be needed for that file)
I agree this could be a huge problem that does nobody any good, but the reality is that the current "dual licensed" status of LO sounds like it really doesn't mean anything from the way this article is making it sound. If there are people who do care about this, let them at least take a look and see how big the problem is to make the codebase dual-license clean.
otherwise, they may as well drop the second license.
Relicensing and rebasing LibreOffice
Posted May 29, 2012 6:46 UTC (Tue) by Jonno (subscriber, #49613)
[Link]
>But weren't there supposed to be many changes all over the LibreOffice
>source to clean up, remove dead code, translate German comments, etc...?
>These would have to be somehow patched or redone for the Apache OpenOffice
>versions of the source files, and this is something that needs programming
>skills, not just legal.
Actually, it may be as simple as "git rebase aoo-3.4" (if you first make sure aoo-3.4 is a git branch that derives from the last common commit).
Of course, there will probably be a few conflicts where both forks have modified the same section of a file, but those should be solvable with only a few days of coding work.
The problem is more what to do about the features removed from AOO with no direct replacement. I would say re-add them as LGPL only for now, and reimplement them later (or rather, steal the AOO reimplementation when they get around to it).
In that scenario LO development will not be set back at all, and less than a man-month of new development will be "wasted", but it may still take a while before a MPL-licensed LO becomes a reality.
Relicensing and rebasing LibreOffice
Posted Jun 1, 2012 0:20 UTC (Fri) by daniel (subscriber, #3181)
[Link]
The word for what you describe is "rebase", which is what the article is about.
And for the record, I'm all for it. I don't personally have an issue with LGPLv3, but MPL is not a problem for me either and if it helps the project advance faster then fine.