Apple의 iPhone 및 공식 App Store와 호환되는 오픈 소스 라이선스는 무엇입니까?
iPhone 앱을 작성 중이며 기능의 일부로 타사 라이브러리를 사용하고 싶습니다. App Store를 통해 판매 할 예정이며 내 코드는 오픈 소스가 아닙니다. 파생물을 만들고 Apple의 자체 조건하에 게시 할 수있는 오픈 소스 라이선스는 무엇입니까?
짧게 / TL; DR :
LGPL 및 응용 프로그램 저장소에는 몇 가지 비 호환성이 있습니다. 즉, DRM이 활성화 된 AppStore 또는 잠긴 장치에 LGPL 코드를 배포 할 수있는 권한이 없습니다.
Apache 2 라이선스, Microsoft Public License 또는 MIT X11 라이선스와 같은 다른 laxer 라이선스에서 라이브러리의 대체 구현을 찾는 것이 가장 좋습니다.
더 길게:
LGPL은 다음과 같이 말합니다.
이 요구 사항은 일반적으로 운영 체제와 함께 제공되지 않는 다른 독점 라이브러리의 라이센스 제한과 모순 될 수 있습니다. 이러한 모순은 배포하는 실행 파일에서 두 라이브러리와 라이브러리를 함께 사용할 수 없음을 의미합니다.
LGPL 코드를 독점 코드와 정적으로 연결하는 권한은 LGPL의 섹션 6에 있습니다. 해당 섹션에서 부여 된 권한 외에도 코드의 다운 스트림 수신자에 대한 요구 사항을 다룹니다.
이 섹션을 자세히 읽어야합니다.
Pay-for-Development와 LGPL 간의 충돌
사용자가 프로그램에 들어가 키 인증서, 프로비저닝 프로파일 및 장치에 배포하기위한 도구를 얻기 위해 비용을 지불해야하는 애플리케이션 스토어는 LGPL과 직접 모순됩니다.
LGPL을 사용하려면 최종 사용자가 개체 파일과 오픈 소스 라이브러리 (및 도구, 아래 섹션 참조)를 가져 와서 작동하는 일부 코드를 생성 할 수 있어야합니다. 다운 스트림 수신자가 자신의 하드웨어에 코드의 작동 버전을 배포하기 위해 Apple, Microsoft, Amazon 또는 Google과 별도의 계약을 체결 할 여지가 없습니다.
특히이 섹션은 관련이 있습니다.
귀하는 여기에서 부여 된 권리의 수령인의 행사에 대해 추가 제한을 부과 할 수 없습니다. 귀하는 제 3자가 본 라이센스를 준수하도록 할 책임이 없습니다.
사용자에게 AppStore에 애플리케이션을 다시 게시 할 수있는 권한을 부여 할 필요는 없지만 수정 된 버전의 LGPL 코드를 사용하여 앱을 자신의 장치에 배포 할 수있는 권한을 사용자에게 부여해야합니다. 배치에 대한 추가 지불은 LGPL과 충돌합니다.
개체 파일 배포
결과 실행 파일의 조건을 통해 수신자가 LGPL 코드를 변경하고 코드에서 새로운 작업 비트를 생성 할 수 있는지 확인해야합니다. 이는 실제로 제 3자가 애플리케이션을 수정 된 버전의 라이브러리와 다시 연결하여 버그를 수정하거나 어떤 방식 으로든 개선하거나 자체 기능을 제공 할 수 있도록 프로그램의 개체 파일을 배포해야 함을 의미합니다.
웹 사이트에 개체 파일을 게시하고 타사에서 응용 프로그램을 다시 연결할 수 있도록 프로젝트를 제공하면이 문제를 해결할 수 있습니다. 그렇게하지 않으면 LGPL에 대한 라이센스가 취소됩니다.
리버스 엔지니어링에 대한 권리
이것은 섹션 6의 또 다른 요구 사항입니다.
이는 다양한 애플리케이션 스토어의 약관과 직접적인 충돌이있을 수 있지만 사용중인 애플리케이션 스토어 (Apple, Amazon, Android 또는 기타 타사)에서 정확한 약관을 확인해야합니다.
공지 및 광고
LGPL 코드에 대한 요구 사항의 일부로 다운 스트림 사용자에게 제공되는 애플리케이션은 LGPL 라이선스와 함께 제공되어야하며 저작권 고지를 표시하는 애플리케이션의 모든 위치에서이 라이선스를 가리켜 야합니다. 일부 응용 프로그램 저장소는이를 응용 프로그램 저장소 사이트에 게시하고 다른 저장소에는 실행 파일 자체에 대한 저작권 정보가있을 수 있습니다.
수정 된 LGPL 코드 배포
이것은 준수하기가 매우 쉽습니다. 웹 사이트에 LGPL 코드 사본을 배포하기 만하면됩니다 (코드를 사용 가능하게 유지하는 데 필요한 시간에 대한 라이센스에 대한 추가 세부 사항이 있습니다).
충족 할 수없는 요구 사항
LGPL과 애플리케이션 저장소를 통해 배포되는 애플리케이션에서 정적 라이브러리를 사용하는 주요 문제 중 하나는 최종 사용자가 소프트웨어를 다시 빌드하는 데 필요한 도구와 스크립트를 배포해야한다는 것입니다.
일부 임베디드 시스템 시나리오의 경우 임베디드 시스템 공급 업체가 최종 사용자에게 개발자 도구 및 API를 공개하도록 요구할 수 있으며 이는 불가능할 수 있습니다. 이 경우 의무를 이행하기 위해 iPhone 또는 Windows SDK와 같은 것을 자유롭게 재배포 할 수 있는지 여부는 명확하지 않습니다. 변호사와 논의하여 요구 사항 노출에 얼마나 편한지 알아보십시오.
할 수있는 일
앱 스토어 또는 임베디드 시스템에서 일부 LGPL 코드를 반드시 사용해야하는 경우 언제든지 코드의 원래 작성자에게 연락하여 다른 조건에 따라 코드에 대한 라이선스를 부여하도록 요청할 수 있습니다.
또는 Apache 2 라이선스, Microsoft Public License 또는 MIT X11 라이선스와 같은 다른 laxer 라이선스에서 라이브러리의 대체 구현을 찾을 수 있습니다.
LGPL에 관해서는 St3fan이 틀렸다고 생각하지만 Louis Gerbarg는 맞습니다. 비공개 소스 iPhone 앱에서 LGPL 라이브러리를 사용할 수 있지만 제한이 있습니다.
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License를 살펴보면 "또는 소스 코드 또는 링크 가능한 개체 파일이 제공되는 경우 정적으로 링크 된 라이브러리가 허용됩니다."를 읽을 수 있습니다.
따라서 Louis Gerbarg가 언급했듯이 LGPL 라이브러리를 사용하는 경우 고객이 애플리케이션을 가져 오는 데 필요한 객체 (예 : * .o) 파일을 자유롭게 사용할 수있는 한 애플리케이션을 비공개 소스로 유지할 수 있습니다. 링크하십시오.
여기서는 iPhone 및 LGPL 호환성 에 대해 자세히 설명 합니다 .
라이브러리의 LGPL 라이선스에 의해 부과되는 앱에 대한 세부 요구 사항 :
d) 다음 중 하나를 수행합니다.
0) 본 라이선스의 조건에 따라 최소 해당 소스를 전달하고 사용자가 애플리케이션을 수정 된 버전의 링크 된 버전과 다시 결합하거나 다시 연결하여 애플리케이션을 생성하는 데 적합한 형식으로 해당 애플리케이션 코드를 해당 출처를 전달하기 위해 GNU GPL의 섹션 6에 지정된 방식으로 수정 된 결합 작업.
LGPL이 iPhone 응용 프로그램에서 작동하지 않을 것이라고 생각합니다.
문제는 iPhone 런타임이 공유 라이브러리 (또는 프레임 워크)를 앱과 번들링하는 것을 허용하지 않는다는 것입니다. 단일 바이너리 응용 프로그램 만 허용됩니다. LGPL은 공유 라이브러리를 애플리케이션과 번들로 제공한다는 가정을 기반으로합니다. 직접 연결은 여전히 금지되어 있습니다.
Apple App Store는 GPL과 LGPL의 모든 버전과 Affero GPL에 존재하는 FSF의 카피 레프트 아이디어와 호환되지 않습니다. Apple App Store는 사용자가 자유 소프트웨어를 가져 와서 수정 한 다음 자신의 장치에서 자유롭게 실행할 수 있도록 허용하지 않습니다. DRM을 사용하고, 1 년에 $ 100를 지불하고, 추가 약관에 동의해야합니다. 여기에 대한 내용이 꽤 잘 나와 있습니다. http://michelf.com/weblog/2011/gpl-ios-app- 저장/
iOS 용 GPL / LGPL 소프트웨어를 App Store 외부에 배포하는 것은 완전히 합법적이며 문제는 Apple App Store에 있습니다. 따라서 제한 사항을 변경하기 위해 Apple에 로비를하는 것이 좋습니다. Mac OS X와 iOS는 기본적으로 GPL / LGPL 소프트웨어 (예 : gcc 등)에 의존하기 때문에 Apple은 자유를 누리고 있지만 사용자에게 동일한 자유를 거부하고 있습니다.
As for licenses that the App Store is compatible with, you will need to go with the very permissive licenses like BSD, MIT, Apache, or public domain.
This is not legal advice, I am not a lawyer, but it sounds like you need a library with a BSD or Apache license. That would be the case if you were developing a proprietary desktop program that used an open source library. I don't know if Apple has any further restrictions for iPhone apps.
(I am not a lawyer.)
Static object file linking may address the question of how to allow an app which uses LGPL licensed code to be made available without distributing the non-LGPL'd portions of its source code.
But it seems like LGPL, as a variant on GPL, imposes a larger insurmountable problem for iPhone app development in that the development tools needed to create and distribute any iPhone app are only available under terms from Apple that are incompatible with GPL. ie. There is a $100/year fee, and there are numerous terms and conditions on the use of those tools that are not part of the GPL license. The terms of the license for Apple's iPhone developer tools seem to be incompatible with the spirit of and perhaps also the letter of GPL.
If you're not releasing your source code, you can't use any strict copyleft license. You can't use any GPLv3-based license in any case, since the iPhone distribution conflicts with the no-Tivoization clause.
If you're using LGPLv2, you'll have to provide your program in linkable format, which may or may not be acceptable (at least it's not source code), and this is likely to be something you don't want to deal with, unless the library offers a lot of benefit.
If there's one copyright holder on the library, you can always see if you can get a license exception.
You won't have any problem with the typical BSD/MIT/Boost/whatever permissive licenses. There are a lot of Open Source/Free Software licenses out there, and for the rest you'll have to read them and see.
When I try to port Fuego onto iPhone, I asked a similar question on the fuego mailing list. So far, my understanding is "LGPL is not compatible with AppStore". A previous question also receives an answer as: no.
A good example is Wunderradio. They use ffmpeg and other LGPLv2 licensed frameworks, and provide the .o files on their website.
Strangely, they also provide full source code for their app.
http://wunderradio.com/code.html
The folks who maintain that the App Store terms of service are problematic, in particular the $100 yearly Apple Dev program fee, are wrong. That $100 is not even close to a showstopper. It is typical of developers that they spend so much time worrying about these type of things ;0) Lawyers have been stick-handling around contract provisions for thousands of years and these are hardly worth losing any sleep over.
Prerequisite: Provide the object files and a basic project file from a web location accessible via a link in the app.
Option 1, for cowboys: Jailbreaking is officially legal (and free). That alone voids any concerns over compatibility between LGPL and the App Store terms. Where does the LPGL specify a particular distribution channel? Nowhere. You want to upgrade a statically linked library in an app you downloaded via the app store? Suck it up, alpha dev and jailbreak your phone! Just because Apple is a bully in the playground doesn't force you stay on their merry-go-round. Enterprising developers can thereby receive valuable bragging rights at the next meetup. Plus the fact that you jailbroke your phone in order to upgrade an LPGL library gives you access to the keg room in Richard Stallman's basement!
Option 2 for getting around it legally, and in good faith: Section 1 of LGPL v2.1 (and section 4 of the GPL v3) allows developer to charge a fee for the physical act of copying the library. This provides a mechanism for the developer to re-assign that fee towards the $99 Apple Dev subscription fee.
What about the 100 device limit? End users who wish to upgrade their binary are upgrading a commercial application, so the app developer's own license terms come into play. It is trivial to add a 100 device limit to a custom license agreement. How many people own more than 100 iOS devices? Even Jobs didn't own that many! It's hardly an unreasonable limit. Given that there's no requirement that an end-user be allowed to release their own modified version of the original commercial app into the wild, there will be no basis for complaints when it fails to load on the device of the modifier's 101st friend.
There is no requirement in the LGPL that the end user has to have a comfy, risk-free, or even obvious choice. They just have to have a choice, and there's 2 perfectly good ones.
'UFO ET IT' 카테고리의 다른 글
| 명령에서 결과 데이터가 필요할 때 명령 쿼리 분리 (CQS)를 어떻게 적용합니까? (0) | 2020.12.01 |
|---|---|
| "해제 된 스크립트에서 코드를 실행할 수 없습니다"오류의 원인 (0) | 2020.12.01 |
| VS2015 : 경고 MSB3884 : 규칙 집합 파일을 찾을 수 없습니다. (0) | 2020.11.30 |
| NSNumber와 NSInteger의 차이점은 무엇입니까? (0) | 2020.11.30 |
| 코드 골프 : 큐브 플레이 (0) | 2020.11.30 |