Re: Official releases vs unreleased code

[Geertjan Wielenga <ge...@googlemail.com.INVALID>]

So, just to be clear what this means in the context of Apache NetBeans.

Here's two different scenarios that relate to this:

1. CoolBeans (coolbeans.xyz) is a distribution of Apache NetBeans, with the
difference that it includes the 'enterprise' cluster (i.e., Jakarta/Java EE
features) of Apache NetBeans, which we have not yet released. We are
working to release this as part of our upcoming release and have several
licensing issues remaining. However, since CoolBeans is not distributed by
Apache, CoolBeans is not constrained by Apache's licensing concerns.

Reading Justin's e-mail, I interpret him to state that it is not allowed to
promote releases to the wider community that contain not released code,
i.e., on the Apache NetBeans webpage, we cannot promote CoolBeans, on
Apache NetBeans Twitter, we cannot promote CoolBeans, on the Apache
NetBeans mailing lists, we cannot promote CoolBeans.

Is this interpretation correct?

2. Even though we have not released the 'enterprise' cluster, we do have
plugins from before we were an Apache project for Java/Jakarta EE features.
These are available from a plugin portal and are built from the the same
code as is found in the Apache NetBeans GitHub, though created from before
that code was at Apache.

Can we promote these plugins?

Thanks,

Gj





On Sun, Jan 6, 2019 at 12:21 AM Justin Mclean <ju...@classsoftware.com>
wrote:

> Hi,
>
> Over the last few months I’ve run into 1/2 dozen podlings who are making
> and promoting releases to the wider community that contain unreleased code,
> and I’m a little surprised that they were unaware that this is not allowed.
> This also has come up in feedback received from the exit questionnaire.
>
> In the release policy [3] it clearly states:
> "Projects MUST direct outsiders towards official releases rather than raw
> source repositories, nightly builds, snapshots, release candidates, or any
> other similar packages.”
>
> This has been discussed many times but these two legal JIRAs [1][2] spell
> it out quite clearly. And while these tickets refer to docker the same
> applies to any distribution mechanism.
>
> In short “It is appropriate to distribute official releases through
> downstream channels, but inappropriate to distribute unreleased materials
> through them.”
>
> So if your projects is using docker, PiPY, GitHub releases, npm or any
> other ways of distribution please make sure that the wider community is
> only pointed at official release and the best way to do this is not to
> publish unreleased code on those platforms. Ask yourself is someone outside
> of the project likely to use this and if the answer is yes then reconsider
> how you are using that distribution channel and make sure it only contains
> official releases.
>
> Thanks,
> Justin
>
> 1. https://issues.apache.org/jira/browse/LEGAL-270
> 2. https://issues.apache.org/jira/browse/LEGAL-427
> 3. http://www.apache.org/legal/release-policy.html#publication
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: Official releases vs unreleased code

[Mark Thomas <ma...@apache.org>]

On 07/01/2019 12:05, Geertjan Wielenga wrote:
> So, just to be clear what this means in the context of Apache NetBeans.
> 
> Here's two different scenarios that relate to this:
> 
> 1. CoolBeans (coolbeans.xyz) is a distribution of Apache NetBeans, with the
> difference that it includes the 'enterprise' cluster (i.e., Jakarta/Java EE
> features) of Apache NetBeans, which we have not yet released. We are
> working to release this as part of our upcoming release and have several
> licensing issues remaining. However, since CoolBeans is not distributed by
> Apache, CoolBeans is not constrained by Apache's licensing concerns.
> 
> Reading Justin's e-mail, I interpret him to state that it is not allowed to
> promote releases to the wider community that contain not released code,
> i.e., on the Apache NetBeans webpage, we cannot promote CoolBeans, on
> Apache NetBeans Twitter, we cannot promote CoolBeans, on the Apache
> NetBeans mailing lists, we cannot promote CoolBeans.
> 
> Is this interpretation correct?

I would suggest reading "promote" in this context as "advertise as an
official ASF release" rather than "make people aware it exists".

Scenario 1 is a different issue. Coolbeans is a non-ASF product. That
makes it more of a branding / community issue than one of release policy.

Generally, projects don't promote down stream releases. Doing so creates
a risk of the ASF being viewed as biased (in favour of the organisation
producing the downstream release) rather than independent.

That said, if the community views it is in the best interest of the
community to promote Coolbeans then the community can do so. The
expectation is that the community would be equally happy to promote any
similar downstream project. If there are criteria about what the
community is and is not willing to promote then those criteria should be
(publicly) documented up front.


> 2. Even though we have not released the 'enterprise' cluster, we do have
> plugins from before we were an Apache project for Java/Jakarta EE features.
> These are available from a plugin portal and are built from the the same
> code as is found in the Apache NetBeans GitHub, though created from before
> that code was at Apache.
> 
> Can we promote these plugins?

Again, as non-ASF releases "make people aware they exist" is fine (same
caveats as above) but "advertise them as official ASF releases" then no.


Generally, I would only expect to see official ASF releases on:
- announcement e-mails from the project
- project main download page
- etc.

HTH,

Mark

> 
> Thanks,
> 
> Gj
> 
> 
> 
> 
> 
> On Sun, Jan 6, 2019 at 12:21 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
> 
>> Hi,
>>
>> Over the last few months I’ve run into 1/2 dozen podlings who are making
>> and promoting releases to the wider community that contain unreleased code,
>> and I’m a little surprised that they were unaware that this is not allowed.
>> This also has come up in feedback received from the exit questionnaire.
>>
>> In the release policy [3] it clearly states:
>> "Projects MUST direct outsiders towards official releases rather than raw
>> source repositories, nightly builds, snapshots, release candidates, or any
>> other similar packages.”
>>
>> This has been discussed many times but these two legal JIRAs [1][2] spell
>> it out quite clearly. And while these tickets refer to docker the same
>> applies to any distribution mechanism.
>>
>> In short “It is appropriate to distribute official releases through
>> downstream channels, but inappropriate to distribute unreleased materials
>> through them.”
>>
>> So if your projects is using docker, PiPY, GitHub releases, npm or any
>> other ways of distribution please make sure that the wider community is
>> only pointed at official release and the best way to do this is not to
>> publish unreleased code on those platforms. Ask yourself is someone outside
>> of the project likely to use this and if the answer is yes then reconsider
>> how you are using that distribution channel and make sure it only contains
>> official releases.
>>
>> Thanks,
>> Justin
>>
>> 1. https://issues.apache.org/jira/browse/LEGAL-270
>> 2. https://issues.apache.org/jira/browse/LEGAL-427
>> 3. http://www.apache.org/legal/release-policy.html#publication
>> ---------------------------------------------------------------------
>> 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