Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adhere to the PSF Trademark Usage Policy #34

Closed
ghost opened this issue Dec 7, 2013 · 14 comments
Closed

Adhere to the PSF Trademark Usage Policy #34

ghost opened this issue Dec 7, 2013 · 14 comments

Comments

@ghost
Copy link

ghost commented Dec 7, 2013

Originally reported by: Anselm Kruis (Bitbucket: akruis, GitHub: akruis)


It is a legal requirement to adhere to the PSF Trademark Usage Policy. Currently that is most certailly not the case.

I would like to update our Stackless specific documentation (rst-files, doc-strings and source code comments) to meet the conditions set by the PSF for usage of the word "python".

Plan:

  1. Summarise the rules for using the word "python" in Stackless.

  2. Update stackless specific *.rst files

  3. Update stackless specific doc strings

  4. Update other stackless specific documentation including sourcee code comments

PythonTrademarkUsage.odt.zip


@ghost
Copy link
Author

ghost commented Dec 8, 2013

Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis):


A libreoffice document with rules for using the word "Python".

@ghost
Copy link
Author

ghost commented Dec 8, 2013

Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis):


How to use the word „Python“ in Stackless

Rules

  • Use of the word "Python" when redistributing the Python programming language
    as part of a freely distributed application -- Allowed. If the standard version of the
    Python programming language is modified, this should be clearly indicated.

  • Always use „Python“ as an adjective only, followed by a generic noun. For
    instance, it is correct to refer to the Python programming language (adjective) but
    not simply to Python (noun)

  • Allways write „Python®“ or „Python (r)“

  • Try to give the word "Python" distinctive graphic treatment wherever possible.

Sphinx Documentation

In *.rst files we use the substitution mechanism of Spinx:

  • write |PY| for Python

  • write |PPL| for a reference to the Python programming language

  • write |SLP| for a reference to Stackless Python.

  • write |CPY| for a reference to C-Python

We will define appropriate substitutions in the Sphinx config variable rst_epilog.

Other documentation

In Strings and Text-files write

  • Python® if a suitable encoding is specified
  • Python(r) otherwise or if ASCII is required (doc-strings)

@ghost
Copy link
Author

ghost commented Dec 8, 2013

Original comment by Anonymous:


@akruis
In *.rst files we use the substitution mechanism of Spinx:

  • write |PY| for Python

  • write |PPL| for a reference to the Python programming language

  • write |SLP| for a reference to Stackless Python.

    * XXX what about 2.8: is |SLP| then automatically "Stackless" without "Python"?
    
  • write |CPY| for a reference to C-Python

@ghost
Copy link
Author

ghost commented Dec 8, 2013

Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis):


I just pushed my changes: 06fadb519e1a

To emphasis that Stackless Python is not the PSF-Python I changed "Stackless Python" to "Stackless-Python" in the rst-documentation. The remaining occurrences of "Python" became "Python®" or "C-Python®".

One might argue that my changes are excessive, but better paranoid than sued.

@ghost
Copy link
Author

ghost commented Dec 8, 2013

Original comment by Anonymous:


Ah! Does the single dash still allow us to use the word "python"? Maybe legally,
but also does that make people like Barry happy?
Just a note. If you think so, ok with me.

@ghost
Copy link
Author

ghost commented Dec 8, 2013

Original comment by RMTEW FULL NAME (Bitbucket: rmtew, GitHub: rmtew):


I think that you should change C-Python(r) back to Python(r). Firstly, C-Python is not a registered trademark. Secondly, we're a C python. C Python is a good term to use when you're written in Java, or a completely alternate implementation. Personally I think Python(r) with the (r) is distinctive enough, but something like "official Python" would be better than c-Python.

I like the Stackless-Python change.

@ghost
Copy link
Author

ghost commented Dec 8, 2013

Original comment by Anonymous:


@rmtew
I like that, too. But I want to warn that this is thin ice. No idea how python-dev
receives it, it is just very close to a space, and Google is very sloppy in searches.

If I would want to be safe, I would proactively remove "python" from "stackless".
Have references to the python docs, but talk about stackless, only. This way, the
unexpected difference has IMHO even a better effect, because it makes people
notice "stackless, no python! Are they diversifying?" Yes, we are, just a bit.

So think about it: Given the public knowledge about stackless, it might become
even a stronger position to say "we are Stackless, everybody knows where its origin is".

@ghost
Copy link
Author

ghost commented Dec 9, 2013

Original comment by RMTEW FULL NAME (Bitbucket: rmtew, GitHub: rmtew):


My concern Christian, is that we are so worried about offending some
sensitive person (who does not necessarily represent official PSF
stance) from the mailing list that we make it less clear for
Stackless.

2.8 is not going in any new directions. It's 2.7 with Stackless with
stuff from 3.x. It is still the Python language, with extra standard
library and extensions. If in the documentation, where we would write
something like "the following Python code..." we instead write "the
following Stackless code", it seems to me we are writing something
less clear and more confusing.

@ghost
Copy link
Author

ghost commented Dec 9, 2013

Original comment by RMTEW FULL NAME (Bitbucket: rmtew, GitHub: rmtew):


And I should say specifically, you are right, we should stick with Stackless as the project name and not use the words Stackless and Python together as a noun.

@ghost
Copy link
Author

ghost commented Dec 9, 2013

Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis):


About "Stackless" vs "Stackless-Python".

Changing the name is now very simple: edit the definition of |SLP| at the end of Doc/conf.py.

I think for 2.7-slp and 3.x-slp Stackless-Python is still OK. 2.8-slp is a different story. But a complete name change is also OK for me. We could ask the PSF Trademarks Committee for an official permission to use the term "Stackless-Python" as name of our project and the released software. The PSF Trademakr Usage Policy explicitly mentions "IronPython" as an allowed usage of "Python". Therefore "Stackless-Python" could be OK too.

About C-Python

Richard, you are right. I have to much Jython background. But we still need a way to refer to the unmodified standard Python. Now the PSF Trademark Usage Policy states "Always use any trademark as an adjective only, followed by a generic noun." We could write "standard Python® implementation" or as a short form "standard Python®". I prefer the later version and I think the footnote at the end of atackless.python.rst clarifies our usage of the term "standard Python®". Again, changing the wording just requires a change of the definition in Doc/conf.py.

@ghost
Copy link
Author

ghost commented Dec 9, 2013

Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis):


I just commited 172c8ecc9edc: it changes "C-Python®" to "standard Python®".

@ghost
Copy link
Author

ghost commented Dec 9, 2013

Original comment by Anonymous:


Great! Can you come to Berlin on Thursday? Would be perfect. Hugs - Chris

@ghost
Copy link
Author

ghost commented Sep 4, 2016

Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis):


Nothing left to do.

@ghost
Copy link
Author

ghost commented Nov 6, 2016

Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis):


Removing milestone: 2.7.6-slp (automated comment)

@ghost ghost closed this as completed Sep 24, 2017
akruis pushed a commit that referenced this issue Mar 3, 2018
* bpo-29026: Clarity documentation of time.time

Clarify the documentation of time.time by more
precisely defining what is meant by "seconds since
the epoch" on most platforms. Additionally explain
how gmtime and localtime may be used to extract
calendar components and convert to a more common
date format.

* bpo-29026: Minor improvements for time.time doc

* bpo-29026: Consistency fixes for time.time doc
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

0 participants