You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Chris Howe <cj...@yahoo.com> on 2007/01/27 17:28:35 UTC

Re: Intellectual Property and Sandbox SVN

Tim,
I do agree that there is a protocol in place, but I do not agree that
everyone is following it. Those that seem the most opposed to a
discussion about a sandbox are the ones that keep pumping out the joint
works.  From my limited understanding, this does not appear to be a
legal format to license under open source without exposing the
contributor to partnership liability and the exposing the community
with the task of rooting out the offending code.

I gave you a list of 10 environments that are complex enough and
require 
more than incremental changes. Tabling this discussion will continue to
lose many of the valuable contributions of the community (Like Phani's
work on Google Checkout integration).

In addition, continuing to table this discussion will increase the
likelihood that offending code makes its way into the project.  If
someone makes a stink about it, my understanding is that the remedy is
for the ASF and anyone using Apache OFBiz to cease and desist until the
offending code is removed.  If a business is running off Apache OFBiz,
how much will it cost them to cease and desist?  If they choose not to
C & D, how much will it cost them to defend against a copyright
infringement claim?

If my legal understanding is incorrect, someone please post the
question to legal-discuss and get a real lawyer's opinion.  If there is
no real risk in these joint works being added to the project, address
it as such.

Regards,
Chris

--- Tim Ruppert <ti...@hotwaxmedia.com> wrote:

> Can we all agree on the fact that there is a protocol in place, that 
> 
> if followed, allows everyone the ability to pass code around in a  
> legal format?  This may or may not be the most optimal format for  
> said collaboration, but it does permit us to contribute back to the  
> community in a meaningful way.
> 
> Let's table this sandbox discussion until we find a movement complex 
> 
> enough that it requires something more than incremental changes to be
>  
> made to the trunk before we can agree to include it.  Does that sound
>  
> reasonable?  Once there is an idea to build something that cannot  
> follow this incremental pattern, we can evaluate where we are in  
> terms of resources and determine the best course of action to follow.
> 
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
> 
> o:801.649.6594
> f:801.649.6595
> 
> 
> On Jan 26, 2007, at 9:39 PM, Chris Howe wrote:
> 
> >
> > --- Jonathon -- Improov <jo...@improov.com> wrote:
> >
> >> Chris,
> >>
> >> Ugh. Remind me never to take up law. (Yeah, I know, I'll be cannon
> >> fodder for big boys with lawyers.)
> >>
> >>> This structure, however does not protect the contributor (you) of
> >> a
> >>> joint work.
> >>
> >> Ok. So if I stole someone else's private work and contributed it
> to a
> >> committer who commits this
> >> stolen work to ASF, then I'm liable for the theft, and ASF and the
> >> committer are not liable.
> >>
> >
> > ASF will need to remove the offending code from distribution.
> >
> >> That'll also mean I better make sure that the contributions put
> into
> >> my private sandbox are not
> >> stolen as well. I'll just follow ASF's "license grant" process, so
> I
> >> won't be liable for any
> >> thefts committed by contributors in my sandbox team.
> >>
> >
> > That may not be sufficient.  The ASF does quite a bit more than the
>  
> > CLA
> > and license grant to protect itself.
> >
> >>> 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.
> >>
> >> Alright. So I just need to make sure all those committing to my
> >> ragtag sandbox assigns rights to
> >> ASF to distribute their contributions under Apache 2.
> >>
> >
> > AFAIK
> > The only way you can grant a license to the ASF is if you make your
> > contribution directly to the ASF.  If they make their contribution
> to
> > you, they are granting you a license not Apache.  However, since
> their
> > contribution is intended to be inseparable from your contribution,
> it
> > is now a joint work absent some sort of agreement. This is the
> point
> > where it gets cloudy and no definitive answer has been offered. 
> Still
> > not a pretty pickle and thus my ranting for a sandbox that is  
> > available
> > to the community but owned by ASF.
> >
> >>> Not a pretty pickle.
> >>
> >> No, it's not pretty to software vendors, OFBiz consultants needing
> >> money for a living, etc. But
> >> that's not my concern. I leave that to businessmen.
> >>
> >>> Does this make my understanding of the scenario clear?
> >>
> >> Quite a bit clearer. Thanks.
> >>
> >> Jonathon
> >>
> >> Chris Howe wrote:
> >>> 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 <jo...@improov.com> 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
> 
=== message truncated ===


Re: Intellectual Property and Sandbox SVN

Posted by Jonathon -- Improov <jo...@improov.com>.
Hi all,

 > - A quickly disappearing svn code state that the patch was created against.

Just thought I'd comment quickly on this, since it's technical and it's in my field.

1. Audit differences between my sandbox and OFBiz regularly.

2. Update regularly (after audit).

3a. Complain quickly if I see a commit in OFBiz that breaks my work.

3b. Change my wrong work direction quickly if my direction is gonna make my
     private branch literally break off of OFBiz main branch due to severe
     incompatibilities.

As for the "quickly disappearing svn code state", it's always there for me, never disappeared. I 
always know which revision I forked from, so I know which revision to "diff upwards from" when 
doing a merge-in from official OFBiz branch.

Hope that was clear. I've done it so often that it's become 2nd nature to me. Not even sure if 
it's right. It just works right, feels right, somehow.

I don't know about the other not-so-technical issues.

I'm touching on SVN topic regarding synchronizing sandboxes with official OFBiz branch. Not 
off-topic, I hope.

Jonathon

Daniel Kunkel wrote:
> Hi
> 
> Ok, Chris, now you've confused me.
> 
> I don't have a problem understanding that collaborative efforts co-
> mingled outside of "Apache Assigned" jira issues could have severe
> issues, but it seems to me that collaboration is currently possible via
> the inefficient jira patch process.
> 
> Isn't it completely appropriate for Collaborator A, say Phani to make an
> "Apache Assigned" contribution in jira which Collaborator B improves and
> again assigns it to Apache in an updated patch?
> 
> This still has all of the challenges I've mentioned before, 
> 
> - One collaborator at a time.
> - A quickly disappearing svn code state that the patch was created
> against.
> - inefficient and often chaotic patch handling.
> - likelihood of losing the work to history
> - lost opportunity to create strong community with more active energized
> contributors.
> - duplication of effort as more than one developer independently work on
> features.
> etc.
> 
> If this jira patch process is legal, then I think we're at the point of
> beating a dead horse, but hopefully with the wheels of change in motion.
> 
> Daniel
> 
> On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
>> Tim,
>> I do agree that there is a protocol in place, but I do not agree that
>> everyone is following it. Those that seem the most opposed to a
>> discussion about a sandbox are the ones that keep pumping out the joint
>> works.  From my limited understanding, this does not appear to be a
>> legal format to license under open source without exposing the
>> contributor to partnership liability and the exposing the community
>> with the task of rooting out the offending code.
>>
>> I gave you a list of 10 environments that are complex enough and
>> require 
>> more than incremental changes. Tabling this discussion will continue to
>> lose many of the valuable contributions of the community (Like Phani's
>> work on Google Checkout integration).
>>
>> In addition, continuing to table this discussion will increase the
>> likelihood that offending code makes its way into the project.  If
>> someone makes a stink about it, my understanding is that the remedy is
>> for the ASF and anyone using Apache OFBiz to cease and desist until the
>> offending code is removed.  If a business is running off Apache OFBiz,
>> how much will it cost them to cease and desist?  If they choose not to
>> C & D, how much will it cost them to defend against a copyright
>> infringement claim?
>>
>> If my legal understanding is incorrect, someone please post the
>> question to legal-discuss and get a real lawyer's opinion.  If there is
>> no real risk in these joint works being added to the project, address
>> it as such.
>>
>> Regards,
>> Chris
>>
>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>
>>> Can we all agree on the fact that there is a protocol in place, that 
>>>
>>> if followed, allows everyone the ability to pass code around in a  
>>> legal format?  This may or may not be the most optimal format for  
>>> said collaboration, but it does permit us to contribute back to the  
>>> community in a meaningful way.
>>>
>>> Let's table this sandbox discussion until we find a movement complex 
>>>
>>> enough that it requires something more than incremental changes to be
>>>  
>>> made to the trunk before we can agree to include it.  Does that sound
>>>  
>>> reasonable?  Once there is an idea to build something that cannot  
>>> follow this incremental pattern, we can evaluate where we are in  
>>> terms of resources and determine the best course of action to follow.
>>>
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
>>>


