Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread William A Rowe Jr 
On Thu, Aug 20, 2015 at 8:52 AM, Jim Jagielski  wrote:

>
> A snapshot is not a release. Licenses "kick in" at distribution/
> release.
>

Lets just imagine if Jim, VP Legal is actually correct in his
interpretation, and that there are no AL 2.0 licenses applicable to our
source code repositories, svn or git.

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

2. Grant of Copyright License. Subject to the terms and conditions of this
License, each Contributor hereby grants to You a perpetual, worldwide,
non-exclusive, no-charge, royalty-free, irrevocable copyright license to
reproduce, prepare Derivative Works of, publicly display, publicly perform,
sublicense, and distribute the Work and such Derivative Works in Source or
Object form.

No, you may not modify the sources or derive those that reside within
version control of the ASF, until and upon the time when the project has
blessed that project as a release.  Patches to others' contributions to
source code control are not within the scope of this imaginary non-license
application.

3. Grant of Patent License. Subject to the terms and conditions of this
License, each Contributor hereby grants to You a perpetual, worldwide,
non-exclusive, no-charge, royalty-free, irrevocable (except as stated in
this section) patent license to make, have made, use, offer to sell, sell,
import, and otherwise transfer the Work, where such license applies only to
those patent claims licensable by such Contributor that are necessarily
infringed by their Contribution(s) alone or by combination of their
Contribution(s) with the Work to which such Contribution(s) was submitted.
If You institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work or a
Contribution incorporated within the Work constitutes direct or
contributory patent infringement, then any patent licenses granted to You
under this License for that Work shall terminate as of the date such
litigation is filed.

No, you may absolutely not test the code that has been committed to source
control without a patent license, which you do not have, until that time
when the ASF blesses the work and calls it a release.

4. Redistribution. You may reproduce and distribute copies of the Work or
Derivative Works thereof in any medium, with or without modifications, and
in Source or Object form

None of that, it's all straight out, none of it applies to your work at the
ASF until the release is blessed.  That includes passing off a patched fork
of a security fix to a reporter who claimed there was a defect in the
earlier release.

5. Submission of Contributions. Unless You explicitly state otherwise, any
Contribution intentionally submitted for inclusion in the Work by You to
the Licensor shall be under the terms and conditions of this License

Except when it isn't in Ross's and our VP Legal's own minds...

6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor, except
as required for reasonable and customary use in describing the origin of
the Work and reproducing the content of the NOTICE file.

Which wasn't a right in the first place, so no change here under any
interpretation...

