search

oasis-tcs / openeox

OASIS OpenEoX TC: The purpose of this repository is to support version control for Work Product artifacts developed by members of the OASIS OpenEoX TC, including prose specification editing and secondary artifacts like meeting minutes, productivity code, etc.
Other
11 stars 5 forks source link

End-of-Sales (EoS) Definition #27

Open santosomar opened 3 months ago

santosomar commented 3 months ago

This is a follow up of #13

Let's define each element and work on their definitions in separate GitHub issues. This issue will focus on defining:

Software End-of-Life (SEoL) or Software End-of-Sales (SEoS)

santosomar commented 3 months ago

Potential Definition

Software End-of-Sales (SEoS) refers to the date after which a vendor ceases to sell a specific software product. After this date, the software is no longer available for purchase from the vendor, although existing users may still receive updates and support until the End-of-Life (SEoL) date. SEoS indicates that the product is being phased out in favor of newer versions or alternatives, and it is a key milestone in the software product lifecycle.

Note: For open-source software, there may not be an End-of-Sales date, as the software is typically freely available for download and use.

Note: SEoS is analogous to End-of-Hardware Sales (EoHS) for hardware products, where the manufacturer stops selling the hardware while possibly continuing support for a specified period.

Example:

Consider a proprietary software application called "PhotoEditPro" developed by MediaSoft. MediaSoft announces that the Software End-of-Sales for PhotoEditPro version 10.0 will be on December 31, 2024. After this date, customers can no longer purchase PhotoEditPro 10.0 directly from MediaSoft. However, existing users of PhotoEditPro 10.0 will continue to receive updates and support until the End-of-Life date of December 31, 2025. Users are encouraged to upgrade to PhotoEditPro version 11.0, which includes new features and ongoing support.

lfrancke commented 3 months ago

One might argue that FOSS software doesn't even have a "Start-of-Sales". Mostly it has a Release date.

santosomar commented 3 months ago

I agree. There could be companies that provide support of open source (eg Red Hat) and they will have a start of sales, but that could also be captured by first release. To be honest, for most open source it will just be a Boolean (supported and not supported)

fjscao commented 3 months ago

"a specific software product" needs to be clarified. There are two categories: the product or <product, version>. In many cases, <product, version> is the case.

santosomar commented 2 months ago

From Langley:

https://www.dell.com/support/kbdoc/en-us/000128563/end-of-life-end-of-support-policy-for-dell-data-security?msockid=071cc6909f9b600e13e6d5c89e9b6192

santosomar commented 2 months ago

This is from Cisco:

image

https://www.cisco.com/c/en/us/products/eos-eol-policy.html

santosomar commented 2 months ago

(SEoS)

SEoS here needs to be expanded to not overlap with other of the elements/definitions.

santosomar commented 2 months ago

From Rogue:

take a look for example on Red Hat OCP lifecycle model, there are more than one Maintenance Support states: https://access.redhat.com/support/policy/updates/openshift/

sardaharin commented 2 months ago

Some thoughts:-

  1. Last lifecycle state of any product (S/W or H/W) should be called as "decommissioned state".

    • Some may have End-of-support as last state, some may have End-of-sales as last state and some may have "extended-update-support" as last state. In such a scenario, having one common end state will be helpful. One can map/assign " decommissioned state" to any of the lifecycle state to call it as end state.

  2. Does "Vendor specific state" add any value?

tschmidtb51 commented 2 months ago

Potential Definition

Software End-of-Sales (SEoS) refers to the date after which a vendor ceases to sell a specific software product. After this date, the software is no longer available for purchase from the vendor, although existing users may still receive updates and support until the End-of-Life (SEoL) date. SEoS indicates that the product is being phased out in favor of newer versions or alternatives, and it is a key milestone in the software product lifecycle.

Note: For open-source software, there may not be an End-of-Sales date, as the software is typically freely available for download and use.

Note: SEoS is analogous to End-of-Hardware Sales (EoHS) for hardware products, where the manufacturer stops selling the hardware while possibly continuing support for a specified period.

As discussed in today's TC meeting, we should mention that a) a vendor might be provider b) other parties than vendors might be selling the product longer/shorter.

Therefore, here is an updated proposal (changes marked in bold):

Software End-of-Sales (SEoS) refers to the date after which a provider ceases to sell a specific software product. After this date, the software is no longer available for purchase from this provider, even though other providers may still sell it. Existing users may still receive updates and support until the End-of-Life (SEoL) date. SEoS indicates that the product is being phased out in favor of newer versions or alternatives, and it is a key milestone in the software product lifecycle.