Re: Intellectual Property and Sandbox SVN

Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Jan 27, 2007, at 9:27 PM, Daniel Kunkel wrote:

> I was just trying to use the best example I could think of.
>
> My thinking ran the lines of:
>
> There are people in production using the Si's Financial module in
> production, and I didn't think it would be possible for these  
> people to
> update to the latest svn trunk during the development of the  
> accounting
> module as there would probably be conflicts. If I'm wrong, that's
> great...  but it's likely to cause some real trouble if an update ever
> caused any mistakes.

This is always a bit of a risk for things going into SVN, which is  
why committers need to be careful, and also check on things regularly  
just in case one of their changes messes something up they can fix  
quickly and such.

For this type of thing there are a lot of ways to develop it so that  
it does not conflict with another module that does similar thing. On  
the webapp side the URLs and webapps would be totally separate. On  
the logic side it is all triggered through ECA rules, and anything  
else done for accounting should do the same thing.

With ECA rules we simply leave them commented out (probably the whole  
file inclusion commented out in the ofbiz-component.xml file) until  
it is stable. Whenever those ECAs are enabled those who with to use  
the OSS financials module would simply exclude that ECA file again.

Fortunately for most parts of OFBiz there are facilities to build  
things and mount them on links or ECA rules or whatever that do not  
conflict with existing functionality.

> Finally I think you and I are thinking along the same lines from  
> Jacques
> original idea. The Apache Lab is really great for collaborative  
> projects
> that stand apart from the svn source tree, but it's better to bring  
> the
> developments as close to the svn trunk as possible to ease the source
> conflicts.

Yes, I think we're on the same page here. That sounds like an  
accurate summary of that part of things.

-David


> On Sat, 2007-01-27 at 20:25 -0700, David E. Jones wrote:
>> On Jan 27, 2007, at 3:19 PM, Daniel Kunkel wrote:
>>
>>> I think you may be on to something great here, however I still
>>> wonder if
>>> a branch and merge would work even better.
>>>
>>> For the fun of it, I'll take an example David mentioned a while
>>> back, a
>>> clean room accounting system. This is a large project that is
>>> likely to
>>> take a long time to develop, even in a collaborative environment,  
>>> and
>>> will probably require significant testing before being dumped  
>>> into svn
>>> trunk.
>>>
>>> Because it's likely to take a long time during development, a
>>> branch and
>>> merge might make more sense instead of merging and upgrading in the
>>> way
>>> Jonathan mentioned, since there are likely to be lots of conflicts
>>> that
>>> will need to be resolved over time.
>>
>> Why not build that, as with everything else in OFBiz, directly into
>> the main code base? That's certainly how I would do it...
>>
>> The main reason to use a branch is when you need to break existing
>> functionality and leave it broken for an extended period of time.
>> When adding new functionality even if it is incomplete it can, and
>> most definitely should, go right into the trunk as the work is done.
>>
>> -David
>>
>


Re: Intellectual Property and Sandbox SVN

Posted by Daniel Kunkel <Da...@BioWaves.com>.
I was just trying to use the best example I could think of. 

My thinking ran the lines of: 

There are people in production using the Si's Financial module in
production, and I didn't think it would be possible for these people to
update to the latest svn trunk during the development of the accounting
module as there would probably be conflicts. If I'm wrong, that's
great...  but it's likely to cause some real trouble if an update ever
caused any mistakes. 

Finally I think you and I are thinking along the same lines from Jacques
original idea. The Apache Lab is really great for collaborative projects
that stand apart from the svn source tree, but it's better to bring the
developments as close to the svn trunk as possible to ease the source
conflicts.


On Sat, 2007-01-27 at 20:25 -0700, David E. Jones wrote:
> On Jan 27, 2007, at 3:19 PM, Daniel Kunkel wrote:
> 
> > I think you may be on to something great here, however I still  
> > wonder if
> > a branch and merge would work even better.
> >
> > For the fun of it, I'll take an example David mentioned a while  
> > back, a
> > clean room accounting system. This is a large project that is  
> > likely to
> > take a long time to develop, even in a collaborative environment, and
> > will probably require significant testing before being dumped into svn
> > trunk.
> >
> > Because it's likely to take a long time during development, a  
> > branch and
> > merge might make more sense instead of merging and upgrading in the  
> > way
> > Jonathan mentioned, since there are likely to be lots of conflicts  
> > that
> > will need to be resolved over time.
> 
> Why not build that, as with everything else in OFBiz, directly into  
> the main code base? That's certainly how I would do it...
> 
> The main reason to use a branch is when you need to break existing  
> functionality and leave it broken for an extended period of time.  
> When adding new functionality even if it is incomplete it can, and  
> most definitely should, go right into the trunk as the work is done.
> 
> -David
> 


Re: Intellectual Property and Sandbox SVN

Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
On Jan 27, 2007, at 3:19 PM, Daniel Kunkel wrote:

> I think you may be on to something great here, however I still  
> wonder if
> a branch and merge would work even better.
>
> For the fun of it, I'll take an example David mentioned a while  
> back, a
> clean room accounting system. This is a large project that is  
> likely to
> take a long time to develop, even in a collaborative environment, and
> will probably require significant testing before being dumped into svn
> trunk.
>
> Because it's likely to take a long time during development, a  
> branch and
> merge might make more sense instead of merging and upgrading in the  
> way
> Jonathan mentioned, since there are likely to be lots of conflicts  
> that
> will need to be resolved over time.

Why not build that, as with everything else in OFBiz, directly into  
the main code base? That's certainly how I would do it...

The main reason to use a branch is when you need to break existing  
functionality and leave it broken for an extended period of time.  
When adding new functionality even if it is incomplete it can, and  
most definitely should, go right into the trunk as the work is done.

-David


Re: Intellectual Property and Sandbox SVN

Posted by Daniel Kunkel <Da...@BioWaves.com>.
Hi

I think you may be on to something great here, however I still wonder if
a branch and merge would work even better.

