You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "Geir Magnusson Jr." <ge...@apache.org> on 2005/12/23 19:15:44 UTC
[policy] bring in full code history on incubated project?
Sorry to change the subject...
Can someone make a definitive statement on whether or not code
history is brought into our repo from elsewhere when a podling brings
code over?
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 03 January 2006 22:40, Jules Gosnell wrote:
> Isn't the incubator meant to lower the bar for projects wishing to
> migrate into ASF ?
Not directly. Incubator is the buffer that is here to ensure that the ASF, its
members and to some degree its committers are given a low legal risk. That
means that the Incubator's primary job is to make sure that we expose
ourselves to possible legal attack, or for that matter, ignorance resulting
in troublesome conversions later, for instance a project named by a trademark
which we later have to change, which causes both confusion for users and
additional workload for the project.
The second main objective of the Incubator is to "educate" incubatees in "The
Apache Way" and bring the project community up to par with the other
projects. The "daily job" for that falls upon the mentor, but the Incubator
PMC has an oversight duty, and should not graduate projects that doesn't show
that they operate according to the general practice of the foundation.
_I_ have not seen any specific directives from the Board that the Incubator
should "lower the bar". In a way the Incubator is lowering the bar, by the
fact that it exist, and one didn't need to go through the Board to create new
projects or import external ones, but that is more a "work load issue" than
anything to do with requirements for becoming an Apache project.
"Making it easier" in terms of providing better tools, support, infrastructure
to achieve the objectives mentioned above are on the Incubators "work list"
on a continuous basis. Perhaps that is what you meant.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Upayavira <uv...@odoko.co.uk>.
Jules Gosnell wrote:
> Geir Magnusson Jr wrote:
>
>>
>>
>> Jules Gosnell wrote:
>>
>>> Geir Magnusson Jr. wrote:
>>>
>>>> Sorry to change the subject...
>>>>
>>>> Can someone make a definitive statement on whether or not code
>>>> history is brought into our repo from elsewhere when a podling
>>>> brings code over?
>>>>
>>>>
>>>
>>> I don't see how the incubator can hold a single position on this one.
>>>
>>> There are good reasons both for and against, depending on your project.
>>>
>>
>> We certainly can have a position, and then deal with exceptions.
>>
>>
>>> Rather than making a decision which is bound to fly in the face of
>>> some potential incubatees, why can it not simply be left to
>>> individual projects to decide for themselves?
>>
>>
>>
>> Because IMO the primary purpose of the incubator is to protect and
>> promote the ASFs interests, not of the candidate individual projects.
>> That's SourceForge.
>>
>>>
>>> My understanding of the incubator's role, was that issues like this
>>> did not have to be resolved until a project sought promotion up out
>>> of the incubator.
>>
>>
>>
>> Well, things have to be complete by then, but this is a case of where
>> if you don't do it from the beginning, you can't fix it later, unless
>> you've made no changes to the code.
>
>
> if you didn't bring your history to the incubator, then you obviously
> didn't intend to bring it to ASF - case closed.
>
> if you did, then you are saying that you want at least one less
> fragmentation of your project's history, but this does not stop you from
> leaving your history behind when you are promoted from the incubator if
> this is requirement.
>
>>
>>>
>>> At this point, I might reasonably expect to have to shed a project
>>> history - if its acceptance into a first-level ASF repo caused
>>> problems - and live with a history divided between two repos.
>>>
>>> Why, though, a passage to this point, via the incubator, should
>>> further fragment a project, and leave me with my history in three
>>> places, I do not understand.
>>>
>>> Isn't the incubator meant to lower the bar for projects wishing to
>>> migrate into ASF ?
>>
>>
>>
>> Where would the three places be? I can see two if we don't take
>> history and only one if we do - here, at the ASF.
>
>
> 1. codehaus (history before move to incubator)
> 2. incubator (history after move and before promotion - many changes
> will occur to the project which it is in the incubator)
> 3. geronimo (history after promotion).
>
> History is an integral part of any project, an important technical
> reference, a record of contributions made to the project and much more.
>
> I don't understand why any constraints (legal, resource-based etc...)
> should be applied to a project on entry into the incubator, although I
> would expect them to be applied strenuously before any promotion could
> occur.
Surely this is simple. Are there legal issues in the history that aren't
present in the current codebase? If the answer is no, then we can take
in the entire history?
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Jules Gosnell <ju...@mortbay.com>.
Geir Magnusson Jr wrote:
>
>
> Jules Gosnell wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>> Sorry to change the subject...
>>>
>>> Can someone make a definitive statement on whether or not code
>>> history is brought into our repo from elsewhere when a podling
>>> brings code over?
>>>
>>>
>>
>> I don't see how the incubator can hold a single position on this one.
>>
>> There are good reasons both for and against, depending on your project.
>>
>
> We certainly can have a position, and then deal with exceptions.
>
>
>> Rather than making a decision which is bound to fly in the face of
>> some potential incubatees, why can it not simply be left to individual
>> projects to decide for themselves?
>
>
> Because IMO the primary purpose of the incubator is to protect and
> promote the ASFs interests, not of the candidate individual projects.
> That's SourceForge.
>
>>
>> My understanding of the incubator's role, was that issues like this
>> did not have to be resolved until a project sought promotion up out of
>> the incubator.
>
>
> Well, things have to be complete by then, but this is a case of where if
> you don't do it from the beginning, you can't fix it later, unless
> you've made no changes to the code.
if you didn't bring your history to the incubator, then you obviously
didn't intend to bring it to ASF - case closed.
if you did, then you are saying that you want at least one less
fragmentation of your project's history, but this does not stop you from
leaving your history behind when you are promoted from the incubator if
this is requirement.
>
>>
>> At this point, I might reasonably expect to have to shed a project
>> history - if its acceptance into a first-level ASF repo caused
>> problems - and live with a history divided between two repos.
>>
>> Why, though, a passage to this point, via the incubator, should
>> further fragment a project, and leave me with my history in three
>> places, I do not understand.
>>
>> Isn't the incubator meant to lower the bar for projects wishing to
>> migrate into ASF ?
>
>
> Where would the three places be? I can see two if we don't take history
> and only one if we do - here, at the ASF.
1. codehaus (history before move to incubator)
2. incubator (history after move and before promotion - many changes
will occur to the project which it is in the incubator)
3. geronimo (history after promotion).
History is an integral part of any project, an important technical
reference, a record of contributions made to the project and much more.
I don't understand why any constraints (legal, resource-based etc...)
should be applied to a project on entry into the incubator, although I
would expect them to be applied strenuously before any promotion could
occur.
respectfully,
Jules
>
> geir
>
>>
>>
>> Jules (WADI)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jules Gosnell wrote:
> Geir Magnusson Jr wrote:
>
>>
>>
>> Jules Gosnell wrote:
>>
>>> Geir Magnusson Jr. wrote:
>>>
>>>> Sorry to change the subject...
>>>>
>>>> Can someone make a definitive statement on whether or not code
>>>> history is brought into our repo from elsewhere when a podling
>>>> brings code over?
>>>>
>>>>
>>>
>>> I don't see how the incubator can hold a single position on this one.
>>>
>>> There are good reasons both for and against, depending on your project.
>>>
>>
>> We certainly can have a position, and then deal with exceptions.
>>
>>
>>> Rather than making a decision which is bound to fly in the face of
>>> some potential incubatees, why can it not simply be left to
>>> individual projects to decide for themselves?
>>
>>
>>
>> Because IMO the primary purpose of the incubator is to protect and
>> promote the ASFs interests, not of the candidate individual projects.
>> That's SourceForge.
>>
>>>
>>> My understanding of the incubator's role, was that issues like this
>>> did not have to be resolved until a project sought promotion up out
>>> of the incubator.
>>
>>
>>
>> Well, things have to be complete by then, but this is a case of where
>> if you don't do it from the beginning, you can't fix it later, unless
>> you've made no changes to the code.
>
>
> if you didn't bring your history to the incubator, then you obviously
> didn't intend to bring it to ASF - case closed.
That's true. I would assume that an OSS project moving here would
indeed want to keep it though....
>
> if you did, then you are saying that you want at least one less
> fragmentation of your project's history, but this does not stop you from
> leaving your history behind when you are promoted from the incubator.
I can't imagine why you'd want to do that.
>
>>
>>>
>>> At this point, I might reasonably expect to have to shed a project
>>> history - if its acceptance into a first-level ASF repo caused
>>> problems - and live with a history divided between two repos.
>>>
>>> Why, though, a passage to this point, via the incubator, should
>>> further fragment a project, and leave me with my history in three
>>> places, I do not understand.
>>>
>>> Isn't the incubator meant to lower the bar for projects wishing to
>>> migrate into ASF ?
>>
>>
>>
>> Where would the three places be? I can see two if we don't take
>> history and only one if we do - here, at the ASF.
>
>
> 1. codehaus (history before move to incubator)
> 2. incubator (history after move and before promotion - many changes
> will occur to the project which it is in the incubator)
> 3. geronimo (history after promotion).
>
> History is an integral part of any project, an important technical
> reference, a record of contributions made to the project and much more.
Right - so why would you want to abandon the history when going to
Geronimo? I can see it happening going from codehaus to incubator if
you chose to do that (although I wouldn't), but we should be able to
keep it when going to G, right?
>
> The incubator is a grey area between outside and inside ASF.
No - it's inside the ASF.
>
> I don't understand why any constraints (legal, resource-based etc...)
> should be applied to a project on entry into the incubator, although I
> would expect them to be applied strenuously before any promotion could
> occur.
Because the incubator is a project of the ASF, and therefore responsible
for what happens here. It's not a "no-man's land".
geir
>
>
> respectfully,
>
>
> Jules
>
>
>
>>
>> geir
>>
>>>
>>>
>>> Jules (WADI)
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Jules Gosnell <ju...@mortbay.com>.
Geir Magnusson Jr wrote:
>
>
> Jules Gosnell wrote:
>
>> Geir Magnusson Jr. wrote:
>>
>>> Sorry to change the subject...
>>>
>>> Can someone make a definitive statement on whether or not code
>>> history is brought into our repo from elsewhere when a podling
>>> brings code over?
>>>
>>>
>>
>> I don't see how the incubator can hold a single position on this one.
>>
>> There are good reasons both for and against, depending on your project.
>>
>
> We certainly can have a position, and then deal with exceptions.
>
>
>> Rather than making a decision which is bound to fly in the face of
>> some potential incubatees, why can it not simply be left to individual
>> projects to decide for themselves?
>
>
> Because IMO the primary purpose of the incubator is to protect and
> promote the ASFs interests, not of the candidate individual projects.
> That's SourceForge.
>
>>
>> My understanding of the incubator's role, was that issues like this
>> did not have to be resolved until a project sought promotion up out of
>> the incubator.
>
>
> Well, things have to be complete by then, but this is a case of where if
> you don't do it from the beginning, you can't fix it later, unless
> you've made no changes to the code.
if you didn't bring your history to the incubator, then you obviously
didn't intend to bring it to ASF - case closed.
if you did, then you are saying that you want at least one less
fragmentation of your project's history, but this does not stop you from
leaving your history behind when you are promoted from the incubator.
>
>>
>> At this point, I might reasonably expect to have to shed a project
>> history - if its acceptance into a first-level ASF repo caused
>> problems - and live with a history divided between two repos.
>>
>> Why, though, a passage to this point, via the incubator, should
>> further fragment a project, and leave me with my history in three
>> places, I do not understand.
>>
>> Isn't the incubator meant to lower the bar for projects wishing to
>> migrate into ASF ?
>
>
> Where would the three places be? I can see two if we don't take history
> and only one if we do - here, at the ASF.
1. codehaus (history before move to incubator)
2. incubator (history after move and before promotion - many changes
will occur to the project which it is in the incubator)
3. geronimo (history after promotion).
History is an integral part of any project, an important technical
reference, a record of contributions made to the project and much more.
The incubator is a grey area between outside and inside ASF.
I don't understand why any constraints (legal, resource-based etc...)
should be applied to a project on entry into the incubator, although I
would expect them to be applied strenuously before any promotion could
occur.
respectfully,
Jules
>
> geir
>
>>
>>
>> Jules (WADI)
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jules Gosnell wrote:
> Geir Magnusson Jr. wrote:
>
>> Sorry to change the subject...
>>
>> Can someone make a definitive statement on whether or not code
>> history is brought into our repo from elsewhere when a podling brings
>> code over?
>>
>>
>
> I don't see how the incubator can hold a single position on this one.
>
> There are good reasons both for and against, depending on your project.
>
We certainly can have a position, and then deal with exceptions.
> Rather than making a decision which is bound to fly in the face of some
> potential incubatees, why can it not simply be left to individual
> projects to decide for themselves?
Because IMO the primary purpose of the incubator is to protect and
promote the ASFs interests, not of the candidate individual projects.
That's SourceForge.
>
> My understanding of the incubator's role, was that issues like this did
> not have to be resolved until a project sought promotion up out of the
> incubator.
Well, things have to be complete by then, but this is a case of where if
you don't do it from the beginning, you can't fix it later, unless
you've made no changes to the code.
>
> At this point, I might reasonably expect to have to shed a project
> history - if its acceptance into a first-level ASF repo caused problems
> - and live with a history divided between two repos.
>
> Why, though, a passage to this point, via the incubator, should further
> fragment a project, and leave me with my history in three places, I do
> not understand.
>
> Isn't the incubator meant to lower the bar for projects wishing to
> migrate into ASF ?
Where would the three places be? I can see two if we don't take history
and only one if we do - here, at the ASF.
geir
>
>
> Jules (WADI)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Jules Gosnell <ju...@mortbay.com>.
Geir Magnusson Jr. wrote:
> Sorry to change the subject...
>
> Can someone make a definitive statement on whether or not code history
> is brought into our repo from elsewhere when a podling brings code over?
>
>
I don't see how the incubator can hold a single position on this one.
There are good reasons both for and against, depending on your project.
Rather than making a decision which is bound to fly in the face of some
potential incubatees, why can it not simply be left to individual
projects to decide for themselves?
My understanding of the incubator's role, was that issues like this did
not have to be resolved until a project sought promotion up out of the
incubator.
At this point, I might reasonably expect to have to shed a project
history - if its acceptance into a first-level ASF repo caused problems
- and live with a history divided between two repos.
Why, though, a passage to this point, via the incubator, should further
fragment a project, and leave me with my history in three places, I do
not understand.
Isn't the incubator meant to lower the bar for projects wishing to
migrate into ASF ?
Jules (WADI)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Jules Gosnell <ju...@mortbay.com>.
Geir Magnusson Jr. wrote:
> Sorry to change the subject...
>
> Can someone make a definitive statement on whether or not code history
> is brought into our repo from elsewhere when a podling brings code over?
>
>
I don't see how the incubator can hold a single position on this one.
There are good reasons both for and against, depending on your project.
Rather than making a decision which is bound to fly in the face of some
potential incubatees, why can it not simply be left to individual
projects to decide for themselves?
My understanding of the incubator's role, was that issues like this did
not have to be resolved until a project sought promotion up out of the
incubator.
At this point, I might reasonably expect to have to shed a project
history - if its acceptance into a first-level ASF repo caused problems
- and live with a history divided between two repos.
Why, though, a passage to this point, via the incubator, should further
fragment a project, and leave me with my history in three places, I do
not understand.
Isn't the incubator meant to lower the bar for projects wishing to
migrate into ASF ?
Jules (WADI)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Greg Wilkins <gr...@mortbay.com>.
We should take history!
A snapshot does not solve any "legal or social issues". Obscuring history
does not change history and if code is a derivative of LGPL, then not having
the history does not change that fact.
If there is something in the real history, then it is best to have that
explicit in the svn history.
regards
Justin Erenkrantz wrote:
> --On December 23, 2005 1:15:44 PM -0500 "Geir Magnusson Jr."
> <ge...@apache.org> wrote:
>
>> Sorry to change the subject...
>>
>> Can someone make a definitive statement on whether or not code history
>> is brought into our repo from elsewhere when a podling brings code over?
>
>
> I say no. We should only take in a snapshot.
>
> If people want to see the history that was done elsewhere, they are free
> to maintain the old history outside. What happened before the ASF was
> involved is something we have no knowledge of and can't speak to. We
> can't be responsible for what happened before we were involved.
>
> By only taking in a snapshot, we create a clean break from a social and
> legal standpoint. All work from that point is done under our oversight
> mechanisms. We can operate in good faith that the snapshot we receive
> is in decent legal shape as we usually have a software grant for the
> bulk of that work. However, taking in complete source history that we
> have no knowledge of the oversight mechanisms that were in place is a
> bad thing in my opinion.
>
> There is a lesser point that taking in the author information from a
> separate project is awkward. This presents conflicts with our user
> account information and muddy things up if we ever have to do an audit.
> -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Jim Jagielski <ji...@jaguNET.com>.
-1 from me :)
If we have access to the history, then we should take advantage
of it. This is especially true when the code is from public
repos, or, at least, non-private donators.
On Dec 23, 2005, at 1:32 PM, Davanum Srinivas wrote:
> +1 from me. Start with a snapshot.
>
> On 12/23/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>> --On December 23, 2005 1:15:44 PM -0500 "Geir Magnusson Jr."
>> <ge...@apache.org> wrote:
>>
>>> Sorry to change the subject...
>>>
>>> Can someone make a definitive statement on whether or not code
>>> history
>>> is brought into our repo from elsewhere when a podling brings
>>> code over?
>>
>> I say no. We should only take in a snapshot.
>>
>> If people want to see the history that was done elsewhere, they
>> are free to
>> maintain the old history outside. What happened before the ASF was
>> involved is something we have no knowledge of and can't speak to.
>> We can't
>> be responsible for what happened before we were involved.
>>
>> By only taking in a snapshot, we create a clean break from a
>> social and
>> legal standpoint. All work from that point is done under our
>> oversight
>> mechanisms. We can operate in good faith that the snapshot we
>> receive is
>> in decent legal shape as we usually have a software grant for the
>> bulk of
>> that work. However, taking in complete source history that we
>> have no
>> knowledge of the oversight mechanisms that were in place is a bad
>> thing in
>> my opinion.
>>
>> There is a lesser point that taking in the author information from a
>> separate project is awkward. This presents conflicts with our
>> user account
>> information and muddy things up if we ever have to do an audit.
>> -- justin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me. Start with a snapshot.
On 12/23/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> --On December 23, 2005 1:15:44 PM -0500 "Geir Magnusson Jr."
> <ge...@apache.org> wrote:
>
> > Sorry to change the subject...
> >
> > Can someone make a definitive statement on whether or not code history
> > is brought into our repo from elsewhere when a podling brings code over?
>
> I say no. We should only take in a snapshot.
>
> If people want to see the history that was done elsewhere, they are free to
> maintain the old history outside. What happened before the ASF was
> involved is something we have no knowledge of and can't speak to. We can't
> be responsible for what happened before we were involved.
>
> By only taking in a snapshot, we create a clean break from a social and
> legal standpoint. All work from that point is done under our oversight
> mechanisms. We can operate in good faith that the snapshot we receive is
> in decent legal shape as we usually have a software grant for the bulk of
> that work. However, taking in complete source history that we have no
> knowledge of the oversight mechanisms that were in place is a bad thing in
> my opinion.
>
> There is a lesser point that taking in the author information from a
> separate project is awkward. This presents conflicts with our user account
> information and muddy things up if we ever have to do an audit. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 24 December 2005 06:26, Justin Erenkrantz wrote:
> However, I'm concerned with altering the perception that everything in our
> code repositories was done on our lists. Instead, we'll now be conveying
> all of the oddball things that happened externally - be it at codehaus,
> SourceForge, tigris.org, or wherever.
Just dump the history into a separate repo;
https://svn.apache.org/repos/imported
and then take the snapshot from there over to /repos/asf.
No confusion of what is what.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Leo Simons <ma...@leosimons.com>.
Hi gang,
I agree with Roy from a policy point of view. From a pragmatism point
of view I think the policy is "we SHOULD preserve history for existing
open source projects", but not a "MUST", because of the technical
difficulties (with SVN, no doubt solvable. With some other stuff (eg
bugzilla), less so).
I think for commercial projects, it'd be the ideal case that a commercial
party donates not just a code dump, but revision and development history
as well. Looking at OpenSolaris it is apparently sometimes possible to
retro-actively open source the "history" of a project too. I think in this
case its more a "MAY" than a "SHOULD" since there are a lot of "IF AND ONLY
IF"s.
cheers,
- Leo
On Fri, Dec 23, 2005 at 10:38:57PM -0800, Roy T. Fielding wrote:
> On Dec 23, 2005, at 2:26 PM, Justin Erenkrantz wrote:
>
> >--On December 23, 2005 1:33:34 PM -0800 "Roy T. Fielding"
> ><fi...@gbiv.com> wrote:
> >
> >>I disagree with Justin on these points. We must have a clean
> >>break when
> >>the code comes from a private source repository, since the history
> >>may
> >>contain information that has never been revealed to the public.
> >>
> >>However, when a public open source code base comes to the ASF, we can
> >>and should keep the full history. The history is already public, so
> >>the ASF cannot be responsible for making it public. Oversight is
> >>irrelevant here because the ASF is not responsible for any of the
> >>content within the history -- it is already public knowledge. I
> >>does,
> >>however, retain the author information, which is desired by us
> >>because
> >>it allows credit to remain where it is due and allows everyone to
> >>keep track of who needs to agree to the move.
> >
> >Is that a question of disclosure or responsibility?
>
> Both.
>
> >Is your argument predicated on the fact that the ASF assumes no
> >responsibility for the content of the imported history?
>
> No, that is a fact -- the ASF doesn't acquire responsibility for past
> acts simply by redistributing the code. The entire repository is
> simply licensed to us for redistribution.
>
> >Are we shielded if it turns out that older releases did bad legal
> >things that no longer apply to our code?
>
> Yes. We are not responsible, and in any case we only have a license.
>
> >Is it permissible to commit code to our repositories that were
> >under, say, GPL (for when a project, like SA, re-licenses)?
>
> Yes. Relicensing means the copyright owners offer a different set
> of terms for the same code -- they do not have to change the files
> for that to take effect.
>
> >To put my Roy hat(tm) on, I'll venture to guess that your response
> >will stem from the fact that the only cause for action is issuing a
> >release. Therefore, since we didn't release that old code (of which
> >we know nothing), it doesn't matter what we have in our code
> >repositories. Even if external committers didn't approve their
> >changes to be a Contribution to the ASF when the project transfers,
> >as long as we don't issue a release with that offending code, then
> >we're fine. Having items that are explicitly 'Not a Contribution'
> >are okay in our source control is fine as long as it doesn't get
> >released? In fact, it'd be in our best interest to have the public
> >history at our disposal so that we can trace the lineage as needed
> >for purity purposes.
> >
> >Am I close? If so, then yes, I understand your reasoning.
>
> Close enough. Also, if one of those people goes psychotic and tries
> to sue the ASF for copyright infringement, we merely point out that
> the publication in subversion is no different from the open source
> license that they originally published under.
>
> >However, I'm concerned with altering the perception that everything
> >in our code repositories was done on our lists. Instead, we'll now
> >be conveying all of the oddball things that happened externally -
> >be it at codehaus, SourceForge, tigris.org, or wherever.
>
> That's life. How much code under httpd "was done on our lists"?
> Probably more than any other project, yet I can still point to
> several thousand lines that were not.
>
> >>>There is a lesser point that taking in the author information from
> >>>a separate project is awkward. This presents conflicts with our
> >>>user account information and muddy things up if we ever have to do
> >>>an audit. -- justin
> >>
> >>Why don't we just run a script on the package before import, e.g.
> >>
> >> perl -pi -e 's/author/codehaus_author/g;' file
> >>
> >>for the case of codehaus usernames.
> >
> >Subversion will look for an svn:author revision property. We could
> >change the svn:author field in the dumps to be an asf:external-
> >contributor field or whatever and leave svn:author blank ("no
> >author"), but I'm not quite sure how I feel about that.
>
> I think you are missing the point. Apache traditionally has said that
> authors are given credit for their work within the changelog and
> version history. Removing the history from a previous open source
> project scrubs the credits for the original authors. At least one
> potential contributor finds that offensive.
>
> What I suggested was prefixing each author in the old dump with
> something to indicate that author name came from some other subversion
> or cvs namespace, thereby avoiding the conflict with our own names
> while still retaining credit for the original developers.
>
> ....Roy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 27, 2005, at 4:32 PM, Martin Cooper wrote:
> So what would it mean if Project Foo comes to the ASF, having
> released their 1.0 beforehand under the GPL, and then I grab the
> 1.0 code from the ASF repo and release that as my own version of
> the original 1.0?
Project Foo can only come to the ASF by licensing every bit of
copyrightable code and contributions within it under a software
grant, which in turn allows the ASF to relicense the entire thing
as Apache Licensed code.
> Can I release this new version under the Apache License, thereby
> effectively retroactively relicensing 1.0 under that license, or is
> that version still GPL, therefore meaning GPL code is checked into
> the ASF repo?
The copyright owners can non-exclusively license a work under as
many licenses as they wish.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Martin Cooper <ma...@apache.org>.
On Fri, 23 Dec 2005, Roy T. Fielding wrote:
> On Dec 23, 2005, at 2:26 PM, Justin Erenkrantz wrote:
<snip/>
>> Is it permissible to commit code to our repositories that were under, say,
>> GPL (for when a project, like SA, re-licenses)?
>
> Yes. Relicensing means the copyright owners offer a different set
> of terms for the same code -- they do not have to change the files
> for that to take effect.
So what would it mean if Project Foo comes to the ASF, having released
their 1.0 beforehand under the GPL, and then I grab the 1.0 code from the
ASF repo and release that as my own version of the original 1.0? Can I
release this new version under the Apache License, thereby effectively
retroactively relicensing 1.0 under that license, or is that version still
GPL, therefore meaning GPL code is checked into the ASF repo? I don't
really understand how this would work, but it seems kinda important.
--
Martin Cooper
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 23, 2005, at 2:26 PM, Justin Erenkrantz wrote:
> --On December 23, 2005 1:33:34 PM -0800 "Roy T. Fielding"
> <fi...@gbiv.com> wrote:
>
>> I disagree with Justin on these points. We must have a clean
>> break when
>> the code comes from a private source repository, since the history
>> may
>> contain information that has never been revealed to the public.
>>
>> However, when a public open source code base comes to the ASF, we can
>> and should keep the full history. The history is already public, so
>> the ASF cannot be responsible for making it public. Oversight is
>> irrelevant here because the ASF is not responsible for any of the
>> content within the history -- it is already public knowledge. I
>> does,
>> however, retain the author information, which is desired by us
>> because
>> it allows credit to remain where it is due and allows everyone to
>> keep track of who needs to agree to the move.
>
> Is that a question of disclosure or responsibility?
Both.
> Is your argument predicated on the fact that the ASF assumes no
> responsibility for the content of the imported history?
No, that is a fact -- the ASF doesn't acquire responsibility for past
acts simply by redistributing the code. The entire repository is
simply licensed to us for redistribution.
> Are we shielded if it turns out that older releases did bad legal
> things that no longer apply to our code?
Yes. We are not responsible, and in any case we only have a license.
> Is it permissible to commit code to our repositories that were
> under, say, GPL (for when a project, like SA, re-licenses)?
Yes. Relicensing means the copyright owners offer a different set
of terms for the same code -- they do not have to change the files
for that to take effect.
> To put my Roy hat(tm) on, I'll venture to guess that your response
> will stem from the fact that the only cause for action is issuing a
> release. Therefore, since we didn't release that old code (of which
> we know nothing), it doesn't matter what we have in our code
> repositories. Even if external committers didn't approve their
> changes to be a Contribution to the ASF when the project transfers,
> as long as we don't issue a release with that offending code, then
> we're fine. Having items that are explicitly 'Not a Contribution'
> are okay in our source control is fine as long as it doesn't get
> released? In fact, it'd be in our best interest to have the public
> history at our disposal so that we can trace the lineage as needed
> for purity purposes.
>
> Am I close? If so, then yes, I understand your reasoning.
Close enough. Also, if one of those people goes psychotic and tries
to sue the ASF for copyright infringement, we merely point out that
the publication in subversion is no different from the open source
license that they originally published under.
> However, I'm concerned with altering the perception that everything
> in our code repositories was done on our lists. Instead, we'll now
> be conveying all of the oddball things that happened externally -
> be it at codehaus, SourceForge, tigris.org, or wherever.
That's life. How much code under httpd "was done on our lists"?
Probably more than any other project, yet I can still point to
several thousand lines that were not.
>>> There is a lesser point that taking in the author information from
>>> a separate project is awkward. This presents conflicts with our
>>> user account information and muddy things up if we ever have to do
>>> an audit. -- justin
>>
>> Why don't we just run a script on the package before import, e.g.
>>
>> perl -pi -e 's/author/codehaus_author/g;' file
>>
>> for the case of codehaus usernames.
>
> Subversion will look for an svn:author revision property. We could
> change the svn:author field in the dumps to be an asf:external-
> contributor field or whatever and leave svn:author blank ("no
> author"), but I'm not quite sure how I feel about that.
I think you are missing the point. Apache traditionally has said that
authors are given credit for their work within the changelog and
version history. Removing the history from a previous open source
project scrubs the credits for the original authors. At least one
potential contributor finds that offensive.
What I suggested was prefixing each author in the old dump with
something to indicate that author name came from some other subversion
or cvs namespace, thereby avoiding the conflict with our own names
while still retaining credit for the original developers.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On December 23, 2005 1:33:34 PM -0800 "Roy T. Fielding"
<fi...@gbiv.com> wrote:
> I disagree with Justin on these points. We must have a clean break when
> the code comes from a private source repository, since the history may
> contain information that has never been revealed to the public.
>
> However, when a public open source code base comes to the ASF, we can
> and should keep the full history. The history is already public, so
> the ASF cannot be responsible for making it public. Oversight is
> irrelevant here because the ASF is not responsible for any of the
> content within the history -- it is already public knowledge. I does,
> however, retain the author information, which is desired by us because
> it allows credit to remain where it is due and allows everyone to
> keep track of who needs to agree to the move.
Is that a question of disclosure or responsibility? Is your argument
predicated on the fact that the ASF assumes no responsibility for the
content of the imported history? Are we shielded if it turns out that
older releases did bad legal things that no longer apply to our code? Is
it permissible to commit code to our repositories that were under, say, GPL
(for when a project, like SA, re-licenses)?
To put my Roy hat(tm) on, I'll venture to guess that your response will
stem from the fact that the only cause for action is issuing a release.
Therefore, since we didn't release that old code (of which we know
nothing), it doesn't matter what we have in our code repositories. Even if
external committers didn't approve their changes to be a Contribution to
the ASF when the project transfers, as long as we don't issue a release
with that offending code, then we're fine. Having items that are
explicitly 'Not a Contribution' are okay in our source control is fine as
long as it doesn't get released? In fact, it'd be in our best interest to
have the public history at our disposal so that we can trace the lineage as
needed for purity purposes.
Am I close? If so, then yes, I understand your reasoning.
However, I'm concerned with altering the perception that everything in our
code repositories was done on our lists. Instead, we'll now be conveying
all of the oddball things that happened externally - be it at codehaus,
SourceForge, tigris.org, or wherever.
>> There is a lesser point that taking in the author information from
>> a separate project is awkward. This presents conflicts with our
>> user account information and muddy things up if we ever have to do
>> an audit. -- justin
>
> Why don't we just run a script on the package before import, e.g.
>
> perl -pi -e 's/author/codehaus_author/g;' file
>
> for the case of codehaus usernames.
Subversion will look for an svn:author revision property. We could change
the svn:author field in the dumps to be an asf:external-contributor field
or whatever and leave svn:author blank ("no author"), but I'm not quite
sure how I feel about that.
It's a minor issue that could be resolved, I'm sure. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Henri Yandell <fl...@gmail.com>.
On 12/23/05, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Dec 23, 2005, at 10:31 AM, Justin Erenkrantz wrote:
>
> > --On December 23, 2005 1:15:44 PM -0500 "Geir Magnusson Jr."
> > <ge...@apache.org> wrote:
> >
> >> Sorry to change the subject...
> >>
> >> Can someone make a definitive statement on whether or not code
> >> history
> >> is brought into our repo from elsewhere when a podling brings
> >> code over?
> >
> > I say no. We should only take in a snapshot.
> >
> > If people want to see the history that was done elsewhere, they are
> > free to maintain the old history outside. What happened before the
> > ASF was involved is something we have no knowledge of and can't
> > speak to. We can't be responsible for what happened before we were
> > involved.
> >
> > By only taking in a snapshot, we create a clean break from a social
> > and legal standpoint. All work from that point is done under our
> > oversight mechanisms. We can operate in good faith that the
> > snapshot we receive is in decent legal shape as we usually have a
> > software grant for the bulk of that work. However, taking in
> > complete source history that we have no knowledge of the oversight
> > mechanisms that were in place is a bad thing in my opinion.
>
> I disagree with Justin on these points. We must have a clean break when
> the code comes from a private source repository, since the history may
> contain information that has never been revealed to the public.
What if the donator wants to bring in the full history? ie) they're
claiming that there is no danger in the information.
> However, when a public open source code base comes to the ASF, we can
> and should keep the full history.
Problems with bringing in a full history:
1) Seems it would confuse the code grant? I'm sure a judge would have
no clue, but I could easily see that someone donating code would
assume that a code grant is for their code today, and not every public
revision of their code.
2) Increases burden on Infrastructure.
3) Obstinate symmetry (ignoring technicalities) suggests we should
bring in the mailing list archives and the issue tracker too. Roller's
an interesting one on 3). We do want to bring in the issue tracker
(unsure if there are any legal problems, who owns copyright on bug
reports?) and when we bring the site over, it's a blog and I presume
we'll be bringing the history of the blog over.
Generally I think it should be done on a simplicity level. If a
migration of XXX-resource is simple (or the incoming project works to
make it simple), then there's no reason not to do it. If it's complex,
then they have a choice of starting from scratch or making it simple.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 23, 2005, at 10:31 AM, Justin Erenkrantz wrote:
> --On December 23, 2005 1:15:44 PM -0500 "Geir Magnusson Jr."
> <ge...@apache.org> wrote:
>
>> Sorry to change the subject...
>>
>> Can someone make a definitive statement on whether or not code
>> history
>> is brought into our repo from elsewhere when a podling brings
>> code over?
>
> I say no. We should only take in a snapshot.
>
> If people want to see the history that was done elsewhere, they are
> free to maintain the old history outside. What happened before the
> ASF was involved is something we have no knowledge of and can't
> speak to. We can't be responsible for what happened before we were
> involved.
>
> By only taking in a snapshot, we create a clean break from a social
> and legal standpoint. All work from that point is done under our
> oversight mechanisms. We can operate in good faith that the
> snapshot we receive is in decent legal shape as we usually have a
> software grant for the bulk of that work. However, taking in
> complete source history that we have no knowledge of the oversight
> mechanisms that were in place is a bad thing in my opinion.
I disagree with Justin on these points. We must have a clean break when
the code comes from a private source repository, since the history may
contain information that has never been revealed to the public.
However, when a public open source code base comes to the ASF, we can
and should keep the full history. The history is already public, so
the ASF cannot be responsible for making it public. Oversight is
irrelevant here because the ASF is not responsible for any of the
content within the history -- it is already public knowledge. I does,
however, retain the author information, which is desired by us because
it allows credit to remain where it is due and allows everyone to
keep track of who needs to agree to the move.
> There is a lesser point that taking in the author information from
> a separate project is awkward. This presents conflicts with our
> user account information and muddy things up if we ever have to do
> an audit. -- justin
Why don't we just run a script on the package before import, e.g.
perl -pi -e 's/author/codehaus_author/g;' file
for the case of codehaus usernames.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On December 23, 2005 1:15:44 PM -0500 "Geir Magnusson Jr."
<ge...@apache.org> wrote:
> Sorry to change the subject...
>
> Can someone make a definitive statement on whether or not code history
> is brought into our repo from elsewhere when a podling brings code over?
I say no. We should only take in a snapshot.
If people want to see the history that was done elsewhere, they are free to
maintain the old history outside. What happened before the ASF was
involved is something we have no knowledge of and can't speak to. We can't
be responsible for what happened before we were involved.
By only taking in a snapshot, we create a clean break from a social and
legal standpoint. All work from that point is done under our oversight
mechanisms. We can operate in good faith that the snapshot we receive is
in decent legal shape as we usually have a software grant for the bulk of
that work. However, taking in complete source history that we have no
knowledge of the oversight mechanisms that were in place is a bad thing in
my opinion.
There is a lesser point that taking in the author information from a
separate project is awkward. This presents conflicts with our user account
information and muddy things up if we ever have to do an audit. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Martin Sebor <se...@roguewave.com>.
Geir Magnusson Jr. wrote:
> Sorry to change the subject...
>
> Can someone make a definitive statement on whether or not code history
> is brought into our repo from elsewhere when a podling brings code over?
I can't make a definitive statement but stdcxx didn't (although
I would have liked it to). It seems that requiring all project
to do so could cause problems for commercial projects since the
logs might contain confidential information.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 1/6/06, Henri Yandell <fl...@gmail.com> wrote:
> On 1/4/06, Noel J. Bergman <no...@devtech.com> wrote:
> > > Can someone make a definitive statement on whether or not code
> > > history is brought into our repo from elsewhere when a podling
> > > brings code over?
> >
> > It is still being debated, so no. Roy's comments about import from private
> > vs public repositories may be a reasonable approach. Personally, I'm a
> > packrat. I'd keep everything possible. But I am not sure if we quite have
> > a consensus, yet. Close.
>
> I'm swayed. +1 on a policy of importing history whenever possible and
> desired by the incoming proposal.
>
> > I did talk with Garrett Rooney, and we can resolve the authorship namespace
> > problem, so we can take that particular technical issue off the table. The
> > imported author, which is held as a property, could be mangled to something
> > like IMPORTED_${PROJECT}_${AUTHOR} during the import, preventing collisions
> > with existing or future ASF Committers.
>
> +1. Probably not worth the extra work of trying to map to the existing
> committers or new committers.
Well, lets be clear, I said it was possible, not trivial. There'd
still be a need for someone to write some code (a new option to
svndumpfilter or something) to make it happen. Not difficult, but I
don't know of any existing code to do it.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Henri Yandell <fl...@gmail.com>.
On 1/4/06, Noel J. Bergman <no...@devtech.com> wrote:
> > Can someone make a definitive statement on whether or not code
> > history is brought into our repo from elsewhere when a podling
> > brings code over?
>
> It is still being debated, so no. Roy's comments about import from private
> vs public repositories may be a reasonable approach. Personally, I'm a
> packrat. I'd keep everything possible. But I am not sure if we quite have
> a consensus, yet. Close.
I'm swayed. +1 on a policy of importing history whenever possible and
desired by the incoming proposal.
> I did talk with Garrett Rooney, and we can resolve the authorship namespace
> problem, so we can take that particular technical issue off the table. The
> imported author, which is held as a property, could be mangled to something
> like IMPORTED_${PROJECT}_${AUTHOR} during the import, preventing collisions
> with existing or future ASF Committers.
+1. Probably not worth the extra work of trying to map to the existing
committers or new committers.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 04, 2006 at 06:21:28PM -0500, Noel J. Bergman wrote:
>...
> Roy, what happens if I have a codebase, and I have one file in it that
> imports or otherwise references third party GPL code, and I then delete my
> infected file? Do we have a concern about having that GPL infected code in
> SVN, even though it is dead?
The GPL and other licenses trigger at distribution time. Since you
aren't distributing the file, then you should be safe.
Of course, some people say that it is implicitly being distributed by
virtue of its availability in our source control. I find that an
extremely tenuous argument. Especially in your scenario, where the
thing has been deleted [and someone has to go back to a prev rev].
FWIW, +1 on keeping history.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [policy] bring in full code history on incubated project?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jan 4, 2006, at 3:21 PM, Noel J. Bergman wrote:
> Roy, what happens if I have a codebase, and I have one file in it that
> imports or otherwise references third party GPL code, and I then
> delete my
> infected file? Do we have a concern about having that GPL infected
> code in
> SVN, even though it is dead?
No, "infection" by GPL only applies to the act of redistribution
under terms that are not GPL compliant -- it is not a communicable
disease. Placing source code on a public subversion instance
is compliant with the GPL, so no worries.
There is a separate question about whether "imports or otherwise
references" by name is sufficient to cause a work to be derivative
(without distribution of the referenced work), which is not something
I want to get into again. FSF and Sun claim that it is sufficient.
Everyone else I've talked to says "no way". I don't know of any
precedent that has decided either way. IANAL, ETIDALOWFT.
[some folks are going to hate this analogy -- I don't care.]
GPL is not really a virus. GPL'd code is more like a genetic mutation
that is applied to cells, basically wherever the copyright owner says
the mutation applies. Copied cells retain the mutation if the original
had the mutation. The mutation isn't really malignant -- it doesn't
spread itself to other cells -- it simply prevents the entire organism
from reproducing until the entire organism has mutated.
The mutation can only be removed from a cell by its copyright owner.
That's why keeping track of the copyright owner of each cell is
very important. A "cell" is some amorphous quantity of work that
qualifies for copyright under international law.
The ASF can do anything GPL-compatible with GPL cells. The only thing
we can't do, really, is distribute them under a non-GPL license. That
means we can't produce released products containing those cells unless
the mutated cells are in source form by nature (e.g., shell scripts),
since doing so would confuse our users that expect a clean bill of
health from the products we release. They expect to be able to safely
incorporate our released products within their own closed-source
products without worrying about mutated cells slipping in by accident.
Similar mutations apply to all copyleft licenses. The real difference
among copyleft licenses is what qualifies as the "entire organism"
for the purpose of reproduction. MPL and CDDL define the organism
to be each individual source file. GPL defines the organism to be
anything linked to the mutation. LGPL defines it in multiple
incompatible ways that are just too confusing to mention.
Whether you consider this mutation to be a disease, or simply some
better form of life (a la X-Men), is largely dependent upon one's
personal PoV and ethical principles.
Regardless, you can eliminate the infection by carving out those
cells that have been mutated, assuming you can identify them, or
by getting a new license from the copyright owners.
Cheers,
Roy T. Fielding <http://roy.gbiv.com/>
Chief Scientist, Day Software <http://www.day.com/>
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: [policy] bring in full code history on incubated project?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jan 4, 2006, at 3:21 PM, Noel J. Bergman wrote:
> Roy, what happens if I have a codebase, and I have one file in it that
> imports or otherwise references third party GPL code, and I then
> delete my
> infected file? Do we have a concern about having that GPL infected
> code in
> SVN, even though it is dead?
No, "infection" by GPL only applies to the act of redistribution
under terms that are not GPL compliant -- it is not a communicable
disease. Placing source code on a public subversion instance
is compliant with the GPL, so no worries.
There is a separate question about whether "imports or otherwise
references" by name is sufficient to cause a work to be derivative
(without distribution of the referenced work), which is not something
I want to get into again. FSF and Sun claim that it is sufficient.
Everyone else I've talked to says "no way". I don't know of any
precedent that has decided either way. IANAL, ETIDALOWFT.
[some folks are going to hate this analogy -- I don't care.]
GPL is not really a virus. GPL'd code is more like a genetic mutation
that is applied to cells, basically wherever the copyright owner says
the mutation applies. Copied cells retain the mutation if the original
had the mutation. The mutation isn't really malignant -- it doesn't
spread itself to other cells -- it simply prevents the entire organism
from reproducing until the entire organism has mutated.
The mutation can only be removed from a cell by its copyright owner.
That's why keeping track of the copyright owner of each cell is
very important. A "cell" is some amorphous quantity of work that
qualifies for copyright under international law.
The ASF can do anything GPL-compatible with GPL cells. The only thing
we can't do, really, is distribute them under a non-GPL license. That
means we can't produce released products containing those cells unless
the mutated cells are in source form by nature (e.g., shell scripts),
since doing so would confuse our users that expect a clean bill of
health from the products we release. They expect to be able to safely
incorporate our released products within their own closed-source
products without worrying about mutated cells slipping in by accident.
Similar mutations apply to all copyleft licenses. The real difference
among copyleft licenses is what qualifies as the "entire organism"
for the purpose of reproduction. MPL and CDDL define the organism
to be each individual source file. GPL defines the organism to be
anything linked to the mutation. LGPL defines it in multiple
incompatible ways that are just too confusing to mention.
Whether you consider this mutation to be a disease, or simply some
better form of life (a la X-Men), is largely dependent upon one's
personal PoV and ethical principles.
Regardless, you can eliminate the infection by carving out those
cells that have been mutated, assuming you can identify them, or
by getting a new license from the copyright owners.
Cheers,
Roy T. Fielding <http://roy.gbiv.com/>
Chief Scientist, Day Software <http://www.day.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: [policy] bring in full code history on incubated project?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Can someone make a definitive statement on whether or not code
> history is brought into our repo from elsewhere when a podling
> brings code over?
It is still being debated, so no. Roy's comments about import from private
vs public repositories may be a reasonable approach. Personally, I'm a
packrat. I'd keep everything possible. But I am not sure if we quite have
a consensus, yet. Close.
Roy, what happens if I have a codebase, and I have one file in it that
imports or otherwise references third party GPL code, and I then delete my
infected file? Do we have a concern about having that GPL infected code in
SVN, even though it is dead?
I did talk with Garrett Rooney, and we can resolve the authorship namespace
problem, so we can take that particular technical issue off the table. The
imported author, which is held as a property, could be mangled to something
like IMPORTED_${PROJECT}_${AUTHOR} during the import, preventing collisions
with existing or future ASF Committers.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org