Lisans Hakkı, Metrik ve Sözleşme Hiyerarşisi

Ön koşul: Arven iş akışı, çözüm mimarisi, sizing ve BoM satırlarını okuyabilmelisin. Bu dersin sonunda kurulabilir ürün ile kullanılabilir hak arasındaki farkı, bir lisans satırının metrik ve kapsamını ve geçerli belgeyi bulma yolunu açıklayacaksın. Yaklaşık 27 dakika anlatı, 25 dakika çalışma ve 14 dakika kontrol önerilir. Lisanslama bir sunucuda yazılımın çalışıp çalışmaması sorusu değildir; müşterinin belirli ürün, sürüm ve edisyonu, belirli kişi/cihaz/işlemci/ortam için, belirli tarihler arasında hangi koşullarla kullanabileceği sorusudur. Aktivasyon kodu geçerli sözleşmenin tamamı değildir. Kurulum envanteri gerçek kullanımın yalnız bir parçasıdır; çalışmayan DR kopyası, test ortamı, otomatik ölçeklenen kopya veya dolaylı erişim gibi durumlar ürün şartına göre ayrı sorular doğurabilir. Tersi de mümkündür: satın alınmış hak kullanıma alınmamış olabilir. Pre-sales'in görevi hukuki hüküm vermek değil, mimari ve teklifin hangi hak varsayımına dayandığını görünür kılmaktır. BoM'daki 'iki sunucu' satırı lisansın iki adet olacağını ispatlamaz. Önce hangi yazılım işlevi nerede çalışıyor, kim erişiyor, hangi metric sayılıyor ve lisans hakkı hangi belgede tanımlı sor. Ürün ailesi, sözleşme programı, bölge ve teklif tarihi bilinmeden sayıya kesin gözüyle bakma. Arven'in portal, ERP arayüzü, işletim sistemi, veri tabanı ve backup katmanları birden çok tedarikçinin farklı koşullarına tabi olabilir. Bir üreticinin soket veya sanal makine mantığını diğerine taşımak ciddi bir hata üretir. Bu derste örnekler yöntem içindir; müşterinin gerçek sözleşmesi, fiyatı veya hak miktarı bilinmiyor.

Bir lisans sorusunu 'internette hangi blog ne demiş' düzeyinde çözme. Önce müşterinin imzaladığı ana sözleşme ve sipariş/program kayıtları, sonra uygulanabilir ürün şartları, kullanım hakları, tanımlar, ürün veya edisyon özel hükümleri, ek haklar ve değişiklik tarihleri bulunur. Bazı üreticiler çevrimiçi şartları düzenli yeniler; arşiv veya etkin tarih seçimi teklif günündeki hak ile satın alma günündeki hakkın ayrılmasına yardım eder. Microsoft'un Product Terms açıklaması, ürün şartlarının müşterinin daha geniş sözleşmesinin bir bileşeni olduğunu ve program, ürün ve tarih açısından değerlendirilmesi gerektiğini söyler. Bu Microsoft'a özgü örnektir; diğer üretici için kendi kaynak hiyerarşisi aranır. Genel şart, model şartı ve ürün özel istisnası birlikte okunmalıdır. Bir satış slaydı, teklif eki veya bayi e-postası hakkın tek otoritesi olarak kabul edilmez. Yetkili yazılı teyit gerekiyorsa lisans uzmanı, üretici veya sözleşme sahibine net soruyla gidilir. Soruda ürün/SKU, edisyon, sürüm, satın alma kanalı, mevcut hak, fiziksel/sanal/bulut yerleşim, HA/DR/test ortamı, kullanıcı tipi ve hedef tarih bulunmalıdır. 'Bu lisans buluta taşınır mı?' çok geniştir; hangi cloud modelinde hangi çalıştırma/erişim hakkının geçerli olduğu sorulmalıdır. Belgeyi okurken tanım ve kapsam diline dikkat et. 'Server', 'OSE', 'instance', 'licensed device' veya 'subscription' farklı ürünlerde farklı anlam taşıyabilir. Sözleşmede yazmayan bir hak, teknik olarak mümkün diye var sayılamaz. Aynı şekilde eski bir kılavuzdaki kısıtı güncel belgeye bakmadan sonsuza dek geçerli sayma. Belge tarihi, URL, ürün şartı versiyonu, ilgili madde ve teyit eden kişiyi karar kaydına yaz; süreli teklif için yeniden kontrol tarihi koy.