For the fun of it, I'll take an example David mentioned a while back, a
clean room accounting system. This is a large project that is likely to
take a long time to develop, even in a collaborative environment, and
will probably require significant testing before being dumped into svn
trunk.

Because it's likely to take a long time during development, a branch and
merge might make more sense instead of merging and upgrading in the way
Jonathan mentioned, since there are likely to be lots of conflicts that
will need to be resolved over time.

Regardless, having more committers definitely helps build the community,
and for that I am excited.

Daniel

On Sat, 2007-01-27 at 21:38 +0100, Jacques Le Roux wrote:
> > Hi all,
> >
> > There is perhaps a solution to this kind of problems. You maybe know that recently the ASF created a sort of sandbox : the labs
> http://labs.apache.org/
> > http://hammett.castleproject.org/?p=91. Unfortunately this is reserved to Apache commiters.
> >
> > But in a recent mail David explained that soon 6 new OFBiz commiters will be invited. So in a near future we will be 13 commiters
> if every person accept to assume of course.
> >
> > Then, when needed (by vote I guess) we may create an entry in the labs for a specific task if at least a commiter is OK to tackle
> it. By needed I mean if enough people want to work on a subject (aka task) that is really too hard to manage through the standard
> process (Jira patches).
> >
> > What do you think folks ?
> >
> > Jacques
> >
> 
> Of course this is not a solution to the hypothetical  problem that Chris raises. We might use the knowledge available (Legal
> discuss) to clear things, why not ?
> 
> Jacques
> 
-- 
Daniel

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!

Daniel Kunkel           DanielKunkel@BioWaves.com
BioWaves, LLC           http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588    425-895-0050
http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
http://www.Card-Offer.com      http://www.RackWine.com
http://www.JokesBlonde.com     http://www.Brain-Fun.com 
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-


Re: Intellectual Property and Sandbox SVN

Posted by Jacques Le Roux <ja...@les7arts.com>.
> Hi all,
>
> There is perhaps a solution to this kind of problems. You maybe know that recently the ASF created a sort of sandbox : the labs
http://labs.apache.org/
> http://hammett.castleproject.org/?p=91. Unfortunately this is reserved to Apache commiters.
>
> But in a recent mail David explained that soon 6 new OFBiz commiters will be invited. So in a near future we will be 13 commiters
if every person accept to assume of course.
>
> Then, when needed (by vote I guess) we may create an entry in the labs for a specific task if at least a commiter is OK to tackle
it. By needed I mean if enough people want to work on a subject (aka task) that is really too hard to manage through the standard
process (Jira patches).
>
> What do you think folks ?
>
> Jacques
>

Of course this is not a solution to the hypothetical  problem that Chris raises. We might use the knowledge available (Legal
discuss) to clear things, why not ?

Jacques


Re: Intellectual Property and Sandbox SVN

Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi all,

There is perhaps a solution to this kind of problems. You maybe know that recently the ASF created a sort of sandbox : the labs http://labs.apache.org/
http://hammett.castleproject.org/?p=91. Unfortunately this is reserved to Apache commiters. 

But in a recent mail David explained that soon 6 new OFBiz commiters will be invited. So in a near future we will be 13 commiters if every person accept to assume of course.

Then, when needed (by vote I guess) we may create an entry in the labs for a specific task if at least a commiter is OK to tackle it. By needed I mean if enough people want to work on a subject (aka task) that is really too hard to manage through the standard process (Jira patches).

What do you think folks ? 

Jacques

Re: Intellectual Property and Sandbox SVN

Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
Chris, no need to worry about pointing me out specifically because I  
HAVE been following the procedures that I outlined in a previous  
message.  If you'd like to talk to me about my contributions  
specifically - and the workflow that was followed - please feel free  
to call me directly at the office number listed below.

There's really aren't any good reasons to bring any BS I told ya so  
into the discussion (and yes I saw your follow on disclaimer) - we're  
all trying to work towards the same altruist goal here.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Jan 27, 2007, at 10:44 AM, Chris Howe wrote:

> Daniel,
>
> IMO you are exactly right both on JIRA and it becoming a dead horse
> (usually a good sign that has occurred when someone politely asks you
> to change the subject line ;) ).
>
> The JIRA process appears perfectly fine for individual works and works
> owned by corporations.  The problem I was pointing out to Tim  is that
> he is asking others to follow a protocol that he has not been  
> following
> himself.   The protocol Tim has been following created joint works
> instead of individual works (Not meaning to point Tim out  
> specifically,
> MANY contributions has been made in a similar manner).
>
> Whoever has the ability to subscribe to the legal-discuss mailing list
> (committers) could you please post the following questions?
>
> Given the following excerpt from FindLaw
> http://library.findlaw.com/1999/Jan/1/241478.html and your own  
> personal
> legal background,
>
> "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."
>
> Is it possible for a joint owner to license the jointly owned work
> under Apache2 or other compatible license?
>
> It appears on the surface that the Apache2 license destroys the value
> of the joint work itself (albeit increasing the value of the ether).
>
> If it is only possible with the consent of the other joint owners,  
> does
> that agreement constitute a partnership between the joint owners?
>
> If it does constitute a partnership, does this partnership bind each
> joint owner jointly and severely to any and all liabilities another
> joint owner may create in their representations of the joint work?
>
> Thank You!
>
> --- Daniel Kunkel <Da...@BioWaves.com> wrote:
>
>> Hi
>>
>> Ok, Chris, now you've confused me.
>>
>> I don't have a problem understanding that collaborative efforts co-
>> mingled outside of "Apache Assigned" jira issues could have severe
>> issues, but it seems to me that collaboration is currently possible
>> via
>> the inefficient jira patch process.
>>
>> Isn't it completely appropriate for Collaborator A, say Phani to make
>> an
>> "Apache Assigned" contribution in jira which Collaborator B improves
>> and
>> again assigns it to Apache in an updated patch?
>>
>> This still has all of the challenges I've mentioned before,
>>
>> - One collaborator at a time.
>> - A quickly disappearing svn code state that the patch was created
>> against.
>> - inefficient and often chaotic patch handling.
>> - likelihood of losing the work to history
>> - lost opportunity to create strong community with more active
>> energized
>> contributors.
>> - duplication of effort as more than one developer independently work
>> on
>> features.
>> etc.
>>
>> If this jira patch process is legal, then I think we're at the point
>> of
>> beating a dead horse, but hopefully with the wheels of change in
>> motion.
>>
>> Daniel
>>
>> On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
>>> Tim,
>>> I do agree that there is a protocol in place, but I do not agree
>> that
>>> everyone is following it. Those that seem the most opposed to a
>>> discussion about a sandbox are the ones that keep pumping out the
>> joint
>>> works.  From my limited understanding, this does not appear to be a
>>> legal format to license under open source without exposing the
>>> contributor to partnership liability and the exposing the community
>>> with the task of rooting out the offending code.
>>>
>>> I gave you a list of 10 environments that are complex enough and
>>> require
>>> more than incremental changes. Tabling this discussion will
>> continue to
>>> lose many of the valuable contributions of the community (Like
>> Phani's
>>> work on Google Checkout integration).
>>>
>>> In addition, continuing to table this discussion will increase the
>>> likelihood that offending code makes its way into the project.  If
>>> someone makes a stink about it, my understanding is that the remedy
>> is
>>> for the ASF and anyone using Apache OFBiz to cease and desist until
>> the
>>> offending code is removed.  If a business is running off Apache
>> OFBiz,
>>> how much will it cost them to cease and desist?  If they choose not
>> to
>>> C & D, how much will it cost them to defend against a copyright
>>> infringement claim?
>>>
>>> If my legal understanding is incorrect, someone please post the
>>> question to legal-discuss and get a real lawyer's opinion.  If
>> there is
>>> no real risk in these joint works being added to the project,
>> address
>>> it as such.
>>>
>>> Regards,
>>> Chris
>>>
>>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>
>>>> Can we all agree on the fact that there is a protocol in place,
>> that
>>>>
>>>> if followed, allows everyone the ability to pass code around in a
>>
>>>> legal format?  This may or may not be the most optimal format for
>>
>>>> said collaboration, but it does permit us to contribute back to
>> the
>>>> community in a meaningful way.
>>>>
>>>> Let's table this sandbox discussion until we find a movement
>> complex
>>>>
>>>> enough that it requires something more than incremental changes
>> to be
>>>>
>>>> made to the trunk before we can agree to include it.  Does that
>> sound
>>>>
>>>> reasonable?  Once there is an idea to build something that cannot
>>
>>>> follow this incremental pattern, we can evaluate where we are in
>>
>>>> terms of resources and determine the best course of action to
>> follow.
>>>>
>>>> Cheers,
>>>> Tim
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>>
>> -- 
>> Daniel
>>
>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>> Have a GREAT Day!
>>
>> Daniel Kunkel           DanielKunkel@BioWaves.com
>> BioWaves, LLC           http://www.BioWaves.com
>> 14150 NE 20th St. Suite F1
>> Bellevue, WA 98007
>> 800-734-3588    425-895-0050
>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>> http://www.Card-Offer.com      http://www.RackWine.com
>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>
>>
>