7. Disclaimer of Warranty. Unless required by applicable law or agreed to
in writing, Licensor provides the Work (and each Contributor provides its
Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied, including, without limitation, any
warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or
FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for
determining the appropriateness of using or redistributing the Work and
assume any risks associated with Your exercise of permissions under this
License.

Except that perhaps the ASF is liable, under our VP Legal's interpretation,
for works which do reside in source control and were not, in fact, released
to the general public?  [Ad nauseam 8. and 9.]

Let's just not go this direction, because it is plainly false. Jim, it
would truly be helpful if you spoke up for or in contradiction to your
earlier statements, here...

Cheers,

Bill

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread William A Rowe Jr 
On Thu, Aug 20, 2015 at 9:11 PM, Christopher  wrote:

> It sounds to me like you're saying that the license under which code is
> offered (to anybody who encounters it) is independent of the license
> declaration attached to the project.
>

No, the license is that which was granted by the author, and I think you
missed my followup by a few minutes, so I will quote myself here...

"Your comment also hones in on the logical fallacy our VP fell into...
While it may be true that the ASF granted its own AL 2.0 license to the
release package, the ASF is unable to change component licenses in
incompatible ways.  And the warranty the ASF offers on an inaccurate
license claims is - nil - c.f. AL 2.0"

"However, if our repositories are under another license, that VP needs to
make public this information, because I never got the memo, and I must
notify friends and the many companies I advise and consult to that they all
need to cease looking at the ASF's repositories, and let their respective
legal departments each sort this all out, if those repositories are
licensed with terms and conditions differing from the AL 2.0."
Obviously, I think our VP Legal isn't taking his job seriously of advising
the community on the specific legal particularities of the software we
create, which is why I'm going to stand pat until someone offers up a
compelling argument over why anyone is not able to take any of the AL 2.0
code out of ASF repositories, released or not, and re-purpose it for
whatever they desire.

But don't name it by "Apache {foo}" unless {foo} PMC sanctioned the release
of the code.  It's entirely in trademark law, and our license and copyright
law gives them everything they need to utilize the code, "released" or not.

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Christopher 
It sounds to me like you're saying that the license under which code is
offered (to anybody who encounters it) is independent of the license
declaration attached to the project.

This makes sense to me, presuming that we still agree that the license
declaration (header or license file) is the best way to communicate the
license under which the code is offered.

It seems to follow, then, that were saying that there are sometimes errors
in the declaration, where it doesn't reflect what license the code is
actually offered under (if any). Further, we're saying that this is
hopefully less likely in a release, which has been vetted with greater
scrutiny.

Is that right?

If so, then it seems to me that the question really becomes: is it
sufficiently communicated by the very fact of being a snapshot (any state
of the code other than in a release), that errors are possible in the
license? I would think the answer is yes, personally. However, I'm not sure
it really means much, because it's still reasonable for people to assume
the license declaration is correct, until shown otherwise.

It seems to me that the very fact that any license declaration is attached
to the code at all, regardless of its state as a release or snapshot,
shifts the burden of responsibility to actually demonstrate that the
license does not apply. This is the reverse of the case when no obvious
license declaration is made. The burden in that case is to show that the
license does apply. Isn't that why we explicitly put headers on each file,
in addition to the LICENSE file? To explicitly shift this burden to us in
order to encourage free use of our software by others?

On Thu, Aug 20, 2015, 21:19 William A Rowe Jr  wrote:

> On Aug 20, 2015 7:39 PM, "Alex Harui"  wrote:
> >
> >
> >
> > On 8/20/15, 5:27 PM, "William A Rowe Jr"  wrote:
> >
> > >It is generally AL code all the time.  I don't know where you invented a
> > >'kick-in' concept, but unless the committers are violating their
> > >ICLA/CCLA,
> > >nothing could be further from the truth.
> >
> > Committers sometimes make mistakes.  IIRC, Justin recently caught a
> > mistake where some files accidentally got their non-AL headers replaced
> > with AL headers.
> >
> > Large codebase contributions, especially initial podling code grants
> might
> > be messy as well until scrubbed and approved for an official ASF release.
> > I know from experience.
>
> We don't disagree on this point.  Sometimes, they are caught through the
> release process, or by peer review.  Other times, we must retract the claim
> we offered.
>
> Nothing changes the fact that code is either offered under the AL 2.0 or
> another license, unless the author/licensor changes their license
> retroactively.
>

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Benson Margulies 
This thread started as a discussion of Linux distros and trademarks.
Perhaps I could try to return it there?

If a distro takes a release of Apache X, compiles it with minimal changes
that adapt it to the environment, and distributes it, I believe that it's a
fine thing for them to call it simple Apache X, and acknowledge our marks.

If a distro takes a release of Apache X, and make significant changes to
it, and then distributes it, I believe that it's not OK with us for them to
simply call it Apache X. I've seen some evidence that Gentoo Linux makes a
regular habit of this, because their policies drive them to make some
pretty scary changes in some cases. Others may not share my view.

Further, if someone takes a snapshot (small 's') from source control and
starts from that, with minimal changes, I think that this would also be
trademark-acceptable, so long as they accurately describe what they did.

The operative concept here, as Shane has taught it, is 'confusion in the
marketplace.' If some third party behaves so as to cause confusion as to
the identity of Apache X, there's a trademark issue. If not, not.

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread William A Rowe Jr 
On Aug 20, 2015 8:19 PM, "William A Rowe Jr"  wrote:
>
> On Aug 20, 2015 7:39 PM, "Alex Harui"  wrote:
> >
> >
> >
> > On 8/20/15, 5:27 PM, "William A Rowe Jr"  wrote:
> >
> > >It is generally AL code all the time.  I don't know where you invented
a
> > >'kick-in' concept, but unless the committers are violating their
> > >ICLA/CCLA,
> > >nothing could be further from the truth.
> >
> > Committers sometimes make mistakes.  IIRC, Justin recently caught a
> > mistake where some files accidentally got their non-AL headers replaced
> > with AL headers.
> >
> > Large codebase contributions, especially initial podling code grants
might
> > be messy as well until scrubbed and approved for an official ASF
release.
> > I know from experience.
>
> We don't disagree on this point.  Sometimes, they are caught through the
release process, or by peer review.  Other times, we must retract the claim
we offered.
>
> Nothing changes the fact that code is either offered under the AL 2.0 or
another license, unless the author/licensor changes their license
retroactively.

Your comment also hones in on the logical fallacy our VP fell into... While
it may be true that the ASF granted its own AL 2.0 license to the release
package, the ASF is unable to change component licenses in incompatible
ways.  And the warranty the ASF offers on an inaccurate license claims is -
nil - c.f. AL 2.0

However, if our repositories are under another license, that VP needs to
make public this information, because I never got the memo, and I must
notify friends and the many companies I advise and consult to that they all
need to cease looking at the ASF's repositories, and let their respective
legal departments each sort this all out, if those repositories are
licensed with terms and conditions differing from the AL 2.0.

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread William A Rowe Jr 
On Aug 20, 2015 7:39 PM, "Alex Harui"  wrote:
>
>
>
> On 8/20/15, 5:27 PM, "William A Rowe Jr"  wrote:
>
> >It is generally AL code all the time.  I don't know where you invented a
> >'kick-in' concept, but unless the committers are violating their
> >ICLA/CCLA,
> >nothing could be further from the truth.
>
> Committers sometimes make mistakes.  IIRC, Justin recently caught a
> mistake where some files accidentally got their non-AL headers replaced
> with AL headers.
>
> Large codebase contributions, especially initial podling code grants might
> be messy as well until scrubbed and approved for an official ASF release.
> I know from experience.

We don't disagree on this point.  Sometimes, they are caught through the
release process, or by peer review.  Other times, we must retract the claim
we offered.

Nothing changes the fact that code is either offered under the AL 2.0 or
another license, unless the author/licensor changes their license
retroactively.

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Alex Harui 


On 8/20/15, 5:27 PM, "William A Rowe Jr"  wrote:

>It is generally AL code all the time.  I don't know where you invented a
>'kick-in' concept, but unless the committers are violating their
>ICLA/CCLA,
>nothing could be further from the truth.

Committers sometimes make mistakes.  IIRC, Justin recently caught a
mistake where some files accidentally got their non-AL headers replaced
with AL headers.

Large codebase contributions, especially initial podling code grants might
be messy as well until scrubbed and approved for an official ASF release.
I know from experience.

-Alex

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread William A Rowe Jr 
On Aug 20, 2015 08:52, "Jim Jagielski"  wrote:
>
> Coming in late.
>
> A snapshot is not a release. Licenses "kick in" at distribution/
> release.

I want to fix FUD before it infests the rafters and subfloor.  I really
have never read something so stupid or ill phrased...

Every contributor committing code to any ASF project, or even contributing
it to us in public forums (including our mailing lists, our bug trackers,
etc) is committing that code under the AL or has designated explicitly what
licence it came in under (commit message: forked from BSD-licensed code
base at {URL}.)

It is generally AL code all the time.  I don't know where you invented a
'kick-in' concept, but unless the committers are violating their ICLA/CCLA,
nothing could be further from the truth.

> There is also a trademark issue as well... only the ASF
> can declare something as a release.

There we agree :)

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread sebb 
AFAIK a SNAPSHOT has not been voted on and is therefore not a formal
ASF release.

