incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: [IMPORTANT] Board proposal on podling releases
Date Fri, 07 Jun 2019 20:20:45 GMT
IMO, there could be several kinds of scenarios under the category of "copyright  violations".
 Such as:

1) Taking something under someone else's copyright and claiming it under a different copyright.
2) No mention of the copyright or the entity owning the IP at all anywhere in the release
files.
3) Mentioning the entity owning the IP but not actually copying the Copyright notice
4) Same as #3, but the root problem is the entity owning the IP did not properly place their
copyright.
5) Not following recommended practices for placing copyrights in LICENSE or NOTICE
6) Not copying an upstream Copyright in a NOTICE file into the release's NOTICE file

And more.  

IMO, only #1 should hold up the release and only if the IP is not under some sort of Open
Source license.  Otherwise, I think I recall past discussion where the entity owning the IP
will probably just ask for attribution in the next release and not sue anybody as a first
reaction.  After all they intended to share their code by putting it under an OS license.

My 2 cents,
-Alex

On 6/7/19, 11:46 AM, "Sam Ruby" <rubys@intertwingly.net> wrote:

    On Fri, Jun 7, 2019 at 2:00 PM Craig Russell <apache.clr@gmail.com> wrote:
    >
    > Hi Justin,
    >
    > As a board member, I'm not comfortable with granting a blanket exception to policy
that might put us at legal risk.
    >
    > As an IPMC member, I think that we do not want to allow podlings to release material
that might put us at legal risk. I do think that the IPMC under today's policy has the ability
to decide whether a podling release puts us at risk and therefore should be blocked. So I
am not convinced that the IPMC needs to ask for this waiver from the board.
    >
    > My understanding as an IPMC member is that there are some items in a release that
can be  allowed where they would not be in a TLP release. These things have historically drawn
-1 votes from IPMC members.
    >
    > I think there is consensus that a podling release does not have to conform in every
respect to what we expect from a TLP release.
    >
    > I think that the incubator IPMC should first flesh out (on the general@ list) which
materials in a podling release are
    > a) fine;
    > b) minor issue (file a JIRA and fix before graduation); or
    > c) blocker (puts the foundation at risk).
    >
    > The detail of what is minor versus what it a blocker is the most important thing
that needs clarity. As of now, I don't see consensus although I see movement.
    
    Drilling down by taking the contents of the draft incubator report:
    
    "Serious problems, such as; including GPL licensed software, including
    compiled code, or copyright violations, in a release is currently seen
    as a reason to vote -1 on a release."
    
    Picking them off one by one:
    
    1) Is it legal to include GPL licensed software in releases?  The
    answer is yes... as long as we comply with the terms of that license.
    In the case of strong copyleft licenses, that could mean that the
    podling release itself may need also be GPL licensed.
    
    2) Is it legal to include compiled code in releases?  Yes.
    
    3) Is it legal to include copyright violations in releases?  No.
    
    > Craig
    
    - Sam Ruby
    
    > > On Jun 6, 2019, at 11:45 PM, Justin Mclean <justin@classsoftware.com>
wrote:
    > >
    > > Hi,
    > >
    > > As suggested I’ve collated information from several threads and turned it
into a proposal for the board. Any edits, feedback, agreement, disagreement etc etc is welcome.
In particular it would be nice  to hear some feedback from people who are in favour of this.
    > >
    > > Note that this is important as it probably changes the advice mentors will give
their podlings on releases and change in a positive way how we vote on releases with serious
issues in them. If you are a mentor or vote on releases please read it. Again feedback welcome.
    > >
    > > If the board agrees with the proposal I think we'll need to update the incubator
DISCLAIMER. I’ve suggested what we might add in the proposal but the exact changes can to
be discussed here. If the board disagrees with the proposal I suggest we discuss and come
up with a list of serious issues that the IPMC recommends voting -1 vote on a release. This
is just guidance, not rules, and there may of course be exceptions. (For instance you could
ask VP legal for an exception as has been done in the past.)  That way mentors and podlings
have clear expectations on releases must contain.
    > >
    > > The proposal can be found in the draft board report. [1]
    > >
    > > Thanks,
    > > Justin
    > >
    > > 1. https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FINCUBATOR%2FJune2019&amp;data=02%7C01%7Caharui%40adobe.com%7C0e5f460f223c47b7cbde08d6eb787dcb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636955300076045986&amp;sdata=F1wBsJQ1%2F%2FFur6dk3DoiaZHehg77vK3mIw2R6G%2FuaGY%3D&amp;reserved=0
    > > ---------------------------------------------------------------------
    > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
    > > For additional commands, e-mail: general-help@incubator.apache.org
    > >
    >
    > Craig L Russell
    > clr@apache.org
    >
    >
    > ---------------------------------------------------------------------
    > 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
    
    


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Mime
View raw message