Re: Intellectual Property and Sandbox SVN

Posted by Chris Howe <cj...@yahoo.com>.
David,

I didn't say anything about #3 or #4, but I suppose those are correct
as well.  That still doesn't talk to the point of joint works.

Every document that you have linked to only mentions the distinctions
of copyright owned by a single entity.  That individual being a single
person, or that entity being a corporation.

>From the Apache 2.0 license:
"Licensor" shall mean the copyright owner or entity authorized by the
copyright owner that is granting the License.
...
"You" (or "Your") shall mean an individual or Legal Entity exercising
permissions granted by this License.
...
"Contributor" shall mean Licensor and any individual or Legal Entity on
behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.

There is a distinct absence of a reference of a plurality of owners.
There is absolutely NO mention that I have come across or that you have
linked to of works jointly owned.  And yet we don't want to clarify the
issue by posing the question to the legal brains at ASF and we keep
allowing code into the project where the copyright is jointly owned. 
This does not suggest sound policy.

If the lawyers have thought of EVERYTHING then why has there been a
need for a 2nd and 3rd revision?  If there are revisions, it means
something wasn't covered substantially enough to allow us to share our
work in the spirit of open source.  Revisions are good, but to be of
the opinion that the current revision are impenetrable, without
subjecting it to all possible scenarios including joint works, IMO, is
naive.  

We are all capable of overlooking something.  Jacques, Scott and
yourself just completed OFBIZ-637 because of an overlooked change in
policy.  Why was this policy changed?  It could have been construed
that the ASF was asserting a copyright on the code that followed in
that file.  That was not the ASF's intention and has since been changed
so that it can't be construed in that manner. Lawyers apparently had
reviewed that policy many times before the recent policy change as
well, right? 

Should the ASF have a policy at all regarding joint works?  I don't
know.  That's what posing the question to legal-discuss would answer.

It is a bit of a tired argument that you keep asserting that if someone
says something you disagree with and they continue to push the topic
they are either trolling or spreading fear uncertainty and doubt.  As a
user of OFBiz and as someone trying to extend the capabilities of
OFBiz, I _have fear, uncertainty and doubt. I am looking for somebody
in the project to _alleviate those _fears, _uncertainties and _doubts. 


Asking questions that raise fears, uncertainties and doubts is only
negative if it is put into a forum that the fears, uncertainty and
doubt cannot be explained away.  This channel is the place to alleviate
fear, uncertainty and doubt.  That can only be positive.


Regarding your problems list

1. Giving away the source code under Apache2 destroys the value of the
work itself.  Make no mistake.  This can be shown by taking your
initial contribution to this great project.  Prior to releasing OFBiz
under the MIT license, could you have licensed the work itself (not
consulting) to to a reasonable, knowledgeable person for a fee? The
answer in your head should be yes.  Now ask yourself, can you
legitimately license that work itself to to a reasonable knowledgeable
person for a fee  (not consulting) today?  The answer in your head
should be a resounding NO.  Why? Because by licensing it under MIT and
subsequently Apache2, you have destroyed the value of the work itself. 
The value of the project itself is greatly raised, but the project work
as a whole is not that same work. From what I've read and my
understanding, a single entity can do this, joint owners cannot without
creating undue liability for the other joint owners.

2.  Patches are in fact a work on their own.  From the Apache2 License:
"Work" shall mean the work of authorship, whether in Source or Object
form, made available under the License, as indicated by a copyright
notice that is included in or attached to the work (an example is
provided in the Appendix below).

>From the inconsistency of your comments to the Apache license it is
clear you have at least as little certainty in your opinion as I do
mine.  Please post the question to legal.

--- "David E. Jones" <jo...@hotwaxmedia.com> wrote:

