>> Yes, I believe there're people capable of producing income-generating stuff >> in the interim. I can't predict how the project would evolve, but am >> optimistic.
Ask Ben about how much that affects a project . . . . >> If you flexibly enter contracts with partners on an individual basis, that's >> what I call opaque. Then your definition of transparent and opaque are seriously non-standard. Transparency has to do with the release of monitoring information, nothing else. >> And that's like a conventional company, with interviews etc that slow down >> and obfuscate recruitment. Huh? You really have it in for conventional companies, don't you? And by the way, being willing to negotiate separate agreements on an individual basis is *NOT* like the traditional hiring policies of a conventional company (except for high-level executives). The only thing that most companies negotiate is salary . . . . >> In that case, the code should be jointly owned by all the contributors you >> mentioned above. Attribution may be done via a combination of self- and >> peer- rating and managerial board arbitration. Nope. I don't buy it. That is *not* a feasible scheme. >> If someone has signed an agreement to pay the consortium for things they >> take from it, then there is no need to put on these red-tape. Anyway, this >> is trivial. Try proving that someone has stolen code from your company. Unless they pretty much immediately turn around and commercialize exactly what they stole, you'll never succeed. >> I think if people trust the attribution mechanism, this is well possible. OK. So give me an attribution mechanism that I can trust. All your previous efforts are so far short than I'm not even laughing. >> How do you judge "intent-to-contribute"? Seems arbitrary to me. Intent to contribute is simply the person saying "I would like to add the following functionality to the following module" OR "I would like to see if I could improve the accuracy of the following module" OR "I would like to see if I could solve the current incorrect behavior of the following module" OR . . . . (you get the idea). I would call that generous and flexible rather than arbitrary -- which normally means capriciously saying no. >> I think the real issue here is your fear of "harvest and run". That's why I >> propose the "outside projects are indebted to the original project" clause >> to turn "harvest and run" into "harvest, profit, and be grateful to the >> originators". Give the man a cigar! But my point is that your clause is nowhere near sufficient to protect you from the real world. It's touching but tremendously naive. >> That's not "unfettered access". That's protected by the "outside projects >> should pay originators" clause. You have far too much faith in legal documentation. It's touching but tremendously naive. >> You haven't explained what these "honor" contracts mean. Because I thought that the meaning was rather obvious. They are simply contracts that focus more upon the working details rather than the teeth. The process will catch potential defectors before they harvest too much and the honor contract ensures that they can't claim ignorance. Your process relies upon catching the harvesting horse after it's out of the barn. >> I think people don't join projects for various reasons, depending on the >> details of the contracts, not simply because there's legal language. You thoughts are all very nice but I know of numerous solid examples where people felt that they couldn't contribute to a project that they would have enjoyed helping because of the fear of legal entanglements and excessive litigation. >> I do have some dislike for authorities, but I'm trying to suppress that >> tendency in order to work with others. I don't agree that people can "very >> easily" harvest and run from my project, since they're legally bound to pay >> for what they take, and that payment, in the form of shares, won't kill >> them. All in all, it's a pretty good deal they're entering. Legally bound often doesn't mean much. Honest people honor it but thieves always exist. Sometime I should tell the full story of how: 1.. Two partners approached CitiCorp with an idea. 2.. CitiCorp liked the idea but correctly identified one partner as a thief 3.. The two partners split up with a whole host of legal documents intending to make it possible for the honest partner to pursue the business with CitiCorp in return for a lot of money to the thief (and the legal documents made it *quite* clear that this is what was going on). 4.. CitiCorp accepted the idea and began paying for development. 5.. After two years of detailed design and development, as delivery drew near, the thief sprang back in and attempted to use the legal system to extort more money out of the partner and Citicorp 6.. At one point, development was even stopped because an ignorant judge insisting on escrowing payments from CitiCorp that were being used to pay programmers 7.. The system was finally delivered but CitiCorp couldn't use it because of the ongoing legal issues and wouldn't pay for it because it couldn't use it 8.. Eventually, CitiCorp paid the thief over a million dollars because their legal costs were clearly going to go higher 9.. The only bright side was that CitiCorp managed to ensure that their payment went directly to a poor widow whose house the thief had bought but had never paid a dime for after the initial deposit (I kid you not). Actually, that pretty much is the whole story . . . . and I lost a substantial amount of money as one of the key programmers -- both from releasing the thief from a decent size debt so that I could take a stake in the new company and from not receiving a portion of the substantial balloon payment that CitiCorp would have paid if they could have used the system. All in all, it was an awesome deal that the thief entered into -- he was paid *a lot* of money just to go away -- but he found it even more profitable to come back and destroy a lot of value for a lot of people just to get some money that never did him any good anyways. Note: Yes, I do have a serious mistrust of the legal system. >> Whether something is relevant to AGI, depends on the group's decision. I >> guess we'd appreciate contributions that indirectly help AGI. Sounds like an afterthought. You need to work that through. >> Transparency: everyone should be able to join the group with minimal >> hassles; the contracts are not individually variable. Everyone can join the group. Enhanced access is based upon contributions. Contracts may be variable for people in special situations but the details of variant contracts are released. That is transparent. >> "Willingness to contribute" is not well-defined or measurable. It doesn't need to be. >> More importantly I don't see the merits of a security hierarchy as long as >> the legal contract reasonably prevents "harvest and dump". I understand and disagree entirely. >> I'm trying to make all aspects of operation very transparent. You haven't >> clearly explained how yours will operate and seem to introduce arbitrary >> measures. Things that you call "complexity" that I think reduce efficiency >> and openness. You clearly don't understand the meaning of transparency. You seem to think that making exceptions for exceptional circumstances is arbitrary and that everything needs to be uniform and identical to be fair (and you call your system for a meritocracy non-arbitrary?). I think that you're entirely wrong about efficiency -- give me some supporting reasons or arguments. But you are correct about openness -- I think that unfettered openness is a recipe for thievery. >> If members sign the contract that "outside projects should pay originators", >> do you think they're likely to "harvest and dump"? As you put it, smart >> people figure out how to make money legally... ;) Yes, yes I do. And how do you prevent dumb people from signing your contract and stealing you blind? ----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?member_id=231415&user_secret=e9e40a7e
