Hacker News Reader

Comment by mindcrime | Hacker News Reader

There's effectively a one-way merge already. LO can - and do - consume patches contributed to AOO. But, for a variety of reasons, that are mostly historical as far as I can tell, the LO developers have generally been unwilling to contribute code in the other direction.

An outright "merger" of the two projects seems unlikely due to the licensing differences and the associated thinking. Some people prefer permissive licenses like the ALv2, others prefer the GPL/LGPL world. So getting everybody to agree on that is probably a non-starter.

View on HN

That's not true. Seversl of us are quite happy to contribute our LO patches to OO. But they just don't have any manpower to merge them.

Sure, I didn't say all LO developers. But from what I've seen (and to be fair, this recollection is a bit old) a lot of the LO people showed a lot of resistance to having code flow back the other way.

OTOH, maybe things have changed since I formed that impression. At any rate, your willingness to do so is appreciated. As far-fetched as it sounds, I still hold out hope that one day the two projects can have an amicable co-existence and collaborate to a greater extent (than today).

Sure, I didn't say all LO developers. But from what I've seen (and to be fair, this recollection is a bit old) a lot of the LO people showed a lot of resistance to having code flow back the other way

I will share a story.

Awhile ago I was employed by Red Hat and, as we know, Red Hat has a number of developers working on LO. I was talking w/ our CTO at the time and suggested that it would be a Good Thing if Red Hat allowed all our code donated to LO be triple-licensed (MPL/GPL/ALv2) so that AOO could benefit from these contributions. He thought it was a great idea since it showed that Red Hat was all about open source and true universal sharing.

But when we asked the developers they refused to do so. The explanations were either (1) We refuse to contribute to permissive projects or (2) We have been told by TDF that they will not accept any of our contributions so licensed.

So the "resistance" in code flowing to AOO is, in fact, reality. My hope is that we can change that for the benefit of the entire OO eco-system.

The "enemy", lest we forget, is MSO, not any of the OO implementations.

I’ve been contributing to LibreOffice since it early months and have been asked nicely if some of my patches can be used by AOO to which I agreed and they were used. To date no one ever from TDF or LibreOffice ever complained or threatened me over doing that.

>> The "enemy", lest we forget, is MSO, not any of the OO implementations.

If the purpose of the "war" is to increase userbase by stealing users from MSO, then having a single implementation that is broadly supported and has brand recognition is vastly preferable to the current situation with two forks, one of which has the branding, while the other one has the features.

I got intrigued by your claims, so I dug up that old e-mail exchange. And I failed to find anything that would substatiate (2). So you misremember at best; at worst you're outright lying to make TDF the bad guys.

Btw, the claim that Red Hat's CTO (or anyone else at RH) "thought it was a great idea" seems to be a bit exaggerated as well. The words you yourself used at that time were "... saw the logic of it".

> (2) We have been told by TDF that they will not accept any of our contributions so licensed.

This claim is false, and it's a false claim I've seen you make before. If you maintain it is not, please link and quote the email that you consider substantiates it.

That is news to me... I've yet to see any real viable patches returned back to AOO. Very occasionally I will see large chunks of code that need to be extremely re-factored to be consumed by AOO, but that's not backwards contribution.

If, however, there are, or have been, patches that could be consumed by AOO, I'd like to see URLs for those discussions and pull/merge requests. Thx!

As I pointed out in the mailing list, there has been practically no development on OO this year though.

As I pointed out in the mailing list, there has been practically no development on OO this year though.

And? I mean, yeah, it would be nice to have more cool new stuff coming out, but it's not like AOO owes the world anything. It's open source, it's volunteer driven. If people want more new features, more development, etc, then more people need to volunteer. If they don't, well... the world gets what it gets from the folks who are contributing.

> it's not like AOO owes the world anything.

It arguably owes its users not distributing security holes to them. Sitting on the vulnerability since October 2015, only revealing it in July because the reporter said they were going public with it ... there is no way that is responsible stewardship of end user software.

In fact, I just checked - I went to www.openoffice.org, went all the way through to download, and it still gives me the vulnerable version and doesn't give me information that there's a vulnerability or a fix.

You're an AOO dev. What do you see as your responsibility in this regard?

The OP explains what the ASF expects in this regard.

    "In the case of Apache OpenOffice, needing to disclose security
    vulnerabilities for which there is no mitigation in an update has
    become a serious issue. In responses to concerns raised in June, the
    PMC is currently tasked by the ASF Board to account for this
    inability and to provide a remedy. An indicator of the seriousness
    of the Board's concern is the PMC been requested to report to the
    Board every month, starting in August, rather than quarterly, the
    normal case. One option for remedy that must be considered is
    retirement of the project. The request is for the PMC's
    consideration among other possible options."

In the strictest sense, as a volunteer who gets paid nothing for participating in this, my responsibility is "nothing". In a sense related to my personal sense of commitment, I think it goes without saying that we want to ship secure software, all the time, every time and to fix security holes as soon they appear. But what we want and what we have the resources to do aren't always the same thing.

In terms of the various security issues that have cropped up, I'd say that if we reach a point where we simply cannot ship a fix AND it's a serious vulnerability, then we have an obligation to inform users of the situation so they can make up their own minds what level of risk they are comfortable with.

Note that informing the user is not sufficient for an Apache project. If the project cannot respond effectively to security reports, it must retire.

This is part of the ongoing discussion on the dev lists. The OP quotes Dennis, the OpenOffice Chair to this effect.

Reply on news.ycombinator.com