Good point. A little more thought: The distinction here is *how* we generate the output, rather than what the output needs upon use. A similar situation is seen in the autotools. Those are GPL'd, but they state "the output from these tools is not required to follow the GPL license" (or something like that).
Our PHP and Java output can be used under those systems in a similar fashion. We've never really need/bothered to clarify that usage scenario since the ALv2 is so easygoing that nobody has asked (afaik). So now the question is: do the C bindings geneation require Thrift itself to link against Glib? Or is Glib only required for the resulting generated code? Cheers, -g On Mon, Jun 7, 2010 at 23:50, Michael Lum <michael....@openx.org> wrote: > How does the Apache license work with Java and PHP for Thrift? Both of > those runtimes have licenses that I didn't see on the 3rd party list, yet > they are required to use the Thrift bindings for those languages. > > On 6/7/2010 5:57 PM, Jake Luciani wrote: >> >> It's used for collections, since none exist in c. >> >> Can it be included under contrib? >> >> Thanks. >> -Jake >> >> On Mon, Jun 7, 2010 at 8:49 PM, Greg Stein<gst...@gmail.com> wrote: >> >>> Yeah... it means that somebody downloading Thrift, expecting just >>> Apache-licensed code is gonna get surprised to also have to include >>> LGPL'd code. That's why we don't allow... no surprises for the user. >>> >>> What features of Glib are needed by this implementation? (I can't tell >>> since it isn't in svn...) >>> >>> Cheers, >>> -g >>> >>> On Mon, Jun 7, 2010 at 20:40, Jake Luciani<jak...@gmail.com> wrote: >>>> >>>> Since Glib is LGPL I think there is an issue including this dependency >>>> on >>>> thrift. >>>> >>>> Can any PMC folks comment if this contribution is going to be possible >>>> to >>>> include? >>>> >>>> http://www.apache.org/legal/3party.html >>>> >>>> -Jake >>>> >>>> On Mon, Jun 7, 2010 at 3:08 PM, David Reiss<dre...@facebook.com> wrote: >>>> >>>>>>>> - should I attach this stuff to THRIFT-582 as a massive patch? >>> >>> not >>>>>>>> >>>>>>>> sure how well that would work, as there will still be a lot of >>> >>> future >>>>>>>> >>>>>>>> updates. I'm happy to just continue to work on github, or use >>>>> >>>>> something >>>>>>>> >>>>>>>> else if there are suggestions. >>>>>>> >>>>>>> Yes, you should attach a massive patch, since that is the easiest way >>>>> >>>>> for >>>>>>> >>>>>>> us to document the history of the code. Keeping an active branch on >>>>> >>>>> github >>>>>>> >>>>>>> is also good to allow more detailed analysis of the development >>> >>> process. >>>>>> >>>>>> Should we do that now, or later, once the server implementation is >>>>>> complete and the tests have full code coverage? >>>>> >>>>> Either. >>>>> >>>> >>> >> >
