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.
Posted Jan 18, 2013 1:21 UTC (Fri)
by rcweir (guest, #48888)
[Link] (9 responses)
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
Posted Jan 18, 2013 1:52 UTC (Fri)
by simosx (guest, #24338)
[Link] (8 responses)
Posted Jan 18, 2013 2:09 UTC (Fri)
by rcweir (guest, #48888)
[Link] (7 responses)
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.
Posted Jan 18, 2013 18:16 UTC (Fri)
by simosx (guest, #24338)
[Link] (6 responses)
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.
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.
Posted Jan 18, 2013 18:36 UTC (Fri)
by rcweir (guest, #48888)
[Link] (4 responses)
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.
Posted Jan 19, 2013 16:34 UTC (Sat)
by nix (subscriber, #2304)
[Link]
If this is a paywall, it's a totally ineffective one.
Posted Jan 19, 2013 22:46 UTC (Sat)
by simosx (guest, #24338)
[Link] (2 responses)
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?
You end up being a liability to the Apache Foundation.
Posted Jan 19, 2013 23:36 UTC (Sat)
by rcweir (guest, #48888)
[Link] (1 responses)
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
Posted Jan 20, 2013 21:59 UTC (Sun)
by simosx (guest, #24338)
[Link]
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?
Posted Jan 19, 2013 16:32 UTC (Sat)
by nix (subscriber, #2304)
[Link]
Re: Stauts of these files
What you wrote earlier is vague.Re: Stauts of these files
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
Re: Stauts of these files
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.
Ouch, Rob, ouch!
Re: Stauts of these files
Re: Stauts of these files
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.
Re: Stauts of these files
If you are trying to build a community, then you are doing it wrong.
Re: Stauts of these files
Re: Stauts of these files
Re: Stauts of these files