Lisans metriği, kullanım hakkının neye göre ölçüldüğünü tarif eder; miktarı hesaplamak için envanter ve topoloji gerekir. Yaygın örnekler kullanıcı, cihaz, sanal makine/instance, soket, fiziksel çekirdek, vCPU, kapasite veya tüketimdir. Bunlar sektör genelinde birbirinin yerine geçen birimler değildir. AWS License Manager bir izleme aracı örneği olarak vCPU, core, socket ve instance metriğini destekler; bir araçta metrik seçebilmek herhangi üreticinin ürün hakkını tanımlamaz. Red Hat Enterprise Linux rehberi, belirli RHEL subscription paketlerinde fiziksel ve sanal dağıtım için farklı sayım seçenekleri verir. Buradan tüm Red Hat ürünlerinin veya başka Linux ürünlerinin aynı kurala tabi olduğu sonucu çıkarılmaz. Metrik birimini öğrendikten sonra kapsanan varlığı belirle: tek node mu, host çiftleri mi, cluster mı, VM'ler mi, kullanıcıların doğrudan/dolaylı erişimi mi, üretim yanında test ve DR mi? Kaynak tahsisi ile eşzamanlı kullanım aynı sayı olmayabilir. Çalışır VM'nin vCPU sayısı, fiziksel çekirdek sayısı veya yetkili kullanıcı sayısı ancak ilgili model öyle diyorsa hesap girdisidir. DR, failover, canlı taşıma ve burst durumunda çalışma sınırı değişiyorsa lisans kapsamı yeniden değerlendirilir. İki fiziksel düğüm için N+1 kapasite hesabı yapmak, yazılım hakkının sadece aktif düğümü kapsadığını kanıtlamaz. Bulut kullanımında 'license included' ile müşterinin mevcut lisansını getirmesi farklı seçeneklerdir; sağlayıcı, ürün, anlaşma ve bölge şartlarını ayrı doğrula. BoM'daki miktar ile lisans hesap tablosu aynı mimari revizyonu, aynı kapasite ve aynı dönem varsayımını göstermelidir. Ölçüm bilinmiyorsa örnek sayı üzerine keskin teklif kurma; miktar için aralık veya TBD, kritik karar etkisi ve owner yaz.

Pre-sales lisans konusunu yalnız satın alma ekibinin son gün işi olarak bırakırsa tasarım, uygulanamayacak bir hak varsayımına dayanabilir. Arven için lisans kanıt defteri aç: yazılım bileşeni ve işlev, ürün/sürüm/edisyon, kurulum ve erişim ortamı, olası metrik, ölçüm kaynağı, mevcut hak belgesi, satın alma kanalı, bitiş/yenileme tarihi, destek seviyesi, DR/test/taşıma sorusu, doğrulama sahibi ve güven düzeyi. Her satırı HLD/LLD ve BoM revizyonuna bağla. Hakkın doğrulanmadığı yerde örnek rakamı teklif kesinliği gibi yazma. Pre-sales ilgili soruyu açıkça formüle eder; lisans uzmanı ve sözleşme sahibi ürüne özgü yorum ve ticari koşulu teyit eder. Finans üç yıllık TCO'da başlangıç, yenileme, support, büyüme ve gerekirse bulut tüketimiyle aynı kapsamı hesaplar. Operasyon süresi dolan abonelik veya desteğin hizmet etkisini bilmelidir. Bir satır için karar durumu Verified, Conditional veya TBD olabilir. Verified, kaynak tarihi ve maddeyle sınırlıdır; sonsuz geçerli hak anlamına gelmez. Conditional, hangi sözleşme/ürün teyidinin hangi mimari ve fiyat satırını değiştireceğini söyler. TBD boş hücre değildir: sahibi, kapanış tarihi, etkisi ve fallback'i vardır. Arven'de ERP arayüz lisansı ölçüm birimi belirsizse portal mimarisini tümden durdurmak gerekmeyebilir; fakat ticari teklif ve koşullu mimari kararda bu açık risk görünür olmalıdır. Müşterinin mevcut hakkını yeniden kullanma iddiası, entitlement, destek ve taşıma kapsamı doğrulanınca yapılır. Tekliften önce belge/ürün şartı tarihi yeniden kontrol edilir; uygulama mimarisi veya sayım sınırı değişince hesap tekrar açılır. Böylece lisans yönetimi yalnız denetim korkusu değil, çalışabilir teklif ve öngörülebilir yaşam döngüsü kararına hizmet eder.