| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-sc] Re: OASIS OSLC Open Project Proposal
- From: "Jim Amsden" <email@example.com>
- To: Carol Geyer <firstname.lastname@example.org>
- Date: Mon, 14 Jan 2019 10:14:15 -0500
I think we are
getting close to being ready to commit to OSLC becoming an OASIS Open Project.
We have a few remaining clarifications/questions/issues to resolve. I hope
these are not blockers, but it would be nice to get some clarification/resolution
as soon as possible.
OASIS waiver of Project Backer fees for OSLC Open Project: OASIS
will waive the Backer fees for the organizations that are represented on
the current OSLC MS StC for the foreseeable future, provided that those
companies retain their OASIS Foundational Sponsor, Sponsor, or Contributor
memberships. Organizations not represented on the current OSLC MS StC,
including OSLC Member Section organizations that are not currently on the
StC, will be able to become OSLC Project Backers and members of the PGB
by paying the annual fees listed above.
For practical and technical reasons, I propose that PROMCODE continue on
its current standards track, maintaining its current TC and not be part
of the OASIS OSLC Open Project.
3. Issue: All
PGB members must sign the CLA regardless of whether or they they contribute
content. This could create a legal hurdle for PGB members who wish to participate
in project governance but may be unable to sign the CLA. Each of the current
StC members will need to research this issue within their own organization
to see if this is an issue for them.
For current OSLC
TC members, what IP agreements already exist for OASIS specification contribution,
and how does this relate to the CLA? Is the CLA a separate agreement covering
the Open Project artifacts, and any standards track documents that arise
from the Open Project still have to adhere to the current OASIS standards
track IP rules?
4. Issue: We need
to outline the process for publishing Open Project artifacts as OASIS standards
approach would be to have the HTML source documents in the Git repo be
the normative documents (since they are version managed), and to use ReSpec
to provide an HTML representation of these documents for consumption. We
would control the document file names and URL references in the Git repo,
avoiding the creation of broken links in the publish step.
We would also
like to maintain the specification track document lifecycles in the Git
repo, using appropriate tags to designate the status of documents. Again,
this links document status with preserved versions in the repo change history.
the standards track documents with specific naming conventions, formats
and/or MIME types in docs.oasis-open.org be part of the Open Project core
services provided by OASIS, and not be the responsibility of the PGB or
TSC? This could be done with redirects or additional script automation
to limit publishing errors.
5. Issue: We need
to understand how the existing open-services.net site would be integrated
with, linked to, be part of, etc. the OASIS OSLC Open Project. Would it
be possible to use the current open-services.net site as the Open Project
site, and use a redirect to provide an additional URL alias for OASIS?
This would leverage a lot of site development work and infrastructure that
is already done.
Jim Amsden, Senior
Technical Staff Member
OSLC and Linked Lifecycle
OSLC Core TC <email@example.com>, OASIS OSLC Domains
TC Discussion List <firstname.lastname@example.org>
Administrator <email@example.com>, Scott McGrath <firstname.lastname@example.org>
Re: OASIS OSLC Open Project Proposal
We are excited
by the possibility of transitioning the OSLC Member Section and TCs to
an Open Project.
to your questions are in red below. We're happy to discuss on or in advance
of the StC call on Jan 21.
On Mon, Dec 17, 2018 at 1:13 PM Jim Amsden
The OASIS OSLC
Membership Steering Committee (StC) proposes to migrate the current OASIS
OSLC standardization activities to a new OASIS OSLC Open Project.
The purposes of this migration are to:
* Engage a broader community in OSLC technical work by allowing participation
and contribution from non-members without incurring dues or fees
* Increase OSLC adoption by encouraging more contribution, awareness and
* Provide a context in which to develop related work products including
open source reference implementations, sample applications, and other collateral
that expand and complement the OASIS Standards track documents
* Simplify the infrastructure and processes for developing OASIS Standards
* Reduce fragmentation in the OSLC community by providing a central, world
wide, respected organization in which to develop OSLC related work products
Specifically, the StC proposes the following:
1. Utilize the current StC members to form the initial OSLC Project Governing
Board (PGB), retaining the current chair
2. The current Core and Domains TC members are merged and become the initial
OSLC Technical Steering Committee, retaining the current chairs and cochairs.
3. The existing OSLC Core and Domains GitHub repositories will be migrated
as is to the OSLC Open Project
4. The existing OSLC4JS project will also be migrated to the OSLC Open
Project and will provide a code base that establishes a Statement of Use
of the OSLC Standards and a code base for exploring and validating proposed
changes to the standards
5. The existing eclipse/Lyo Open Source project at eclipse.orgwill remain unchanged in order to leverage the eclipse governance process
and Type B due diligence.
This proposal is subject to approval by the StC, with the decision scheduled
to be addressed at the next StC meeting, Jan 21, 2019.
In order to facilitate the decision process, the StC would like clarification
on the following questions.
1. What exactly are the Open Project fees and who pays them?
fees are used to fund core services provided by OASIS (legal, technical,
and fiscal administration, basic marketing support, etc.).
TCs (which are funded by inclusive OASIS membership dues and where dues
are required for technical participation), each Open Project is funded
by fees paid by its own sponsoring organizations (we're calling these "Project
Backers"). The funding provided by Project Backers enables anyone
in the community to participate technically without paying dues.
Project Backer fees are paid annually. The fees are scaled, based on the
organizationâs employee headcount:
25,000: 2,000+ employees
15,000: 500-1,999 employees
10,000: 100-499 employees
5,000: 10-99 employees
2,000: <10 employees
1,000: Nonprofit, university, local or non-OECD government
Backer organizations each receive a seat on the Project Governing Board
(PGB) as well as exclusive visibility and promotional benefits.
OSLC... if the StC and TCs decide in January to form the Open Project (in
time for inclusion in OASISâ program roll-out in late March), OASIS will
waive the Backer fees for the organizations that are represented on the
current OSLC MS StC for the foreseeable future, provided that those companies
retain their OASIS Foundational Sponsor, Sponsor, or Contributor memberships.
not represented on the current OSLC MS StC will be able to become OSLC
Backers by paying the annual fees listed above.
This offer covers core services provided by OASIS. If the OSLC PGB determines
the need for supplemental activities (code auditing, event hosting, consultants,
etc.), then additional funding will be required. OASIS staff will work
with the OSLC PGB to determine its funding requirements and how to best
1.1. What are the startup and annual fees for an Open Project?
1.2. It is our understanding that the PGC requires a minimum threshold
in annual sponsorship commitments by OASIS member companies. What is this
OASIS requires new projects to identify commitments of at least $25,000
in annual Project Backers fees and at least two organizations for its PGB
before it can be launched.
OASIS OSLC members will enjoy the fee waiver noted above, but still will
need to have at least two organizations on its PGB. These may be either
current MS StC organizations (holding OASIS Foundational, Sponsor, or Contributors
membership) or new organizations that pay the annual OSLC Project Backer
1.3. What are
OASIS members of the PGC expected to contribute to the Open Project fees?
MS organizations are not expected to contribute additional funding for
the foreseeable future to cover the core services provided by OASIS. If
the OSLC PGB decides supplemental activities/services are needed, fees
may be necessary.
1.4. What is the
relationship between the OASIS member dues and Open Project fees?
That is, if an OASIS member company participates in many Open Projects
that develop different OASIS Standards, will the member company have to
pay OASIS membership fees as well as additional fees for each Open Project
for which they are PGC members?
thereâs no relationship between OASIS membership and Open Project sponsorship.
Each Open Project is funded by its own Project Backers.
special cases, we may offer OASIS members a reduced or waived fee to become
Project Backers for specific Open Projects (e.g., our current offering
to OSLC MS members).
1.5. What happens of the member participation in the PGC falls below the
minimum threshold, but there is still ongoing work by the Technical Steering
Committee in the open source and/or specification deliverables?
The OP program
is designed to gracefully degrade in such cases. If the OP no longer has
at least two Project Backers:
- OASIS will
continue to provide free public access to the project's deliverables in
- The project's
repositories remain open. Contributions and comments may be accepted, and
successor Maintainers may be appointed.
- The project
will no longer receive facilitation or other services from OASIS.
- The repoâs
content wonât continue to be eligible for approval as Project Specifications
or advanced through the OASIS standards track.
2. What are the rules for non-member participants, contributors, maintainers
and PGB members?
2.1. Do non-members of either the Technical Steering Committee or Project
Governing Board have voting rights?
with common open source practices, Open Projects rules allow most decisions
to be made by group consensus.
of the PGB approve major governance and advancement actions via ballot
of the Technical Steering Committee (TSC) are free to determine how to
manage achieving consensus; voting is not required.
2.2. How are these voting rights calculated? At the discretion of the PGB?
are made on the PGB by one-org/one-vote. Each Project Backer organization
has one seat on the PGB.
are selected for their technical contributions to the project, regardless
of whether or not they are employed by Project Backers. Thisgives the project another opportunity for inclusive leadership.
2.3. Do all voting members have to sign the CLA (even if they don't contribute
All PGB members
must sign the CLA regardless of whether or not they contribute content.
3. Regarding Legal entity, oversight, management of IP and licensing agreements,
trademarks and copyrights: Specifically what services will OASIS provide
in order to assess the IP of Open Project work products, including dependencies
on components outside the project?
For example, open source projects often have dependencies on other open
source projects. In order to assess IP exposure, it is typically necessary
to examine all direct and transitive dependencies to ensure there are no
licensing issues. This often requires code scans to detect potential issues.
Will OASIS provide these services?
from a PGB, OASIS will contract with a third-party to provide code scan
services. OASIS will work with the PGB to identify the provider and scope
of service that best meets their projectâs needs.
scans are not included in the core services provided by OASIS for all Open
Projects. The cost to provide this service will have to be covered by supplemental
funding (e.g. fees for Project Backers).
OSLC requires code scans, let us know as soon as possible. OASIS will work
with the StC to determine specific needs, evaluate service provider options,
and agree on how the cost will be covered.
4. Will the current OSLC TC GitHub repos, wikis and issues be migrated
as is to the new open project?
participants agree to re-contribute them). When the outgoing license
is royalty-free, and the selected incoming FOSS license is reasonably permissive,
itâs an easy ask from the participants. This is made even easier when
a known, stable group is involved, as is the case with OSLC.
4.1. Will there
be any impact on existing TC work products?
Not on the
TC-approved versions. Once a published OASIS Committee Specification,
always a published OASIS Committee Specification.
4.2. Will the
open project specification template be different than what is currently
being used by the OSLC TCs, and automated through ReSpec? We are trying
to minimize spec rework and ReSpec updates.
templates for Open Project work are based on the current TC templates.
While there will be some labeling differences, rework will be minimal.
4.3. The Open
Project specification lifecycle appears to require statements of use before
public review. What are the implications for OSLC Domain and Core TC documents
that are already in progress?
Specifications only require public reviews and Statements of Use when they
move forward as Candidate OASIS Standards (in the same way a TC would proceed).
SoU are not required for a public review. Migrating to Open Projects should
have little effect on existing work.
4.4. Are there any changes in how Open Project standards track work products
are published by OASIS?
Specifically I'm trying to understand if the issue we had with document
relative links being broken by the OASIS publishing process will be resolved
by migrating to an Open Project so that we don't have do the work to modify
ReSpec to fix up links on document publish.
on this are TBD, but we are confident we can work out an arrangement where
the canonical standard lives on the OP repo with a backup verified copy
5. What are the hosting constraints and any additional costs associated
with utilizing the Open Project Web site?
We have just deployed a new open-servicers.netsite. This site was developed using HUGO (https://gohugo.io).
Can we continue using this technology and URL for the Open Project web
site? Note that it is necessary to preserve the open-service.netdomain since the OSLC namespaces utilize this domain name for backward
compatibility and access to machine readable vocabulary documents.
this will require investigation, but we donât expect a problem. We will
want to add boilerplate text and minimal branding to the site, and some
kind of linking or mirroring so that material cross-references into OASIS
resources. Staying with this current infrastructure and URLs will make
life easier for all of us.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
Chief Development Officer
Open Source and Standards Communities
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]