www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: To IP Clearance? or not?
Date Fri, 01 Feb 2013 18:59:38 GMT
I don't think that's entirely true. What about PCRE and Expat?

We must certainly ask if we're trying to *move* the canonical repository to
here. No question. But a convenience copy? I don't think so.

It gets sketchier with a fork. What if upstream doesn't agree with the
direction of an ASF project's needed changes? Where does that go? I say it
is fine to bring it here, just as long as the new direction doesn't confuse
users (ie. don't make independent releases under the original name; maybe
even change lib name to prevent collision).

Cheers,
-g
 On Feb 1, 2013 9:56 AM, "Jim Jagielski" <jim@jagunet.com> wrote:

> The understanding is that we only accept into Apache
> "voluntary" code, so even code that we could simply
> "bring in", due to its license, we still check
> with the copyright holder to ensure it's OK to
> do so.
>
> On Jan 31, 2013, at 1:35 PM, Greg Stein <gstein@gmail.com> wrote:
>
> > On Thu, Jan 31, 2013 at 1:13 PM, David Nalley <david@gnsa.us> wrote:
> >> On Thu, Jan 31, 2013 at 12:08 PM, Greg Stein <gstein@gmail.com> wrote:
> >>> On Jan 31, 2013 11:47 AM, "Benson Margulies" <bimargulies@gmail.com>
> wrote:
> >>>>
> >>>> On Thu, Jan 31, 2013 at 4:38 PM, David Nalley <david@gnsa.us>
wrote:
> >>>>> Hi folks:
> >>>>>
> >>>>> CloudStack is currently discussing adding some code which includes
> >>>>> some chunks of 3rd party code that is licensed under ALv2. [1]
> >>>>>
> >>>>> Essentialy the situation is:
> >>>>>
> >>>>> * Developer found some ALv2 code that fit a specific need from a
> >>>>> non-ASF open source project that is in the same space.
> >>>>> * Developer modified that code to work in CloudStack
> >>>>> * Developer submitted that for review/inclusion, at which point
> >>>>> someone noted the Copyright attributions and our discussion began.
> >>>>> * If accepted (and I think the assumption is that it would be) the
> >>>>> code would be included in the CloudStack codebase and distributed
in
> >>>>> future CloudStack releases.
> >>>>> * The total line count is around 1500 lines of code that wasn't
> >>>>> developed specifically for CloudStack
> >>>>
> >>>> The issue here is the absolute requirements that all code
> >>>> contributions be _voluntary_. The policy has been that ' very small'
> >>>> bits of code under 'category A' licenses can be committed, but, if
> >>>> it's larger than small, it must be actively contributes by its author.
> >>>> Whether we need IP clearance is again a matter of judgement based on
> >>>> size.
> >>>>
> >>>> It strikes me as too big to be collected without active participation
> >>>> from the author, but I leave it to others to comment on whether it's
> >>>> big enough to require full IP clearance.
> >>>
> >>> No no... You're talking about code that arrives with the intent on
> >>> *moving* its locus of development to the ASF. The IP clearance is
> >>> needed to ensure we have the necessary rights to do the work here. It
> >>> sounds like this is (and will remain) a third-party library. That its
> >>> development location isn't moving here.
> >>>
> >>> If the code is merely a dependent library, pulled into our version
> >>> control for ease of packaging, then that's just fine. In httpd, we do
> >>> that with PCRE. In APR, we do that with Expat. There is ample
> >>> precedent, as long as the code is properly marked (ie. leave all of
> >>> its headers alone, noting the correct copyright holder and license).
> >>>
> >>> If the code is a third-party library, and further work is intended,
> >>> then I would suggest a vendor branch. Check in the original library
> >>> onto a vendor branch, copy that into trunk, and apply changes into
> >>> trunk. For "large" modifications (for some suitable definition of
> >>> "large"), then it may be desirable to apply additional ASF headers
> >>> into the files, noting "portions are copyright ASF, and subject to
> >>> ALv2" (or whatever the right text is; you get the idea)
> >>>
> >>> So... IP clearance in this situation depends on long-term intent, I
> would say.
> >>>
> >>> Cheers,
> >>> -g
> >>>
> >>
> >>
> >> This was 3rd party code - but it has already been morphed and
> >> development was continued on that code outside of the 'upstream' and
> >> is expected to continue to diverge within our codebase. So effectively
> >> we are talking about adopting this code and making it ours, not just
> >> inclusion for convenience.
> >
> > We have no formal, written policy against forking outside projects
> > into Apache, but several "old timers" have suggested we have an
> > unwritten policy. Mostly based on it being anti-social or somesuch.
> >
> > My personal position is to try and avoid it. Otherwise, to create a
> > vendor branch, so you can see how we diverged from upstream. And
> > hopefully, some kind of attempt to get some of those changes merged
> > upstream.
> >
> > As long as we obey their license, and include appropriate info into
> > LICENSE and NOTICE, then (IMO) this is exactly how Open Source is
> > supposed to work. From a social standpoint, clarifying our divergence
> > is a Good Thing, and the vendor branch helps there.
> >
> > I would recommend an IP clearance form, to clarify we have the rights
> > to (further) develop those 1500 lines here at the ASF.
> >
> > Cheers,
> > -g
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Mime
View raw message