www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: Is GitHub forking subject to clause 4b?
Date Tue, 03 Jan 2017 18:06:25 GMT
Thanks for clarifying the intention from the license writers!  So we
can conclude that it's intentionally vague and so it would be
difficult to add anything to the FAQ?


My apologies - I did not know the internal bit of the process. (is the
suggested method of contributing to such pages documented somewhere?)

I've reverted both suggestion HTML comments from the FAQ.



On 3 January 2017 at 02:07, Roy T. Fielding <fielding@gbiv.com> wrote:
> No, no, no, no, ...
>
> -1
>
> First, this public discussion list is not where we decide to make changes to
> our legal FAQ.  We have an internal list for that, managed by our VP, and
> checked by our lawyers.
>
> Second, that answer is wrong in almost all cases (e.g., the vast majority of
> changes to existing files are not sufficient to attain a separate copyright,
> meaning that suggested addition of a new copyright notice is dubious at best).
> We certainly don't want to recommend the addition of copyright notices
> when we are making significant efforts to exclude them from contributions.
>
> Third, the license already says what needs to be said.  We don't define
> what a prominent notice "is", exactly, because it will depend on the nature of
> the change.  For example, a simple one-liner might have a one-line comment
> next to it indicating why it was changed. We didn't want to define (limit)
> that phrase in the license when it was written, and still don't want to now.
> It is a notice that happens to be prominent.  It's purpose is to alert readers.
> That's all. It can even be accomplished external to the file itself (and note
> that we don't define what "file" means either).
>
> Finally, enough with the Github nonsense. When people fork our products they
> have to do a lot of things to avoid infringing our trademarks and avoid
> confusing downstream recipients of that software.  We are not going to list
> them because it will depend as much on the person's intent and context as it
> does on the extent of changes in relation to the specific product in question.
> Forking is obviously permitted by our license. Modifications are permitted by
> our license. Redistribution of modified works is permitted by our license.
> Github doesn't change anything here.
>
> I appreciate the desire and energy to clarify our documentation.  However,
> clarifying our license for one context often acts at cross-purposes with
> how we want people to interpret that same license in other contexts.
> It is important to understand that our license is a product of thousands of
> agreements and compromises over time, and every single term within it that
> appears to be ambiguous (or broadly undefined) is intended to be so.
>
> That's not a bug.
>
> ....Roy
>
>> On Jan 2, 2017, at 3:18 PM, Stian Soiland-Reyes <stain@apache.org> wrote:
>>
>> I've committed in CMS two new suggested entries to add to the FAQ
>> about Prominent Notices, intended for
>> https://www.apache.org/foundation/license-faq.html
>>
>> As there was no clear way to fork (!) the www.apache.org site in CMS
>> commits and this shouldn't go straight live before Legal agrees, I
>> used HTML comments as safeguards, so it does not show up on the
>> staging build. Use https://cms.apache.org/www/ to  modify the text and
>> comment in this thread.  (Remember the notorious "Update" button
>> first)
>>
>> Comments welcome!
>>
>>
>>
>> ---------------
>>
>> ## How do I provide a "prominent notice" if I modify Apache source
>> code? ## {#Prominent-Notice}
>>
>> The Apache License 2.0 [clause 4b](/licenses/LICENSE-2.0#redistribution) permits
>> you to distribute Apache source code with your own modifications, provided that:
>>
>>> 4b) You must cause any modified files to carry prominent notices stating that
You changed the files
>>
>> The easiest way to add a _prominent notice_ for your modifications
>> is to amend the [license header](/legal/src-headers.html) at the top of the
>> source code file and add a separate comment immediately above or below
>> the existing
>> license header.
>>
>> For instance, if Example Corporation has modified a file from Apache Foo:
>>
>>
>>    /**
>>     * Adapted from Apache Foo 1.2.3 http://foo.apache.org/
>>     * Modifications Copyright 2015-2016 Example Corporation
>>     */
>>    /**
>>     * Licensed to the Apache Software Foundation (ASF) under one
>>     * or more contributor license agreements.  See the NOTICE file
>>     * distributed with this work for additional information
>>     * ...
>>
>>
>> As exemplified above, you are recommended (but not required)
>> to also include a reference to which Apache release the file
>> was adapted from.
>>
>> Note that derivative work (e.g. compiled binaries) do not need to carry a
>> prominent notice of your changes, however as you are required to
>> [redistribute any NOTICE file](/licenses/LICENSE-2.0#redistribution)
>> (clause 4d),
>> you may want to also amend the NOTICE file
>> to include the copyright of your modifications.
>>
>>
>> ---------------
>>
>>
>> ## Does forking Apache code require prominent notices? ## {#Forking}
>>
>> In general, _forking_ Apache code, e.g. publishing your own source
>> code repository with
>> modified Apache code, is
>> [considered](https://lists.apache.org/thread.html/6ce8ebd903c826a292b6ed3d65776fefebff926ffbf23266b65d317d@%3Clegal-discuss.apache.org%3E)
>> a form of
>> [redistribution]([clause 4b](/licenses/LICENSE-2.0#redistribution)
>> and therefore require any Apache files you modify to include a
>> [prominent notice](#Prominent-Notice).
>>
>> The Apache Software Foundation do however recognise that open source
>> development can be
>> performed in distributed collaboration,
>> including [GitHub pull
>> requests](https://help.github.com/articles/about-pull-requests/) and
>> public personal branches of version management systems like Git and
>> Mercurial, and that
>> distributing such contributions publicly is a side-effect of open development.
>>
>>
>> We therefore consider a forked repository which includes modified Apache code
>> to sufficiently carry a _prominent notice_ if:
>>
>> a) The repository clearly shows which files have been modified (e.g.
>> prominently showing "Latest commit")
>>
>> b) The repository clearly shows its origin from ASF (e.g. prominently
>> showing "Forked from apache/foo")
>>
>> c) The repository is **not** intended for redistribution, e.g.
>> additional release tags or custom installation instructions
>>
>> d) The modifications are clearly experimental or intended for
>> contribution to the Apache Software Foundation.
>>
>>
>> ---------------
>>
>>
>> Not sure about the a/b/c/d  break down list as it becomes a bit too
>> specific and sounds too legalish - this is a FAQ! But how can we
>> otherwise say "Heey.. we don't care as long as you are nice and it's
>> not a fork-fork" ?
>>
>>
>>
>> On 31 December 2016 at 12:00, Stian Soiland-Reyes <stain@apache.org> wrote:
>>> This is not a problem that ASF is legally in trouble, but that we could be
>>> pushing contributors towards a license violation.
>>>
>>> I am merely concerned that many projects now encourage contributions through
>>> GH pull requests (good), and notice that some projects even use tags in
>>> personal (but public) Gh repositories as release candidates, subject to vote
>>> of their PMCs. In some projects even committers use such pull requests for
>>> code review. I think this reflects modern open source development.
>>>
>>> However, as what is established in this thread, publishing a modified source
>>> to GitHub would be subject to clause 4b requiring a "prominent notice". It
>>> is unclear if a commit history shown would be sufficient; however we seem to
>>> think it *should be*.
>>>
>>> As this is currently unclear, we could be encouraging third-parties and
>>> existing committers to violate our own license to contribute.
>>>
>>> The license is written for a time when contributions were done by patches
>>> emailed or attached to ASF-hosted infrastructure, which then would not be in
>>> violation of 4b.
>>>
>>> As technically GitHub forks of any kind could be against clause 4b,  but not
>>> be something ASF would pursue legally for contribution-intended changes,
>>> this means that either the license is "wrong", or our policy needs
>>> clarification to match current practice.
>>>
>>> At the same time we want to keep the option for any actual freestanding
>>> forks which would need to comply with 4b by modifying their file headers or
>>> similar.
>>>
>>> Perhaps we can add something to the FAQ on GH pull requests? "When do I need
>>> to add a prominent notice?"
>>>
>>>
>>>
>>> On 31 Dec 2016 12:46 am, "Shane Curcuru" <asf@shanecurcuru.org> wrote:
>>>>
>>>> There's some good discussion in this thread, but more to the point: what
>>>> is the specific question that one of our projects is asking here?
>>>>
>>>> Separately: immaterial of the legal details, where is the business or
>>>> community process question?
>>>>
>>>> - That is, are you (or others) concerned that the ASF might go after
>>>> other developers forking our project code on github?
>>>>
>>>> In that case, it's a policy decision to discuss in Legal Affairs if and
>>>> when it happens, and *only if* we decide we care.  I can't see the ASF
>>>> doing that unless someone else is purposefully and egregiously breaking
>>>> our license - incredibly unlikely.
>>>>
>>>> - Or are people concerned that third party developers who's code is
>>>> included in an Apache project on github might complain to the ASF?
>>>>
>>>> If so, this is a process risk to our project communities, because the
>>>> ASF will then (if our lawyers say we need to) have to ask the project to
>>>> remove the offending code or otherwise remediate the issue in a timely
>>>> manner so that we're respecting the other party's license.
>>>>
>>>> But it's not much of a legal risk, because the ASF would always want to
>>>> ensure we comply with someone else's license.  We'd change the code
>>>> before anyone would take us to court.
>>>>
>>>> - Shane
>>>>
>>>> Stian Soiland-Reyes wrote on 12/27/16 6:43 PM:
>>>>> BTW, I was just wondering.. as it's late December and all:
>>>>>
>>>>> It seems technically anyone forking an Apache repository on GitHub,
>>>>> modifying some source code, and then contribute it as a pull request
>>>>> (or not), could be in violation of our clause 4b
>>>>>
>>>>>>     (b) You must cause any modified files to carry prominent notices
>>>>>>         stating that You changed the files; and
>>>>>
>>>>>
>>>>> unless they also modified each file they propose changes to - which
>>>>> probably we would not want in the pull request.
>>>>>
>>>>> (The pull request itself constitutes a contribution under clause 5,
>>>>> but that does not except from 4b - in addition, a forked branch might
>>>>> be public before it is sent as a pull request)
>>>>>
>>>>>
>>>>> Would keeping a branch on your own github repository constitute
>>>>> "redistribution", or are we good with "carry prominent notices" as
>>>>> long as you don't publish/tag the source code?
>>>>>
>>>>> (GitHub shows the list of recent commits pretty prominently!)
>>>>>
>>>>>
>>>>> And who would be in violation, GitHub or the user? GitHub would be
>>>>> "any medium" i think.
>>>>>
>>>>>
>>>>> This is also related to an earlier discussion: A practice in some ASF
>>>>> projects to do a release candidate git tag only in a personal GitHub
>>>>> repository and use that personal URL as the subject of the release
>>>>> vote - this reduces "pre-publishing" the RC tag to wider audience but
>>>>> can be seen as "distribution" as GitHub creates a 'release' archive of
>>>>> the tag.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> - Shane
>>>>  https://www.apache.org/foundation/marks/resources
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>>
>>>
>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> http://orcid.org/0000-0001-9842-9718
>>
>> ---------------------------------------------------------------------
>> 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
>



-- 
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718

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


Mime
View raw message