|
|
Subscribe / Log in / New account

Re: Stauts of these files

Re: Stauts of these files

Posted Jan 18, 2013 1:01 UTC (Fri) by simosx (guest, #24338)
In reply to: Stauts of these files by rcweir
Parent article: A discordant symphony

I think it is pretty simple. Until code is released, someone dipping into Subversion for code [of Symphony] is on their own. They project [Apache] does not vouch for its quality, performance, security or license.

I suppose you mean here that The project does not vouch for the Symphony code license with respect to third-party code.

If that is the case, then you should simply state it. That any code owned by IBM (All rights reserved to IBM) is distributed under the Apache License with the exception of any files that mention other copyright holders.


to post comments

Re: Stauts of these files

Posted Jan 18, 2013 1:21 UTC (Fri) by rcweir (guest, #48888) [Link] (9 responses)

Actually, I meant exactly what I wrote.

It is not our process to encourage downstream consumers to dip into pre-release code, source or binary. Although we work transparently, the pre-release code is intended for project participants to work with, not for the general public.

In fact we actively take steps to discourage general use pre-release. For example, we don't send out notes to general user lists advertising developer snapshot builds. We only advertise that on internal project lists.

Remember, we take pride in the full review we give to our releases. This is part of the Apache reputation, the Apache brand. I don't think we should dumb that down and publish to the public "Apache-lite" code that is only-partially reviewed, for the benefit consumers who are impatient to wait for the real release, but also unwilling to help us get there.

Regards,

-Rob

Re: Stauts of these files

Posted Jan 18, 2013 1:52 UTC (Fri) by simosx (guest, #24338) [Link] (8 responses)

What you wrote earlier is vague.
Do you not vouch the Apache license even for the Symphony code that is clearly owned by IBM? You said earlier that you do not vouch for the license and leave it open for interpretation.
You gave the impression that LibreOffice takes lots of stuff from Apache Office. This would be a good opportunity for LibreOffice to do the work and not depend on Apache Office.

Re: Stauts of these files

Posted Jan 18, 2013 2:09 UTC (Fri) by rcweir (guest, #48888) [Link] (7 responses)

What I vouch for is not the relevant. I'm not a voucher.

The point is that Apache projects do not encourage downstream consumers to dip into SVN to grab unreviewed code. All sorts of issues can occur in such code.

For example, I've seen code, submitted under SGA, that contained a proprietary Microsoft header file. It was an honest mistake, and fixed as soon as found, but it very good that this did not spread to other products, due to the obvious consequences that can come from it. (Anyone remember SCO?).

The fact that other projects may have less concern for basic hygiene and are more willing to accept risk does not mean that we should encourage this. IMHO it would be irresponsible to encourage others to download and consume unreviewed code.

In any case, I truly do appreciate your concern, and your recognition that LibreOffice would greatly benefit from code from Apache OpenOffice. But it would sure be nice to hear it from them, with a real proposal for cooperation, then have it be argued by proxies.

Re: Stauts of these files

Posted Jan 18, 2013 18:16 UTC (Fri) by simosx (guest, #24338) [Link] (6 responses)

The fact that other projects may have less concern for basic hygiene and are more willing to accept risk does not mean that we should encourage this. IMHO it would be irresponsible to encourage others to download and consume unreviewed code.

In any case, I truly do appreciate your concern, and your recognition that LibreOffice would greatly benefit from code from Apache OpenOffice. But it would sure be nice to hear it from them, with a real proposal for cooperation, then(sic) have it be argued by proxies.

Ouch, Rob, ouch!

Having read this, it feels quite toxic to approach the Apache Foundation.

What is your definition of real proposal for cooperation? You should blog about this. I highly doubt that you would accept any proposal unless you write it yourself.

Does the Apache Foundation have a process to deal with the polarization from the OpenOffice.org case? If not, I suggest to get someone be the contact point for the Apache Foundation in trying to resolve the issue.

Re: Stauts of these files

Posted Jan 18, 2013 18:36 UTC (Fri) by rcweir (guest, #48888) [Link] (4 responses)

If you want to ask a question of the Apache OpenOffice project you can send it to: dev@openoffice.apache.org

That's where we do business, openly and transparently on publicly-archived mailing lists. We don't resolve issues behind pay-walls.

As for cooperation, we (IBM) have reached out to the companies who do the vast majority of the LibreOffice coding, and offered to help them with the Symphony code, especially in the areas of accessibility and Microsoft interoperability. They said they were not interested.

So I suggest we try to leave hypothetically behind, and if anyone who actually has the ability and desire to do something with this code has a genuine question, then they can take to the Apache mailing list. But hypothetical from bystanders are not really interesting to me.

Re: Stauts of these files

Posted Jan 19, 2013 16:34 UTC (Sat) by nix (subscriber, #2304) [Link]

We don't resolve issues behind pay-walls.
What paywall? Anybody can contribute to this thread, paying subscriber or no, and articles in the weekly edition can be sent to anyone via the prominently displayed subscriber link at the bottom of the article. No articles stay behind a paywall for longer than a week in any case.

If this is a paywall, it's a totally ineffective one.

Re: Stauts of these files

Posted Jan 19, 2013 22:46 UTC (Sat) by simosx (guest, #24338) [Link] (2 responses)

Rob, you are toxic. In every reply you add a snide remark or two.

LWN a paywal? In four days the article will be public and people will see what kind of bully you are.

You say that you are only interested in coders?
If you are trying to build a community, then you are doing it wrong.

You end up being a liability to the Apache Foundation.

Re: Stauts of these files

Posted Jan 19, 2013 23:36 UTC (Sat) by rcweir (guest, #48888) [Link] (1 responses)

Well, yes. When discussing code I am mainly interested in talking to coders who actually want to make use of the code, not bystanders who are just looking for debating practice. Seems kind of obvious. Or at least I would have thought.

As for building a community, I think we're doing fine. 50 new QA volunteers in the last two weeks, based on a promotion that I took the lead on. Coders will be next.

In any case, don't feel that you absolutely need to respond unless you have a comment on the article. I'm happy to answer questions on those topics. But I'm not going to waste time engaging in meta-arguments, i.e., arguments about the argument, by those who have nothing useful to say about the main points of the article.

-Rob

Re: Stauts of these files

Posted Jan 20, 2013 21:59 UTC (Sun) by simosx (guest, #24338) [Link]

Rob, you are a bully. You are playing the bully game and at the same time, by association, you make Apache Office look like a dirty project.

Your bullying trick now is to divert the discussion and make it personal.

What do you think the Apache Office community will feel if they see your comments? Do you object if I take the issue to the Apache Foundation?

Re: Stauts of these files

Posted Jan 19, 2013 16:32 UTC (Sat) by nix (subscriber, #2304) [Link]

I hasten to add that most Apache projects are not remotely this bad. Rob is very definitely an outlier. The SpamAssassin people are charming and helpful, for instance, as are the HTTP server guys. I'm afraid that 'charming and helpful' is not at all a decsription I could apply to Rob in this thread.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds