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" <ru...@intertwingly.net> wrote:
On Fri, Jun 7, 2019 at 2:00 PM Craig Russell <apache....@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 <jus...@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&data=02%7C01%7Caharui%40adobe.com%7C0e5f460f223c47b7cbde08d6eb787dcb%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636955300076045986&sdata=F1wBsJQ1%2F%2FFur6dk3DoiaZHehg77vK3mIw2R6G%2FuaGY%3D&reserved=0
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> Craig L Russell
> c...@apache.org
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
