You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Ralph Goers <ra...@dslextreme.com> on 2009/08/17 02:13:37 UTC
Re: Thrift release legal issues
See below. First, this should have been asked on legal-discuss.
Second, the answers below are just my opinion.
On Aug 16, 2009, at 4:24 PM, Joe Schaefer wrote:
> I'm trying to coax out a release of Apache Thrift and ran into a
> few obstacles. Maybe you can offer me a little guidance?
>
> First, I found that the CCLA from Facebook excludes
> contributions from 3rd parties who wrote code for Thrift
> prior to the move to Apache. With the exception of imeem.com,
> all of the corporate entities appear to have a CCLA on file
> with us. I've attempted to contact the folks from imeem.com
> to request that a CCLA be filed for their Thrift work.
>
> I've also found that there are 6 individuals listed in the
> Facebook CCLA who do not have ICLAs with us and have accordingly
> contacted them as well.
Was the Facebook CCLA a software grant and were the 6 individuals
Facebook employees (if not, why were they listed in the CCLA)? If they
did their development on behalf of Facebook then as I understand it
Facebook owns the rights to the software and ICLAs shouldn't be
required. The software grant from Facebook would be enough.
>
> So the first question is: do we have any contingency strategies
> for the likely situation where not all past contributors to Thrift
> will have paperwork on file in the near future? Can Thrift still
> cut a release or does that block it? Thrift was in fact an open
> source project prior to coming here, and it *has* released stuff under
> an alternate license. Does that mitigate the issue at all?
See my comment above.
>
> The second question regards the LICENSE file. I'm accustomed to
> seeing all the licenses for all the code to be distributed listed
> in the LICENSE file, but don't see anywhere within the Incubator
> docs that this concept is mandatory. I've been pushing Thrift to
> do this because that's the way I've usually seen it done but the
> idea hasn't gained any traction with the thrift devs yet. Is there
> such a policy, does it simply constitute best practice, or am I
> barking up the wrong tree?
I was under the impression the LICENSE file should contain the Apache
license. All other licenses should be referenced in the NOTICE file.
See http://www.apache.org/licenses/.
> The third issue is that Thrift intends to distribute with an LGPL
> dependency on their build system. I'm familiar with the scary
> language
> adopted by the legal team regarding the LGPL, but don't consider this
> situation to be problematic since it's just a few Makefiles and such.
> Will I need to get special permission from legal for this?
If they are using Maven 2 and if the LGPL dependency is referenced as
a dependency in the pom such that it is downloaded during the build
and is not distributed with Apache software (or if the build process
is functionally equivalent to this), I personally would have no
problem with it being used as part of the build. https://issues.apache.org/jira/browse/LEGAL-19
and https://issues.apache.org/jira/browse/LEGAL-23 seem similar to
this. In general, anything involving software in Category X should
seek permission. The best way is to create a Jira issue.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Thrift release legal issues
Posted by Robert Burrell Donkin <rd...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Joe Schaefer wrote:
> ----- Original Message ----
>
>> From: Robert Burrell Donkin <rd...@apache.org>
>> To: legal-discuss@apache.org
>> Sent: Tuesday, August 18, 2009 2:56:12 AM
>> Subject: Re: Thrift release legal issues
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Ralph Goers wrote:
>>> On Aug 17, 2009, at 10:38 PM, Joe Schaefer wrote:
>>>
>>>> OK, so to make sure I understand you correctly: in the situation where no
>>>> CCLA/ICLA is available, we can treat the works in question as
>>>> 3rd-party works
>>>> under their original Facebook MIT-style license. That doesn't give us
>>>> the right
>>>> to relicense those works under the Apache License, so the files in
>>>> question need
>>>> to be changed back to the original Facebook license (the project has
>>>> already done
>>>> a mass switch of all Facebook-licensed files to the AL).
>>>>
>>> The MIT license allows the work to be sublicensed so I believe the files
>>> in question could be under both.
>> providing that the relicensing is done properly
>
> And by that do you mean that the files in question contain both the AL
> boilerplate and the Facebook license, with an explanatory comment that
> the file used to be licensed under the Facebook license?
yes (give or take some arguable nuances)
if we don't have an example documented, probably should need one
- - robert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIcBAEBCgAGBQJKir/hAAoJEHl6NpRAqILLNcQQAMhhuSkTA0uwrY7pVZdCUEpZ
GJKk2dk0cql0b+1tTTNzNgqLoro3kUfOiHqdhHK3ATdE7s4vTrOsmrhCRgXfapOR
alas8RmvMGcTsgbu4DUjkmqR/ZWpYMsh8d4IItLTthge5YU72FCDYYkAZNJG0LAl
Hv6HluC0RzmpEgUUmF4bXCQtPyH1QohHu1JIC9pIJHDX1XvqQamwLJYu49HhqL4i
I8JN6yf+FWQA2mfg43V9Pgn/GRlZRMlnSu/xu1YVgwj7JY2qNov49QBL+8XdzZAi
NNJIK5im1qxfB83OFYc7yU0/eRH9lHq8H4g7np9evalWWmhjUfy44zIJBF4N3AHg
UZ0XG5ktl5pLC5bGyrYipmJ/zM7P8OnWRBk7ZpvADx020z4zAHLS1Vvz6/rDPmLG
LBpU+nzeshAM2eEvk/Lr2cK2henTNe6EEFck5I2+3eFfbvo2xnc15ifCyJBKdlV7
e0XHp8DeYdFNttldQzynFWrD4JOr149xz0HyxDMAVxPtC4A2OrBCdaPEj0EfbMXn
f3RA6lKWUTfEM/oCMMN07HFvWwUAjA6jtuaxnOx8te1qdPugGFMaQ7h6503qcH1y
ghJ8nFKj1+Wh8reiT6chsVsM9YbuojpVRLX6OpsxcQWDj0Ki01JsDqcQPtWI3cAn
ZioxtMaIwZzpDOUHtSMt
=iO8N
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Thrift release legal issues
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Robert Burrell Donkin <rd...@apache.org>
> To: legal-discuss@apache.org
> Sent: Tuesday, August 18, 2009 2:56:12 AM
> Subject: Re: Thrift release legal issues
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Ralph Goers wrote:
> >
> > On Aug 17, 2009, at 10:38 PM, Joe Schaefer wrote:
> >
> >>
> >> OK, so to make sure I understand you correctly: in the situation where no
> >> CCLA/ICLA is available, we can treat the works in question as
> >> 3rd-party works
> >> under their original Facebook MIT-style license. That doesn't give us
> >> the right
> >> to relicense those works under the Apache License, so the files in
> >> question need
> >> to be changed back to the original Facebook license (the project has
> >> already done
> >> a mass switch of all Facebook-licensed files to the AL).
> >>
> > The MIT license allows the work to be sublicensed so I believe the files
> > in question could be under both.
>
> providing that the relicensing is done properly
And by that do you mean that the files in question contain both the AL
boilerplate and the Facebook license, with an explanatory comment that
the file used to be licensed under the Facebook license?
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Thrift release legal issues
Posted by Robert Burrell Donkin <rd...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Ralph Goers wrote:
>
> On Aug 17, 2009, at 10:38 PM, Joe Schaefer wrote:
>
>>
>> OK, so to make sure I understand you correctly: in the situation where no
>> CCLA/ICLA is available, we can treat the works in question as
>> 3rd-party works
>> under their original Facebook MIT-style license. That doesn't give us
>> the right
>> to relicense those works under the Apache License, so the files in
>> question need
>> to be changed back to the original Facebook license (the project has
>> already done
>> a mass switch of all Facebook-licensed files to the AL).
>>
> The MIT license allows the work to be sublicensed so I believe the files
> in question could be under both.
providing that the relicensing is done properly
- - robert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIcBAEBCgAGBQJKilCMAAoJEHl6NpRAqILLmwIQAOsK5ASzl1jFvh6FNdw/MM1c
rCIXe9PEoM2TyD95fUZqr2KTZ2jdpoNKpHd0Fx0H3oNrCxoMIeqY+aww7a6z7f02
EOzFOoXI5l/ofVYsFumTiX8kItAC99DpfvC4TDtqkbYL/tZg/blKWDyNpUbVbR7j
YV6tTwQOXtzBtjrOIX0LKerR6yRT4G750/Y11vob504GWSfXbcTP+yUb36dAoc3r
PjenO413ISmqZNW5BnkTUDnWwd9Gqp1sFV6oEad575bkZ9yIhVgsmSzSZEtc+NLm
jILlS6Kg7ydWNhbN+AMNWNL6nk/Sj0YfA8rdrK6fTdUGmB2hUVvbImtQ0Xk0K+Eo
JlHrYFf0MbKbA+0MCCfmzh7hi/lC9AkO9XTG3xFXvhG4Cf+C6SvgqY4NP/3ku++n
xOfFb1ZYN03XGa8zgMSrxav9TkEapWZ91iQ0Rj+UbGCzbq7XGLd9CmyL8GgTxYHW
orwddlL2/9vwWFbvbk5bDGEKR6pes8vQqXwrN+ltEQWlKDLAXgqZOFBefaHhmZc4
3Gpk8901fQr82KDQTwgcICcQRxJqFhSTWsS3H1y52qbdrUzQhSob1wVRPVw/zUZy
IBiW9vsqM1BIWo+VlyQ4SSL1BCbvf9wqmQEoTSVWl2v9/OgPXjcGubk10ZNdgIF9
D4t7MnB4/pNcqgkDGO+M
=CCFQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Thrift release legal issues
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 17, 2009, at 10:38 PM, Joe Schaefer wrote:
>
> OK, so to make sure I understand you correctly: in the situation
> where no
> CCLA/ICLA is available, we can treat the works in question as 3rd-
> party works
> under their original Facebook MIT-style license. That doesn't give
> us the right
> to relicense those works under the Apache License, so the files in
> question need
> to be changed back to the original Facebook license (the project has
> already done
> a mass switch of all Facebook-licensed files to the AL).
>
The MIT license allows the work to be sublicensed so I believe the
files in question could be under both.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Thrift release legal issues
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Sam Ruby <ru...@intertwingly.net>
> To: legal-discuss@apache.org
> Sent: Monday, August 17, 2009 12:53:54 PM
> Subject: Re: Thrift release legal issues
>
> On Sun, Aug 16, 2009 at 9:17 PM, Joe Schaeferwrote:
> >>
> >> Thanks for the clarification. I would think we would want ICLAs from those
> 6. I
> >> don't suppose these folks had to sign anything before the code was
> contributed
> >> to Apache? Out of curiosity, what license was the code under before it came
> to
> >> Apache?
> >
> > Basically an MIT license:
> >
> >
> http://github.com/schacon/thrift/blob/4fdf4d2e7b44c666c59d8d32f8068b5151e3940a/LICENSE
>
> To address your original question: dependency on a category A license
> should not hold up a release.
OK, so to make sure I understand you correctly: in the situation where no
CCLA/ICLA is available, we can treat the works in question as 3rd-party works
under their original Facebook MIT-style license. That doesn't give us the right
to relicense those works under the Apache License, so the files in question need
to be changed back to the original Facebook license (the project has already done
a mass switch of all Facebook-licensed files to the AL).
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Thrift release legal issues
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sun, Aug 16, 2009 at 9:17 PM, Joe Schaefer<jo...@yahoo.com> wrote:
>>
>> Thanks for the clarification. I would think we would want ICLAs from those 6. I
>> don't suppose these folks had to sign anything before the code was contributed
>> to Apache? Out of curiosity, what license was the code under before it came to
>> Apache?
>
> Basically an MIT license:
>
> http://github.com/schacon/thrift/blob/4fdf4d2e7b44c666c59d8d32f8068b5151e3940a/LICENSE
To address your original question: dependency on a category A license
should not hold up a release.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Thrift release legal issues
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Aug 17, 2009 at 12:56 PM, sebb<se...@gmail.com> wrote:
> On 17/08/2009, ant elder <an...@gmail.com> wrote:
>> On Mon, Aug 17, 2009 at 11:51 AM, Robert Burrell
>> Donkin<ro...@gmail.com> wrote:
>>
>> >> You can put all the licenses or references to the licences in the
>> >> LICENSE file.
>> >
>> > AIUI this is only best practice, not normative. every third party
>> > library MUST have a license but including them next to the appropriate
>> > artifact (rather than collecting them together) is ok but not
>> > recommended.
>> >
>>
>>
>> Thats my understanding too. I know of a number of Apache projects
>> where the licenses are kept separate and with no mention in the top
>> LICENSE file, and IIRC in the past we've also had Incubator poddlings
>> doing this having their releases approved by the IPMC .
>>
>
> It's not my understanding.
> AIUI, the LICENSE file should start with the AL and be followed by all
> the other licenses.
AIUI that's best practice but no formal policy change has been made
mandating that. if anyone can supply an URL or message ID for the VOTE
by the legal team mandating this then i'd be glad to admit that i'm
wrong...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Thrift release legal issues
Posted by sebb <se...@gmail.com>.
On 17/08/2009, ant elder <an...@gmail.com> wrote:
> On Mon, Aug 17, 2009 at 11:51 AM, Robert Burrell
> Donkin<ro...@gmail.com> wrote:
>
> >> You can put all the licenses or references to the licences in the
> >> LICENSE file.
> >
> > AIUI this is only best practice, not normative. every third party
> > library MUST have a license but including them next to the appropriate
> > artifact (rather than collecting them together) is ok but not
> > recommended.
> >
>
>
> Thats my understanding too. I know of a number of Apache projects
> where the licenses are kept separate and with no mention in the top
> LICENSE file, and IIRC in the past we've also had Incubator poddlings
> doing this having their releases approved by the IPMC .
>
It's not my understanding.
AIUI, the LICENSE file should start with the AL and be followed by all
the other licenses.
> ...ant
>
>
> ---------------------------------------------------------------------
> 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: Thrift release legal issues
Posted by ant elder <an...@gmail.com>.
On Mon, Aug 17, 2009 at 11:51 AM, Robert Burrell
Donkin<ro...@gmail.com> wrote:
>> You can put all the licenses or references to the licences in the
>> LICENSE file.
>
> AIUI this is only best practice, not normative. every third party
> library MUST have a license but including them next to the appropriate
> artifact (rather than collecting them together) is ok but not
> recommended.
>
Thats my understanding too. I know of a number of Apache projects
where the licenses are kept separate and with no mention in the top
LICENSE file, and IIRC in the past we've also had Incubator poddlings
doing this having their releases approved by the IPMC .
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Thrift release legal issues
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Aug 17, 2009 at 7:38 AM, J Aaron Farr<fa...@apache.org> wrote:
> On Mon 17 Aug 2009 10:20, Niclas Hedhman <ni...@hedhman.org> wrote:
>
>> On Mon, Aug 17, 2009 at 10:04 AM, David Crossley<cr...@apache.org> wrote:
>>
>>> The NOTICE file is not for that purpose. Did you mean to
>>> say that you have seen "LICENSE" files containing pointers?
>>
>> No, I don't mean LICENSE... IIRC (it was not yesterday), the NOTICE
>> file would contain something like;
>>
>> "Portions of this software contains Foo from Bar Foundation, which is
>> under the Abc license. See licenses/license.foo"
>
> That's only necessary if the ABC license requires attribution similar to
> the Apache license. The NOTICE file is *not* for notifications about
> other licenses. The NOTICE file is for required attributions as
> specified in the Apache license.
http://www.apache.org/legal/src-headers.html#3party notes that it
should include relocated copyright attributions (if there are any)
> You can put all the licenses or references to the licences in the
> LICENSE file.
AIUI this is only best practice, not normative. every third party
library MUST have a license but including them next to the appropriate
artifact (rather than collecting them together) is ok but not
recommended.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Thrift release legal issues
Posted by J Aaron Farr <fa...@apache.org>.
On Mon 17 Aug 2009 10:20, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Mon, Aug 17, 2009 at 10:04 AM, David Crossley<cr...@apache.org> wrote:
>
>> The NOTICE file is not for that purpose. Did you mean to
>> say that you have seen "LICENSE" files containing pointers?
>
> No, I don't mean LICENSE... IIRC (it was not yesterday), the NOTICE
> file would contain something like;
>
> "Portions of this software contains Foo from Bar Foundation, which is
> under the Abc license. See licenses/license.foo"
That's only necessary if the ABC license requires attribution similar to
the Apache license. The NOTICE file is *not* for notifications about
other licenses. The NOTICE file is for required attributions as
specified in the Apache license.
You can put all the licenses or references to the licences in the
LICENSE file.
--
J. Aaron Farr
馮傑仁
www.cubiclemuses.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Thrift release legal issues
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Aug 17, 2009 at 10:04 AM, David Crossley<cr...@apache.org> wrote:
> The NOTICE file is not for that purpose. Did you mean to
> say that you have seen "LICENSE" files containing pointers?
No, I don't mean LICENSE... IIRC (it was not yesterday), the NOTICE
file would contain something like;
"Portions of this software contains Foo from Bar Foundation, which is
under the Abc license. See licenses/license.foo"
A quick Googling reveals a couple of samples of licenses outside the
LICENSE, but of these only the first make any reference to look for a
file with the license text. I don't have time to dig up what I recall
(possibly erratically) from memory...
https://svn.apache.org/repos/asf/webservices/woden/trunk/java/
http://svn.apache.org/repos/asf/xml/security/trunk/c/doc/
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PATCH Re: Thrift release legal issues
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Aug 17, 2009 at 4:21 AM, Joe Schaefer<jo...@yahoo.com> wrote:
> ----- Original Message ----
>
>> From: David Crossley <cr...@apache.org>
>> To: general@incubator.apache.org
>> Sent: Sunday, August 16, 2009 11:10:13 PM
>> Subject: Re: PATCH Re: Thrift release legal issues
>>
>> Joe, as far as i know, just dive in and make changes to
>> most Incubator documents.
>> http://incubator.apache.org/guides/website.html
+1
>> For the main "policy" document, there is a note at
>> http://incubator.apache.org/incubation/Incubation_Policy.html#Changing+this+Document
>> We usually pass such changes through Jira, etc.
+1
> Frankly the document in question is a bunch of intimidating
> circular gibberish. I would strongly prefer a normative document
> that doesn't allow a lot of leeway for projects to get creative
> in their compliance efforts.
-1
the incubator does not set apache release policy: the incubator guides
projects in their implemention of apache policy
> After all the primary concern of the document
> is to ensure projects meeting all the legal and formal requirements for a
> proper release.
-1
the release management documentation in the incubator are just guides.
the normative release management stuff belongs to infra and lives in
dev.
> That's boring stuff that should be written in an
> informative style, largely with a single voice, not by starting off with
> a gigantic heirarchy of categories of the sparsely collected wisdom of
> the IPMC.
>
> I'd be more than happy to burn the document down and start over again.
if you have the time to produce something better, just go for it. if
you can write a good, informative guide that applies to all projects
that's cool: project will use the guide as if it's normative. you'll
find that much easier than trying to get a load of extra policy
passed.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PATCH Re: Thrift release legal issues
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Crossley <cr...@apache.org>
> To: general@incubator.apache.org
> Sent: Sunday, August 16, 2009 11:10:13 PM
> Subject: Re: PATCH Re: Thrift release legal issues
>
> Joe, as far as i know, just dive in and make changes to
> most Incubator documents.
> http://incubator.apache.org/guides/website.html
>
> For the main "policy" document, there is a note at
> http://incubator.apache.org/incubation/Incubation_Policy.html#Changing+this+Document
> We usually pass such changes through Jira, etc.
Frankly the document in question is a bunch of intimidating
circular gibberish. I would strongly prefer a normative document
that doesn't allow a lot of leeway for projects to get creative
in their compliance efforts. After all the primary concern of the document
is to ensure projects meeting all the legal and formal requirements for a
proper release. That's boring stuff that should be written in an
informative style, largely with a single voice, not by starting off with
a gigantic heirarchy of categories of the sparsely collected wisdom of
the IPMC.
I'd be more than happy to burn the document down and start over again.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: PATCH Re: Thrift release legal issues
Posted by David Crossley <cr...@apache.org>.
Joe, as far as i know, just dive in and make changes to
most Incubator documents.
http://incubator.apache.org/guides/website.html
For the main "policy" document, there is a note at
http://incubator.apache.org/incubation/Incubation_Policy.html#Changing+this+Document
We usually pass such changes through Jira, etc.
-David
Joe Schaefer wrote:
>
> Here's a quick patch to consider:
> Index: releasemanagement.xml
> ===================================================================
> --- releasemanagement.xml (revision 803351)
> +++ releasemanagement.xml (working copy)
> @@ -941,9 +941,9 @@
> </p>
> <p>
> The artifacts and documents to which each subsidiary clause applies should be
> -indicated in the document. This <a href='examples/LICENSE'>LICENSE</a>
> +indicated in the LICENSE document. This <a href='examples/LICENSE'>LICENSE</a>
> (courtesy of <a href='http://httpd.apache.org'>Apache HTTPD</a>) is a
> -good example. The Apache License is at the top of document. The explanation
> +good example. The Apache License is at the top of LICENSE document. The explanation
> is clear and the files to which the licenses apply are clearly noted.
> </p>
> </section>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
PATCH Re: Thrift release legal issues
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: David Crossley <cr...@apache.org>
> To: general@incubator.apache.org
> Sent: Sunday, August 16, 2009 10:04:50 PM
> Subject: Re: Thrift release legal issues
>
> Niclas Hedhman wrote:
> > Joe Schaefer wrote:
> > >
> > > AIUI, and the way httpd does it, the LICENSE file contains all the licenses
> in
> > > the distribution, preferably in an annotated fashion so you know which
> license
> > > goes with which component. ?The NOTICE file is for any additional required
> > > Copyright statements and/or attribution notices that each license may
> require.
> >
> > I understand this to be the recommended approach, but IIRC I have seen
> > other ones, such as having the NOTICE file contain a local pointer to
> > each license in a separate file, often named accordingly, such as
> > license.bsd or in some cases license.foo (where foo is the component
> > being dependent on). I also have the impression that a single LICENSE
> > file containing all licenses with a heading of which
> > component/part/dependency is under which license, is the only
> > candidate for a unified approach and promoted heavily by many...
>
> The NOTICE file is not for that purpose. Did you mean to
> say that you have seen "LICENSE" files containing pointers?
>
> Here is one guidelines doc:
> http://incubator.apache.org/guides/releasemanagement.html#note-license-and-notice
> Would rather find something at www.apache.org legal,
> but my quick browse today did not find it.
Here's a quick patch to consider:
Index: releasemanagement.xml
===================================================================
--- releasemanagement.xml (revision 803351)
+++ releasemanagement.xml (working copy)
@@ -941,9 +941,9 @@
</p>
<p>
The artifacts and documents to which each subsidiary clause applies should be
-indicated in the document. This <a href='examples/LICENSE'>LICENSE</a>
+indicated in the LICENSE document. This <a href='examples/LICENSE'>LICENSE</a>
(courtesy of <a href='http://httpd.apache.org'>Apache HTTPD</a>) is a
-good example. The Apache License is at the top of document. The explanation
+good example. The Apache License is at the top of LICENSE document. The explanation
is clear and the files to which the licenses apply are clearly noted.
</p>
</section>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Thrift release legal issues
Posted by David Crossley <cr...@apache.org>.
Niclas Hedhman wrote:
> Joe Schaefer wrote:
> >
> > AIUI, and the way httpd does it, the LICENSE file contains all the licenses in
> > the distribution, preferably in an annotated fashion so you know which license
> > goes with which component. ?The NOTICE file is for any additional required
> > Copyright statements and/or attribution notices that each license may require.
>
> I understand this to be the recommended approach, but IIRC I have seen
> other ones, such as having the NOTICE file contain a local pointer to
> each license in a separate file, often named accordingly, such as
> license.bsd or in some cases license.foo (where foo is the component
> being dependent on). I also have the impression that a single LICENSE
> file containing all licenses with a heading of which
> component/part/dependency is under which license, is the only
> candidate for a unified approach and promoted heavily by many...
The NOTICE file is not for that purpose. Did you mean to
say that you have seen "LICENSE" files containing pointers?
Here is one guidelines doc:
http://incubator.apache.org/guides/releasemanagement.html#note-license-and-notice
Would rather find something at www.apache.org legal,
but my quick browse today did not find it.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Thrift release legal issues
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Mon, Aug 17, 2009 at 9:17 AM, Joe Schaefer<jo...@yahoo.com> wrote:
> AIUI, and the way httpd does it, the LICENSE file contains all the licenses in
> the distribution, preferably in an annotated fashion so you know which license
> goes with which component. The NOTICE file is for any additional required
> Copyright statements and/or attribution notices that each license may require.
I understand this to be the recommended approach, but IIRC I have seen
other ones, such as having the NOTICE file contain a local pointer to
each license in a separate file, often named accordingly, such as
license.bsd or in some cases license.foo (where foo is the component
being dependent on). I also have the impression that a single LICENSE
file containing all licenses with a heading of which
component/part/dependency is under which license, is the only
candidate for a unified approach and promoted heavily by many...
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Thrift release legal issues
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Ralph Goers <ra...@dslextreme.com>
> To: Legal Discuss <le...@apache.org>; general@incubator.apache.org
> Sent: Sunday, August 16, 2009 9:10:11 PM
> Subject: Re: Thrift release legal issues
>
>
> On Aug 16, 2009, at 5:38 PM, Joe Schaefer wrote:
>
> >>
> >> On Aug 16, 2009, at 4:24 PM, Joe Schaefer wrote:
> >>>
> >>> I've also found that there are 6 individuals listed in the
> >>> Facebook CCLA who do not have ICLAs with us and have accordingly
> >>> contacted them as well.
> >>
> >> Was the Facebook CCLA a software grant and were the 6 individuals Facebook
> >> employees (if not, why were they listed in the CCLA)?
> >
> > They were not Facebook employees. The individuals in question were listed
> > as exclusions to the covered contributions. See
> >
> > https://svn.apache.org/repos/private/documents/cclas/facebook-2.pdf
>
> Thanks for the clarification. I would think we would want ICLAs from those 6. I
> don't suppose these folks had to sign anything before the code was contributed
> to Apache? Out of curiosity, what license was the code under before it came to
> Apache?
Basically an MIT license:
http://github.com/schacon/thrift/blob/4fdf4d2e7b44c666c59d8d32f8068b5151e3940a/LICENSE
>
> >
> >>
> >>>
> >>> So the first question is: do we have any contingency strategies
> >>> for the likely situation where not all past contributors to Thrift
> >>> will have paperwork on file in the near future? Can Thrift still
> >>> cut a release or does that block it? Thrift was in fact an open
> >>> source project prior to coming here, and it *has* released stuff under
> >>> an alternate license. Does that mitigate the issue at all?
> >>
> >> See my comment above.
> >>
> >>>
> >>> The second question regards the LICENSE file. I'm accustomed to
> >>> seeing all the licenses for all the code to be distributed listed
> >>> in the LICENSE file, but don't see anywhere within the Incubator
> >>> docs that this concept is mandatory. I've been pushing Thrift to
> >>> do this because that's the way I've usually seen it done but the
> >>> idea hasn't gained any traction with the thrift devs yet. Is there
> >>> such a policy, does it simply constitute best practice, or am I
> >>> barking up the wrong tree?
> >>
> >> I was under the impression the LICENSE file should contain the Apache
> license.
> >> All other licenses should be referenced in the NOTICE file. See
> >> http://www.apache.org/licenses/.
> >
> > That's not the way the Apache HTTPD Server manages their LICENSE file.
> > Each 3rd party component's corresponding license is included in the
> > LICENSE file.
>
> Perhaps I misunderstand how the LICENSE and NOTICE files are to be used then.
> The link above actually includes a link to an HTTPD server NOTICE file as an
> example. That sample NOTICE file does not include the actual license text and
> doesn't contain either the 3rd party license or a link to it so it clearly isn't
> sufficient. However, https://issues.apache.org/jira/browse/LEGAL-31, which
> discusses this, is still unresolved.
AIUI, and the way httpd does it, the LICENSE file contains all the licenses in
the distribution, preferably in an annotated fashion so you know which license
goes with which component. The NOTICE file is for any additional required
Copyright statements and/or attribution notices that each license may require.
>
> >>
> >>> The third issue is that Thrift intends to distribute with an LGPL
> >>> dependency on their build system. I'm familiar with the scary language
> >>> adopted by the legal team regarding the LGPL, but don't consider this
> >>> situation to be problematic since it's just a few Makefiles and such.
> >>> Will I need to get special permission from legal for this?
> >>
> >> If they are using Maven 2 and if the LGPL dependency is referenced as a
> >> dependency in the pom such that it is downloaded during the build and is not
> >> distributed with Apache software (or if the build process is functionally
> >> equivalent to this), I personally would have no problem with it being used as
> >> part of the build.
> >
> > It's a C-style project, with C-style Makefiles. Nothing is downloaded during
> > the build process- the LGPL'd Makefiles in question are in subversion and to
> > be distributed within a release package.
>
> My preference is that works under Category X shouldn't be in Apache SVN nor
> should they be distributed as part of an Apache release. I believe that is in
> general alignment with conversations on legal-discuss in the past but I would
> expect that to get answered in the Jira issue, should one be created.
I'll create one if common sense practices are only applicable to JIRA issues.
Bundled LGPL'd build dependencies should be a no-brainer, we'll see what happens.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Thrift release legal issues
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Ralph Goers <ra...@dslextreme.com>
> To: Legal Discuss <le...@apache.org>; general@incubator.apache.org
> Sent: Sunday, August 16, 2009 9:10:11 PM
> Subject: Re: Thrift release legal issues
>
>
> On Aug 16, 2009, at 5:38 PM, Joe Schaefer wrote:
>
> >>
> >> On Aug 16, 2009, at 4:24 PM, Joe Schaefer wrote:
> >>>
> >>> I've also found that there are 6 individuals listed in the
> >>> Facebook CCLA who do not have ICLAs with us and have accordingly
> >>> contacted them as well.
> >>
> >> Was the Facebook CCLA a software grant and were the 6 individuals Facebook
> >> employees (if not, why were they listed in the CCLA)?
> >
> > They were not Facebook employees. The individuals in question were listed
> > as exclusions to the covered contributions. See
> >
> > https://svn.apache.org/repos/private/documents/cclas/facebook-2.pdf
>
> Thanks for the clarification. I would think we would want ICLAs from those 6. I
> don't suppose these folks had to sign anything before the code was contributed
> to Apache? Out of curiosity, what license was the code under before it came to
> Apache?
Basically an MIT license:
http://github.com/schacon/thrift/blob/4fdf4d2e7b44c666c59d8d32f8068b5151e3940a/LICENSE
>
> >
> >>
> >>>
> >>> So the first question is: do we have any contingency strategies
> >>> for the likely situation where not all past contributors to Thrift
> >>> will have paperwork on file in the near future? Can Thrift still
> >>> cut a release or does that block it? Thrift was in fact an open
> >>> source project prior to coming here, and it *has* released stuff under
> >>> an alternate license. Does that mitigate the issue at all?
> >>
> >> See my comment above.
> >>
> >>>
> >>> The second question regards the LICENSE file. I'm accustomed to
> >>> seeing all the licenses for all the code to be distributed listed
> >>> in the LICENSE file, but don't see anywhere within the Incubator
> >>> docs that this concept is mandatory. I've been pushing Thrift to
> >>> do this because that's the way I've usually seen it done but the
> >>> idea hasn't gained any traction with the thrift devs yet. Is there
> >>> such a policy, does it simply constitute best practice, or am I
> >>> barking up the wrong tree?
> >>
> >> I was under the impression the LICENSE file should contain the Apache
> license.
> >> All other licenses should be referenced in the NOTICE file. See
> >> http://www.apache.org/licenses/.
> >
> > That's not the way the Apache HTTPD Server manages their LICENSE file.
> > Each 3rd party component's corresponding license is included in the
> > LICENSE file.
>
> Perhaps I misunderstand how the LICENSE and NOTICE files are to be used then.
> The link above actually includes a link to an HTTPD server NOTICE file as an
> example. That sample NOTICE file does not include the actual license text and
> doesn't contain either the 3rd party license or a link to it so it clearly isn't
> sufficient. However, https://issues.apache.org/jira/browse/LEGAL-31, which
> discusses this, is still unresolved.
AIUI, and the way httpd does it, the LICENSE file contains all the licenses in
the distribution, preferably in an annotated fashion so you know which license
goes with which component. The NOTICE file is for any additional required
Copyright statements and/or attribution notices that each license may require.
>
> >>
> >>> The third issue is that Thrift intends to distribute with an LGPL
> >>> dependency on their build system. I'm familiar with the scary language
> >>> adopted by the legal team regarding the LGPL, but don't consider this
> >>> situation to be problematic since it's just a few Makefiles and such.
> >>> Will I need to get special permission from legal for this?
> >>
> >> If they are using Maven 2 and if the LGPL dependency is referenced as a
> >> dependency in the pom such that it is downloaded during the build and is not
> >> distributed with Apache software (or if the build process is functionally
> >> equivalent to this), I personally would have no problem with it being used as
> >> part of the build.
> >
> > It's a C-style project, with C-style Makefiles. Nothing is downloaded during
> > the build process- the LGPL'd Makefiles in question are in subversion and to
> > be distributed within a release package.
>
> My preference is that works under Category X shouldn't be in Apache SVN nor
> should they be distributed as part of an Apache release. I believe that is in
> general alignment with conversations on legal-discuss in the past but I would
> expect that to get answered in the Jira issue, should one be created.
I'll create one if common sense practices are only applicable to JIRA issues.
Bundled LGPL'd build dependencies should be a no-brainer, we'll see what happens.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Thrift release legal issues
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 16, 2009, at 5:38 PM, Joe Schaefer wrote:
>>
>> On Aug 16, 2009, at 4:24 PM, Joe Schaefer wrote:
>>>
>>> I've also found that there are 6 individuals listed in the
>>> Facebook CCLA who do not have ICLAs with us and have accordingly
>>> contacted them as well.
>>
>> Was the Facebook CCLA a software grant and were the 6 individuals
>> Facebook
>> employees (if not, why were they listed in the CCLA)?
>
> They were not Facebook employees. The individuals in question were
> listed
> as exclusions to the covered contributions. See
>
> https://svn.apache.org/repos/private/documents/cclas/facebook-2.pdf
Thanks for the clarification. I would think we would want ICLAs from
those 6. I don't suppose these folks had to sign anything before the
code was contributed to Apache? Out of curiosity, what license was the
code under before it came to Apache?
>
>>
>>>
>>> So the first question is: do we have any contingency strategies
>>> for the likely situation where not all past contributors to Thrift
>>> will have paperwork on file in the near future? Can Thrift still
>>> cut a release or does that block it? Thrift was in fact an open
>>> source project prior to coming here, and it *has* released stuff
>>> under
>>> an alternate license. Does that mitigate the issue at all?
>>
>> See my comment above.
>>
>>>
>>> The second question regards the LICENSE file. I'm accustomed to
>>> seeing all the licenses for all the code to be distributed listed
>>> in the LICENSE file, but don't see anywhere within the Incubator
>>> docs that this concept is mandatory. I've been pushing Thrift to
>>> do this because that's the way I've usually seen it done but the
>>> idea hasn't gained any traction with the thrift devs yet. Is there
>>> such a policy, does it simply constitute best practice, or am I
>>> barking up the wrong tree?
>>
>> I was under the impression the LICENSE file should contain the
>> Apache license.
>> All other licenses should be referenced in the NOTICE file. See
>> http://www.apache.org/licenses/.
>
> That's not the way the Apache HTTPD Server manages their LICENSE file.
> Each 3rd party component's corresponding license is included in the
> LICENSE file.
Perhaps I misunderstand how the LICENSE and NOTICE files are to be
used then. The link above actually includes a link to an HTTPD server
NOTICE file as an example. That sample NOTICE file does not include
the actual license text and doesn't contain either the 3rd party
license or a link to it so it clearly isn't sufficient. However, https://issues.apache.org/jira/browse/LEGAL-31
, which discusses this, is still unresolved.
>>
>>> The third issue is that Thrift intends to distribute with an LGPL
>>> dependency on their build system. I'm familiar with the scary
>>> language
>>> adopted by the legal team regarding the LGPL, but don't consider
>>> this
>>> situation to be problematic since it's just a few Makefiles and
>>> such.
>>> Will I need to get special permission from legal for this?
>>
>> If they are using Maven 2 and if the LGPL dependency is referenced
>> as a
>> dependency in the pom such that it is downloaded during the build
>> and is not
>> distributed with Apache software (or if the build process is
>> functionally
>> equivalent to this), I personally would have no problem with it
>> being used as
>> part of the build.
>
> It's a C-style project, with C-style Makefiles. Nothing is
> downloaded during
> the build process- the LGPL'd Makefiles in question are in
> subversion and to
> be distributed within a release package.
My preference is that works under Category X shouldn't be in Apache
SVN nor should they be distributed as part of an Apache release. I
believe that is in general alignment with conversations on legal-
discuss in the past but I would expect that to get answered in the
Jira issue, should one be created.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Thrift release legal issues
Posted by Ralph Goers <ra...@dslextreme.com>.
On Aug 16, 2009, at 5:38 PM, Joe Schaefer wrote:
>>
>> On Aug 16, 2009, at 4:24 PM, Joe Schaefer wrote:
>>>
>>> I've also found that there are 6 individuals listed in the
>>> Facebook CCLA who do not have ICLAs with us and have accordingly
>>> contacted them as well.
>>
>> Was the Facebook CCLA a software grant and were the 6 individuals
>> Facebook
>> employees (if not, why were they listed in the CCLA)?
>
> They were not Facebook employees. The individuals in question were
> listed
> as exclusions to the covered contributions. See
>
> https://svn.apache.org/repos/private/documents/cclas/facebook-2.pdf
Thanks for the clarification. I would think we would want ICLAs from
those 6. I don't suppose these folks had to sign anything before the
code was contributed to Apache? Out of curiosity, what license was the
code under before it came to Apache?
>
>>
>>>
>>> So the first question is: do we have any contingency strategies
>>> for the likely situation where not all past contributors to Thrift
>>> will have paperwork on file in the near future? Can Thrift still
>>> cut a release or does that block it? Thrift was in fact an open
>>> source project prior to coming here, and it *has* released stuff
>>> under
>>> an alternate license. Does that mitigate the issue at all?
>>
>> See my comment above.
>>
>>>
>>> The second question regards the LICENSE file. I'm accustomed to
>>> seeing all the licenses for all the code to be distributed listed
>>> in the LICENSE file, but don't see anywhere within the Incubator
>>> docs that this concept is mandatory. I've been pushing Thrift to
>>> do this because that's the way I've usually seen it done but the
>>> idea hasn't gained any traction with the thrift devs yet. Is there
>>> such a policy, does it simply constitute best practice, or am I
>>> barking up the wrong tree?
>>
>> I was under the impression the LICENSE file should contain the
>> Apache license.
>> All other licenses should be referenced in the NOTICE file. See
>> http://www.apache.org/licenses/.
>
> That's not the way the Apache HTTPD Server manages their LICENSE file.
> Each 3rd party component's corresponding license is included in the
> LICENSE file.
Perhaps I misunderstand how the LICENSE and NOTICE files are to be
used then. The link above actually includes a link to an HTTPD server
NOTICE file as an example. That sample NOTICE file does not include
the actual license text and doesn't contain either the 3rd party
license or a link to it so it clearly isn't sufficient. However, https://issues.apache.org/jira/browse/LEGAL-31
, which discusses this, is still unresolved.
>>
>>> The third issue is that Thrift intends to distribute with an LGPL
>>> dependency on their build system. I'm familiar with the scary
>>> language
>>> adopted by the legal team regarding the LGPL, but don't consider
>>> this
>>> situation to be problematic since it's just a few Makefiles and
>>> such.
>>> Will I need to get special permission from legal for this?
>>
>> If they are using Maven 2 and if the LGPL dependency is referenced
>> as a
>> dependency in the pom such that it is downloaded during the build
>> and is not
>> distributed with Apache software (or if the build process is
>> functionally
>> equivalent to this), I personally would have no problem with it
>> being used as
>> part of the build.
>
> It's a C-style project, with C-style Makefiles. Nothing is
> downloaded during
> the build process- the LGPL'd Makefiles in question are in
> subversion and to
> be distributed within a release package.
My preference is that works under Category X shouldn't be in Apache
SVN nor should they be distributed as part of an Apache release. I
believe that is in general alignment with conversations on legal-
discuss in the past but I would expect that to get answered in the
Jira issue, should one be created.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Thrift release legal issues
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Ralph Goers <ra...@dslextreme.com>
> To: general@incubator.apache.org
> Cc: Legal Discuss <le...@apache.org>
> Sent: Sunday, August 16, 2009 8:13:37 PM
> Subject: Re: Thrift release legal issues
>
> See below. First, this should have been asked on legal-discuss. Second, the
> answers below are just my opinion.
>
> On Aug 16, 2009, at 4:24 PM, Joe Schaefer wrote:
>
> > I'm trying to coax out a release of Apache Thrift and ran into a
> > few obstacles. Maybe you can offer me a little guidance?
> >
> > First, I found that the CCLA from Facebook excludes
> > contributions from 3rd parties who wrote code for Thrift
> > prior to the move to Apache. With the exception of imeem.com,
> > all of the corporate entities appear to have a CCLA on file
> > with us. I've attempted to contact the folks from imeem.com
> > to request that a CCLA be filed for their Thrift work.
> >
> > I've also found that there are 6 individuals listed in the
> > Facebook CCLA who do not have ICLAs with us and have accordingly
> > contacted them as well.
>
> Was the Facebook CCLA a software grant and were the 6 individuals Facebook
> employees (if not, why were they listed in the CCLA)?
They were not Facebook employees. The individuals in question were listed
as exclusions to the covered contributions. See
https://svn.apache.org/repos/private/documents/cclas/facebook-2.pdf
> If they did their
> development on behalf of Facebook then as I understand it Facebook owns the
> rights to the software and ICLAs shouldn't be required. The software grant from
> Facebook would be enough.
It isn't.
>
> >
> > So the first question is: do we have any contingency strategies
> > for the likely situation where not all past contributors to Thrift
> > will have paperwork on file in the near future? Can Thrift still
> > cut a release or does that block it? Thrift was in fact an open
> > source project prior to coming here, and it *has* released stuff under
> > an alternate license. Does that mitigate the issue at all?
>
> See my comment above.
>
> >
> > The second question regards the LICENSE file. I'm accustomed to
> > seeing all the licenses for all the code to be distributed listed
> > in the LICENSE file, but don't see anywhere within the Incubator
> > docs that this concept is mandatory. I've been pushing Thrift to
> > do this because that's the way I've usually seen it done but the
> > idea hasn't gained any traction with the thrift devs yet. Is there
> > such a policy, does it simply constitute best practice, or am I
> > barking up the wrong tree?
>
> I was under the impression the LICENSE file should contain the Apache license.
> All other licenses should be referenced in the NOTICE file. See
> http://www.apache.org/licenses/.
That's not the way the Apache HTTPD Server manages their LICENSE file.
Each 3rd party component's corresponding license is included in the
LICENSE file.
>
> > The third issue is that Thrift intends to distribute with an LGPL
> > dependency on their build system. I'm familiar with the scary language
> > adopted by the legal team regarding the LGPL, but don't consider this
> > situation to be problematic since it's just a few Makefiles and such.
> > Will I need to get special permission from legal for this?
>
> If they are using Maven 2 and if the LGPL dependency is referenced as a
> dependency in the pom such that it is downloaded during the build and is not
> distributed with Apache software (or if the build process is functionally
> equivalent to this), I personally would have no problem with it being used as
> part of the build.
It's a C-style project, with C-style Makefiles. Nothing is downloaded during
the build process- the LGPL'd Makefiles in question are in subversion and to
be distributed within a release package.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Thrift release legal issues
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message ----
> From: Ralph Goers <ra...@dslextreme.com>
> To: general@incubator.apache.org
> Cc: Legal Discuss <le...@apache.org>
> Sent: Sunday, August 16, 2009 8:13:37 PM
> Subject: Re: Thrift release legal issues
>
> See below. First, this should have been asked on legal-discuss. Second, the
> answers below are just my opinion.
>
> On Aug 16, 2009, at 4:24 PM, Joe Schaefer wrote:
>
> > I'm trying to coax out a release of Apache Thrift and ran into a
> > few obstacles. Maybe you can offer me a little guidance?
> >
> > First, I found that the CCLA from Facebook excludes
> > contributions from 3rd parties who wrote code for Thrift
> > prior to the move to Apache. With the exception of imeem.com,
> > all of the corporate entities appear to have a CCLA on file
> > with us. I've attempted to contact the folks from imeem.com
> > to request that a CCLA be filed for their Thrift work.
> >
> > I've also found that there are 6 individuals listed in the
> > Facebook CCLA who do not have ICLAs with us and have accordingly
> > contacted them as well.
>
> Was the Facebook CCLA a software grant and were the 6 individuals Facebook
> employees (if not, why were they listed in the CCLA)?
They were not Facebook employees. The individuals in question were listed
as exclusions to the covered contributions. See
https://svn.apache.org/repos/private/documents/cclas/facebook-2.pdf
> If they did their
> development on behalf of Facebook then as I understand it Facebook owns the
> rights to the software and ICLAs shouldn't be required. The software grant from
> Facebook would be enough.
It isn't.
>
> >
> > So the first question is: do we have any contingency strategies
> > for the likely situation where not all past contributors to Thrift
> > will have paperwork on file in the near future? Can Thrift still
> > cut a release or does that block it? Thrift was in fact an open
> > source project prior to coming here, and it *has* released stuff under
> > an alternate license. Does that mitigate the issue at all?
>
> See my comment above.
>
> >
> > The second question regards the LICENSE file. I'm accustomed to
> > seeing all the licenses for all the code to be distributed listed
> > in the LICENSE file, but don't see anywhere within the Incubator
> > docs that this concept is mandatory. I've been pushing Thrift to
> > do this because that's the way I've usually seen it done but the
> > idea hasn't gained any traction with the thrift devs yet. Is there
> > such a policy, does it simply constitute best practice, or am I
> > barking up the wrong tree?
>
> I was under the impression the LICENSE file should contain the Apache license.
> All other licenses should be referenced in the NOTICE file. See
> http://www.apache.org/licenses/.
That's not the way the Apache HTTPD Server manages their LICENSE file.
Each 3rd party component's corresponding license is included in the
LICENSE file.
>
> > The third issue is that Thrift intends to distribute with an LGPL
> > dependency on their build system. I'm familiar with the scary language
> > adopted by the legal team regarding the LGPL, but don't consider this
> > situation to be problematic since it's just a few Makefiles and such.
> > Will I need to get special permission from legal for this?
>
> If they are using Maven 2 and if the LGPL dependency is referenced as a
> dependency in the pom such that it is downloaded during the build and is not
> distributed with Apache software (or if the build process is functionally
> equivalent to this), I personally would have no problem with it being used as
> part of the build.
It's a C-style project, with C-style Makefiles. Nothing is downloaded during
the build process- the LGPL'd Makefiles in question are in subversion and to
be distributed within a release package.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org