So for example this would cover CI builds that deploy jars to the ASF
Maven SNAPSHOT repo.


On 20 August 2015 at 23:33, Mike Kienenberger  wrote:
> On Thu, Aug 20, 2015 at 6:23 PM, Gavin McDonald  
> wrote:
>> So what do we do about all the rc1|rc2|rcx ,alphas, betas and Milestone
>> ‘releases’ that are on our official mirrors right now?
>>
>> (Because they would have been voted on as a ‘’release’’ for the projects to
>> put them there in the first place)
>
> "Release" means different things in different contexts.  An ASF
> release is a product that a PMC has vetted to meet ASF release
> standards (builds from source, APL2 licensed) and has made available
> to end-users in our download services.  This use of "release" deals
> with legal and "can-be-modified" promises made to the end-user.
>
> Various ASF projects also use "release" to mean something different --
> a community-approved product that has a certain API and typically has
> no known issues.  This use of "release" generally deals with technical
> aspects of the project, such as stability and reliability.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Mike Kienenberger 
On Thu, Aug 20, 2015 at 6:23 PM, Gavin McDonald  wrote:
> So what do we do about all the rc1|rc2|rcx ,alphas, betas and Milestone
> ‘releases’ that are on our official mirrors right now?
>
> (Because they would have been voted on as a ‘’release’’ for the projects to
> put them there in the first place)

