You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2005/12/13 16:08:42 UTC
Need advice on accepting a particular patch
I need some advice. Here's the situation: About two years ago, a FOP
committer went away and forked the old maintenance branch (ALv1.1) into
a SourceForge project called FOray. FOray is now published under the
ALv2.0. Now, a contributor has taken code from FOray that fixes a
long-standing problem in FOP, has adapted it to the FOP's maintenance
branch and then to the latest FOP Trunk and then submitted it as a patch
[1] for inclusion in FOP. One of the files in the patch would be a new
file for FOP trunk, includes the ALv1.1 license header and is clearly
derived from [2].
[1] Patch:
http://issues.apache.org/bugzilla/attachment.cgi?id=17203
[2] Original file:
http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-pdf/src/java/org/foray/pdf/object/PDFToUnicodeCMap.java?view=markup
I can't just accept this contribution without the approval of the FOray
author, can I? It's probably also irrelevant that the FOray author has
an ICLA on file with the ASF (being a inactive committer).
Any suggestions how to proceed?
Thanks a lot,
Jeremias Maerki
---------------------------------------------------------------------
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: Need advice on accepting a particular patch
Posted by Martin van den Bemt <mv...@apache.org>.
Maybe asking on incubator, since they handle these kind of issues..
Mvgr,
Martin
Jeremias Maerki wrote:
> No guidance here? Anyone? I'm actually having a second issue of more or
> less the same. Only this second issue is actually more important since
> it can supercede the first one.
>
> Situation again:
> - Former FOP committer (ICLA on file) forks FOP (ALv2).
> - Makes modifications to the fork and adds new files (still ALv2).
> - Contributor (ICLA soon on file) creates a patch that will use a
> (font) library that evolved from that FOP fork but also contains a file
> created by the former committer (with his informal permission).
>
> My best guess:
> - Contributor must have an ICLA on file.
> - Former FOP committer needs to do a formal license grant for the parts
> that were not done by the contributor.
>
> Correct? A lot of pain to go through.
>
> Of course, we could just as well simply apply the code with the informal
> approval by the former committer (via mail) by claiming that it would go
> under the former committer's ICLA. That would be easier, but would it be
> enough?
>
> Please bear with me. I just want to do it right. Thanks!
>
> On 13.12.2005 16:08:42 Jeremias Maerki wrote:
>
>>I need some advice. Here's the situation: About two years ago, a FOP
>>committer went away and forked the old maintenance branch (ALv1.1) into
>>a SourceForge project called FOray. FOray is now published under the
>>ALv2.0. Now, a contributor has taken code from FOray that fixes a
>>long-standing problem in FOP, has adapted it to the FOP's maintenance
>>branch and then to the latest FOP Trunk and then submitted it as a patch
>>[1] for inclusion in FOP. One of the files in the patch would be a new
>>file for FOP trunk, includes the ALv1.1 license header and is clearly
>>derived from [2].
>>
>>[1] Patch:
>>http://issues.apache.org/bugzilla/attachment.cgi?id=17203
>>
>>[2] Original file:
>>http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-pdf/src/java/org/foray/pdf/object/PDFToUnicodeCMap.java?view=markup
>>
>>I can't just accept this contribution without the approval of the FOray
>>author, can I? It's probably also irrelevant that the FOray author has
>>an ICLA on file with the ASF (being a inactive committer).
>>
>>Any suggestions how to proceed?
>>
>>
>>Thanks a lot,
>>Jeremias Maerki
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
---------------------------------------------------------------------
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: Need advice on accepting a particular patch
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
No guidance here? Anyone? I'm actually having a second issue of more or
less the same. Only this second issue is actually more important since
it can supercede the first one.
Situation again:
- Former FOP committer (ICLA on file) forks FOP (ALv2).
- Makes modifications to the fork and adds new files (still ALv2).
- Contributor (ICLA soon on file) creates a patch that will use a
(font) library that evolved from that FOP fork but also contains a file
created by the former committer (with his informal permission).
My best guess:
- Contributor must have an ICLA on file.
- Former FOP committer needs to do a formal license grant for the parts
that were not done by the contributor.
Correct? A lot of pain to go through.
Of course, we could just as well simply apply the code with the informal
approval by the former committer (via mail) by claiming that it would go
under the former committer's ICLA. That would be easier, but would it be
enough?
Please bear with me. I just want to do it right. Thanks!
On 13.12.2005 16:08:42 Jeremias Maerki wrote:
> I need some advice. Here's the situation: About two years ago, a FOP
> committer went away and forked the old maintenance branch (ALv1.1) into
> a SourceForge project called FOray. FOray is now published under the
> ALv2.0. Now, a contributor has taken code from FOray that fixes a
> long-standing problem in FOP, has adapted it to the FOP's maintenance
> branch and then to the latest FOP Trunk and then submitted it as a patch
> [1] for inclusion in FOP. One of the files in the patch would be a new
> file for FOP trunk, includes the ALv1.1 license header and is clearly
> derived from [2].
>
> [1] Patch:
> http://issues.apache.org/bugzilla/attachment.cgi?id=17203
>
> [2] Original file:
> http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-pdf/src/java/org/foray/pdf/object/PDFToUnicodeCMap.java?view=markup
>
> I can't just accept this contribution without the approval of the FOray
> author, can I? It's probably also irrelevant that the FOray author has
> an ICLA on file with the ASF (being a inactive committer).
>
> Any suggestions how to proceed?
>
>
> Thanks a lot,
> Jeremias Maerki
Jeremias Maerki
---------------------------------------------------------------------
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: Need advice on accepting a particular patch
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Thanks for all the answers so far, everyone!
On 23.12.2005 10:19:10 Niclas Hedhman wrote:
> On Tuesday 20 December 2005 09:43, Noel J. Bergman wrote:
>
> > You can doublecheck with Cliff, but since the thing is published under
> > ALv2, I believe that yes, you can use the code.
>
> The scenario painted involves making the code part of the ASF maintained
> codebase. Why would this case be any different from adding a whole ALv2
> licensed library of code into a project, which AFAICT requires vetting and
> other processes thorugh the Incubator?
I thought some more about this. I think it depends whether we're talking
about source code (as in this example) or just an external library
(binary). Until recently, I was under the impression that source (!) code
that does not contain the ASF ALv2 header is not supposed to be in the
ASF's repository. But there are W3C-licensed sources in XML Commons
Externals and Apache Batik (the latter will move to the former before
its next release). And I recently learned that HTTPD contains several
classes that are not bearing the ASF ALv2 header. I think it was mainly
the Java land here in the ASF where non-ASF-owned code was not supposed to
be placed in SVN. Or at least that's what I thought the whole time. XML
Commons Externals was some kind of an exception, but at least it is
carefully separated from other packages. Then I realized we had similar
W3C licensed sources in Batik...
Anyway, for the Java world it's relatively easy to simply work with
binaries (JAR files) to handle external code, although it wouldn't work
in my particular case here. For C/C++ programs this is a lot more
complicated because there are no portable binaries (unless it's managed
.NET code).
So, Noel seems to suggest to go down the route HTTPD has taken.
> To me, it seems that the legal requirements are not clear enough and we try to
> be pragmatic about it. This leads to a "soft environment" that is up to
> interpretation.
> Jeremias is probably expressing that programmers like solid rules and expected
> behaviours around themselves.
Yes. The recent survey Cliff sent to the PMCs was very highly
appreciated (at least by me) because it shows that steps in the right
direction are underway.
Jeremias Maerki
---------------------------------------------------------------------
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: Need advice on accepting a particular patch
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 20 December 2005 09:43, Noel J. Bergman wrote:
> You can doublecheck with Cliff, but since the thing is published under
> ALv2, I believe that yes, you can use the code.
The scenario painted involves making the code part of the ASF maintained
codebase. Why would this case be any different from adding a whole ALv2
licensed library of code into a project, which AFAICT requires vetting and
other processes thorugh the Incubator?
To me, it seems that the legal requirements are not clear enough and we try to
be pragmatic about it. This leads to a "soft environment" that is up to
interpretation.
Jeremias is probably expressing that programmers like solid rules and expected
behaviours around themselves.
Cheers
Niclas
---------------------------------------------------------------------
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: Need advice on accepting a particular patch
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jeremias Maerki wrote:
> a FOP committer went away and forked the old maintenance branch
> [that fork] is now published under the ALv2.0.
> a contributor has taken code from [that fork] that fixes a
> long-standing problem in FOP, [and] submitted it as a patch
> One of the files in the patch would be a new file for FOP trunk,
> includes the ALv1.1 license header and is clearly derived from [2].
> [1] http://issues.apache.org/bugzilla/attachment.cgi?id=17203
> [2]
http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-pdf/src/java/org/for
ay/pdf/object/PDFToUnicodeCMap.java?view=markup
> I can't just accept this contribution without the approval of the
> FOray author, can I?
You can doublecheck with Cliff, but since the thing is published under ALv2,
I believe that yes, you can use the code.
--- Noel
---------------------------------------------------------------------
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