Are you also going to stop others from using the psf theme? On May 27, 2017 11:35, "Brett Cannon" <brett@python.org> wrote:

On Fri, 26 May 2017 at 21:28 Nick Coghlan <ncoghlan@gmail.com> wrote:

...

Hi folks,

Over on https://github.com/pypa/python-packaging-user-guide/ pull/305#issuecomment-304169735 we're looking to update the theming of packaging.python.org to match that of the language documentation at docs.python.org.

Doing that would also entail updating the documentation of the individual tools and services (pip, pypi, setuptools, wheel, etc) to maintain consistency with the main packaging user guide, so Jon has tentatively broken the theme out as a (not yet published anywhere) "pypa-theme" package to make it easier to re-use across multiple projects.

The question that occurred to me is whether or not it might make more sense to instead call that package "psf-docs-theme", to reflect that it's intended specifically for projects that are legally backed by the PSF, and that general Python projects looking for a nice, high-contrast, theme should consider using an org independent one like Alabaster instead.

Thoughts? Should we stick with pypa-theme as the name? Switch to psf-docs-theme? Publish both, with pypa-theme adding PyPA specific elements to a more general psf-docs-theme?

If we're going to share the theme beyond docs.python.org it makes sense to have a shared theme under the Python org that can easily be reused by multiple sets of documentation.

As for the name, the psf-docs-theme seems fine with me.

-Brett

...

Cheers, Nick.

P.S. In case folks aren't aware of the full legal arrangements here: in addition to the informal "Python Packaging Authority" designation, there's also a formally constituted PSF Packaging Working Group that provides the legal connection back to the PSF. That means the relationship between PyPA and the PSF ends up being pretty similar to the one between python-dev and the PSF, where there's no direct PSF involvement in day to day development activities, but the PSF provides the legal and financial backing needed to sustainably maintain popular community-supported software and services.

Part of my rationale for suggesting the inclusion of "psf" in the package name is to make it clear that the intent would be to create a clear and distinctive "trade dress" for the documentation of directly PSF backed projects: https://en.wikipedia.org/wiki/Trade_dress#Protection_for_ electronic_interfaces_and_websites

Future requests to use the theme (beyond CPython and the PyPA) could then be run through the PSF Trademarks committee, as with requests to use the registered marks.

Whereas if we go with pypa-theme, then that would just be a non-precedent-setting agreement between PyPA and CPython to share a documentation theme, without trying to define any form of documentation trade dress for the PSF in general.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ brett%40python.org

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ guido%40python.org

I'm -1 on going down the suggested route of Apple et al. for an open source language. We don't need more trademarks to "protect" ourselves against fellow open source projects. I see this whole trademark business that OSS projects are getting into in recent years in a more and more critical light. On one hand you have the open source idea, where you want to enable anyone to reuse your code. The OSS copyright licenses implement this idea nicely. On the other hand, you have trademark law which limits this reusability by imposing strict rules on how you can reuse the names, designs, colors, etc. trademarked by the OSS project (or else - TM lawyers tell you - you lose the rights to the TMs). The latter has to be handled with great care, since while you do want to protect the trademarks against malicious use by third parties (e.g. a company registering the same mark and then preventing use of the trademark in their jurisdiction), you don't want to hinder the original intent of having an open source license. In particular, you don't want to bully community projects which try to further the use of our open source software by using similar marks. In my role as PSF TM committee member, it's often painful to have to tell community members that they cannot use e.g. really nice looking variants of the Python logo for their projects. Let's not add more pain. If you want to make PSF related projects be recognized as such, simply add the PSF logo to the footer of the site and provide some blurb explaining the relationships to the about page. We could also have a special "PSF Project" logo for such a purpose. Use of the logo would then be subject to the TM requirements, but not the looks and UI of the site. On 28.05.2017 07:31, Nick Coghlan wrote:

On 28 May 2017 at 06:54, Guido van Rossum <gvanrossum@gmail.com> wrote:

...

Are you also going to stop others from using the psf theme?

I think it would definitely make sense to discourage the use of this particular theme for projects that aren't relatively directly affiliated with the PSF - there are plenty of other pip-installable high contrast themes out there that aren't closely associated with a particular backing organisation.

The one Jon was originally considering for the PyPA docs was Alabaster, which is now the default theme in Sphinx 1.3+: https://alabaster.readthedocs.io/en/latest/

So I think it would be appropriate to include a sentence like the following in the README for psf-docs-theme:

"Please limit use of this theme to projects which are closely affiliated with the Python Software Foundation, and have permission from either the CPython core development team or the PSF itself for such use. For other projects looking for a simple, high contrast, pip installable Sphinx theme, we recommend the Alabaster theme used by default in Sphinx 1.3+."

Cheers, Nick.

-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 28 2017)

...

...

Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/

::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

On 29 May 2017 at 01:15, David Mertz <mertz@gnosis.cx> wrote:

I agree with MAL and have also been on the Trademarks Committee for 8-9 years. Protecting an actual Mark like the logo is fine, as painful as it is to someone's say no to an attractive derived logo. But trying to protect a look-and-feel is way too far down the path of evil (it's what some proprietary companies we want to be different from do). Moreover, when when that's done it's not generally as trademark but as "trade dress" copyright... which is a concept I opposed ethically, but know it's the usual legal instrument.

I'm also fine with leaving the trade dress aspect completely unenforced - the main question is whether or not folks are OK with PyPA using a derivative of the CPython docs theme to make PyPA-related documentation look more like the CPython docs, and hence more official. I do think it's appropriate for us to ask that question, as going down this path means we're deliberately trading on the community trust earned by the CPython core development team over the past 20+ years specifically in order to help make PyPA's own documentation seem more trustworthy to others. If we're going to borrow somebody else's reputation like that, then it seems reasonable to me for us to offer the people whose reputation we're borrowing the courtesy of *asking first*, regardless of what the law says we're technically allowed to do. Here's an alternate wording for the README that would focus on those considerations without explicitly asking folks not to use the theme: "Note that when adopting this theme, you're also borrowing an element of the trust and credibility established by the CPython core developers over the years, as well as the legal credibility arising from their close association with the Python Software Foundation. That's fine, and you're welcome to do so for other Python community projects if you so choose, but please keep in mind that in doing so you're also choosing to become a co-steward of that collective trust :)" Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Tue, 30 May 2017 21:49:19 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:

Here's an alternate wording for the README that would focus on those considerations without explicitly asking folks not to use the theme:

"Note that when adopting this theme, you're also borrowing an element of the trust and credibility established by the CPython core developers over the years, as well as the legal credibility arising from their close association with the Python Software Foundation.

The statement about "legal credibility" sounds wishy-washy and could lure users into thinking that they're doing something illegal by borrowing the theme. Also I'm not sure what is that "legal credibility" you're talking about. If it's about the PSF license and the Python CLA then better to voice that explicitly, IMO.

That's fine, and you're welcome to do so for other Python community projects if you so choose, but please keep in mind that in doing so you're also choosing to become a co-steward of that collective trust :)"

"Becoming a co-steward of that collective trust" sounds serious enough (even though I don't understand what it means concretely), so why the smiley? Regards Antoine.

M.-A. Lemburg wrote:

In my role as PSF TM committee member, it's often painful to have to tell community members that they cannot use e.g. really nice looking variants of the Python logo for their projects. Let's not add more pain.

But it's always within the PSF's power to give that community member permission to use that variant if they ask, is it not? So you don't actually have to tell anyone that they can't use anything. -- Greg