> 
> Chris,
> 
> I've already answered on this topic and I'll include my previous  
> answer below because in spite of the conversation in the interim, it 
> 
> still applies just fine.
> 
> Before that, maybe we should step back a little bit. Let me rephrase 
> 
> what I'm hearing from you and see if I'm understanding right:
> 
> 1. you (Chris Howe) are not a lawyer
> 2. the Apache 2.0 license and supporting documents form a process of 
> 
> creating, maintaining and licensing software projects
> 3. the Apache 2.0 license and supporting documents were prepared and 
> 
> reviewed by a number of different lawyers and are in their third  
> major revision (that I'm aware of, ie 1.0, 1.1, 2.0), each of those  
> having gone through significant review and discussion
> 4. the Apache 2.0 license and supporting documents have garnered  
> support from large corporations such as IBM and Sun
> 5. somehow in spite of all of this they missed some basic tenets of  
> intellectual property law that is part of the USA copyright code
> 
> Am I getting this right?
> 
> Have you considered the possibility that your understanding and  
> interpretations are wrong?
> 
> Have you considered that this is such a strong possibility that maybe
>  
> you should start looking for reasons why it works rather than reasons
>  
> why it doesn't and bias your interpretations in that direction?
> 
> Have you considered looking around on the internet or in books for  
> more information specifically about how the Apache 2.0 license works 
> 
> (especially if you're not satisfied by the documents on apache.org)?
> 
> Have you considered that you are spreading a fairly thick and foul  
> smelling cloud of FUD and that this isn't necessarily good for the  
> project? If there really was a problem then this would be important  
> to discuss, but as I said before and I guess you didn't agree with,  
> there is no problem, and what's more is that it's not your  
> responsibility to manage and those whose responsibility it IS to  
> manage have spoken on the topic.
> 
> I read over your comments last night and based on my understanding of
>  
> how the licensing and development process fit together there are some
>  
> pretty significant problems with your assertions. The first thing to 
> 
> consider is what the ASF is all about and how the process works. That
>  
> is what the apache.org/dev/ documents teach committers and PMC  
> members about, ie the processes they should follow and the things  
> they should be checking.
> 
> The main thing that committers need to remember is that there are 2  
> important categories of things that might come in as contributions,  
> or that they might work on. If it is developed with the intent of  
> going into the open source project and is a natural extension or  
> modification to the existing artifacts, then it can go right in and  
> is immediately covered by the Apache 2 license. If something was  
> developed independently or varies a lot from the normal process, or  
> if the source of the software isn't clear (ie exactly who worked on  
> it), and that they did it with the understanding of contributing it  
> and such, then we can't just commit it "willy nilly". Any time there 
> 
> is a higher risk situation then we need to go through a more thorough
>  
> review and get the incubator folks involved, as described here:
> 
> http://incubator.apache.org/ip-clearance/index.html
> 
> Note that this is reference from the PMC Guide here:
> 
> http://www.apache.org/dev/pmc.html
> 
> If you want to know what the OFBiz PMC, or any ASF PMC, is  
> responsible for and does, this is where to look.
> 
> So, for an external sandbox you can go ahead with it. If there is  
> anything a committer is unsure about, it will go through the "mini- 
> incubation" IP clearance process.
> 
> Okay, now I think I've duplicated everything significant in my  
> original answer.
> 
> So, based on my understanding of the process and recommendations and 
> 
> documents prepared by the actual lawyers, here are some places where 
> 
> I think you assertions might have problems:
> 
> 1. if something is developed with the intent of contributing it to  
> any ASF project then licensing and distributing it through the ASF  
> under the Apache 2 license will not destroy it's value, in fact it  
> will INCREASE the value; from one way of looking at it, the  
> contribution is only of any value to the world or the developers  
> after it has been committed to the project, if that was the intent/ 
> goal from the beginning
> 
> 2. a patch or contribution created for such a purpose is not a "Work"
>  
> on its own from a legal perspective, it is part of a larger Work,  
> namely OFBiz or whatever the ASF project is
> 
> So, why haven't I asked about this on the legal-discuss mailing list?
>  
> I explained that in my other post as well. I really don't see an  
> issue to bug them about. They have already documented the process and
>  
> explained some distinctions between normal commits and what needs to 
> 
> go through the IP clearance process. That's all there is to it.
> 
> -David
> 
> 
> 
> On Jan 27, 2007, at 10:44 AM, Chris Howe wrote:
> 
> > Daniel,
> >
> > IMO you are exactly right both on JIRA and it becoming a dead horse
> > (usually a good sign that has occurred when someone politely asks
> you
> > to change the subject line ;) ).
> >
> > The JIRA process appears perfectly fine for individual works and
> works
> > owned by corporations.  The problem I was pointing out to Tim  is
> that
> > he is asking others to follow a protocol that he has not been  
> > following
> > himself.   The protocol Tim has been following created joint works
> > instead of individual works (Not meaning to point Tim out  
> > specifically,
> > MANY contributions has been made in a similar manner).
> >
> > Whoever has the ability to subscribe to the legal-discuss mailing
> list
> > (committers) could you please post the following questions?
> >
> > Given the following excerpt from FindLaw
> > http://library.findlaw.com/1999/Jan/1/241478.html and your own  
> > personal
> > legal background,
> >
> > "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."
> >
> > Is it possible for a joint owner to license the jointly owned work
> > under Apache2 or other compatible license?
> >
> > It appears on the surface that the Apache2 license destroys the
> value
> > of the joint work itself (albeit increasing the value of the
> ether).
> >
> > If it is only possible with the consent of the other joint owners, 
> 
> > does
> > that agreement constitute a partnership between the joint owners?
> >
> > If it does constitute a partnership, does this partnership bind
> each
> > joint owner jointly and severely to any and all liabilities another
> > joint owner may create in their representations of the joint work?
> >
> > Thank You!
> >
> > --- Daniel Kunkel <Da...@BioWaves.com> wrote:
> >
> >> Hi
> >>
> >> Ok, Chris, now you've confused me.
> >>
> >> I don't have a problem understanding that collaborative efforts
> co-
> >> mingled outside of "Apache Assigned" jira issues could have severe
> >> issues, but it seems to me that collaboration is currently
> possible
> >> via
> >> the inefficient jira patch process.
> 
=== message truncated ===


Re: Intellectual Property and Sandbox SVN

Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
Chris,

I've already answered on this topic and I'll include my previous  
answer below because in spite of the conversation in the interim, it  
still applies just fine.

Before that, maybe we should step back a little bit. Let me rephrase  
what I'm hearing from you and see if I'm understanding right:

