Imagine if the project agreed to publish (release) the Symphony codebase. That would require months of up front work, but would also be an ongoing obligation. We would need to provide patches and do CVE reporting on discovered security flaws. We would need to track bugs. We would need to respond to user and developer queries. We would need to maintain the code and periodically come out with new releases.
We were certainly willing to do this, if the project wanted to make Symphony be the new base for the OpenOffice project. But after examining the code and lengthy discussions, the community decided against that path and decided on the "slow merge" approach, to take enhancements from Symphony and merge them into OpenOffice. That is fine. I can see the merit in that decision. It is less disruptive to users. It keeps us on the code base that more volunteers are familiar with, etc.
But once that decision was made, it no longer makes sense to release the Symphony code base, and take on those support obligations. To do so would be to have responsibilities to maintain and support two different code bases, Symphony and OpenOffice. Double the work. Who would want to do that? Remember, the point of the Symphony contribution was to end the Symphony fork and concentrate resources on a single project, not simply to maintain the fork to another venue.
Posted Jan 18, 2013 14:01 UTC (Fri) by mjw (subscriber, #16740)
[Link]
IBM not having resources to finalize the donation of the code base and clear up any legal uncertainties by cleaning up the file headers is a pity. But then you shouldn't be surprised people are scratching their head whether IBM really donated the code or not. The current status is that people (both from Apache and in the wider Free Software community) don't feel sure about the legal status of these files.
But you seem to misunderstand what people are asking for from IBM. Nobody is asking for a full blown ASF blessed Symphony release.
The current status of the symphony donation is unclear because the file headers don't match the intended license IBM says they wanted to grant to the ASF and the general public. As you say yourself IBM might have made mistakes in their SGA list or the code dump. And ASF policy is that only the contributor of the files can update the license headers. Without that having happened neither other Apache hackers nor the general public can really legally (re)use this contribution. By cleaning up the file headers and double checking their legal status you as IBM would not just help the general public, but also your fellow Apache hackers to work on integrating and completing the "slow merge" sooner.
Priority of cleaning up unclear legal status
Posted Jan 18, 2013 14:31 UTC (Fri) by rcweir (subscriber, #48888)
[Link]
Anyone who thinks the file headers are an issue, and that merely changing them does anything to the license, has a poor understanding.
Take a look at the README. The file headers tell you which files are IBM contributions, versus pre-existing OpenOffice files. And read some other, more perceptive comments on this same topic.
In any case, you seem to misunderstand what Apache projects do. We don't just take code, slap a new license header on things, hold our nose and toss it over the wall for public consumption. That is not how we operate. We're not the money launderers of the open source world. We do thorough reviews or we don't release at all. There is no Apache-lite release. I sense that you wish this were not the case, but it is.
And note that there is absolutely no issue for project members to touch the code. They already have. Indeed, with the Oracle SGA it took 6 months to clean up all the headers, and all along we were all working on the code base. So that is non-issue, more FUD.
Regards,
-Rob
Priority of cleaning up unclear legal status
Posted Jan 18, 2013 15:11 UTC (Fri) by mjw (subscriber, #16740)
[Link]
I get the impression you deliberately misunderstand the issue.
The issue is precisely the indirect nature of the license grant. If IBM would clean up the header files that does give legal clarity (as opposed to anybody else changing those legal statements on the files).
People don't question the value of what Apache projects do. That is indeed much more than the single act of IBM clearing up the legal status of the files by cleaning up the headers.
Various Apache project members have stated on the mailinglist they feel not cleaning up the headers is a problem and they don't want to touch any of the files till IBM does that.
Priority of cleaning up unclear legal status
Posted Jan 18, 2013 15:32 UTC (Fri) by rcweir (subscriber, #48888)
[Link]
But we are cleaning up those files and getting them into proper form, as we merge them into OpenOffice 4.0. So we're doing exactly what we need to do to get this code into a release. Maybe not as fast as you would like, but complaining doesn't make it happen any faster.
You seem to be upset that we're not also maintaining a second fork of Symphony for the benefit of LibreOffice. Sorry, but no one has volunteered to do that. We're working on one codebase.
-Rob
Priority of cleaning up unclear legal status
Posted Jan 19, 2013 16:26 UTC (Sat) by nix (subscriber, #2304)
[Link]
You seem to be upset that we're not also maintaining a second fork of Symphony for the benefit of LibreOffice. Sorry, but no one has volunteered to do that. We're working on one codebase.
You keep on saying this over and over, but nobody else in the thread has suggested it, and several people have explicitly said that this is not what they want. Does license clarity necessarily require a fork?! If so, Apache's procedures are even more hidebound than I thought they were.
Priority of cleaning up unclear legal status
Posted Jan 18, 2013 21:07 UTC (Fri) by raven667 (subscriber, #5198)
[Link]
> ongoing obligation. We would need to provide patches and do CVE reporting on discovered security flaws. We would need to track bugs. We would need to respond to user and developer queries. We would need to maintain the code and periodically come out with new releases.
I'm guessing that there is probably legitimate disagreement on that point, there are many instances of code dumps where a dead project is released without any obligation for ongoing maintenance. The quicker that is done the quicker that others can pick over the corpse for juicy tidbits.
Priority of cleaning up unclear legal status
Posted Jan 18, 2013 21:22 UTC (Fri) by rcweir (subscriber, #48888)
[Link]
Well, I know there were fantasies expressed in some quarters, that Apache would just take the OpenOffice.org code from Oracle, slap an Apache license on it, and hand it over, along with trademarks, website, etc., to LibreOffice. Those fantasies have gone unfulfilled.
It would probably be very unsatisfying to develop new fantasies that Apache will do this for the Symphony contribution. The plan of record, as decided by the community, is to merge enhancements from Symphony into OpenOffice and release this code as part of Apache OpenOffice 4.0.
Remember, Symphony is not an entirely different code base. It is a fork of OpenOffice.org. We're just rejoining the codebases and ending the fork.
If LibreOffice is truly interested in having "juicy tidbits" from it, then it is in their best interest for us to merge the code into Apache OpenOffice, where they can cherry pick from it, just like their ongoing harvesting of features from OpenOffice 3.4.1. It will be much easier for them to have one code base to sync from, then deal with two.
Congratulations! [was: priority of cleaning up unclear legal status]
Posted Jan 18, 2013 21:33 UTC (Fri) by jubal (subscriber, #67202)
[Link]
I have to admit, you're an incredible PR asset to both the Libre Office and The Document Foundation, Mr. Weir.
Congratulations! [was: priority of cleaning up unclear legal status]
Posted Jan 18, 2013 21:42 UTC (Fri) by rcweir (subscriber, #48888)
[Link]