Jonathon, You are missing the whole legal obstacle.
Given the IP clearances necessary in all of those wonderful legal links that David provided, your rag tag team's collaborative contributions cannot be submitted to Apache OFBiz and be accepted into the project in the form that they're likely to be offered. Any collaborative efforts on the ofbiz-sandbox project on Sourceforge.net do not clear the IP hurdles. As far as the discussion surrounding the anon checkout process, that did not clear the IP hurdles. The manner in which the Developer's conference has been proposed, does not clear the IP hurdles. OFBiz itself did not clear the IP hurdle. David, IP law in America is insufficient to provide documented references so everything regarding it has to do with the concepts that surround it instead of actual legislation or clear case law. Do a google search for Intellectual Property Bankruptcy Case Law and you will see some staggering rulings. A few legal concepts, IANAL See Joint authorship and Ownership http://library.findlaw.com/1999/Jan/1/241478.html Every person who writes code (not under contract) owns the copyright of what they write, this is because each individual is a sole-proprietor. When you collaborate with someone, you own the copyright for the portion you write, and the other person owns the copyright for the portion they write. The problem occurs that the partnership between the two of you owns the copyright for the work as a whole. Now, what's the big deal? The findlaw link only refers to the assets, not the liabilities. Say one of these partners goes to a client and says "So and So and me worked on this part of the code and I guarantee that it works." The source code says plain as day "No guarantees". However, because one of the partners guaranteed it, the partnership has guaranteed it. The members of the partnership are now jointly and SEVERELY liable for the fulfillment of that guarantee. The person spouting out guarantees has overstepped his authority in making the guarantee, but that only makes him liable to his partners as it's not fraudulent. The partnership is still liable to the bad partner's client. Again, both jointly and SEVERELY. How does this likely affect Apache? Likely only distribution will be affected, not financial. If it's found that the code is owned by the partnership and there is some IP problem arising in that partnership, Apache can be served a cease and desist order and will need to pull that contribution out by it's root as well as any derivative of that contribution. No big deal, we can code around contributions. However, Apache then cannot make previous revisions available through SVN either. With jars this isn't a big problem, however the manner in which OFBiz is written with it's components and services, and the largest likely contribution not being in jar format, it is a HUGE problem. If this is simply not a problem that can be solved in Apache, fine, I accept that and we'll just have to live with either keeping our collaborative contributions out of Apache OFBiz source, live with limits of JIRA and the time and expertise (though limited :-) )constraints of the committers or continue to accept the risk of including these contributions in OFBiz source. There are at least five separate groups of community members (including one that you're involved with) vocally trying to collaborate on solutions that are beneficial to the OFBiz community at large that if allowed to their own devices will create great contributions that no one can benefit from without obtaining the source from disparate locations, unless they choose to ignore the possible repercussions. I think this constitutes a need in the community. I am shocked that no one who can post to the legal-discuss list will. The easier to beg forgiveness than to ask for permission has the potential of large repercussions especially when we're talking about software that is attempting to be the backbone of businesses. --- Jonathon -- Improov <[EMAIL PROTECTED]> wrote: > David, > > Just a brief response here. > > Sandbox can be created outside of the OFBiz SVN. Even your personal > branch (assuming you do an > "SVN copy/branch" from the OFBiz SVN trunk, not your read-only > workspace containing the downloaded > OFBiz) is a sandbox. > > > - A sandbox with lots of committers isn't going to work. Thanks > for > > explaining that in your e-mail, I didn't realize this wasn't > > workable till now. > > David's right. If an OFBiz SVN trunk isn't working as well as we'd > all like it (given limited > committers' resources to audit and/or to commit patches), then a > sandbox given a disorganized > ragtag (at least I consider myself ragtag) team of committers won't > work either (too many cooks). > > > Would it work to have a sandbox that is managed by the existing > > committers, or perhaps a few new committers? As a committer, you > > wouldn't need to give nearly the same amount of time and attention > to > > trying to make sure the commitment met best practices, free of > bugs, > > etc. Any developer could share their stuff that they've > implemented for > > their business, or other neat components. And, since the > commitments > > would be in svn on the other side of the "Donate to the Apache > > Foundation legal radio button, it'd be easy for these developers > to > > collaborate and slowly bring unworkable buggy messes into gold. > Finally, > > users could easily find and try the components without mucking > with > > patch files, etc. > > I (and some others) are currently looking to "round off loose ends" > in OFBiz (for easy successful > demonstration to business clients, not IT folks). We're doing it in > our own sandbox. If you'd like > to join us, let me know. > > Our sandbox will contain many patches that won't be in OFBiz SVN. We > (the ragtag team) will be > responsible for crash-testing those patches to death before we submit > them to OFBiz. I believe > this is an excellent way to free up the OFBiz committers. We really > test and audit our patches > first before even posting to OFBiz committers, in the proper formats > (see > http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices) > no less. > > We're trying to take the heat off of the committers, allowing for a > playground without messing up > the official OFBiz trunk for you/me/everybody, and create a > structured way to submit patches to > OFBiz for review. > > Well, at least that's my direction. The ragtag team isn't headed by > me (I'm not paying). > > Jonathon > > Daniel Kunkel wrote: > > Hi > > > > First, please understand I hold you in incredibly high regard, and > > apologize for causing any frustration... You and Andy have created > an > > amazing software tool that I'm basing my business on, and you've > given > > it away. I love that! As you can see, your efforts are now > multiplying > > in to a system that has a life of its own, which will eventually > change > > the face of many businesses throughout the world. > > > > During this process, you've needed to exercise great control in > choosing > > what to allow into the project, and what to reject. Since I often > update > > my production system to the svn head, I'm very glad someone is > there > > watching, and if you think about it, it makes sense that access has > been > > very limited to just the professionals that have devoted themselves > to > > the project. > > > > However, as it grows, there are more and more newbies that want to > help > > in their little way. Many *non-committers* who have wanted to give > back > > to the project have been stifled and frustrated, often because > their > > contributions were not appropriate, but sometimes simply because > the > > committers are too busy to review/test/correct their contributions. > In > > other cases, the resultant solutions are too specific to just their > > business, or as a employee, the business although willing to donate > the > > code back, was not willing to devote the time needed to make the > > consumable by the project at large. > > > > So, what can we do to create a space where non-committers can share > > their bits with the community? Please understand, we are agreed > that > > neither of us would want their contributions running on a system. > > > > - The source forge sandbox isn't really a good fit, because, as > Chris > > has researched, the legal ramifications of donating it back to the > > project outweigh the benefits begotten from the group effort. > > > > - Forcing developers to work alone isn't working very well. > > > > - A sandbox with lots of committers isn't going to work. Thanks for > > explaining that in your e-mail, I didn't realize this wasn't > workable > > till now. > > > > - Jira isn't working. > > > > - The wiki could possibly work, but it doesn't go through the legal > > process with each submission, and I cringe even thinking of trying > to > > work with code in wiki. Eek. > > > > - Even using the wiki, to catalog which jira issues are "in play" > is > > unwieldy. Patch nightmare actually. > > > > David, can you think of way to make a space in this community where > the > > new/non-polished committers can easily share and play together with > > their ideas where they won't hurt the bigger project until the > > components are well proven? > > > > Would it work to have a sandbox that is managed by the existing > > committers, or perhaps a few new committers? As a committer, you > > wouldn't need to give nearly the same amount of time and attention > to > > trying to make sure the commitment met best practices, free of > bugs, > > etc. Any developer could share their stuff that they've implemented > for > > their business, or other neat components. And, since the > commitments > > would be in svn on the other side of the "Donate to the Apache > > Foundation legal radio button, it'd be easy for these developers to > > collaborate and slowly bring unworkable buggy messes into gold. > Finally, > > users could easily find and try the components without mucking with > > patch files, etc. > > > > Thanks > > > > Daniel > > > > On Fri, 2007-01-26 at 00:45 -0700, David E. Jones wrote: > >> Okay, I just wrote a huge thing and deleted it. There might have > been > >> good stuff in there, but I am really frustrated because I've said > it > >> all before and based on the comments from Chris it doesn't seem > like > >> anything it making it out there. > >> > >> If you're not a lawyer, then reference documents and processes > >> already established. > >> > >> I'm not even going to bother going into detail unless people are > >> willing to: > >> > >> 1. describe their understanding of how what they want to do would > be > >> done under current policy > >> 2. describe why that doesn't work for what you want to do > >> 3. describe how the existing processes need to changed in order to > > >> accommodate it > >> > >> A sandbox is a BAD BAD BAD BAD IDEA. Like you mentioned Daniel it > > >> would create a huge mess. I'm afraid one of two things would > happen: > >> > >> 1. nothing > >> 2. a lot > >> > >> In the case of number 1 it's not worth the effort to set it up. In > > >> the case of #2 it would required more effort to administer and > >> monitor than we have resources for in OFBiz. There is no way I'd > even === message truncated ===