"Release" means different things in different contexts.  An ASF
release is a product that a PMC has vetted to meet ASF release
standards (builds from source, APL2 licensed) and has made available
to end-users in our download services.  This use of "release" deals
with legal and "can-be-modified" promises made to the end-user.

Various ASF projects also use "release" to mean something different --
a community-approved product that has a certain API and typically has
no known issues.  This use of "release" generally deals with technical
aspects of the project, such as stability and reliability.

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Gavin McDonald 

> On 20 Aug 2015, at 2:52 pm, Jim Jagielski  wrote:
> 
> Coming in late.
> 
> A snapshot is not a release. Licenses "kick in" at distribution/
> release.
> 

Interesting.

So what do we do about all the rc1|rc2|rcx ,alphas, betas and Milestone 
‘releases’ that 
are on our official mirrors right now?

(Because they would have been voted on as a ‘’release’’ for the projects to put 
them there
in the first place)

(Or are all those different to Snapshots somehow?)

Gav…

> There is also a trademark issue as well... only the ASF
> can declare something as a release.
> 
>> On Aug 6, 2015, at 8:50 PM, Roman Shaposhnik  wrote:
>> 
>> Hi!
>> 
>> while answering a question on release policies and ALv2
>> I've suddenly realized that I really don't know what is the
>> legal basis for enforcing release policies we've got
>> documented over here:
>>  http://www.apache.org/dev/release.html
>> 
>> For example, what would be the legal basis for stopping
>> a 3d party from releasing a snapshot of ASF's project
>> source tree and claim it to be a release X.Y.Z of said
>> project?
>> 
>> Thanks,
>> Roman.
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Gav...

  ((  ( 
 
   (  )\ ) )\ )   )\ )   (   )) 
 
   )\(()/((()/(  (()/(   )\ )  (   )  ( /( (  (( /( 
  (   (  (   
_)(   /(_))/(_))  /(_)) (   (()/(  )(   ( /(  (   )\()))())\   (   
)\()) ))\  )())\  
 )\ _ )\ (_)) (_))_| (_))   )\ ) /(_))(()\  )(_)) )\ (_))/(()\  /((_)  )\ (_))/ 
