You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Doug Judd <do...@zvents.com> on 2009/10/08 22:51:16 UTC
patch for solaris
I had to apply the following patch to get thrift to compile on Solaris.
- Doug
Index: configure.ac
===================================================================
--- configure.ac (revision 820547)
+++ configure.ac (working copy)
@@ -142,6 +142,7 @@
dnl of the POSIX Real-Time Extensions. This seems necessary on Linux,
dnl and we haven't yet found a system where this is a problem.
AC_CHECK_LIB(rt, clock_gettime)
+AC_CHECK_LIB(socket, setsockopt)
AC_TYPE_INT16_T
AC_TYPE_INT32_T
Index: lib/cpp/src/protocol/TProtocol.h
===================================================================
--- lib/cpp/src/protocol/TProtocol.h (revision 820547)
+++ lib/cpp/src/protocol/TProtocol.h (working copy)
@@ -86,7 +86,10 @@
# define __LITTLE_ENDIAN LITTLE_ENDIAN
# define __BIG_ENDIAN BIG_ENDIAN
# else
-# error "Cannot determine endianness"
+#include <boost/config.hpp>
+# define __BYTE_ORDER BOOST_BYTE_ORDER
+# define __LITTLE_ENDIAN BOOST_LITTLE_ENDIAN
+# define __BIG_ENDIAN BOOST_BIG_ENDIAN
# endif
#endif
Index: lib/cpp/src/server/TNonblockingServer.cpp
===================================================================
--- lib/cpp/src/server/TNonblockingServer.cpp (revision 820547)
+++ lib/cpp/src/server/TNonblockingServer.cpp (working copy)
@@ -29,6 +29,10 @@
#include <errno.h>
#include <assert.h>
+#ifndef AF_LOCAL
+#define AF_LOCAL AF_UNIX
+#endif
+
namespace apache { namespace thrift { namespace server {
using namespace apache::thrift::protocol;
Index: lib/cpp/src/transport/TServerSocket.cpp
===================================================================
--- lib/cpp/src/transport/TServerSocket.cpp (revision 820547)
+++ lib/cpp/src/transport/TServerSocket.cpp (working copy)
@@ -33,6 +33,10 @@
#include "TServerSocket.h"
#include <boost/shared_ptr.hpp>
+#ifndef AF_LOCAL
+#define AF_LOCAL AF_UNIX
+#endif
+
namespace apache { namespace thrift { namespace transport {
using namespace std;
Re: patch for solaris
Posted by Doug Judd <nu...@gmail.com>.
Hi Chad,
Thanks for the response. I've gone ahead and created Thrift JIRA 606 to
track it.
- Doug
On Wed, Oct 14, 2009 at 12:55 PM, Chad Walters
<Ch...@microsoft.com>wrote:
> Doug,
>
> Please put this as a patch file in a JIRA -- code that is just sent to the
> mailing list has murky status WRT license issues, while code entered in JIRA
> is clearly licensed. Plus it will get tracked better if it is in JIRA.
>
> Chad
>
> -----Original Message-----
> From: nuggetwheat@gmail.com [mailto:nuggetwheat@gmail.com] On Behalf Of
> Doug Judd
> Sent: Thursday, October 08, 2009 1:51 PM
> To: thrift-dev@incubator.apache.org
> Subject: patch for solaris
>
> I had to apply the following patch to get thrift to compile on Solaris.
>
> - Doug
>
> Index: configure.ac
> ===================================================================
> --- configure.ac (revision 820547)
> +++ configure.ac (working copy)
> @@ -142,6 +142,7 @@
> dnl of the POSIX Real-Time Extensions. This seems necessary on Linux,
> dnl and we haven't yet found a system where this is a problem.
> AC_CHECK_LIB(rt, clock_gettime)
> +AC_CHECK_LIB(socket, setsockopt)
>
> AC_TYPE_INT16_T
> AC_TYPE_INT32_T
> Index: lib/cpp/src/protocol/TProtocol.h
> ===================================================================
> --- lib/cpp/src/protocol/TProtocol.h (revision 820547)
> +++ lib/cpp/src/protocol/TProtocol.h (working copy)
> @@ -86,7 +86,10 @@
> # define __LITTLE_ENDIAN LITTLE_ENDIAN
> # define __BIG_ENDIAN BIG_ENDIAN
> # else
> -# error "Cannot determine endianness"
> +#include <boost/config.hpp>
> +# define __BYTE_ORDER BOOST_BYTE_ORDER
> +# define __LITTLE_ENDIAN BOOST_LITTLE_ENDIAN
> +# define __BIG_ENDIAN BOOST_BIG_ENDIAN
> # endif
> #endif
>
> Index: lib/cpp/src/server/TNonblockingServer.cpp
> ===================================================================
> --- lib/cpp/src/server/TNonblockingServer.cpp (revision 820547)
> +++ lib/cpp/src/server/TNonblockingServer.cpp (working copy)
> @@ -29,6 +29,10 @@
> #include <errno.h>
> #include <assert.h>
>
> +#ifndef AF_LOCAL
> +#define AF_LOCAL AF_UNIX
> +#endif
> +
> namespace apache { namespace thrift { namespace server {
>
> using namespace apache::thrift::protocol;
> Index: lib/cpp/src/transport/TServerSocket.cpp
> ===================================================================
> --- lib/cpp/src/transport/TServerSocket.cpp (revision 820547)
> +++ lib/cpp/src/transport/TServerSocket.cpp (working copy)
> @@ -33,6 +33,10 @@
> #include "TServerSocket.h"
> #include <boost/shared_ptr.hpp>
>
> +#ifndef AF_LOCAL
> +#define AF_LOCAL AF_UNIX
> +#endif
> +
> namespace apache { namespace thrift { namespace transport {
>
> using namespace std;
>
RE: patch for solaris
Posted by Chad Walters <Ch...@microsoft.com>.
Thanks for the clarification -- somehow that meme has taken hold of me (previous traffic on this list?).
In any case, adding a JIRA will help with tracking!
Chad
-----Original Message-----
From: Joe Schaefer [mailto:joe_schaefer@yahoo.com]
Sent: Wednesday, October 14, 2009 1:14 PM
To: thrift-dev@incubator.apache.org; nuggetwheat@gmail.com
Subject: Re: patch for solaris
----- Original Message ----
> From: Chad Walters <Ch...@microsoft.com>
> To: "thrift-dev@incubator.apache.org" <th...@incubator.apache.org>; "nuggetwheat@gmail.com" <nu...@gmail.com>
> Sent: Wed, October 14, 2009 3:55:36 PM
> Subject: RE: patch for solaris
>
> Doug,
>
> Please put this as a patch file in a JIRA -- code that is just sent to the
> mailing list has murky status WRT license issues, while code entered in JIRA is
> clearly licensed.
100% not true. There's nothing wrong with the license status of a patch
submitted to the mailing list. I don't know where this misunderstanding
comes from but it needs to be put to rest- simply read the Apache License
and you'll see that patches submitted to a mailing list are covered
contributions. The JIRA checkbox is an appendage that makes it convenient
to opt-out of the license. It is by no means an essential element.
> Plus it will get tracked better if it is in JIRA.
Maybe so.
Re: patch for solaris
Posted by Kevin Clark <ke...@gmail.com>.
On Wed, Oct 28, 2009 at 10:28 AM, Todd Lipcon <to...@cloudera.com> wrote:
> On Wed, Oct 28, 2009 at 9:56 AM, David Reiss <dr...@facebook.com> wrote:
>
>> >> My concern is that we never asked contributors to explicitly agree to
>> >> the Thrift License.
>> >
>> > Would it be reasonable to assume that they implicitly agreed to it?
>> I don't know.
>>
>
> As someone who contributed some code pre-incubator I feel like I implicitly
> agreed to it. I think that's the general understanding with open source - if
> you contribute a patch to code that has a LICENSE file, you're saying you're
> OK with your code being under that license unless you specify otherwise.
>
> -Todd
>
I also contributed pre-apache and agree.
--
Kevin Clark
http://glu.ttono.us
Re: patch for solaris
Posted by Todd Lipcon <to...@cloudera.com>.
On Wed, Oct 28, 2009 at 9:56 AM, David Reiss <dr...@facebook.com> wrote:
> >> My concern is that we never asked contributors to explicitly agree to
> >> the Thrift License.
> >
> > Would it be reasonable to assume that they implicitly agreed to it?
> I don't know.
>
As someone who contributed some code pre-incubator I feel like I implicitly
agreed to it. I think that's the general understanding with open source - if
you contribute a patch to code that has a LICENSE file, you're saying you're
OK with your code being under that license unless you specify otherwise.
-Todd
Re: patch for solaris
Posted by Todd Lipcon <to...@cloudera.com>.
On Wed, Oct 28, 2009 at 9:34 AM, Doug Cutting <cu...@apache.org> wrote:
> David Reiss wrote:
>
>> My concern is that we never asked contributors to explicitly agree to
>>>> the Thrift License.
>>>>
>>> Would it be reasonable to assume that they implicitly agreed to it?
>>>
>> I don't know.
>>
>
> Does Facebook distribute these contributions under the Thrift license? If
> so, then Facebook already assumes the contributors agreed to that license.
> Does Facebook distribute these contributions with "Copyright (c) Facebook"?
> If so, then Facebook already claims that copyright assignment was made.
>
>
Looks like there is an svn snapshot tarball available from
http://developers.facebook.com/thrift/ from 3/30/09. This is post-incubator
but the tarball still has some files that say copyright by Facebook. Many of
the source files show no copyright whatsoever in that tarball.
I'm inclined to say, based on my understanding of the questions involved,
that all contributions were made with the understanding that it would be
released under the license in the COPYING or LICENSE files at the time. For
all of history this has either been Thrift Software License (essentially BSD
or MIT) or the Apache license itself, and thus should be compatible. The
copyrights may not be completely assigned, but as long as we can go through
the source and make a list of what things are copyright ASF and what things
are copyright other organizations, we are OK to release an 0.1, yes? We can
then spend some time post-release to go through and get copyright reassigned
by the original authors where possible, if that's a goal of ASF.
-Todd
Re: Thrift Licensing
Posted by Joe Schaefer <jo...@yahoo.com>.
emailing them to secretary@ is fine, you can even GPG-sign
them if you don't wanna attach a pdf.
----- Original Message ----
> From: Kevin Clark <ke...@gmail.com>
> To: thrift-dev@incubator.apache.org
> Cc: Joe Schaefer <jo...@yahoo.com>
> Sent: Wed, October 28, 2009 3:18:37 PM
> Subject: Re: Thrift Licensing
>
> I'm not sure, William Morgan had asked about it, and I think Joe
> Schaefer had the answer. I'm CCing him.
>
> On Wed, Oct 28, 2009 at 11:28 AM, David Reiss wrote:
> > I'm happy to ask. What is the address?
> >
> > Kevin Clark wrote:
> >> On Wed, Oct 28, 2009 at 11:08 AM, David Reiss wrote:
> >>> I just talked to some of the guys from imeem, and they said that
> >>> they sent in all of the documents, but the ICLAs are not on file.
> >>> Can someone confirm that +1-919-573-9199 (from
> >>> http://www.apache.org/licenses/cla-corporate.txt r190612) is the best
> >>> fax number before I ask them to resend it?
> >>>
> >>> --David
> >>
> >> Can they email them in? Documents faxed in have been lost many many
> >> times at this point.
> >>
> >
>
>
>
> --
> Kevin Clark
> http://glu.ttono.us
Re: Thrift Licensing
Posted by Kevin Clark <ke...@gmail.com>.
I'm not sure, William Morgan had asked about it, and I think Joe
Schaefer had the answer. I'm CCing him.
On Wed, Oct 28, 2009 at 11:28 AM, David Reiss <dr...@facebook.com> wrote:
> I'm happy to ask. What is the address?
>
> Kevin Clark wrote:
>> On Wed, Oct 28, 2009 at 11:08 AM, David Reiss <dr...@facebook.com> wrote:
>>> I just talked to some of the guys from imeem, and they said that
>>> they sent in all of the documents, but the ICLAs are not on file.
>>> Can someone confirm that +1-919-573-9199 (from
>>> http://www.apache.org/licenses/cla-corporate.txt r190612) is the best
>>> fax number before I ask them to resend it?
>>>
>>> --David
>>
>> Can they email them in? Documents faxed in have been lost many many
>> times at this point.
>>
>
--
Kevin Clark
http://glu.ttono.us
Re: Thrift Licensing
Posted by David Reiss <dr...@facebook.com>.
I'm happy to ask. What is the address?
Kevin Clark wrote:
> On Wed, Oct 28, 2009 at 11:08 AM, David Reiss <dr...@facebook.com> wrote:
>> I just talked to some of the guys from imeem, and they said that
>> they sent in all of the documents, but the ICLAs are not on file.
>> Can someone confirm that +1-919-573-9199 (from
>> http://www.apache.org/licenses/cla-corporate.txt r190612) is the best
>> fax number before I ask them to resend it?
>>
>> --David
>
> Can they email them in? Documents faxed in have been lost many many
> times at this point.
>
Re: Thrift Licensing
Posted by Kevin Clark <ke...@gmail.com>.
On Wed, Oct 28, 2009 at 11:08 AM, David Reiss <dr...@facebook.com> wrote:
> I just talked to some of the guys from imeem, and they said that
> they sent in all of the documents, but the ICLAs are not on file.
> Can someone confirm that +1-919-573-9199 (from
> http://www.apache.org/licenses/cla-corporate.txt r190612) is the best
> fax number before I ask them to resend it?
>
> --David
Can they email them in? Documents faxed in have been lost many many
times at this point.
--
Kevin Clark
http://glu.ttono.us
Re: Thrift Licensing
Posted by David Reiss <dr...@facebook.com>.
I just talked to some of the guys from imeem, and they said that
they sent in all of the documents, but the ICLAs are not on file.
Can someone confirm that +1-919-573-9199 (from
http://www.apache.org/licenses/cla-corporate.txt r190612) is the best
fax number before I ask them to resend it?
--David
David Reiss wrote:
> Does anyone know if there is a list of CCLAs on file for the ASF?
> I'm going through some of our old correspondences, and it seems like
> some of the groups might have sent in CCLAs with software grants but
> not ICLAs.
>
> --David
Thrift Licensing (was: patch for solaris)
Posted by David Reiss <dr...@facebook.com>.
Does anyone know if there is a list of CCLAs on file for the ASF?
I'm going through some of our old correspondences, and it seems like
some of the groups might have sent in CCLAs with software grants but
not ICLAs.
--David
Re: patch for solaris
Posted by David Reiss <dr...@facebook.com>.
Maybe we should stop doing that, then.
Doug Cutting wrote:
> David Reiss wrote:
>>>> My concern is that we never asked contributors to explicitly agree to
>>>> the Thrift License.
>>> Would it be reasonable to assume that they implicitly agreed to it?
>> I don't know.
>
> Does Facebook distribute these contributions under the Thrift license?
> If so, then Facebook already assumes the contributors agreed to that
> license. Does Facebook distribute these contributions with "Copyright
> (c) Facebook"? If so, then Facebook already claims that copyright
> assignment was made.
>
> Doug
Re: patch for solaris
Posted by Doug Cutting <cu...@apache.org>.
David Reiss wrote:
>>> My concern is that we never asked contributors to explicitly agree to
>>> the Thrift License.
>> Would it be reasonable to assume that they implicitly agreed to it?
> I don't know.
Does Facebook distribute these contributions under the Thrift license?
If so, then Facebook already assumes the contributors agreed to that
license. Does Facebook distribute these contributions with "Copyright
(c) Facebook"? If so, then Facebook already claims that copyright
assignment was made.
Doug
Re: patch for solaris
Posted by David Reiss <dr...@facebook.com>.
>> My concern is that we never asked contributors to explicitly agree to
>> the Thrift License.
>
> Would it be reasonable to assume that they implicitly agreed to it?
I don't know.
Re: patch for solaris
Posted by Doug Cutting <cu...@apache.org>.
David Reiss wrote:
> My concern is that we never asked contributors to explicitly agree to
> the Thrift License.
Would it be reasonable to assume that they implicitly agreed to it? If
they knew that Thrift was distributed under that license, and made
contributions with the expectation that they would be distributed under
that license, then that seems like a strongly implied intent to
distribute their additions under that license, no?
In any case, the code in question is currently distributed by Facebook
under the Thrift license. We either need someone to claim ownership of
that code to permit us to change its license, or we should redistribute
under that license.
Doug
Re: patch for solaris
Posted by David Reiss <dr...@facebook.com>.
My concern is that we never asked contributors to explicitly agree to
the Thrift License.
Todd Lipcon wrote:
> Latest word from Doug is that we don't need ICLAs for contributions that
> were pre-incubator so long as we have a notice that calls out those
> contributions and points out that they are not under the Apache license. As
> long as the previous open source license is Apache-compatible this is
> supposed to be OK. Looking back at the history, the original license was:
>
> +Thrift Software License
> +Copyright (c) 2006- Facebook, Inc.
> +
> +Permission is hereby granted, free of charge, to any person or organization
> +obtaining a copy of the software and accompanying documentation covered by
> +this license (the "Software") to use, reproduce, display, distribute,
> +execute, and transmit the Software, and to prepare derivative works of the
> +Software, and to permit third-parties to whom the Software is furnished to
> +do so, all subject to the following:
> +
> +The copyright notices in the Software and this entire statement, including
> +the above license grant, this restriction and the following disclaimer,
> +must be included in all copies of the Software, in whole or in part, and
> +all derivative works of the Software, unless such copies or derivative
> +works are solely in the form of machine-executable object code generated by
> +a source language processor.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
> +SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
> +FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
> +ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
>
> Looks like BSD license, which should be compatible.
>
> Does anyone know otherwise?
>
> -Todd
>
> On Sun, Oct 25, 2009 at 8:39 PM, Kevin Clark <ke...@gmail.com> wrote:
>
>> On Sun, Oct 25, 2009 at 1:46 PM, Chad Walters
>> <Ch...@microsoft.com> wrote:
>>>> You could always ask the person if you're concerned about it,
>>>> but the simplest way to resolve this is to start cutting Apache
>>>> releases ;-).
>>> What is the current blocker for making a release, anyway?
>> Afaik it was that someone decided we need to solicit ICLAs again. Again.
>>
>>
>> --
>> Kevin Clark
>> http://glu.ttono.us
>>
Re: patch for solaris
Posted by Todd Lipcon <to...@cloudera.com>.
Latest word from Doug is that we don't need ICLAs for contributions that
were pre-incubator so long as we have a notice that calls out those
contributions and points out that they are not under the Apache license. As
long as the previous open source license is Apache-compatible this is
supposed to be OK. Looking back at the history, the original license was:
+Thrift Software License
+Copyright (c) 2006- Facebook, Inc.
+
+Permission is hereby granted, free of charge, to any person or organization
+obtaining a copy of the software and accompanying documentation covered by
+this license (the "Software") to use, reproduce, display, distribute,
+execute, and transmit the Software, and to prepare derivative works of the
+Software, and to permit third-parties to whom the Software is furnished to
+do so, all subject to the following:
+
+The copyright notices in the Software and this entire statement, including
+the above license grant, this restriction and the following disclaimer,
+must be included in all copies of the Software, in whole or in part, and
+all derivative works of the Software, unless such copies or derivative
+works are solely in the form of machine-executable object code generated by
+a source language processor.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
+SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
+FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
+ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
Looks like BSD license, which should be compatible.
Does anyone know otherwise?
-Todd
On Sun, Oct 25, 2009 at 8:39 PM, Kevin Clark <ke...@gmail.com> wrote:
> On Sun, Oct 25, 2009 at 1:46 PM, Chad Walters
> <Ch...@microsoft.com> wrote:
> >>You could always ask the person if you're concerned about it,
> >>but the simplest way to resolve this is to start cutting Apache
> >>releases ;-).
> >
> > What is the current blocker for making a release, anyway?
>
> Afaik it was that someone decided we need to solicit ICLAs again. Again.
>
>
> --
> Kevin Clark
> http://glu.ttono.us
>
Re: patch for solaris
Posted by Kevin Clark <ke...@gmail.com>.
On Sun, Oct 25, 2009 at 1:46 PM, Chad Walters
<Ch...@microsoft.com> wrote:
>>You could always ask the person if you're concerned about it,
>>but the simplest way to resolve this is to start cutting Apache
>>releases ;-).
>
> What is the current blocker for making a release, anyway?
Afaik it was that someone decided we need to solicit ICLAs again. Again.
--
Kevin Clark
http://glu.ttono.us
Re: patch for solaris
Posted by "Rob S." <rs...@sfu.ca>.
Just joking my man, referring to this:
http://issues.apache.org/jira/browse/THRIFT-363
Rob
On Oct 15, 2009, at 8:44 PM, David Reiss wrote:
> I don't understand how either of these is related to licensing.
>
> Rob S. wrote:
>>> You could always ask the person if you're concerned about it,
>>> but the simplest way to resolve this is to start cutting Apache
>>> releases ;-).
>>
>> And publishing them at the Maven repo! ;)
>>
>> Rob
>>
Re: patch for solaris
Posted by David Reiss <dr...@facebook.com>.
I don't understand how either of these is related to licensing.
Rob S. wrote:
>> You could always ask the person if you're concerned about it,
>> but the simplest way to resolve this is to start cutting Apache
>> releases ;-).
>
> And publishing them at the Maven repo! ;)
>
> Rob
>
Re: patch for solaris
Posted by "Rob S." <rs...@sfu.ca>.
> You could always ask the person if you're concerned about it,
> but the simplest way to resolve this is to start cutting Apache
> releases ;-).
And publishing them at the Maven repo! ;)
Rob
RE: patch for solaris
Posted by Chad Walters <Ch...@microsoft.com>.
>You could always ask the person if you're concerned about it,
>but the simplest way to resolve this is to start cutting Apache
>releases ;-).
What is the current blocker for making a release, anyway?
Chad
Re: patch for solaris
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Reiss <dr...@facebook.com>
> To: "thrift-dev@incubator.apache.org" <th...@incubator.apache.org>
> Sent: Thu, October 15, 2009 8:29:03 PM
> Subject: Re: patch for solaris
>
> I'm not talking about contributions that were made before Thrift moved
> into the Incubator. I'm talking about new patches from people who might
> say that the patch is a derivative work of the original permissively
> licensed Thrift, not the newer Apache Licensed version.
Licensing issues aside, the principle that Apache operates on is
*voluntary* contributions. If someone offers a patch to this mailing
list, it gets included, and the person later changes their mind about
the contribution, the courteous thing to do is to pull their contribution,
even if you think the person has no legal grounds to stand on.
You could always ask the person if you're concerned about it,
but the simplest way to resolve this is to start cutting Apache releases ;-).
>
> --David
>
> Joe Schaefer wrote:
> > ----- Original Message ----
> >
> >> From: David Reiss
> >> To: "thrift-dev@incubator.apache.org"
> >> Sent: Thu, October 15, 2009 7:27:44 PM
> >> Subject: Re: patch for solaris
> >>
> >>> Read the Apache License 2.0, particularly the section defining a
> Contribution.
> >> I just did, which is why I asked the question.
> >>
> >>>> Is the assumption that sending the patch to a mailing list is an
> >>>> implicit license grant?
> >>> Open source at Apache has always operated under this principle as well,
> >>> even before we migrated to the 2.0 License. The 2.0 License however
> >>> makes the grant explicit- you can't post a patch of our software to
> >>> our mailing lists without complying with the terms of the license-
> >>> you have no other right to do that because a patch is a derivative work.
> >> Ah. That makes sense.
> >>
> >> What about a project like Thrift that was previously distributed under
> >> a more permissive license? Could the patch poster claim that they
> >> patch was a derivative work of the permissive-licensed version of Thrift
> >> and therefore not subject to the terms of the Apache License? (Obviously,
> >> this assumes that the patch is equally relevant to the old version.)
> >
> > This is the whole reason we sought CLAs from contributors to Thrift prior
> > to its entrance at Apache. Nothing gives us the right to relicense their
> > MIT-based contributions other than some explicit agreement to the contrary,
> > like a CLA.
> >
> > There are two working theories in open source regarding project relicensing.
> > One theory, which is commonly held, states that relicensing requires explicit
> > assent of everyone with a copyright interest in the codebase. The other
> theory
> > is that project maintainers may relicense as they see fit, so long as their
> > actions do not induce a tort offense against any other contributor. Basically
> > that theory is limited to relicensing attempts that are more strict than the
> > original, otherwise the additional rights the project maintainers are giving
> > away might give grounds to a suit from a contributor who objects to the
> change.
> >
> > I have no idea which of the two theories are held by the legal committee at
> > Apache, but I tend to err on the side of caution and assume the former is more
> > likely to be the case. Which is why I suggest noting the original Thrift
> license
> > in any file that has contributions from folks who haven't submitted an ICLA
> > by now.
> >
> >
> >
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: patch for solaris
Posted by David Reiss <dr...@facebook.com>.
I'm not talking about contributions that were made before Thrift moved
into the Incubator. I'm talking about new patches from people who might
say that the patch is a derivative work of the original permissively
licensed Thrift, not the newer Apache Licensed version.
--David
Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: David Reiss <dr...@facebook.com>
>> To: "thrift-dev@incubator.apache.org" <th...@incubator.apache.org>
>> Sent: Thu, October 15, 2009 7:27:44 PM
>> Subject: Re: patch for solaris
>>
>>> Read the Apache License 2.0, particularly the section defining a Contribution.
>> I just did, which is why I asked the question.
>>
>>>> Is the assumption that sending the patch to a mailing list is an
>>>> implicit license grant?
>>> Open source at Apache has always operated under this principle as well,
>>> even before we migrated to the 2.0 License. The 2.0 License however
>>> makes the grant explicit- you can't post a patch of our software to
>>> our mailing lists without complying with the terms of the license-
>>> you have no other right to do that because a patch is a derivative work.
>> Ah. That makes sense.
>>
>> What about a project like Thrift that was previously distributed under
>> a more permissive license? Could the patch poster claim that they
>> patch was a derivative work of the permissive-licensed version of Thrift
>> and therefore not subject to the terms of the Apache License? (Obviously,
>> this assumes that the patch is equally relevant to the old version.)
>
> This is the whole reason we sought CLAs from contributors to Thrift prior
> to its entrance at Apache. Nothing gives us the right to relicense their
> MIT-based contributions other than some explicit agreement to the contrary,
> like a CLA.
>
> There are two working theories in open source regarding project relicensing.
> One theory, which is commonly held, states that relicensing requires explicit
> assent of everyone with a copyright interest in the codebase. The other theory
> is that project maintainers may relicense as they see fit, so long as their
> actions do not induce a tort offense against any other contributor. Basically
> that theory is limited to relicensing attempts that are more strict than the
> original, otherwise the additional rights the project maintainers are giving
> away might give grounds to a suit from a contributor who objects to the change.
>
> I have no idea which of the two theories are held by the legal committee at
> Apache, but I tend to err on the side of caution and assume the former is more
> likely to be the case. Which is why I suggest noting the original Thrift license
> in any file that has contributions from folks who haven't submitted an ICLA
> by now.
>
>
>
Re: patch for solaris
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Reiss <dr...@facebook.com>
> To: "thrift-dev@incubator.apache.org" <th...@incubator.apache.org>
> Sent: Thu, October 15, 2009 7:27:44 PM
> Subject: Re: patch for solaris
>
> > Read the Apache License 2.0, particularly the section defining a Contribution.
> I just did, which is why I asked the question.
>
> >> Is the assumption that sending the patch to a mailing list is an
> >> implicit license grant?
> >
> > Open source at Apache has always operated under this principle as well,
> > even before we migrated to the 2.0 License. The 2.0 License however
> > makes the grant explicit- you can't post a patch of our software to
> > our mailing lists without complying with the terms of the license-
> > you have no other right to do that because a patch is a derivative work.
> Ah. That makes sense.
>
> What about a project like Thrift that was previously distributed under
> a more permissive license? Could the patch poster claim that they
> patch was a derivative work of the permissive-licensed version of Thrift
> and therefore not subject to the terms of the Apache License? (Obviously,
> this assumes that the patch is equally relevant to the old version.)
This is the whole reason we sought CLAs from contributors to Thrift prior
to its entrance at Apache. Nothing gives us the right to relicense their
MIT-based contributions other than some explicit agreement to the contrary,
like a CLA.
There are two working theories in open source regarding project relicensing.
One theory, which is commonly held, states that relicensing requires explicit
assent of everyone with a copyright interest in the codebase. The other theory
is that project maintainers may relicense as they see fit, so long as their
actions do not induce a tort offense against any other contributor. Basically
that theory is limited to relicensing attempts that are more strict than the
original, otherwise the additional rights the project maintainers are giving
away might give grounds to a suit from a contributor who objects to the change.
I have no idea which of the two theories are held by the legal committee at
Apache, but I tend to err on the side of caution and assume the former is more
likely to be the case. Which is why I suggest noting the original Thrift license
in any file that has contributions from folks who haven't submitted an ICLA
by now.
Re: patch for solaris
Posted by David Reiss <dr...@facebook.com>.
> Read the Apache License 2.0, particularly the section defining a Contribution.
I just did, which is why I asked the question.
>> Is the assumption that sending the patch to a mailing list is an
>> implicit license grant?
>
> Open source at Apache has always operated under this principle as well,
> even before we migrated to the 2.0 License. The 2.0 License however
> makes the grant explicit- you can't post a patch of our software to
> our mailing lists without complying with the terms of the license-
> you have no other right to do that because a patch is a derivative work.
Ah. That makes sense.
What about a project like Thrift that was previously distributed under
a more permissive license? Could the patch poster claim that they
patch was a derivative work of the permissive-licensed version of Thrift
and therefore not subject to the terms of the Apache License? (Obviously,
this assumes that the patch is equally relevant to the old version.)
--David
Re: patch for solaris
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Reiss <dr...@facebook.com>
> To: "thrift-dev@incubator.apache.org" <th...@incubator.apache.org>
> Sent: Thu, October 15, 2009 7:01:09 PM
> Subject: Re: patch for solaris
>
> >> So is the assumption that the person who emailed the patch has implicitly
> >> agreed to allow the patch to be covered under the Apache License? What
> >> if he later says, "Oh, I never contributed it. I was just posting it
> >> to inform the maintainers that the project doesn't build on Solaris.
> >
> > Then you pull the patch and provide another work-around, same as you would
> > if the person was talking about a patch posted to JIRA. The License is
> > clear that anything intentionally submitted to Apache that isn't clearly
> > marked as not-a-contribution will be treated as a contribution by us.
> I, of course, am not a lawyer, but I don't really understand where Apache
> gets the legal right to claim that everything is a contribution unless
> specifically marked otherwise.
Read the Apache License 2.0, particularly the section defining a Contribution.
> Is the assumption that sending the patch to a mailing list is an
> implicit license grant?
Open source at Apache has always operated under this principle as well,
even before we migrated to the 2.0 License. The 2.0 License however
makes the grant explicit- you can't post a patch of our software to
our mailing lists without complying with the terms of the license-
you have no other right to do that because a patch is a derivative work.
Re: patch for solaris
Posted by David Reiss <dr...@facebook.com>.
>> So is the assumption that the person who emailed the patch has implicitly
>> agreed to allow the patch to be covered under the Apache License? What
>> if he later says, "Oh, I never contributed it. I was just posting it
>> to inform the maintainers that the project doesn't build on Solaris.
>
> Then you pull the patch and provide another work-around, same as you would
> if the person was talking about a patch posted to JIRA. The License is
> clear that anything intentionally submitted to Apache that isn't clearly
> marked as not-a-contribution will be treated as a contribution by us.
I, of course, am not a lawyer, but I don't really understand where Apache
gets the legal right to claim that everything is a contribution unless
specifically marked otherwise. Is the assumption that sending the patch
to a mailing list is an implicit license grant?
>> I still maintain full copyright over the contents of the patch."?
>
> Contributors always maintain their copyrights. Apache is entitled to a
> non-exclusive license under the terms of the Apache License by the very
> act of their posting the patch to an Apache mailing list. This is the
> weakest form of coverage as far as Apache is concerned (the JIRA checkbox
> does nothing to improve the situation), and if the work is substantial
> enough you should request an ICLA from the contributor and possibly make
> them a committer on the project.
I meant if they claim that no one else has a license to distribute it.
Re: patch for solaris
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Reiss <dr...@facebook.com>
> To: "thrift-dev@incubator.apache.org" <th...@incubator.apache.org>
> Sent: Wed, October 14, 2009 7:52:59 PM
> Subject: Re: patch for solaris
>
> So is the assumption that the person who emailed the patch has implicitly
> agreed to allow the patch to be covered under the Apache License? What
> if he later says, "Oh, I never contributed it. I was just posting it
> to inform the maintainers that the project doesn't build on Solaris.
Then you pull the patch and provide another work-around, same as you would
if the person was talking about a patch posted to JIRA. The License is
clear that anything intentionally submitted to Apache that isn't clearly
marked as not-a-contribution will be treated as a contribution by us.
> I still maintain full copyright over the contents of the patch."?
Contributors always maintain their copyrights. Apache is entitled to a
non-exclusive license under the terms of the Apache License by the very
act of their posting the patch to an Apache mailing list. This is the
weakest form of coverage as far as Apache is concerned (the JIRA checkbox
does nothing to improve the situation), and if the work is substantial
enough you should request an ICLA from the contributor and possibly make
them a committer on the project.
Re: patch for solaris
Posted by David Reiss <dr...@facebook.com>.
So is the assumption that the person who emailed the patch has implicitly
agreed to allow the patch to be covered under the Apache License? What
if he later says, "Oh, I never contributed it. I was just posting it
to inform the maintainers that the project doesn't build on Solaris. I
still maintain full copyright over the contents of the patch."?
--David
Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: Chad Walters <Ch...@microsoft.com>
>> To: "thrift-dev@incubator.apache.org" <th...@incubator.apache.org>; "nuggetwheat@gmail.com" <nu...@gmail.com>
>> Sent: Wed, October 14, 2009 3:55:36 PM
>> Subject: RE: patch for solaris
>>
>> Doug,
>>
>> Please put this as a patch file in a JIRA -- code that is just sent to the
>> mailing list has murky status WRT license issues, while code entered in JIRA is
>> clearly licensed.
>
> 100% not true. There's nothing wrong with the license status of a patch
> submitted to the mailing list. I don't know where this misunderstanding
> comes from but it needs to be put to rest- simply read the Apache License
> and you'll see that patches submitted to a mailing list are covered
> contributions. The JIRA checkbox is an appendage that makes it convenient
> to opt-out of the license. It is by no means an essential element.
>
>> Plus it will get tracked better if it is in JIRA.
>
> Maybe so.
>
>
>
Re: patch for solaris
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Chad Walters <Ch...@microsoft.com>
> To: "thrift-dev@incubator.apache.org" <th...@incubator.apache.org>; "nuggetwheat@gmail.com" <nu...@gmail.com>
> Sent: Wed, October 14, 2009 3:55:36 PM
> Subject: RE: patch for solaris
>
> Doug,
>
> Please put this as a patch file in a JIRA -- code that is just sent to the
> mailing list has murky status WRT license issues, while code entered in JIRA is
> clearly licensed.
100% not true. There's nothing wrong with the license status of a patch
submitted to the mailing list. I don't know where this misunderstanding
comes from but it needs to be put to rest- simply read the Apache License
and you'll see that patches submitted to a mailing list are covered
contributions. The JIRA checkbox is an appendage that makes it convenient
to opt-out of the license. It is by no means an essential element.
> Plus it will get tracked better if it is in JIRA.
Maybe so.
RE: patch for solaris
Posted by Chad Walters <Ch...@microsoft.com>.
Doug,
Please put this as a patch file in a JIRA -- code that is just sent to the mailing list has murky status WRT license issues, while code entered in JIRA is clearly licensed. Plus it will get tracked better if it is in JIRA.
Chad
-----Original Message-----
From: nuggetwheat@gmail.com [mailto:nuggetwheat@gmail.com] On Behalf Of Doug Judd
Sent: Thursday, October 08, 2009 1:51 PM
To: thrift-dev@incubator.apache.org
Subject: patch for solaris
I had to apply the following patch to get thrift to compile on Solaris.
- Doug
Index: configure.ac
===================================================================
--- configure.ac (revision 820547)
+++ configure.ac (working copy)
@@ -142,6 +142,7 @@
dnl of the POSIX Real-Time Extensions. This seems necessary on Linux,
dnl and we haven't yet found a system where this is a problem.
AC_CHECK_LIB(rt, clock_gettime)
+AC_CHECK_LIB(socket, setsockopt)
AC_TYPE_INT16_T
AC_TYPE_INT32_T
Index: lib/cpp/src/protocol/TProtocol.h
===================================================================
--- lib/cpp/src/protocol/TProtocol.h (revision 820547)
+++ lib/cpp/src/protocol/TProtocol.h (working copy)
@@ -86,7 +86,10 @@
# define __LITTLE_ENDIAN LITTLE_ENDIAN
# define __BIG_ENDIAN BIG_ENDIAN
# else
-# error "Cannot determine endianness"
+#include <boost/config.hpp>
+# define __BYTE_ORDER BOOST_BYTE_ORDER
+# define __LITTLE_ENDIAN BOOST_LITTLE_ENDIAN
+# define __BIG_ENDIAN BOOST_BIG_ENDIAN
# endif
#endif
Index: lib/cpp/src/server/TNonblockingServer.cpp
===================================================================
--- lib/cpp/src/server/TNonblockingServer.cpp (revision 820547)
+++ lib/cpp/src/server/TNonblockingServer.cpp (working copy)
@@ -29,6 +29,10 @@
#include <errno.h>
#include <assert.h>
+#ifndef AF_LOCAL
+#define AF_LOCAL AF_UNIX
+#endif
+
namespace apache { namespace thrift { namespace server {
using namespace apache::thrift::protocol;
Index: lib/cpp/src/transport/TServerSocket.cpp
===================================================================
--- lib/cpp/src/transport/TServerSocket.cpp (revision 820547)
+++ lib/cpp/src/transport/TServerSocket.cpp (working copy)
@@ -33,6 +33,10 @@
#include "TServerSocket.h"
#include <boost/shared_ptr.hpp>
+#ifndef AF_LOCAL
+#define AF_LOCAL AF_UNIX
+#endif
+
namespace apache { namespace thrift { namespace transport {
using namespace std;