www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Schmidt <cliffschm...@gmail.com>
Subject Re: Plans for Apache Licensing Policy
Date Tue, 11 Oct 2005 16:28:30 GMT
On 10/6/05, Jeffrey Thompson <jthom@us.ibm.com> wrote:
>
> Cliff,
>    Thank you for getting the discussion started on these points.
>
> "Cliff Schmidt" <cliffschmidt@gmail.com> wrote on 10/06/2005 08:35:13 AM:
>
>  > I'm working on an ASF licensing policy.
>  >
>  > I hope to have a draft available
>  > within the next couple weeks, but I thought I'd start by asking folks on
>  > this list for any feedback on the scope of the document and the direction
>  > I'm leaning for each issue.  Please note the last issue on releasing
>  > distributions under a single Apache License or using multiple licenses.
>  >
>  > Here is a preview of the questions I want to answer and the possible
> answers:
>  >
>  > 1. What notice should go at the top of all ASF-developed source files?
>  >      (this will change from what is done now to better reflect
>  >       the multiple copyrights involved)
>  >
>  > 2. Where should any copyright notice be placed
>  >      (in the NOTICE file or possibly new COPYRIGHT file -- the
>  >       answer will not be "in the source files")
>
> Some notice would need to be in every file, right?  I think Apache members
> generally looks at code from the project down, that is, they know what
> project they are dealing with and they are examining the files to find out
> what code is in it.  I've had many circumstances where I have a .java or .c
> file, and only a file. I'm looking at the file and trying to figure out
> where it came from, who wrote it, what license it is under, etc.  Without
> something in each file, how would I know?

Without something over each line of contributed code, you wouldn't
know who contributed each...unless you looked in the source repository
log file or asked one of the committers to do so for you.  If you want
to know the entire set of individuals and entities with some claim of
copyright on some part of the distribution you would look in either
the NOTICE or COPYRIGHT file (tbd).

Here's what I will be proposing go at the top of every source file:

---BEGIN PROPOSED SOURCE FILE HEADER---
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  The ASF licenses this file to You
  under the Apache License, Version 2.0 (the "License"); you may not
  use this file except in compliance with the License.
  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
---END PROPOSED SOURCE FILE HEADER---

>
> >
>  > 3. Who can place a copyright notice in the file?
>  >      (I think the answer should be any individual
>  >       or entity who's IP ends up in the project's
>  >       source control)
>
> The two obvious answers are any of the original authors of the file and
> Apache (the original authors because they own the copyright and Apache
> because they are licensed).  If we are worried about some unrelated third
> party adding copyright notices, I'm not aware of any legal case where a
> third party has added a truthful copyright notice and it was found to be a
> problem.

Not worried about that.  Just need to be clear that it would not only
be the company that contributed the starter code, for instance.  It
would be a place to list all individual and entity IP owners, of
contributions large and small.

>  > 4. What exactly is a committer supposed to do when offered a patch?
>  >      (e.g. get explicit confirmation on the mailing
>  >       list that contributor acknowledges that they
>  >       are licensing their IP under AL2 and that they
>  >       do not work for an employer who has claims on
>  >       the IP they generate -- might be simpler to put
>  >       a statement like this on a "Terms of Use" page
>  >       and just have a committer ask the contributor
>  >       to acknowledge they agree to those terms.)
>
> That's one of the reasons why CLAs from all contributors is a good idea.
> Those issues are already addressed.  Failing that, a bugzilla signon notice
> is a good step, as Justin M observed.  Including a notice in the
> subscription details of the mailing list would be great, as long as only
> subscribers can submit patches.  You might want to consider a periodic
> (monthly) sending of the basic mailing list info (including the notice).  I
> don't know if Apache does that, but many other lists do and its not THAT
> annoying.  I tend to like it because I don't have to save the original
> notice for years just in case I want to unsubscribe or modify my
> subscription.  I know that I'm on average only 2 weeks away from getting a
> new one.

Thanks -- definitely some good ideas to consider.  Although I don't
think there would be much support for requiring ALL contributors to
sign a CLA.

> The theoretical problem of relying solely on the AL2 terms is that a patch
> could be an entirely new work (not based on any AL2 licensed code).  If it
> was a small class file, that's not out of the question.

yep - I also think that most contributors have not read and understood
that aspect of AL2.

