Hva team antar versus hva lisensene krever

Open source betyr ikke fravær av juridiske forpliktelser.

Det betyr at forpliktelsene er standardiserte, offentlige og håndhevbare, ofte uten at noen i teamet har lest dem.

• Antakelse

  “Det er open source. Vi kan bare levere det.”

  Virkelighet

  Hver komponent kommer med vilkår. Permissive lisenser krever fortsatt opphavsretts- og lisensmerknader i distribusjoner. Copyleft-lisenser kan kreve kildekodetilbud, videreføring av lisensen og distribusjonsanalyse. Ikke en fotnote på en wiki.

• Antakelse

  “Vi er SaaS, så lisenser gjelder ikke oss.”

  Virkelighet

  Noen forpliktelser er lettere ved rent nettverksbasert bruk; mange er det ikke. GPL, LGPL, Apache-navngivelse i installasjonsprogrammer, videredistribusjon av fonter og navngivelse av ressurser betyr fortsatt noe. Og kundene spør fortsatt om hva du leverer og hva du bunter med.

• Antakelse

  “Juridisk tar seg av det hvis det er viktig.”

  Virkelighet

  Juridisk kan ikke operasjonalisere det ingeniørene aldri har ført opp. Pakkelister endrer seg hver sprint; fonter, ikoner og SDK-er dukker ofte aldri opp i dem. Innen juridisk kobles inn, er utgivelsen allerede ute.

• Antakelse

  “Vi har en LICENSE-fil i repoet.”

  Virkelighet

  Lisensen i repoet ditt er din egen. Ikke avhengighetenes. En enkelt navngivelsesfil fra tre år tilbake beskriver ikke det kundene laster ned i dag.

• Antakelse

  “npm update er bare en patch, etterlevelsen forblir den samme.”

  Virkelighet

  En versjonsoppdatering kan endre den reelle lisensen, legge til copyleft, eller bytte ut forpliktelsene helt. Rutineoppdateringer er en av de vanligste måtene etterlevelsen brytes på uten at noen legger merke til det.