Also, any builds with custom C that is not in this repo of CircuitPython make the build CircuitPython-compatible and not vanilla CircuitPython.

I don't want to weigh in too heavily on this issue, because it is not impossible to insert a custom module, even now. But is the distinction really so important for you? I mean, as soon as you make circuitpython open source, it is not in your hands anymore what others do with it. The question is only how hard you make the modifications.

Yes, the CircuitPython trademark and brand is incredibly important to me. Losing control of what it means to be CircuitPython means that guides, drivers and experiences will not match user's expectations. By being open source, we give others the right to use the code, not the trademark. I outlined more about it here: https://github.com/adafruit/circuitpython#branding

If folks want to be "CircuitPython" they should have modifications checked into master of the adafruit/circuitpython repo so that it is versioned and released with all other CircuitPython releases.

@v923z I don't think Scott is rejecting the idea, so much as establishing what the labeling guidelines will be if it is implemented and what's considered priority for the sponsored-by-Adafruit team. I'd also be very excited to see C modules supported and I saw it in three Circuitpython 2020s, so I don't think anyone would object to a PR being submitted to align with Micropython's implementation. It's just not high on the list for sponsored folks.

Thanks for clarifying for me @hierophect. I should state what I am for.

We (Adafruit sponsored folks) will always review and merge PRs that don't disrupt the core beginner-friendly goal of CircuitPython. This includes merging custom modules for custom non-Adafruit boards. That way they can be proper "CircuitPython".

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions