IMO, this is certainly not a non-issue, it's the issue I've been trying to get a definitive answer to for the last few weeks and everyone wants to simply ignore it and act like we're a bunch of hippies. It's fun being a hippie until some large corporation comes by and carts your commune off their land. Then you're not a hippie, you're just homeless.
I've changed my stance slightly contemplating Jonathon's questions. I think this explanation is more correct, consistent and also easier to follow. But again IANAL. Comments inline. --- Jonathon -- Improov <[EMAIL PROTECTED]> wrote: > David (Jones), Tim, Chris, > > Sorry, I know this thread isn't about legal issues with OFBiz. But > Chris often has a way of > spotting some oft-missed angle, and I'm concerned about a particular > angle now. Though I'm also > often lost in his long complex explanations, please forgive me if I > feel scared/concerned about > some issues mentioned. Need just a bit of advice here. > > I'm looking at some excertps from Chris' "findlaw" URL. Please note > those words between **. > > "When the copyright... *provided that the use does not destroy the > value of the > work* ..." > > I understand that the ASF license is like the MIT license, so the > open sourced codes can be packed > into a commercial package (much like the LGPL?). > AFAIK, correct. > How do I publish codes (assuming I do have a semi-public SVN shared > between a few friends) without > damaging that license? > The license is fine. The owner of a copyright can write as many nonexclusive licenses as he/she/it/they wish. However, I don't believe a joint owner can grant the Apache 2 license to anyone without greatly diminishes the financial value of the work itself. This is further compounded by granting the Apache 2 license to the ASF as one of their main functions is to distribute that work freely to anyone who points a browser or other client software in their direction. > "According to the Copyright Act... *a work prepared by two or more > authors with the intention that their contributions be merged into > inseparable or interdependent parts of a unitary whole*." > > What if I explicitly mention that I INTEND to merge my private > sandbox into OFBiz as a collection > of "interdependent parts of a unitary whole". Will that mean the > OFBiz core team and my own ragtag > team become a partnership? No. This I believe is the trick of the contributor license agreement. Your "patch" is a complete work and you are granting license to anyone who has access to JIRA the Apache 2 license. The committers of OFBiz as individuals accept your complete work and make a contribution to the ASF project under the terms of the CLA. The only interaction with the ASF is between the committer and the ASF, not you. This, I believe protects the ASF to only being subject to cease and desist orders in the event of infringement. This structure should also protect the committer as it is their impression the work is being licensed under Apache 2. This structure, however does not protect the contributor (you) of a joint work. The problem as I see it with your semi-private SVN is that your "patch" is not exclusively yours, it's the joint owners. You as a joint owner can license it anyway you want as long as you share the royalties and don't diminish its value. Distributing it under Apache 2, diminishes its value. So, only an individual entity (individual or corporation) can distribute it under Apache 2. The only way as I see around this is to have a specific agreement amongst all joint owners allowing for its distribution under Apache 2. This agreement creates a legally binding partnership and now you're subject to the representations and liabilities that the other joint owners make regarding the joint work in their licensing to other people. Not a pretty pickle. Does this make my understanding of the scenario clear? On a side note (from the findlaw article), a copyright holder cannot waive their termination right in advance. This makes for an interesting scenario 35 years from now. Perhaps the ASF should reconsider the copyright assignment that the FSF has adopted. Although then you have to rethink the trick of the CLA. This could get scary as the copyright is owned by the estate and thus can be distributed to heirs/debtors upon death. > > I'm really lost. Anyway, if it's a non-issue, just let me know? > Thanks. > > Don't need to brief me about open source and GPL/LGPL, I already know > all that. > > Jonathon > > Chris Howe wrote: > > --- Tim Ruppert <[EMAIL PROTECTED]> wrote: > > <snip> > >> I reviewed patches for Anil and Ashish - that is correct. There's > no > >> > >> fancy partnership here - nor is there any any legal concern, but > >> that's truly not what this discussion should be about. > >> > > <snip> > > > > You're absolutely correct that there isn't a _fancy partnership > > present. The partnership created is the same mundane one that is > > created every day. I must disagree with you, it is of GREAT legal > > concern. Since you obviously did not follow the link of background > > information I provided David in my reply, I'll take a quote from a > > section of http://library.findlaw.com/1999/Jan/1/241478.html > > > > 'According to the Copyright Act, the authors of a joint work > jointly > > own the copyright in the work they create. A joint work is defined > in > > Section 101 of the Copyright Act as "a work prepared by two or more > > authors with the intention that their contributions be merged into > > inseparable or interdependent parts of a unitary whole."' > > > > "When the copyright in a work is jointly owned, each joint owner > can > > use or license the work in the United States without the consent of > the > > other owner, provided that the use does not destroy the value of > the > > work and the parties do not have an agreement requiring the consent > of > > each owner for use or licensing. A joint owner who licenses a work > must > > share any royalties he or she receives with the other owners." > > > > If this doesn't sound like what you did with Anil and Ashish, read > it > > again. If it doesn't sound dangerous, read it again and then > _again > > and then consider whether releasing something as "open source" > destroys > > the value of the work. It does, there is no doubt about it. > Since a > > joint owner who license a work must share any royalties he or she > > receives with the other owners, guess what, the owners must share > the > > liability that a joint owner creates regarding that work. > > > > A _fancy partnership would spell out who and how the joint work can > be > > distributed and be agreed to in writing and the extent to which the > > other joint owners can accept liability on behalf of the class of > joint > > owners. The _fancy partnership would protect us all. > > > >> 1. There already is an SVN for managing the OFBiz > > Yes, and IMO the only things that should go into that project are > > tested contributions that can hopefully be the basis of what > someone > > can run their business off of. Half tested, half implemented ideas > > should be in a sandbox SVN so that the community can get them ready > for > > the parent project. > > > >> 2. You will have to manage mods to the trunk in patches regardless > - > >> > >> unless you'd want to go with some vendor branch scheme, which in > my > >> experience is WAY more trouble than it's worth. > > > > The sandbox isn't suggesting a branch or a branch structure, so > there's > > no trouble. Since the two options are neutral in comparrison in > how > > they get re assimilated into OFBiz, we should only concern > ourselves in > > the easiest manner to incorporate the contribution into the teams > > (using someone else's word). That is SVN by a long shot over JIRA > > patches. > > > >> 3. Why can't you play on your own box like the rest of us - and > only > >> > >> submit (or commit) when you have something to say that you want > >> reviewed or to be shared? > > > > That is the whole point of the discussion, no one is playing on > their > > own box. You, Anil and Ashish aren't, the ofbiz-sandbox project on > > sourceforge would not be and the proposed platform of the > developers > > conference will not be. > > > > Currently, the only _safe manner for a non committer to collaborate > on > > his own box is to > > > > download from Apache Ofbiz, > > upload to JIRA, > > have your collaborator download from JIRA, > > make sure the patch works because you two may be using different > > revisions > > make changes > > then upload to JIRA, > > you download from JIRA, > > make sure the patch works because you two may be using different > > revisions > > and so on... > > > > Committers only have the additional benefit of using > labs.apache.org or > > trunk instead of patches. This limits their possible collaborators > to > > other committers. > > > >> Chris, know that I feel you here, but why don't we just try this > and > >> > >> see how it goes? If you end up having a huge following for these > > >> types of things, then I'll be the first person backing you and > doing > >> > >> the leg work to put more infrastructure in place will be most > >> beneficial. > > > > I've been trying it in the manner suggested by David in my spare > time > > for the past two years. Other's aren't so patient and have simply > > moved on. And yes, it does work somewhat, but it could work a lot > > better and without us having to cross our fingers, hoping no one > tries > > to sabotage the project. > > > > Depending on your definition of "huge" it already exists. (this > also > > answers someone's question earlier on who the groups were) > > 1. Those wanting to develop google checkout > > has code, but has been lost because Phani apparently has since > > stopped monitoring the mailing lists. > > 2. Those wanting more modularization between the components > > has code, not sure where to contribute it because of the legal > > scenario > > 3. The upcoming developer's "hackathon" > > will undoubtedly have code and will be contributed in a manner > that > > is subject to all the questions I have been asking. > > 4. Those wanting to refactor the create order process > > has code, been contributed to JIRA, though because it's a patch > will > > only attract those that are _really committed to the topic and not > > those that have a passing interest. > > 5. Jonathon's rag tag team > > Jonathon claims it has lots of code > === message truncated ===
