소프트웨어가 "사용 가능한 소스"이지만 "오픈 소스"는 아님

OSI가 공식적으로 승인 한 오픈 소스 라이센스 목록을 알고있을 것입니다. 가장 주목할만한 점은 GPL, MIT입니다.

나는 최근 오픈 소스 였지만 (작성자가 모든 소스 코드를 사용 가능하게 만들었 음) 공식 라이센스 중 하나에 따라 공식적으로 오픈 소스가 아닌 프로젝트를 만났다.

• 그것은 소스를 공개했지만 앞으로 소스를 공개하겠다고 약속하지 않았습니다.

• 수정 제안을 허용했지만 패치를 수락하고 외부 패치 버전의 외부 배포를 허용하지 않을 것이라고 약속하지 않았습니다.

• 상용 또는 유료 프로젝트에서 소프트웨어를 사용할 수는 있었지만 소프트웨어 자체의 판매는 허용하지 않았습니다.

우리가 생각하기에 오픈 소스가 아닌 "사용 가능한 소스"라고 할 수 있다고 생각합니다.

회사의 관리 팀이이 소프트웨어를 사용하고 싶지 않은 이유를 알 수 있습니다. 그들은 포크 할 수없고, 팔 수도없고, 자신의 소프트웨어 버전을 만들어 배포하거나 팔 수도 없습니다.

그러나이 소프트웨어를 방금 사용하는 소프트웨어 엔지니어링 팀의 일원으로서 당신에게 중요합니까? 나는 여전히 내 일을 할 수 있고, 내가 지불 한 프로젝트에서 사용할 수는 있지만 (어쨌든 나는 사업 자체가 아닌 소프트웨어 자체를 팔 수는 없다), 나는 할 수있다 내 요구에 따라 다르게 동작하도록 코드를 변경하십시오 (그러나 수정 사항을 공개 할 수는 없습니다). 이러한 수정 사항을 다른 사람에게 공식적으로 제공하려는 경우 승인은 프로젝트 자체에 달려 있으며 그들은 여부를 선택합니다 공식 릴리스에 포함할지 여부

따라서이 "사용 가능한 소스"소프트웨어를 기반으로 비즈니스를 운영하려는 회사는이를 수행 할 수 없지만 소프트웨어 엔지니어링 팀의 직원으로서 이러한 차이가 귀하에게 중요하거나 덜 관련성이있는 것처럼 보입니까?

다른 사람들이 이것에 대해 어떻게 생각하는지 궁금합니다.

이 소프트웨어가 제공하는 기능을 처음부터 개발해야했던 프로젝트의 경우 그렇게하지 않는 것이 매우 편리합니다.

그러나 비슷한 오픈 소스 패키지가 더 나은지 여부는 다른 요소에 달려 있습니다.

• 서비스를 제공하거나 다른 제품의 일부로 번들하는 데 사용됩니까?
• 제품을 독립적으로 향상시키고 유지 관리 할 수있는 리소스가 있습니까?
• 오픈 소스 버전 (코드 또는 프로젝트 관리)에서이 소프트웨어를 사용하면 경쟁 우위가 있습니까?

이러한 요소 중 어느 것에도 대답 하지 않으면 OSS가 더 나은 선택임을 나타냅니다.

대부분의 경우 코드 자체가 결정 요소가 아닙니다. 더 큰 그림을 조사해야합니다.

SIDEBAR OSS 프로젝트는 향후 버전을 공개하거나 향후 버전이있을 것이라고 법적으로 약속 할 수 없습니다 . 이것이 오픈 라이센스를 갖는 것이 유리한 이유 중 하나입니다. 또한 OSS 프로젝트는 기여자로부터 패치를받을 필요가 없습니다 (특히 소유권이나 권리의 양도없이).

이것과 다른 외부 라이브러리에 대한 질문은 유지 보수 입니다.

응용 프로그램의 수명은 얼마이며이 라이브러리의 명백한 수명은 얼마입니까? 당신의 희망이 가장 짧아야합니다.

이 라이브러리의 버그 수정은 누가 수행합니까? 여기서 볼 수 있듯이 회사는 향후 다른 수정 버그에 의존 할 수 없으므로이 소프트웨어를 유지 관리하기 위해 향후 명시 적으로 리소스를 할당해야합니다. 소스를 공유 할 수 없으므로 유지 관리 부담을 다른 사람과 공유 할 수 없습니다. 모르는 코드에서 어려운 경쟁 조건 버그를 해결하고 싶습니까?

이 생각만으로도 라이브러리를 사용하기에는 너무 비쌀 수 있습니다.

라이브러리가 매우 견고하고 강력하고 소스 수준에서 작업하기 쉬운 경우에는 관련이 없지만 내 오픈 소스 프로젝트의 동료 압력은 단순히 최선을 다하는 경향이 있기 때문에 단순히 코드를 개선하는 것입니다.

