[jira] [Updated] (LEGAL-155) Please help us educate projects about LICENSE and NOTICE

["Benson Margulies (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LEGAL-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benson Margulies updated LEGAL-155:
-----------------------------------

    Description: 
Dear Legal,

The incubator continues to struggle to educate projects in the proper construction and maintenance of LICENSE and NOTICE files. INCUBATOR-125 is an attempt to write some documentation. This document suffers from its authors' inability to even find a single point of reference on the ASF website for theory of these files. 

Since podlings are unusual only in their need to set up initial versions, it seems to me that most of this documentation should be produced and maintained at the foundation level, and the incubator should be pointing to it, instead of maintain detailed alternatives with risk of divergence.

If there is existing documentation, please comment and point me to it. If there is not, can we collaborate to write it?

In this area, I have a particular curiosity and concern about convenience binaries.

A typical Apache project has very limited needs for complexity in these files for its *releases*. Only sources with external provenance (e.g., results of an SGA) or bundled dependencies trigger it. Far more dependencies get bundled in convenience binaries. But convenience binaries are, merely, conveniences, not legally, releases from the foundation. I've never seen any discussion of this; does the foundation's liability umbrella even extend over them? I doubt it, for all the usual reasons given in emphasizing that the real release is the source release. So I wonder about what policies or guidelines should exist for their legal boilerplate.


  was:
Dear Legal,

The incubator continues to struggle to educate projects in the proper construction and maintenance of LICENSE and NOTICE files. INCUBATOR-125 is an attempt to write some documentation. This document suffers from its authors' inability to even find a single point of reference on the ASF website for theory of these files. 

Since podlings are unusual only in their need to set up initial versions, it seems to me that most of this documentation should be produced and maintained at the foundation level, and the incubator should be pointing to it, instead of maintain detailed alternatives with risk of divergence.

If there is existing documentation, please comment and point me to it. If there is not, can we collaborate to write it?

In this area, I have a particular curiosity and concern about convenience binaries.

A typical Apache project has very limited needs for complexity in these files for it's *releases*. Only sources with external provenance (e.g., results of an SGA) or bundled dependencies trigger it. Far more dependencies get bundled in convenience binaries. But convenience binaries are, merely, conveniences, not legally, releases from the foundation. I've never seen any discussion of this; does the foundation's liability umbrella even extend over them? I doubt it, for all the usual reasons given in emphasizing that the real release is the source release. So I wonder about what policies or guidelines should exist for their legal boilerplate.


    
> Please help us educate projects about LICENSE and NOTICE
> --------------------------------------------------------
>
>                 Key: LEGAL-155
>                 URL: https://issues.apache.org/jira/browse/LEGAL-155
>             Project: Legal Discuss
>          Issue Type: Task
>            Reporter: Benson Margulies
>
> Dear Legal,
> The incubator continues to struggle to educate projects in the proper construction and maintenance of LICENSE and NOTICE files. INCUBATOR-125 is an attempt to write some documentation. This document suffers from its authors' inability to even find a single point of reference on the ASF website for theory of these files. 
> Since podlings are unusual only in their need to set up initial versions, it seems to me that most of this documentation should be produced and maintained at the foundation level, and the incubator should be pointing to it, instead of maintain detailed alternatives with risk of divergence.
> If there is existing documentation, please comment and point me to it. If there is not, can we collaborate to write it?
> In this area, I have a particular curiosity and concern about convenience binaries.
> A typical Apache project has very limited needs for complexity in these files for its *releases*. Only sources with external provenance (e.g., results of an SGA) or bundled dependencies trigger it. Far more dependencies get bundled in convenience binaries. But convenience binaries are, merely, conveniences, not legally, releases from the foundation. I've never seen any discussion of this; does the foundation's liability umbrella even extend over them? I doubt it, for all the usual reasons given in emphasizing that the real release is the source release. So I wonder about what policies or guidelines should exist for their legal boilerplate.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

Re: [jira] [Updated] (LEGAL-155) Please help us educate projects about LICENSE and NOTICE

[Benson Margulies <bi...@gmail.com>]

On Sun, Jan 13, 2013 at 6:48 PM, Lawrence Rosen <lr...@rosenlaw.com> wrote:
> <snip>
> Benson Margulies wrote:
>> In this area, I have a particular curiosity and concern about convenience binaries.
>>
>> A typical Apache project has very limited needs for complexity in these files for
>> its *releases*. Only sources with external provenance (e.g., results of an SGA)
>> or bundled dependencies trigger it. Far more dependencies get bundled in
>> convenience binaries. But convenience binaries are, merely, conveniences,
>> not legally, releases from the foundation. I've never seen any discussion of
>> this; does the foundation's liability umbrella even extend over them? I doubt it,
>> for all the usual reasons given in emphasizing that the real release is the
>> source release. So I wonder about what policies or guidelines should exist
>> for their legal boilerplate.



>
> *****
>
> Thanks for raising these questions, Benson. I've also wondered about some of these undocumented Apache procedures. It sounds like you've given them careful thought, at least in the Incubator.
>
> From a legal perspective, Apache shouldn't need to distinguish between binary distribution and source distribution of FOSS works. Even the US Copyright Act and the Library of Congress do not consider these to be independent works for copyright purposes (although the procedures for registering copyrights in “trade secret" software might apply if we weren’t entirely open source). There is no such thing as a "convenience binary", except perhaps as a special Apache term I’ve never heard before.

Larry,

The foundation, as a matter of policy, takes the following position:

The Foundation takes responsibility, and indemnifies people for,
releases that are formally approved via the vote of the releasing PMC.
Since there is no practical way for PMCs to validate the content of
binary releases, these must be *source* releases. There is an ongoing
discussion about the possibility of building up the technological
infrastructure to produce trusted binaries, and, if that ever happens,
I imagine that the policy discussion will reopen.

As I understand the history, once upon a time, Apache PMCs did not
create binaries *at all*. If some third party wanted to take an Apache
source release, compile it, and offer up the resulting binaries, they
could, and various people did. At some later time, PMCs started
creating and publishing binaries themselves. However, as I understand
it, the policy I described above still applied/applies, there are not
officially indemnified releases of the Foundation.

My goal is to have a web page that says:

" All Apache Releases contain two files that describe their IP
content. The LICENSE file contains the license terms under which the
released content is offered for use. It will alway start with the AL
2.0 and then ... The NOTICE file contains ...."

And then I get stuck, since I don't, personally, have a grip on how to
describe 'some of the content of this release was originally released
under other licenses that allow for relicensing under the AL 2.0.
We've incorporated it, relicensed it as AL 2.0, and put the original
notice here."

Or maybe I do, and I wish someone would tell me if that's the right description.



>
> For FOSS and certainly for Apache software that we distribute, I believe a *source version* is always made available. Otherwise, it isn’t FOSS and it certainly isn’t from Apache. Do any Apache projects ever distribute binary software that is not also *available* from us in source form?
>
> Meanwhile, the choice of whether to distribute source or binary version(s) has nothing to do with legal convenience. The decision should be entirely a technical one, based on customer convenience mostly, as determined by the project itself. Perhaps that's what Benson means by "convenience binary"?
>
> As for LICENSE and NOTICE files, I would expect these to accompany *every* Apache distribution regardless of whether it is in binary or source form. These LICENSE and NOTICE files can be created according to specific guidelines (TBD), but they should be made available with each distribution of Apache software so that downstream redistributors and end-users have full knowledge of the important licenses and notices that apply to that Apache software regardless of which form they find it in.
>
> I generally advise my clients (but Apache is NOT one of my clients, so do your own thing!) to follow these simple rules for LICENSE and NOTICE files:
>
> 1. Always publish in the LICENSE file the text of any licenses that apply to the software, in addition to the Apache License. In some situations it is more convenient to publish that text on a website and merely point to it from the LICENSE file.
>
> 2. Always make the complete source version of whatever is distributed available on a website and point to it from a NOTICE file. Sometimes it is more convenient to simply distribute the source version directly, but that shouldn't stop you from also including a NOTICE file with an appropriate permanent website link.
>
> 3. Other contents of the NOTICE file would probably be project-specific. For example (and this is NOT Apache policy but my own suggestion), it is very helpful to downstream redistributors and users of Apache software to learn about patent assertions (even if you don't agree with them); standards compliance of the software;  special compatibility announcements; links back to the Apache project; etc. Perhaps every NOTICE file ought to contain a standard Apache disclaimer of liability or warranty?
>
> /Larry
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

RE: [jira] [Updated] (LEGAL-155) Please help us educate projects about LICENSE and NOTICE

[Lawrence Rosen <lr...@rosenlaw.com>]

<snip>
Benson Margulies wrote:
> In this area, I have a particular curiosity and concern about convenience binaries.
>
> A typical Apache project has very limited needs for complexity in these files for 
> its *releases*. Only sources with external provenance (e.g., results of an SGA) 
> or bundled dependencies trigger it. Far more dependencies get bundled in 
> convenience binaries. But convenience binaries are, merely, conveniences, 
> not legally, releases from the foundation. I've never seen any discussion of
> this; does the foundation's liability umbrella even extend over them? I doubt it,
> for all the usual reasons given in emphasizing that the real release is the
> source release. So I wonder about what policies or guidelines should exist
> for their legal boilerplate.

*****

Thanks for raising these questions, Benson. I've also wondered about some of these undocumented Apache procedures. It sounds like you've given them careful thought, at least in the Incubator.

>From a legal perspective, Apache shouldn't need to distinguish between binary distribution and source distribution of FOSS works. Even the US Copyright Act and the Library of Congress do not consider these to be independent works for copyright purposes (although the procedures for registering copyrights in “trade secret" software might apply if we weren’t entirely open source). There is no such thing as a "convenience binary", except perhaps as a special Apache term I’ve never heard before. 

For FOSS and certainly for Apache software that we distribute, I believe a *source version* is always made available. Otherwise, it isn’t FOSS and it certainly isn’t from Apache. Do any Apache projects ever distribute binary software that is not also *available* from us in source form? 

Meanwhile, the choice of whether to distribute source or binary version(s) has nothing to do with legal convenience. The decision should be entirely a technical one, based on customer convenience mostly, as determined by the project itself. Perhaps that's what Benson means by "convenience binary"? 

As for LICENSE and NOTICE files, I would expect these to accompany *every* Apache distribution regardless of whether it is in binary or source form. These LICENSE and NOTICE files can be created according to specific guidelines (TBD), but they should be made available with each distribution of Apache software so that downstream redistributors and end-users have full knowledge of the important licenses and notices that apply to that Apache software regardless of which form they find it in.

I generally advise my clients (but Apache is NOT one of my clients, so do your own thing!) to follow these simple rules for LICENSE and NOTICE files:

1. Always publish in the LICENSE file the text of any licenses that apply to the software, in addition to the Apache License. In some situations it is more convenient to publish that text on a website and merely point to it from the LICENSE file. 

2. Always make the complete source version of whatever is distributed available on a website and point to it from a NOTICE file. Sometimes it is more convenient to simply distribute the source version directly, but that shouldn't stop you from also including a NOTICE file with an appropriate permanent website link.

3. Other contents of the NOTICE file would probably be project-specific. For example (and this is NOT Apache policy but my own suggestion), it is very helpful to downstream redistributors and users of Apache software to learn about patent assertions (even if you don't agree with them); standards compliance of the software;  special compatibility announcements; links back to the Apache project; etc. Perhaps every NOTICE file ought to contain a standard Apache disclaimer of liability or warranty?

/Larry




---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org