Greetings specification committee
I would like to draw your attention to an update to the
EFSP that we've been working on, that I've named "1.4
(DRAFT)".
I've described the significant changes in
a presentation.
As we've stated in the presentation, our primary
motivation is to extend the EFSP to be inclusive of
process specifications which, as non-technical
specifications, do not have things like TCKs (TCKs are
pretty deeply baked into the current revision). We're also
taking the opportunity to simplify where we can, and
increase the flexibility to support a broader range of
domains, while keeping everything 100% backwards
compatible.
I believe that we've met the goal to be 100% backwards
compatible, in that we haven't added any new requirements
for existing projects. Upon adopting the new version,
however, some working groups may choose to restore some of
the removed elements and specific technical details to the
working group requirements.
I've published a draft of the update along with a diff:
The final draft will also include some updates to
conform with UK English spelling and grammar. I've not
included these updates in the documents at this time to
avoid adding unnecessary clutter.
I ask that you please review the presentation and the
documents. If you have questions or concerns, please
express them in this thread, or (ideally) in the
issue that we
created to track this effort (or create a new issue if
that makes more sense to you).
While I have your attention, I'd like to remind you
that we updated the Eclipse Foundation Specification
License to version 1.1 and Eclipse Foundation TCK License
1.1. in October 2023 (Sharon sent a
note out at
the time). The changes are primarily concerned with
changing the copyright holder to the Eclipse Foundation
AISBL.
Specification projects should update to the new version
of the license as soon as possible. Projects that have
already committed their Specification Version artifacts
for review do not need to rebuild and resubmit those
artifacts. We do, however, ask that you work with your
projects to help them adopt the new version of the license
at their earliest convenience (e.g., the next release).
Note also (and I suspect that this will provoke some
discussion), the license text should not be changed. It is
tempting to fill in the two copyright statement templates
that are present in the specification license, but these
should not be edited. Again, there's no need to recall
projects that have already been released; rather, let's
think of this as something to get right in the next
release.
Thanks for your attention. Let me know if you have any
questions.
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation
My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.