Note: For open-source software, there may not be an End-of-Sales date, as the software is typically freely available for download and use.

Note: SEoS is analogous to End-of-Hardware Sales (EoHS) for hardware products, where the provider stops selling the hardware while possibly continuing support for a specified period.

tschmidtb51 commented 2 months ago

Note: We need to revisit the definition as soon as we have a solid definition for #33 as it is mentioned here as "receive updates and support until the End-of-Life"

thschaffr commented 1 month ago

Hello team,

as discussed in our previous TC meeting. @p-rog and I worked on a draft to describe Software End-of-Sales (SEoS). The result is a combination of several key elements around the EoS of a product. We tried to keep it as generic as possible, yet targeted enough to match it to a separate lifecycle phase.

During our research we discovered that the lines between Software- and Hardware EoS are very blurred. Therefore, we suggest creating one general definition for Software and Hardware. It could be named "xEnd-of-Sales" (xEoS). In addition to the general definition, any particular vendor specific details could be referenced in an optional field based on the schema. (Dependent on #15 to #12)

For example:

Mandatory field: Category: Software or Hardware

Suggestion for SEoS:

The Software End-of-Sales (SEoS) indicates the last day when a particular product (or the product version/release) may be ordered by customers from vendor sales channels. After this date, the product or specific version or edition of the software or license is no longer for sale. However, there might be other sources where the product is still available. Once the product reaches the End-of-Sales (EoS) lifecycle stage, it may still be supported by the vendor, based on the official or dedicated vendor lifecycle model for this product, for existing customers. The implications for existing customers regarding license renewals, updates, upgrades to newer versions or ongoing technical support can vary depending on the vendor's specific policies.

tschmidtb51 commented 1 month ago

@thschaffr and @p-rog: Thank you for your work on this. I have two points that I think should be addressed:

  1. IMHO, we should not introduce the suggested category field as there are more categories than just hardware and software. There might also be a specification or the product might be an AI training data sets etc. However, that is not a problem, as we assign the field to a specific product. So this product has its EoS date at that specific date. This works for any type. Note: You need to separate hardware and software anyway in CSAF to be compliant.
  2. The definition is based around the term vendor. However, in OpenEoX it should be about the document issuer. If "company A" (vendor) decides that they stop selling "product 1" today, I might still get it from "company B" (reseller of A) as they have a huge stockpile that they want to sell.
tschmidtb51 commented 1 month ago

Therefore, I suggest to change the definition to:

Potential definition

The Software End-of-Sales (SEoS) indicates the last day when a particular product (or the product version/release) can be ordered by customers from issuing party's sales channels. After this date, the product or specific version or edition of the software or license is no longer for sale. However, there might be other sources where the product is still available. Once the product reaches the End-of-Sales (EoS) lifecycle stage, it can still be supported by the vendor (or 3rd parties), based on the official or dedicated vendor lifecycle model for this product, for existing customers. The implications for existing customers regarding license renewals, updates, upgrades to newer versions or ongoing technical support can vary depending on the vendor's specific policies.

Example

Consider an operating system company, OSTech, that produces an operating system named "OS 20". OSTech announces that the Hardware End-of-Life for OS 20 will be on December 31, 2024. From this date forward, OSTech will stop manufacturing and selling OS 20. Although existing customers may still receive support for a limited time, they are encouraged to transition to newer products like OS 24.

There are also two reseller: FastRes and Stockpiler Warehouse. FastRes already announced that its EoS for OS 20 is January 31, 2024. Stockpiler Warehouse announces to be selling OS 20 until June 30, 2027.

Edit: Corrected typo of OS 24 in last paragraph.

p-rog commented 1 month ago

@tschmidtb51 thank you for your feedback.

Vendor term describes who is selling and delivering the support. It means that in your example the FastRes and Stockpiler Warehouse are considered as vendors. They could even add their own versioning to the "OS 20", because when the original OSTech's "OS 20" is already EoL, they still delivering it with their own support, means their own patches and updates.

Resellers usually only sell the product and don't deliver their own support. Especially for software. For hardware you can usually return the device to the seller, but at the end it is sent to the original vendor service. The Resellers can extent the warranty, but it's their own offer and in that case they became a "vendor" from the lifecycle perspective. It doesn't mean that they are manufacturer, they are vendor.

We can add a "vendor" definition to avoid confusion. What do you think?

Regarding the category field to the product definition, it was only an idea. In CSAF product is defined in the Product Name and many Product Identification Helpers. Adding a mandatory product family category with a few pre-defined values and optional, custom, category to cover potential corner cases would be very useful. We won't mix product types within one support model, hence it will be compliant with CSAF Product definition (which is one of our objectives).

tschmidtb51 commented 1 month ago

@p-rog Thank you for your response - I guess that is even harder for me as non-native speaker. I'll try to reply anyway :wink:

Vendor term describes who is selling and delivering the support.

IMHO, those are two things that can be done by one party, but that is not always the case. For example, I bought a Lenovo device from a reseller, the support however is handled through Lenovo directly.

It means that in your example the FastRes and Stockpiler Warehouse are considered as vendors.

I can't follow that conclusion. FastRes takes OS 20 earlier out of stock, so I think they are not providing "extra support". For Stockpiler Warehouse it is not defined but OSTech might have an obligation to provide five years of support (ending on 2029-12-31) and (e.g. due to a different regulation where Stockpiler Warehouse is located) Stockpiler Warehouse has just the obligation to provide 2.5 years support (ending on 2029-12-30). The point is: We don't know and it should be independent of that question. The purpose here is to tell people "How long can you buy that product from us".

Nevertheless, I see the difference between a manufacturer (maybe better creator) and a vendor.

I agree that we should add a vendor definition to highlight what is mean here. BTW CSAF uses the following vendor definition (which leans more towards the creator/maintainer):

vendor: the community, individual, or organization that created or maintains a product (including open source software and hardware providers)

Regarding the category field to the product definition [...]

I think that the definition is unnecessary as the product is (hopefully) clearly defined by the issuing party. If the product is hardware, then this date applies to the hardware. If it is an AI training data set, then this applies to the data set. If it is software that lives on a hardware, then it is exactly that. It was just a comment, that IMHO we don't need the field as it makes OpenEoX broadly applicable (to all sorts of products) if we do not limit that to specific categories.

In CSAF product is defined in the Product Name and many Product Identification Helpers. Adding a mandatory product family category with a few pre-defined values and optional, custom, category to cover potential corner cases would be very useful.

This is something for the CSAF TC to discuss and independent of OpenEoX.

thschaffr commented 1 month ago

Hi @tschmidtb51,

thank you for your input. I like the idea of abstracting the term vendor and name it issuing party / issuer. In order to avoid confusion, I also agree with adding a issuer definition.

Regarding the product family. Personally I do favor having this field, as we can't always expect the issuer to describe their product in an adequate/targeted way. Sometimes the lines will be blurred, making it harder to interpret the issuing party's intention. Therefore, I like the idea of additionally having predefined options to choose from when it comes to the category or product family field.

Let's discuss this together with the TC.

Thank you.

thschaffr commented 1 month ago

Hi @tschmidtb51,

could it be that you meant to use the OS20 instead of OS24 release in your example below?

There are also two reseller: FastRes and Stockpiler Warehouse. FastRes already announced that its EoS for OS 24 is January 31, 2024. Stockpiler Warehouse announces to be selling OS 24 until June 30, 2027.

tschmidtb51 commented 1 month ago

Hi @tschmidtb51,

could it be that you meant to use the OS20 instead of OS24 release in your example below?

There are also two reseller: FastRes and Stockpiler Warehouse. FastRes already announced that its EoS for OS 24 is January 31, 2024. Stockpiler Warehouse announces to be selling OS 24 until June 30, 2027.

Thank you for pointing that out. I corrected the typos.

tschmidtb51 commented 1 month ago

I like the idea of abstracting the term vendor and name it issuing party / issuer. In order to avoid confusion, I also agree with adding a issuer definition.

Agreed, I think it makes it easier as it binds the statement to the party that publishes the document.

Regarding the product family. Personally I do favor having this field, as we can't always expect the issuer to describe their product in an adequate/targeted way. Sometimes the lines will be blurred, making it harder to interpret the issuing party's intention. Therefore, I like the idea of additionally having predefined options to choose from when it comes to the category or product family field.

I think this might be something that we could add in the shell schema. This would allow for it to be a part of OpenEoX and still is not mandatory exported into other standards that might have their own product definition.

p-rog commented 1 month ago

Regarding the product family. Personally I do favor having this field, as we can't always expect the issuer to describe their product in an adequate/targeted way. Sometimes the lines will be blurred, making it harder to interpret the issuing party's intention. Therefore, I like the idea of additionally having predefined options to choose from when it comes to the category or product family field.

I think this might be something that we could add in the shell schema. This would allow for it to be a part of OpenEoX and still is not mandatory exported into other standards that might have their own product definition.

:+1: to this idea, let's do it like this!

thank you for your input. I like the idea of abstracting the term vendor and name it issuing party / issuer. In order to avoid confusion, I also agree with adding a issuer definition.

The problem with issuer can mean an entity that publish the OpenEoX document. It could mean also the reseller, when even in your example, where you bought the Lenovo laptop, the reseller is not delivering it's own OpenEoX file. The Reseller can redistribute the original OpenEoX document issued by the original vendor. Vendor is the producer, maintainer and entity that deliver a support for the particular product.

I hope it makes sense.

tschmidtb51 commented 1 month ago

The problem with issuer can mean an entity that publish the OpenEoX document. It could mean also the reseller, when even in your example, where you bought the Lenovo laptop, the reseller is not delivering it's own OpenEoX file. The Reseller can redistribute the original OpenEoX document issued by the original vendor. Vendor is the producer, maintainer and entity that deliver a support for the particular product.

I hope it makes sense.

That is intended: The issuing party states the status for itself. If the reseller just provides the manufacturer's OpenEoX file - it just redistributes it. The issuing party stays the manufacturer. If the reseller provides its own, then it is the issuing party.

Note: I just realized that we don't have that in the shell schema yet - but I guess that is not too late to add it :wink:

santosomar commented 1 month ago

In other initiatives, we have called this supplier. However, that can also be tricky. Can we just use the definition of vendors like we do in CSAF?

In CSAF, we just call them vendors:

vendor: the community, individual, or organization that created or maintains a product (including open source software and hardware providers)

I am also including the following NIST definitions for reference and for people reading this thread:

p-rog commented 1 month ago

@tschmidtb51 it seems that we are going into the right direction :) Your issuing party term is my vendor term. Only small clarification, the issuing party or vendor is not necessary the original manufacturer (software creator).