1. you (Chris Howe) are not a lawyer
2. the Apache 2.0 license and supporting documents form a process of  
creating, maintaining and licensing software projects
3. the Apache 2.0 license and supporting documents were prepared and  
reviewed by a number of different lawyers and are in their third  
major revision (that I'm aware of, ie 1.0, 1.1, 2.0), each of those  
having gone through significant review and discussion
4. the Apache 2.0 license and supporting documents have garnered  
support from large corporations such as IBM and Sun
5. somehow in spite of all of this they missed some basic tenets of  
intellectual property law that is part of the USA copyright code

Am I getting this right?

Have you considered the possibility that your understanding and  
interpretations are wrong?

Have you considered that this is such a strong possibility that maybe  
you should start looking for reasons why it works rather than reasons  
why it doesn't and bias your interpretations in that direction?

Have you considered looking around on the internet or in books for  
more information specifically about how the Apache 2.0 license works  
(especially if you're not satisfied by the documents on apache.org)?

Have you considered that you are spreading a fairly thick and foul  
smelling cloud of FUD and that this isn't necessarily good for the  
project? If there really was a problem then this would be important  
to discuss, but as I said before and I guess you didn't agree with,  
there is no problem, and what's more is that it's not your  
responsibility to manage and those whose responsibility it IS to  
manage have spoken on the topic.

I read over your comments last night and based on my understanding of  
how the licensing and development process fit together there are some  
pretty significant problems with your assertions. The first thing to  
consider is what the ASF is all about and how the process works. That  
is what the apache.org/dev/ documents teach committers and PMC  
members about, ie the processes they should follow and the things  
they should be checking.

The main thing that committers need to remember is that there are 2  
important categories of things that might come in as contributions,  
or that they might work on. If it is developed with the intent of  
going into the open source project and is a natural extension or  
modification to the existing artifacts, then it can go right in and  
is immediately covered by the Apache 2 license. If something was  
developed independently or varies a lot from the normal process, or  
if the source of the software isn't clear (ie exactly who worked on  
it), and that they did it with the understanding of contributing it  
and such, then we can't just commit it "willy nilly". Any time there  
is a higher risk situation then we need to go through a more thorough  
review and get the incubator folks involved, as described here:

http://incubator.apache.org/ip-clearance/index.html

Note that this is reference from the PMC Guide here:

http://www.apache.org/dev/pmc.html

If you want to know what the OFBiz PMC, or any ASF PMC, is  
responsible for and does, this is where to look.

So, for an external sandbox you can go ahead with it. If there is  
anything a committer is unsure about, it will go through the "mini- 
incubation" IP clearance process.

Okay, now I think I've duplicated everything significant in my  
original answer.

So, based on my understanding of the process and recommendations and  
documents prepared by the actual lawyers, here are some places where  
I think you assertions might have problems:

1. if something is developed with the intent of contributing it to  
any ASF project then licensing and distributing it through the ASF  
under the Apache 2 license will not destroy it's value, in fact it  
will INCREASE the value; from one way of looking at it, the  
contribution is only of any value to the world or the developers  
after it has been committed to the project, if that was the intent/ 
goal from the beginning

2. a patch or contribution created for such a purpose is not a "Work"  
on its own from a legal perspective, it is part of a larger Work,  
namely OFBiz or whatever the ASF project is

So, why haven't I asked about this on the legal-discuss mailing list?  
I explained that in my other post as well. I really don't see an  
issue to bug them about. They have already documented the process and  
explained some distinctions between normal commits and what needs to  
go through the IP clearance process. That's all there is to it.

-David



On Jan 27, 2007, at 10:44 AM, Chris Howe wrote:

> Daniel,
>
> IMO you are exactly right both on JIRA and it becoming a dead horse
> (usually a good sign that has occurred when someone politely asks you
> to change the subject line ;) ).
>
> The JIRA process appears perfectly fine for individual works and works
> owned by corporations.  The problem I was pointing out to Tim  is that
> he is asking others to follow a protocol that he has not been  
> following
> himself.   The protocol Tim has been following created joint works
> instead of individual works (Not meaning to point Tim out  
> specifically,
> MANY contributions has been made in a similar manner).
>
> Whoever has the ability to subscribe to the legal-discuss mailing list
> (committers) could you please post the following questions?
>
> Given the following excerpt from FindLaw
> http://library.findlaw.com/1999/Jan/1/241478.html and your own  
> personal
> legal background,
>
> "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."
>
> Is it possible for a joint owner to license the jointly owned work
> under Apache2 or other compatible license?
>
> It appears on the surface that the Apache2 license destroys the value
> of the joint work itself (albeit increasing the value of the ether).
>
> If it is only possible with the consent of the other joint owners,  
> does
> that agreement constitute a partnership between the joint owners?
>
> If it does constitute a partnership, does this partnership bind each
> joint owner jointly and severely to any and all liabilities another
> joint owner may create in their representations of the joint work?
>
> Thank You!
>
> --- Daniel Kunkel <Da...@BioWaves.com> wrote:
>
>> Hi
>>
>> Ok, Chris, now you've confused me.
>>
>> I don't have a problem understanding that collaborative efforts co-
>> mingled outside of "Apache Assigned" jira issues could have severe
>> issues, but it seems to me that collaboration is currently possible
>> via
>> the inefficient jira patch process.
>>
>> Isn't it completely appropriate for Collaborator A, say Phani to make
>> an
>> "Apache Assigned" contribution in jira which Collaborator B improves
>> and
>> again assigns it to Apache in an updated patch?
>>
>> This still has all of the challenges I've mentioned before,
>>
>> - One collaborator at a time.
>> - A quickly disappearing svn code state that the patch was created
>> against.
>> - inefficient and often chaotic patch handling.
>> - likelihood of losing the work to history
>> - lost opportunity to create strong community with more active
>> energized
>> contributors.
>> - duplication of effort as more than one developer independently work
>> on
>> features.
>> etc.
>>
>> If this jira patch process is legal, then I think we're at the point
>> of
>> beating a dead horse, but hopefully with the wheels of change in
>> motion.
>>
>> Daniel
>>
>> On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
>>> Tim,
>>> I do agree that there is a protocol in place, but I do not agree
>> that
>>> everyone is following it. Those that seem the most opposed to a
>>> discussion about a sandbox are the ones that keep pumping out the
>> joint
>>> works.  From my limited understanding, this does not appear to be a
>>> legal format to license under open source without exposing the
>>> contributor to partnership liability and the exposing the community
>>> with the task of rooting out the offending code.
>>>
>>> I gave you a list of 10 environments that are complex enough and
>>> require
>>> more than incremental changes. Tabling this discussion will
>> continue to
>>> lose many of the valuable contributions of the community (Like
>> Phani's
>>> work on Google Checkout integration).
>>>
>>> In addition, continuing to table this discussion will increase the
>>> likelihood that offending code makes its way into the project.  If
>>> someone makes a stink about it, my understanding is that the remedy
>> is
>>> for the ASF and anyone using Apache OFBiz to cease and desist until
>> the
>>> offending code is removed.  If a business is running off Apache
>> OFBiz,
>>> how much will it cost them to cease and desist?  If they choose not
>> to
>>> C & D, how much will it cost them to defend against a copyright
>>> infringement claim?
>>>
>>> If my legal understanding is incorrect, someone please post the
>>> question to legal-discuss and get a real lawyer's opinion.  If
>> there is
>>> no real risk in these joint works being added to the project,
>> address
>>> it as such.
>>>
>>> Regards,
>>> Chris
>>>
>>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>
>>>> Can we all agree on the fact that there is a protocol in place,
>> that
>>>>
>>>> if followed, allows everyone the ability to pass code around in a
>>
>>>> legal format?  This may or may not be the most optimal format for
>>
>>>> said collaboration, but it does permit us to contribute back to
>> the
>>>> community in a meaningful way.
>>>>
>>>> Let's table this sandbox discussion until we find a movement
>> complex
>>>>
>>>> enough that it requires something more than incremental changes
>> to be
>>>>
>>>> made to the trunk before we can agree to include it.  Does that
>> sound
>>>>
>>>> reasonable?  Once there is an idea to build something that cannot
>>
>>>> follow this incremental pattern, we can evaluate where we are in
>>
>>>> terms of resources and determine the best course of action to
>> follow.
>>>>
>>>> Cheers,
>>>> Tim
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>>
>> -- 
>> Daniel
>>
>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>> Have a GREAT Day!
>>
>> Daniel Kunkel           DanielKunkel@BioWaves.com
>> BioWaves, LLC           http://www.BioWaves.com
>> 14150 NE 20th St. Suite F1
>> Bellevue, WA 98007
>> 800-734-3588    425-895-0050
>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>> http://www.Card-Offer.com      http://www.RackWine.com
>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>
>>
>


Re: Intellectual Property and Sandbox SVN

Posted by Chris Howe <cj...@yahoo.com>.
Daniel,

IMO you are exactly right both on JIRA and it becoming a dead horse
(usually a good sign that has occurred when someone politely asks you
to change the subject line ;) ).  

The JIRA process appears perfectly fine for individual works and works
owned by corporations.  The problem I was pointing out to Tim  is that
he is asking others to follow a protocol that he has not been following
himself.   The protocol Tim has been following created joint works
instead of individual works (Not meaning to point Tim out specifically,
MANY contributions has been made in a similar manner).

