Gianugo Rabellino wrote:
Andy,to be honest, I find very hard to have a discussion with someone who doesn't want to listen and keeps ignoring my contributions. Pardon me
If I did, I did not do it intentionally
for taking it personally when you not only ignore what I'm saying, but keep on posting FUD about us trying to inject patent trojan horses, and now implying that we are bribing a white knight (God, I wish I had so much influence on highly respectable organizations like OSSWatch). I know you have all the right intentions to ensure that POI is and remains OSS, but I would appreciate at least a collaborative attitude in analyzing the issues in front of us. The moment you stop snickering comments and random FUD bits is the moment we can resume a conversation.
FUD = an argument that you do not accept.
Why can't Microsoft just submit a CLA-C for the work they wish to contribute via source sense and we be done with this?I'll give it a last shot then call it a day unless you decide for a change to discuss my arguments, stop sidetracking the real questions and discuss the potential issues in the right places. First of all, let me state loud and clear that I'm approaching this issue from a Sourcesense (and ASF) angle, with no intention of representing Microsoft at all: this means I won't be answering your question on Microsoft filing a C-CLA, but I will show you why that's not the problem. For all I know, the document could be signed by SB and in the fax machine by now. Or not. The core issue is that, really, it doesn't matter. Bear with me while I try (again) to tell you why is that, and let me draw a simple line in the sand, first.
..fine but we may not end up agreeing in which case my -1 will stand. You have to have enough evidence.
As all things legal with software, we are faced with two potential issues here: one is copyright (that is "who wrote that?"), and the other is patents (as in "is the copyright holder authorized to write that code?"). Let's address the two separately, please.From a copyright perspective let's assume, for the sake of discussion, that I *am* right when I'm saying that a large chunk of the actual POI contribution is (c) Sourcesense, with possibly some bits (c) of other POI committers, and that's it from a copyright perspective. Let's also hypothetically assume Microsoft itself didn't produce any kind of copyrighted contribution, either directly (via Microsoft employees) or indirectly (via WFH agreements and the like): if you assume that's the
Unless you have a contract that says it is not WFH, if they are paying for the work then. Regarding this though, if you state that you have covered your basis here contractually and have the (C) rightfully then your word will be good enough for me on that Gianugo. So far you've kind of danced around it "yeah they're paying us but it isn't WFH" is an illogical statement unless you have a paper in hand that specifically yields the (C) to you (http://en.wikipedia.org/wiki/Work_for_hire). If you actually say you have that then your word will be good enough for me.
case, do you agree that a CLA-C from MS wouldn't change a single thing? Actually, wouldn't be actually something inherently false, since in that case MS wouldn't be providing any copyrighted stuff at all? If you're with me so far, the consequence of all this is that a CLA-C from a non-copyright holder is, at a very least, redundant. Before you ask, yes, even section 3 (Grant of Patent License) of a CLA-C would be redundant, as that's not a blanket patent license, but it's tied to contributions-related patents. That is, no actual contributions, no patent license grant.
This assumes that the above is true (also read regarding the wikipedia article US copyright and Bern convention issues). When doing WFH regarding POI in the past, I've always included an explicit note of the (C) in the contract for just this reason.
You are of course entitled to your opinion when you say that the specific Sourcesense/Microsoft agreement has to mean that Microsoft is the actual copyright holder. I'm afraid, however, that yours is and will remain an opinion, and I hope you will agree with me when I say that there are a number of ways to ensure that parties can collaborate with no direct influences on copyright. Now, the ASF is funded on trusting the official declarations of contributors: the moment we contribute stuff under the Sourcesense C-CLA (not to mention people working outside their work remit, being covered by the I-CLA), you have to trust that we are entitled to contribute that code, implicitly stating that we have all the necessary rights to do so.
This argument is a false dilemma http://en.wikipedia.org/wiki/False_dilemma. Meaning that there is also a chance you didn't do your homework and get the necessary (C) and Patent grants. In which case I'm free to -1 and ask you to do so :-)
I don't see any practical way to challenge that without undermining the very foundation of the ASF and of Open Source contributions in general, as this would actually mean that everyone should be required to file not only a CLA-C, but also any accompanying paperwork that actually provides evidence that he's actually telling the truth, which is unpractical at a very least, and stupid at best (but hey, feel free to set an example and send all your past contracts which resulted into POI contributions so that we can actually scrutinize if you were entitled to contribute that code and not working under a WFH scenario). I don't see any use in discussing this specific angle any further, unless you have evidence that we are actually lying to the ASF and our contributions are actually someone else's copyright.
http://en.wikipedia.org/wiki/False_dilemma. Had anyone -1'd those contributions I'd have provided the legal supporting evidence. No one did. In the past we even explicitly asked people to certify that their contributions were indeed not bound by any exclusionary agreement with Microsoft explicitly (because someone tried to do something very stupid one time).
On to the patent side. Here the risk we might be facing is having a patent holder claim a patent infringement for implementing a patented technology. This risk won't go away with a CLA-C, as stated above, given that Microsoft hasn't been contributing anything from a copyright perspective. Also, OOXML is a bit of a specific beast in that it's not only a Microsoft technology, but also an ECMA and ISO standard, but let's keep that aside for a moment. What we have here is the OSP, that is a covenant that has been already deemed sufficient by the ASF when the POI PMC specifically asked if OSP terms were fine: this is enough to me to clear any issue from a [EMAIL PROTECTED] perspective. If you have any gripes with that, you are more than welcome to challenge and change the ASF position, but this mailing list is not the right place for that: I would suggest you send a note to legal-discuss and take it from there. In the meantime, I believe your patent-related objections, as per your copyright-related opposition don't have any actual ground.
I've given sufficient grounds, supporting references, you simply are choosing not to address them. I'm not going to some other forum. I am on the PMC and am -1ing.
I hope this helps,
Unless explicitly addressed (which it looks like you're starting to try to do), I expect the contributions to be removed from the repository. If they are not addressed, removed, then I'll remove them. Noting that I'll risk my continued access rights and at some point "Apache POI founded kicked out of POI over Source Sense OOXML" gets slashdotted. Neither of us really wants it to come to that. Can you instead EXPLICITLY address the issues rather than threaten to ignore my -1?
Why am I willing to go this far? Because I feel a deep responsibility to the banking, financial, government and other institutions that have supported us over the years and I want to protect POI. Can't you work with me on that?
-Andy -- Buni Meldware Communication Suite http://buni.org Multi-platform and extensible Email, Calendaring (including freebusy), Rich Webmail, Web-calendaring, ease of installation/administration.
smime.p7s
Description: S/MIME Cryptographic Signature