I would propose to stay with the vendor term, because it's in sync wit CSAF standard like @santosomar mentioned above. We can extend our definition by adding that vendor can be considered also as issuing party. It's the entity that issue the OpenEoX file for the particular product, defining its support model and maintaining this product based on the defined support model.

What do you think? I can add the vendor (issuing party) definition to the https://github.com/oasis-tcs/openeox/issues/35 core definitions.

thschaffr commented 1 month ago

Summary for the TC meeting on Wednesday, Aug 21 2024:

santosomar commented 1 month ago

As discussed on 2024-08-21 the following is the current definition (which includes software and hardware):

The End-of-Sales (EoS) indicates the last day when a particular product (or the product version/release) may be ordered by customers from vendor sales channels. After this date, the product or specific version or edition of the software or license is no longer for sale. However, there might be other sources where the product is still available. Once the product reaches the End-of-Sales (EoS) lifecycle stage, it may still be supported by the vendor, based on the official or dedicated vendor lifecycle model for this product, for existing customers. The implications for existing customers regarding license renewals, updates, upgrades to newer versions or ongoing technical support can vary depending on the vendor's specific policies.

santosomar commented 1 month ago

The motion to accept the definition above is available at: https://groups.oasis-open.org/discussion/motion-to-accept-the-end-of-sales-eos-definition