>
> >
>  > 5. What info should be in commit log for non-committer IP?
>  >      (e.g. msgid of contributor acknowledging terms)
>  >
>  > 6. What text should be included in any -dev list "welcome" msg?
>  >      (e.g. reference to the "Terms of Use"-like
>  >       contributor guidelines)
>
> Text that explicitly states that submissions are under AL2 would be better.
> No need to follow a link.

sure -- no need to follow a link - just to make sure the AL2 is
exactly what we need to refer to.  I think it is, but I was leaving
room for any other needs there.

>  > 7. Should all mailing lists have footers referencing such "Terms of Use"?
>  >      (more notice is better from a legal perspective,
>  >       but I tend to think the other measures are enough)
>
> Right, more is better.
>
> >
>  > 8. What are the allowable methods of receiving a contribution?
>  >      (e.g. Jira/Bugzilla, -dev list attachments,
>  >       but definitely not from private/direct email)
>
> One person's opinion -- there should be a single official channel (maybe 2
> if one is for bulk contributions and one is for patches).  But both should
> be official, tracked, contain the right notices, etc.

agree that both should be tracked, but I'm not sure that there would
be support within Apache to require all contributions to go through
bug tracking.  I think bug tracking + mailing list - and ensuring we
have good records of both and methods of ensuring the contributor
understands the licensing no matter which method they use.

> >
>  > 9. When an Apache project includes third-party code (any packages
>  >    created outside the Apache process), what should be done to the
>  >    copyright and licensing notices?
>  >      (They should not be touched.  However, if the
>  >       third-party code is source contributed by the
>  >       IP owner to be evolved within the ASF, such
>  >       as initial code for an incubating project,
>  >       then we will require that they follow the same
>  >       copyright and notice guidelines that apply to
>  >       ASF-developed code -- see questions #1-3)
>
> Right.  If its 'source contributed', isn't it just another contribution?

I was mainly referring to properly-licensed third-party libraries that
are included within an Apache distribution without getting each
copyright holder to sign and submit a software grant.

> >
>  > 10. What legal review/checklist should be completed by the PMC prior
>  >     to each new release?
>  >       (This is something I will develop to include BXA/crypto checks
>  >        and a review of allowable licenses, etc.)
>  >
>  > 11. What exactly goes in a NOTICE file?  What does not go there?
>  >       (e.g. see existing file on /licenses page, but will also
>  >        add more clarification that it should include no new terms,
>  >        but may or may not be the right place for committer
>  >        copyright notices -- see questions #2 and 3)
>
> Notices are great, as long as it is EXPLICITLY clear that the terms of the
> license aren't being modified.

agreed

>  > 12. What exactly goes in the LICENSE file?
>  >       (e.g. a copy of the Apache License, Version 2,
>  >        *plus* a copy of all other licenses that apply
>  >        to included IP -- an alternative option may be
>  >        to use a /LICENSE directory containing all
>  >        licenses)
>
> If Apache is shipping components under other licenses, wouldn't they have
> their own LICENSE files?  What is referred to by "included IP"?

yes - but I think it is important for there to be one location for a
user to look to see all the licenses applicable to the distribution as
a whole -- rather than having to dig into each component and find a
nearby license file.  This could mean appending all licenses to the
top-level LICENSE file, or it could mean putting them all in a LICENSE
directory.

> >
>  > 13. Must all ASF releases be solely licensed under the Apache License
>  >     or a license with fewer conditions?
>  >       (This is the area where different projects at
>  >        the ASF are doing different things.  I used to
>  >        subscribe to the idea that we license only
>  >        under the Apache License, which means that we
>  >        are able to sublicense everything else we want
>  >        to include.  However, I now don't believe this
>  >        "sublicense strategy" is feasible.  Licenses
>  >        such as the CPL, MIT, and the W3C Software
>  >        License all have terms that either make
>  >        proper sublicensing impossible, or at the very
>  >        least mislead our users by doing so.  Therefore,
>  >        I am going to propose that we formally allow
>  >        shipping distributions under multiple licenses;
>  >        however, that will require that the Apache
>  >        community determine what makes a license
>  >        acceptable or unacceptable.  This aspect will
>  >        not be covered in the first release of Licensing
>  >        Policy -- but I will try to drive that discussion
>  >        in parallel.)
>
> There's a lot of work in this question.

you're telling me...  ;-)

> >
>  >
>  > Cliff
>  >
>
>
> Staff Counsel, IBM Corporation  (914)766-1757  (tie)8-826  (fax) -8160
>  (notes) jthom@ibmus  (internet) jthom@us.ibm.com (home) jeff@beff.net
>  (web) http://www.beff.net/
>
>

---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message