/((_)(()\  /((_) 
 (_)_\(_)/ __|| |_   |_ _| _(_/((_) _| ((_)((_)_ ((_)| |_  ((_)(_))(  ((_)| |_ 
(_))(  ((_)(_))   
  / _ \  \__ \| __|   | | | ' \))|  _|| '_|/ _` |(_-<|  _|| '_|| || |/ _| |  
_|| || || '_|/ -_)  
 /_/ \_\ |___/|_||___||_||_| |_|  |_|  \__,_|/__/ \__||_|   \_,_|\__|  \__| 
\_,_||_|  \___|

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Ajoy Bhatia 
Pardon me from jumping in but... Roman's original question was:

>
>
>
> *For example, what would be the legal basis for stopping a 3d party from
> releasing a snapshot of ASF's project source tree and claim it to be a
> release X.Y.Z of said project?*
>

So he was asking about someone taking what ASF calls a "snapshot" and
making a release out of it, claiming that it is a release of the same
project. I am also not sure if he meant "SNAPSHOT" in the Maven sense, or
just the state of the project's source repository at a specific moment in
time.

And when Jim said:

>
> *A snapshot is not a release. Licenses "kick in" at distribution/ release.*
>

Jim might have been meaning "SNAPSHOT" and "RELEASE" in the Maven sense.

This is all just my speculation but I thought it might clarify some
misunderstanding.

Thanks...
- Ajoy

On Thu, Aug 20, 2015 at 11:15 AM, Alex Harui  wrote:

>
>
> On 8/20/15, 9:26 AM, "Benson Margulies"  wrote:
>
> >
> >However, a quick search reveals that there are precisely zero
> >occurrences of the word 'release' in version 2.0 of the Apache
> >License.
> >
> >So, I don't know what Jim meant by 'licenses kick in at release', but
> >my view is that putting source in a public Subversion server or git
> >repo is a publication in the legal sense, and that the Foundation
> >grants the Apache license to that content, since we nowhere
> >communicate that we grant some other (lack of) license until the point
> >of release. To me, the plain sense of Jim's phrase is that, somehow,
> >the AL does not apply until there's a release, and I can't make heads
> >or tails of that.
>
> I assumed Jim meant that the public should not feel certain that the AL
> header is correct on items found in the repo, but should feel more certain
> it is correct for files in a release, since, supposedly, a bit more
> scrutiny about the headers happened in creating the release.
>
> IIRC, one of my employer’s lawyers said that the AL applies to any code
> written to be under AL whether it has the header or not.  Headers are a
> convenient signpost, but are not required to connect licensing and
> copyright to lines of code.
>
> -Alex
>
>

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Alex Harui 


On 8/20/15, 9:26 AM, "Benson Margulies"  wrote:

>
>However, a quick search reveals that there are precisely zero
>occurrences of the word 'release' in version 2.0 of the Apache
>License.
>
>So, I don't know what Jim meant by 'licenses kick in at release', but
>my view is that putting source in a public Subversion server or git
>repo is a publication in the legal sense, and that the Foundation
>grants the Apache license to that content, since we nowhere
>communicate that we grant some other (lack of) license until the point
>of release. To me, the plain sense of Jim's phrase is that, somehow,
>the AL does not apply until there's a release, and I can't make heads
>or tails of that.

I assumed Jim meant that the public should not feel certain that the AL
header is correct on items found in the repo, but should feel more certain
it is correct for files in a release, since, supposedly, a bit more
scrutiny about the headers happened in creating the release.

IIRC, one of my employer’s lawyers said that the AL applies to any code
written to be under AL whether it has the header or not.  Headers are a
convenient signpost, but are not required to connect licensing and
copyright to lines of code.

-Alex

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Benson Margulies 
On Thu, Aug 20, 2015 at 12:16 PM, Marvin Humphrey
 wrote:
> On Thu, Aug 20, 2015 at 7:23 AM, Benson Margulies  
> wrote:
>> On Thu, Aug 20, 2015 at 9:52 AM, Jim Jagielski  wrote:
>>> Coming in late.
>>>
>>> A snapshot is not a release. Licenses "kick in" at distribution/
>>> release.
>>
>> Are you sure? When you have a public source control repo, with a
>> LICENSE file at the top, I would think that this counts as a legal
>> 'publication' under the terms of the license.
>>
>> if not, just what is the legal status of source code snipped from our
>> repositories?
>
> I agree with Jim that "a snapshot is not a release".  I also agree with him
> that licenses "kick in" at distribution.  As to whether they kick in at
> "distribution/release", I think that's a weird bit of wording, and I would be
> surprised if we are not all in agreement here.

I'm sorry if my original message was unclear. I didn't mean to comment
or question the dictum that 'a snapshot is not a release'.  The
Foundation offers specific legal protections to releases that it does
not offer to anything else.

However, a quick search reveals that there are precisely zero
occurrences of the word 'release' in version 2.0 of the Apache
License.

So, I don't know what Jim meant by 'licenses kick in at release', but
my view is that putting source in a public Subversion server or git
repo is a publication in the legal sense, and that the Foundation
grants the Apache license to that content, since we nowhere
communicate that we grant some other (lack of) license until the point
of release. To me, the plain sense of Jim's phrase is that, somehow,
the AL does not apply until there's a release, and I can't make heads
or tails of that.

>
> There were long threads on this topic back in 2007-2009 on
> legal-discuss@apache.
>
> http://markmail.org/message/jangmpbssvvd73az
> http://s.apache.org/6Wm
>
> http://markmail.org/message/xietapwmthvvknex
> http://s.apache.org/H6o
>
> Here's are a couple germane points from Roy:
>
> http://markmail.org/message/vbfjep4r2npkwufa
> http://s.apache.org/aXK
>
> Copyright law has no concept of software development. So, when a
> lawyer looks at
>
> http://svn.apache.org/repos/asf/httpd/httpd/trunk/
>
> what the lawyer (or even layperson) sees is a website.
>
> http://markmail.org/message/44ezdre3se3ov5nu
> http://s.apache.org/MEC
>
> > SVN is not a distribution point.
>
> Of course it is a distribution point. Distribution == copy to someone
> else. It isn't a release (an editorial decision by the ASF).
>
> Marvin Humphrey

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Marvin Humphrey 
On Thu, Aug 20, 2015 at 7:23 AM, Benson Margulies  wrote:
> On Thu, Aug 20, 2015 at 9:52 AM, Jim Jagielski  wrote:
>> Coming in late.
>>
>> A snapshot is not a release. Licenses "kick in" at distribution/
>> release.
>
> Are you sure? When you have a public source control repo, with a
> LICENSE file at the top, I would think that this counts as a legal
> 'publication' under the terms of the license.
>
> if not, just what is the legal status of source code snipped from our
> repositories?

I agree with Jim that "a snapshot is not a release".  I also agree with him
that licenses "kick in" at distribution.  As to whether they kick in at
"distribution/release", I think that's a weird bit of wording, and I would be
surprised if we are not all in agreement here.

There were long threads on this topic back in 2007-2009 on
legal-discuss@apache.

http://markmail.org/message/jangmpbssvvd73az
http://s.apache.org/6Wm

http://markmail.org/message/xietapwmthvvknex
http://s.apache.org/H6o

Here's are a couple germane points from Roy:

http://markmail.org/message/vbfjep4r2npkwufa
http://s.apache.org/aXK

Copyright law has no concept of software development. So, when a
lawyer looks at

http://svn.apache.org/repos/asf/httpd/httpd/trunk/

what the lawyer (or even layperson) sees is a website.

http://markmail.org/message/44ezdre3se3ov5nu
http://s.apache.org/MEC

> SVN is not a distribution point.

Of course it is a distribution point. Distribution == copy to someone
else. It isn't a release (an editorial decision by the ASF).

Marvin Humphrey

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Christopher 
On Thu, Aug 20, 2015 at 10:23 AM, Benson Margulies
 wrote:
> On Thu, Aug 20, 2015 at 9:52 AM, Jim Jagielski  wrote:
>> Coming in late.
>>
>> A snapshot is not a release. Licenses "kick in" at distribution/
>> release.
>
> Are you sure? When you have a public source control repo, with a
> LICENSE file at the top, I would think that this counts as a legal
> 'publication' under the terms of the license.
>
> if not, just what is the legal status of source code snipped from our
> repositories?
>

I was thinking a similar thing. If a user encounters software, in any
state (released, or whatever), in a repo with a LICENSE attached, it
seems to me that they have every reasonable expectation that they are
in their right to take actions granted by that license (modification,
redistribution).

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Benson Margulies 
On Thu, Aug 20, 2015 at 9:52 AM, Jim Jagielski  wrote:
> Coming in late.
>
> A snapshot is not a release. Licenses "kick in" at distribution/
> release.

Are you sure? When you have a public source control repo, with a
LICENSE file at the top, I would think that this counts as a legal
'publication' under the terms of the license.

if not, just what is the legal status of source code snipped from our
repositories?


>
> There is also a trademark issue as well... only the ASF
> can declare something as a release.
>
>> On Aug 6, 2015, at 8:50 PM, Roman Shaposhnik  wrote:
>>
>> Hi!
>>
>> while answering a question on release policies and ALv2
>> I've suddenly realized that I really don't know what is the
>> legal basis for enforcing release policies we've got
>> documented over here:
>>   http://www.apache.org/dev/release.html
>>
>> For example, what would be the legal basis for stopping
>> a 3d party from releasing a snapshot of ASF's project
>> source tree and claim it to be a release X.Y.Z of said
>> project?
>>
>> Thanks,
>> Roman.
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Jim Jagielski 
Coming in late.

A snapshot is not a release. Licenses "kick in" at distribution/
release.

There is also a trademark issue as well... only the ASF
can declare something as a release.

> On Aug 6, 2015, at 8:50 PM, Roman Shaposhnik  wrote:
> 
> Hi!
> 
> while answering a question on release policies and ALv2
> I've suddenly realized that I really don't know what is the
> legal basis for enforcing release policies we've got
> documented over here:
>   http://www.apache.org/dev/release.html
> 
> For example, what would be the legal basis for stopping
> a 3d party from releasing a snapshot of ASF's project
> source tree and claim it to be a release X.Y.Z of said
> project?
> 
> Thanks,
> Roman.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

Re: What is the legal basis for enforcing release policies at ASF?

2015-08-20 Thread Ulrich Stärk 
You can't generalize from a single sample.

I see the pattern of email addresses with varying amounts of numbers in
them, some of them also very long, every year with GSoC students.

Uli

On Thu, August 20, 2015 00:32, sebb wrote:
> The recent spammers have used quite unusual e-mail addresses, with
> very long numbers in them.
>
> On 19 August 2015 at 23:18, Ulrich Stärk  wrote:
>> So how would you distinguish a spammer's subscription request from that
>> of a valid user? I certainly
>> can't from looking at the email address alone.
>>
>> Uli
>>
>> On 17.08.15 14:46, sebb wrote:
>>> On 17 August 2015 at 10:52, Gavin McDonald 
>>> wrote:
 So I checked the config for dev@community and it is set up as a normal
 dev@ list operates.

 Therefore anyone can subscribe to the list and post.

 The only thing we can do here is change it to subscription moderation
 - that is an on|off switch so therefore
 ALL subscription requests will have to be approved by a moderator.

 If you are ok with that I can make the change .
>>>
>>> +1 from me.
>>>
>>>
 I checked the logs and it looks like a mod has removed the
 subscription for the user in this thread.
>>>
>>> That was me, sorry forgot to let the list know.
>>>
 Let me know,

 Gav…

> On 17 Aug 2015, at 9:48 am, Ross Gardler 
> wrote:
>
> Not sure if it's possible (you reply made me think I may be mixing up
> Google Groups features with our lists)
>
> Sent from my Windows Phone
> From: jan i 
> Sent: ‎8/‎17/‎2015 1:44 AM
> To: dev@community.apache.org 
> Cc: Roman Shaposhnik ; Apache
> Infrastructure 
> Subject: Re: What is the legal basis for enforcing release policies
> at ASF?
>
> On 17 August 2015 at 10:24, Ross Gardler  > wrote:
>
>> Moderating first posts would be better.
>>
> +1 to that solution (did not know that was possible), that way the
> moderators to not get overloaded with work.
>
> Alternative would be to allow apache ID, and moderate others.
>
> rgds
> jan i.
>
>
>>
>> -Original Message-
>> From: sebb [mailto:seb...@gmail.com ]
>> Sent: Monday, August 17, 2015 1:22 AM
>> To: Roman Shaposhnik > >
>> Cc: ComDev > >; Apache Infrastructure <
>> infrastruct...@apache.org >
>> Subject: Re: What is the legal basis for enforcing release policies
>> at ASF?
>>
>> This is a new subscription (send an e-mail to dev-log@community.a.o
>>  for
>> details)
>>
>> Perhaps we need to consider moderated subscriptions for this list.
>>
>> On 16 August 2015 at 21:33, Roman Shaposhnik > > wrote:
>>> This email echoing keeps happening. I thought we've dealt with it,
>>> no?
>>>
>>>
>>> -- Forwarded message --
>>> From: 田義忠 >> >
>>> Date: Sun, Aug 16, 2015 at 1:27 PM
>>> Subject: Re: What is the legal basis for enforcing release policies
>>> at
>> ASF?
>>> To: "dev@community.apache.org "
>>> mailto:dev@community.apache.org>>
>>>
>>>
>>>
>>>
>>> 從我的 iPhone 傳送
>>>
 Roman Shaposhnik >>> > 於 2015年8月17日 04:25 寫道：

> On Fri, Aug 14, 2015 at 3:59 PM, Shane Curcuru
> mailto:a...@shanecurcuru.org>>
>> wrote:
>> On 8/7/15 7:53 AM, Niclas Hedhman wrote:
>> Bill,
>> So I can release "Niclas Hadoop platform, based on Apache
>> Hadoop"
>> ?? I thought the discussion a few years ago was that this was
>> misleading...
>
> No, you cannot.  See our actual trademark policy:
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww
> 
> .apache.org
> %2ffoundation%2fmarks%2ffaq%2f%23products&data=01%7c01%7c
> ross.gardler%40microsoft.com
> %7c53be77cdd3ef4dca285308d2a6dced17%7c72
> f988bf86f141af91ab2d7cd011db47%7c1&sdata=DdcuJh%2bbhphaiy7yoW%2f2caG
> y15TIxfrsXg1V%2fHh9Jsg%3d
>
> Our release policy, as Roman originally asked about, applies only
> to
> ASF projects, and has no bearing on third parties.  However our
> trademark policy, and trademark law, prevents third parties from
> publicly providing software using our trademarks.
>
> Our operational pol