sparrell commented 1 month ago

I'm not against definition above but I do wonder about supply chain issues and want to make sure I am reading correctly. If a piece of software has both an OEM and a VAR (ie the VAR buys from the OEM and resells, maybe under a different name or as part of something bigger or whatever) then the VAR could have a different EoS date than the OEM EoS date (maybe before, maybe after), correct? That is common in hardware so I want to make sure it applies to software as well.

santosomar commented 1 month ago

Hi @sparrell , yes indeed. We discussed this during today's meeting, as well as in the working session last month. This will definitely apply to what you suggested above. This scenario applies to software as well as hardware. Let me break down the key points to ensure clarity:

  1. OEM and VAR relationship:

    • OEM (Original Equipment Manufacturer) creates the original software.
    • VAR (Value-Added Reseller) buys from the OEM and resells the software.

  2. VAR modifications:

    • The VAR might rebrand the software (or hardware).
    • They could integrate it into a larger package or solution.
    • VARs often add value through customization, additional services, or support.

  3. Different EoS (End of Support) dates:

    • The VAR can indeed set a different EoS date than the OEM to their customers. They will issue an OpenEoX statement for that product.
    • This date could be earlier or later than the OEM's EoS date.

  4. Reasons for different EoS dates:

    • Earlier VAR EoS: The VAR might decide to stop supporting the product before the OEM does, perhaps due to a change in business strategy or the introduction of a replacement product.
    • Later VAR EoS: The VAR might offer extended support beyond the OEM's EoS date as a value-added service to their customers.

This practice is common in both hardware and software industries. It allows VARs to manage their product lifecycles independently, which can be beneficial for their business model and customer relationships.