Whoever has the ability to subscribe to the legal-discuss mailing list
(committers) could you please post the following questions?

Given the following excerpt from FindLaw
http://library.findlaw.com/1999/Jan/1/241478.html and your own personal
legal background, 

"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."

Is it possible for a joint owner to license the jointly owned work
under Apache2 or other compatible license? 

It appears on the surface that the Apache2 license destroys the value
of the joint work itself (albeit increasing the value of the ether).

If it is only possible with the consent of the other joint owners, does
that agreement constitute a partnership between the joint owners? 

If it does constitute a partnership, does this partnership bind each
joint owner jointly and severely to any and all liabilities another
joint owner may create in their representations of the joint work?

Thank You!

--- Daniel Kunkel <Da...@BioWaves.com> wrote:

> Hi
> 
> Ok, Chris, now you've confused me.
> 
> I don't have a problem understanding that collaborative efforts co-
> mingled outside of "Apache Assigned" jira issues could have severe
> issues, but it seems to me that collaboration is currently possible
> via
> the inefficient jira patch process.
> 
> Isn't it completely appropriate for Collaborator A, say Phani to make
> an
> "Apache Assigned" contribution in jira which Collaborator B improves
> and
> again assigns it to Apache in an updated patch?
> 
> This still has all of the challenges I've mentioned before, 
> 
> - One collaborator at a time.
> - A quickly disappearing svn code state that the patch was created
> against.
> - inefficient and often chaotic patch handling.
> - likelihood of losing the work to history
> - lost opportunity to create strong community with more active
> energized
> contributors.
> - duplication of effort as more than one developer independently work
> on
> features.
> etc.
> 
> If this jira patch process is legal, then I think we're at the point
> of
> beating a dead horse, but hopefully with the wheels of change in
> motion.
> 
> Daniel
> 
> On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
> > Tim,
> > I do agree that there is a protocol in place, but I do not agree
> that
> > everyone is following it. Those that seem the most opposed to a
> > discussion about a sandbox are the ones that keep pumping out the
> joint
> > works.  From my limited understanding, this does not appear to be a
> > legal format to license under open source without exposing the
> > contributor to partnership liability and the exposing the community
> > with the task of rooting out the offending code.
> > 
> > I gave you a list of 10 environments that are complex enough and
> > require 
> > more than incremental changes. Tabling this discussion will
> continue to
> > lose many of the valuable contributions of the community (Like
> Phani's
> > work on Google Checkout integration).
> > 
> > In addition, continuing to table this discussion will increase the
> > likelihood that offending code makes its way into the project.  If
> > someone makes a stink about it, my understanding is that the remedy
> is
> > for the ASF and anyone using Apache OFBiz to cease and desist until
> the
> > offending code is removed.  If a business is running off Apache
> OFBiz,
> > how much will it cost them to cease and desist?  If they choose not
> to
> > C & D, how much will it cost them to defend against a copyright
> > infringement claim?
> > 
> > If my legal understanding is incorrect, someone please post the
> > question to legal-discuss and get a real lawyer's opinion.  If
> there is
> > no real risk in these joint works being added to the project,
> address
> > it as such.
> > 
> > Regards,
> > Chris
> > 
> > --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
> > 
> > > Can we all agree on the fact that there is a protocol in place,
> that 
> > > 
> > > if followed, allows everyone the ability to pass code around in a
>  
> > > legal format?  This may or may not be the most optimal format for
>  
> > > said collaboration, but it does permit us to contribute back to
> the  
> > > community in a meaningful way.
> > > 
> > > Let's table this sandbox discussion until we find a movement
> complex 
> > > 
> > > enough that it requires something more than incremental changes
> to be
> > >  
> > > made to the trunk before we can agree to include it.  Does that
> sound
> > >  
> > > reasonable?  Once there is an idea to build something that cannot
>  
> > > follow this incremental pattern, we can evaluate where we are in 
> 
> > > terms of resources and determine the best course of action to
> follow.
> > > 
> > > Cheers,
> > > Tim
> > > --
> > > Tim Ruppert
> > > HotWax Media
> > > http://www.hotwaxmedia.com
> > > 
> > > o:801.649.6594
> > > f:801.649.6595
> > > 
> -- 
> Daniel
> 
> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
> Have a GREAT Day!
> 
> Daniel Kunkel           DanielKunkel@BioWaves.com
> BioWaves, LLC           http://www.BioWaves.com
> 14150 NE 20th St. Suite F1
> Bellevue, WA 98007
> 800-734-3588    425-895-0050
> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
> http://www.Card-Offer.com      http://www.RackWine.com
> http://www.JokesBlonde.com     http://www.Brain-Fun.com 
> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
> 
> 


Re: Intellectual Property and Sandbox SVN

Posted by Daniel Kunkel <Da...@BioWaves.com>.
Hi

Ok, Chris, now you've confused me.

I don't have a problem understanding that collaborative efforts co-
mingled outside of "Apache Assigned" jira issues could have severe
issues, but it seems to me that collaboration is currently possible via
the inefficient jira patch process.

Isn't it completely appropriate for Collaborator A, say Phani to make an
"Apache Assigned" contribution in jira which Collaborator B improves and
again assigns it to Apache in an updated patch?

This still has all of the challenges I've mentioned before, 

- One collaborator at a time.
- A quickly disappearing svn code state that the patch was created
against.
- inefficient and often chaotic patch handling.
- likelihood of losing the work to history
- lost opportunity to create strong community with more active energized
contributors.
- duplication of effort as more than one developer independently work on
features.
etc.

If this jira patch process is legal, then I think we're at the point of
beating a dead horse, but hopefully with the wheels of change in motion.

Daniel

On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
> Tim,
> I do agree that there is a protocol in place, but I do not agree that
> everyone is following it. Those that seem the most opposed to a
> discussion about a sandbox are the ones that keep pumping out the joint
> works.  From my limited understanding, this does not appear to be a
> legal format to license under open source without exposing the
> contributor to partnership liability and the exposing the community
> with the task of rooting out the offending code.
> 
> I gave you a list of 10 environments that are complex enough and
> require 
> more than incremental changes. Tabling this discussion will continue to
> lose many of the valuable contributions of the community (Like Phani's
> work on Google Checkout integration).
> 
> In addition, continuing to table this discussion will increase the
> likelihood that offending code makes its way into the project.  If
> someone makes a stink about it, my understanding is that the remedy is
> for the ASF and anyone using Apache OFBiz to cease and desist until the
> offending code is removed.  If a business is running off Apache OFBiz,
> how much will it cost them to cease and desist?  If they choose not to
> C & D, how much will it cost them to defend against a copyright
> infringement claim?
> 
> If my legal understanding is incorrect, someone please post the
> question to legal-discuss and get a real lawyer's opinion.  If there is
> no real risk in these joint works being added to the project, address
> it as such.
> 
> Regards,
> Chris
> 
> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
> 
> > Can we all agree on the fact that there is a protocol in place, that 
> > 
> > if followed, allows everyone the ability to pass code around in a  
> > legal format?  This may or may not be the most optimal format for  
> > said collaboration, but it does permit us to contribute back to the  
> > community in a meaningful way.
> > 
> > Let's table this sandbox discussion until we find a movement complex 
> > 
> > enough that it requires something more than incremental changes to be
> >  
> > made to the trunk before we can agree to include it.  Does that sound
> >  
> > reasonable?  Once there is an idea to build something that cannot  
> > follow this incremental pattern, we can evaluate where we are in  
> > terms of resources and determine the best course of action to follow.
> > 
> > Cheers,
> > Tim
> > --
> > Tim Ruppert
> > HotWax Media
> > http://www.hotwaxmedia.com
> > 
> > o:801.649.6594
> > f:801.649.6595
> > 
-- 
Daniel

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!