다른 사람들의 코드를 사용하는 모든 이유는 당신이 직접 처리 할 필요가 없기 때문에 개인적으로 나는이 코드 또는 다른 외부 코드를 채택 할 것인지에 대해 매우 신중하게 생각할 것 입니다. 또한 미래의 유지 보수 담당자를 생각하십시오-라이브러리에서 코드를 변경하는 소방 훈련을 수행하여 전혀 수행 할 수 있는지 확인해야합니다. 여기에는 매우 불쾌한 놀라움이있을 수 있습니다.

해당 도서관에 대해 자유롭게상의 할 수 있습니까?

솔직히 말해서, 회사의 관리 팀이 왜 "사용 가능한 소스"라이브러리를 사용하는 데 문제가 있는지 모르겠습니다. 자체 제품에 통합하는 경우 폐쇄 소스 라이브러리로 간주 할 수 있습니다.

저에게는 프로그래머로서 라이브러리가 "오픈 소스"인지 "사용 가능한 소스"인지는 중요하지 않습니다. 외부 라이브러리를 로컬로 수정하지 않는 것이 좋습니다. 추가 유지 관리 부담이 있기 때문입니다. 로컬 수정에서 버그가 발견되었을 때뿐만 아니라 라이브러리의 새 릴리스가 나오면 수정을 계속 통합하는 것에 대해서도.

IMHO의 "오픈 소스"가 질문에 요약 된 "사용 가능한 소스"라이센스를 능가하는 유일한 상황은

• 당사 제품의 라이센스에는 포함 된 라이브러리의 소스 공개가 필요합니다
• 우리는 라이브러리의 확장 / 확장 버전을 생산하는 사업에 있습니다

그렇기 때문에 자유 소프트웨어 재단은 '무료'또는 '비 무료' 라는 용어를 사용하여 소프트웨어를 설명합니다. 이들은 가격을 말하는 것이 아니라 소프트웨어의 사용 또는 배포에 관한 제한 사항입니다.

소스 코드에 완전히 액세스 할 수있는 드문 경우이지만 OSI 정의에 의해 소프트웨어가 "오픈 소스"가 아닌 것 같습니다 .

어느 용어 든 잘못 될 수있는 능력이 있습니다. 첫 번째 emacs 사본 (QIC 테이프)에 $ 50를 지불했지만 emacs는 무료 소프트웨어 입니다. 회사에서 내부적으로 사용하는 일부 독점 응용 프로그램에 대한 소스 코드가 있지만 오픈 소스가 아닙니다.

(적어도 나에게) 가장 큰 적기를 제기하는 것은 향후 버전의 소스 코드에 액세스한다고 보장하지 않습니다. 이 도구를 수정하는 데 크게 의존한다면 조심해야합니다. 공급 업체와 구두 계약을 체결하더라도 계약 형식이 아닌 한 코드를 항상 보유하게됩니다.

CTO는 자유 소프트웨어가 아닌 소프트웨어에 의존 하지 않도록 최선을 다합니다 . 나는 과거에 여러 번 벤더 잠금 장치의 나쁜 끝을 겪었습니다. 우리는 독점적 인 물건을 사용하지만 갑자기 우리가 더 이상 사용할 수 없다면 우리의 사업은 과도한 어려움을 겪지 않을 것입니다.

이 소프트웨어를 가지고 코드에 액세스하는 것과 관련하여 물건을 만드는 것처럼 들리므로 항상 액세스 할 수 있다는 것을 서면으로 작성하는 것이 좋습니다 . 공급 업체를 구매하면 어떻게됩니까?

이것은 꽤 중요합니다. 설명한 "사용 가능한 소스"접근 방식의 주요 문제 :

• 소스를 수정할 자유가 없다면 기술적 인 운명을 통제 할 수 없습니다. 소스를 직접 해킹하는 것은 복잡한 해결 방법보다 선호 될 수 있습니다.
• 소프트웨어가 계속 유지 될 것이라는 보장은 없으며, 진정한 오픈 소스를 통해 스스로 소프트웨어를 대체 할 수있는 대체 옵션이 없습니다.
• 사용자 정의 라이센스처럼 들리므로 GPL 또는 BSD 라이센스와 같이 잘 알려져 있고 입증 된 것을 사용하는 것에 비해 법적 위험이 더 큽니다.
• 그것이 실제 오픈 소스가 아니라면, 당신은 그와 비슷한 수준의 유용한 커뮤니티를 얻지 못할 것입니다. 이것은 많은 오픈 소스 프로젝트 의 주요 이점입니다

내 제안 : 오픈 소스 라이센스로 소프트웨어를 공개하도록 제작자를 설득하려고 노력하십시오. 오픈 소스 라이센싱하에 원하는 소프트웨어를 얻을 수 있기 때문에 프로젝트를 오픈 소스로 만드는 것이 장기적으로 소프트웨어를 더욱 성공적으로 만들 가능성이 높기 때문에 제작자는 모두에게 유리합니다.