Daniel Kunkel           DanielKunkel@BioWaves.com
BioWaves, LLC           http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588    425-895-0050
http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
http://www.Card-Offer.com      http://www.RackWine.com
http://www.JokesBlonde.com     http://www.Brain-Fun.com 
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-


Re: Intellectual Property and Sandbox SVN

Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
And as I said last night Chris - I'm not opposed to doing something  
to rectify the situation - all anyone is asking here that you try ONE  
of the ten things you have going and try doing it iteratively using  
the same model that's been outlined many times before.

Just do it once, see how many people get involved - see how  
unmanageable the process is with someone making a patch, submitting  
it, people testing it, and it going into the project.

I believe that the first of such patches could easily be just a new  
application, some controller and web xml files, and ofbiz- 
component.xml, etc, etc.  Then a proposal would be put forth to the  
community for the project.  People could jump in and the changes  
could be built upon quite easily.  We've been managing updates in  
this way for a good long while now and it has been quite manageable  
and made for quick turnarounds.

I personally think that it is easier to manage small patches as they  
are created versus trying to submit something that's TOTALLY new  
application.  Think about how much time it would take for the  
committers to review an application that grows that large?  Why not  
try it iteratively and see how you like it?

As for the legal concerns, if there's someone at the ASF we can send  
this question to once and for all - by all means let's find a way to  
at least send it over there.  Chris, if you have a lawyer that you'd  
like to review all of the docs and give you a formal understanding of  
everything - please knock yourself and let us know how it all goes.   
If there is anyone else that wants to donate legal time - we would  
all love for this to be resolved so that it doesn't come up again.

So, here's my final two cents on the issue:

1. START USING THE EXISTING PROCESS
2. Check and see if someone can donate some legal time to quiesce any  
legal questions
3. Check and see if the ASF can help us with this conundrum
4. Evaluate legal resolutions and make infrastructure decisions based  
on true need resource availability.

Chris, I hope this works for you both as a short-term solution and as  
an understanding that we must wait until a true need shows itself  
(not proven) and some of these legal questions are answered by  
someone classically trained (instead of just someone's conjecture).

This is the last time I want to address this issue until we have both  
a real life situation that's not working AND legal answers from  
someone that specializes in Intellectual Property Law and knows the  
ASF intimately.  Anybody else that wants to continue deliberating on  
this topic - please feel free.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Jan 27, 2007, at 9:28 AM, Chris Howe wrote:

> Tim,
> I do agree that there is a protocol in place, but I do not agree that
> everyone is following it. Those that seem the most opposed to a
> discussion about a sandbox are the ones that keep pumping out the  
> joint
> works.  From my limited understanding, this does not appear to be a
> legal format to license under open source without exposing the
> contributor to partnership liability and the exposing the community
> with the task of rooting out the offending code.
>
> I gave you a list of 10 environments that are complex enough and
> require
> more than incremental changes. Tabling this discussion will  
> continue to
> lose many of the valuable contributions of the community (Like Phani's
> work on Google Checkout integration).
>
> In addition, continuing to table this discussion will increase the
> likelihood that offending code makes its way into the project.  If
> someone makes a stink about it, my understanding is that the remedy is
> for the ASF and anyone using Apache OFBiz to cease and desist until  
> the
> offending code is removed.  If a business is running off Apache OFBiz,
> how much will it cost them to cease and desist?  If they choose not to
> C & D, how much will it cost them to defend against a copyright
> infringement claim?
>
> If my legal understanding is incorrect, someone please post the
> question to legal-discuss and get a real lawyer's opinion.  If  
> there is
> no real risk in these joint works being added to the project, address
> it as such.
>
> Regards,
> Chris
>
> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>
>> Can we all agree on the fact that there is a protocol in place, that
>>
>> if followed, allows everyone the ability to pass code around in a
>> legal format?  This may or may not be the most optimal format for
>> said collaboration, but it does permit us to contribute back to the
>> community in a meaningful way.
>>
>> Let's table this sandbox discussion until we find a movement complex
>>
>> enough that it requires something more than incremental changes to be
>>
>> made to the trunk before we can agree to include it.  Does that sound
>>
>> reasonable?  Once there is an idea to build something that cannot
>> follow this incremental pattern, we can evaluate where we are in
>> terms of resources and determine the best course of action to follow.
>>
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>>
>> On Jan 26, 2007, at 9:39 PM, Chris Howe wrote:
>>
>>>
>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>
>>>> Chris,
>>>>
>>>> Ugh. Remind me never to take up law. (Yeah, I know, I'll be cannon
>>>> fodder for big boys with lawyers.)
>>>>
>>>>> This structure, however does not protect the contributor (you) of
>>>> a
>>>>> joint work.
>>>>
>>>> Ok. So if I stole someone else's private work and contributed it
>> to a
>>>> committer who commits this
>>>> stolen work to ASF, then I'm liable for the theft, and ASF and the
>>>> committer are not liable.
>>>>
>>>
>>> ASF will need to remove the offending code from distribution.
>>>
>>>> That'll also mean I better make sure that the contributions put
>> into
>>>> my private sandbox are not
>>>> stolen as well. I'll just follow ASF's "license grant" process, so
>> I
>>>> won't be liable for any
>>>> thefts committed by contributors in my sandbox team.
>>>>
>>>
>>> That may not be sufficient.  The ASF does quite a bit more than the
>>
>>> CLA
>>> and license grant to protect itself.
>>>
>>>>> 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.
>>>>
>>>> Alright. So I just need to make sure all those committing to my
>>>> ragtag sandbox assigns rights to
>>>> ASF to distribute their contributions under Apache 2.
>>>>
>>>
>>> AFAIK
>>> The only way you can grant a license to the ASF is if you make your
>>> contribution directly to the ASF.  If they make their contribution
>> to
>>> you, they are granting you a license not Apache.  However, since
>> their
>>> contribution is intended to be inseparable from your contribution,
>> it
>>> is now a joint work absent some sort of agreement. This is the
>> point
>>> where it gets cloudy and no definitive answer has been offered.
>> Still
>>> not a pretty pickle and thus my ranting for a sandbox that is
>>> available
>>> to the community but owned by ASF.
>>>
>>>>> Not a pretty pickle.
>>>>
>>>> No, it's not pretty to software vendors, OFBiz consultants needing
>>>> money for a living, etc. But
>>>> that's not my concern. I leave that to businessmen.
>>>>
>>>>> Does this make my understanding of the scenario clear?
>>>>
>>>> Quite a bit clearer. Thanks.
>>>>
>>>> Jonathon
>>>>
>>>> Chris Howe wrote:
>>>>> 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 <jo...@improov.com> 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
>>
> === message truncated ===
>