Category Archives: Documents

그냥 인터넷 문서들.

Http/2에서 변경되는 부분

Spec 문서 : https://tools.ietf.org/html/rfc7540

Github에 올라온 문서 : https://http2.github.io/faq/

 

Http/2정보 몇가지

구글 SPDY스피디에서 몇가지 스펙 덧붙여서 만든 프로토콜(인 것 같다)

Explorer 8(WinXP)에서 지원안함 볼 수 없음.. (현재 사용자의 6%가량)

Http 0.9 1.0 1.1처럼 .x가 안 붙고 Http/2라는것은 버전업을 할 예정이 없어서라고 자신있게 말 했다던데…

 

Http/2의 특징 대표적인 3가지는 아래~

참고정보 : https://b.luavis.kr/http2/http2-overall-operation

1.multiplex streams

http1은 무전기였다면 http2는 전화기. 양방향 데이터 흐름
http1은 request-response가 반복되느라 낭비가 있었는데
http2는 쭉 흘러온다고… stream. 그것도 양방향

http1에서 도메인당 request-response 채널이 보통 10개밑으로 열린다고 했다. 그래서 html, js, css, image. 등등을 다 다른도메인으로 설정하는 꼼수로 속도를 빠르게 할 수 있다고…

2. header compression

압축방식 : zlib(SPDY) -> HPACK(Http/2)
Http1.1까지는 text 통신이었는데 Http/2는 binary 통신이다. 압축해서 전달.

그로인한 변화는
text기반인 telnet은 이제 쓸 수 없다.
네트워크 용량이 절약된다.

3. server push

http1에서 html을 요청해서 받고나서 html을 파싱한다음에 리소스를 요청하는식으로 처리를 했다면… http2에서는 예상되는 파일들을 먼저 보내준다.
서버가 해킹당하면 이상한 파일을 먼저 보낼 수 있지 않을까? 라고 생각할 수 있지만.. 어련히 잘 해놨겠지? 나중에 찾아봐야겠다. (인증서라던가 신뢰할 수 있는 서비스에서만 사용할 수 있게 변경되는걸로 되지 않을까)

server push는 websocket과는 다른 기술이다.
관련 포스팅 : https://www.infoq.com/articles/websocket-and-http2-coexist
Well, the answer is clearly no, for a simple reason: As we have seen above, HTTP/2 introduces Server Push which enables the server to proactively send resources to the client cache. It does not, however, allow for pushing data down to the client application itself. Server pushes are only processed by the browser and do not pop up to the application code, meaning there is no API for the application to get notifications for those eve
대강 … 이벤트 전달용이 아니라 리소스만 전달한다는 것 같다.
WebSocket은 메셰지나 이벤트를 전달하는 용도고

이런이유로 속도가 빨라지고 네트워크 자원이 절약된다고 한다. Google이 죽자고 크롬 만들어서 배포한 이유가 여기 있었다. SPDY프로토콜 이용한 통신으로 네트워크 비용을 많이 절약했겠다.

빼먹은거 하나. Http1.1도 gzip 압축compress해서 전송하는걸 지원하긴했는데 Http/2에서 개선된점은 압축방식이 더 좋다고 한다. 뭔진 모르겠지만… 그리고 Http1에서는 헤더는 압축불가능하고 반복되는게 계속 전달됐는데 Http/2는 헤더와 쿠키의 반복전송을 하지 않는다는점.

웹개발자들은 WindowsXP8 유저들을 위한 대안도 준비해야겠다.
웹개발은 진짜 돈도 안되고 신경쓸것도 많고

OAuth2 Spec. – 1.3. Authorization Grant

1.3. Authorization Grant

An authorization grant is a credential / representing the resource owner’s authorization / (to access its protected resources) / used by the client / to obtain an access token. // This specification defines four grant types / — authorization code, implicit, resource owner password credentials, and client credentials — as well as an extensibility mechanism // for defining additional types.

authorization grant는 자격이다. / resource owner의 authorization인증을 대표하는 / (이것의 protected보호된 resources자원에 접근하기 위해) / client에 의해 사용된다 / access token을 얻기 위해. //
이 규격은 네 가지 인증 타입을 정의한다 / — 인증코드, 내재화, 자원소유자의 비밀번호 인증정보, client 인증정보 — / 게다가 추가적인 타입을 위한 확장 메커니즘

authorization grant는 client가 resource owner의 protected resource에 접근하기 위한 access token을 받기위한 인증을 말한다.
이 규격서는 네가지 인증 방식grant types을 정의한다
authorization code
implicit
resource owner password credentials
client credentials
위 네개 뿐 아니라 추가로 확장도 가능하다

1.3.1. Authorization Code

The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code.

authorization server : client와 resource owner사이의 중재자 역할을 한다
authorization code는 authorization server에서 얻을 수 있다.
client는 authorization을 resource owner에 직접 요청하는 대신에 resource owner를 authorization server에 연결해줄 수 잇다. ([RFC2616]에 정의되어있는 user-agent를 이용)

Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner’s credentials are never shared with the client.

resource owner에서 client로 authorization code를 전달하기 전에 authorization server는 resource owner를 인증하고 authorization을 얻는다. 왜냐하면 resource owner는 authorization server과만 인증을 하고 resource owner의 인증정보는 client와 공유되지 않기 때문이다.

The authorization code provides a few important security benefits,
such as the ability to authenticate the client, as well as the
transmission of the access token directly to the client without
passing it through the resource owner’s user-agent and potentially
exposing it to others, including the resource owner.

authorization code는 몇가지 보안 잇점이 있다. client를 인증하는 기능, 예를들어) access token을 resource owner의 user-agent를 거치지 않고 직접 client에 전달한다던가… 그리고 잠재적으로 이게 resource를 포함해서 제3자에게 노출될 가능성 없다

1.3.2. Implicit

The implicit grant is a simplified authorization code flow optimized
for clients implemented in a browser using a scripting language such
as JavaScript. In the implicit flow, instead of issuing the client
an authorization code, the client is issued an access token directly

Implicit 인증은 authorization code의 절차를 간소화 시킨 것이다. JavaScript와 같은 Brower단의 스크립트 언어에서 쓸 수 있도록. client에게 authorization code를 발급하는 대신에 client는 access token을 직접 발급한다.

(as the result of the resource owner authorization). The grant type is implicit, as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token).
(resource owner의 인증의 결과로). grant type인증 타입이 implicit인 경우 중재해주는 credential이 발급되지 않는다. (authorization code라던가…)(그리고 나중에 access token을 얻을 때 쓰인다)

When issuing an access token during the implicit grant flow, the
authorization server does not authenticate the client. In some
cases, the client identity can be verified via the redirection URI
used to deliver the access token to the client. The access token may
be exposed to the resource owner or other applications with access to
the resource owner’s user-agent.

implicit 인증 흐름에서 access token이 발급될 때 authorization server는 client를 인증해주지않느다. 간혹, client identify가 redirection uri로 전달된 access token으로 인증되기도한다. access token은 노출될 수 있다. resource owner에게 또는 다른 application이 reosurce owner의 user-agent에 접근할 때

Implicit grants improve the responsiveness and efficiency of some
clients (such as a client implemented as an in-browser application),
since it reduces the number of round trips required to obtain an
access token. However, this convenience should be weighed against
the security implications of using implicit grants, such as those
described in Sections 10.3 and 10.16, especially when the
authorization code grant type is available.

implicit 인증은 민감성과 효율을 증가시킨다.(TODO)

1.3.3. Resource Owner Password Credentials

The resource owner password credentials (i.e., username and password)
can be used directly as an authorization grant to obtain an access
token. The credentials should only be used when there is a high
degree of trust between the resource owner and the client (e.g., the
client is part of the device operating system or a highly privileged
application), and when other authorization grant types are not
available (such as an authorization code).

Even though this grant type requires direct client access to the
resource owner credentials, the resource owner credentials are used
for a single request and are exchanged for an access token. This
grant type can eliminate the need for the client to store the
resource owner credentials for future use, by exchanging the
credentials with a long-lived access token or refresh token.

1.3.4. Client Credentials

The client credentials (or other forms of client authentication) can
be used as an authorization grant when the authorization scope is
limited to the protected resources under the control of the client,
or to protected resources previously arranged with the authorization
server. Client credentials are used as an authorization grant
typically when the client is acting on its own behalf (the client is
also the resource owner) or is requesting access to protected
resources based on an authorization previously arranged with the
authorization server.

OAuth2 Spec. – 1.2. Protocol Flow

https://tools.ietf.org/html/rfc6749#section-1.2

1.2. Protocol Flow
protocol의 흐름

+——–+ +—————+
| |–(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| | | | +---------------+ | | | | +---------------+ | |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| | | | +---------------+ | | | | +---------------+ | |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| | +--------+ +---------------+ Figure 1: Abstract Protocol Flow The abstract OAuth 2.0 flow illustrated in Figure 1 describes the interaction between the four roles and includes the following steps: OAuth 2.0의 개념은 Figure 1과 같다. (A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary. client는 resource owner에게 인증을 요청한다. 인증 요청은 resource owner에게 직접 할 수도 있는데 보통 authorization server를 통해 간접적으로 한다. (B) The client receives an authorization grant, which is a credential representing the resource owner's authorization, expressed using one of four grant types defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server. client는 resource owner의 인증정보를 갖고있는 authorization grant를 받는다. 이 규격서에 네가지 grant type이 정의되어있다. client에서 알아서 골라쓰면되고 authorization server는 이 방법을 모두 지원한다. **라고 하지만 이 스펙을 온전히 지원하지 않는 경우가 많은 것 같다 (C) The client requests an access token by authenticating with the authorization server and presenting the authorization grant. client는 authorization grant를 에서 authorization server에게 access token요청을 보낸다. (D) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token. authorization server는 client를 인증하고 authorization grant를 검증한다. 맞으면 access token을 발행해준다. (E) The client requests the protected resource from the resource server and authenticates by presenting the access token. client에서 resource server에 protected resource를 요청한다. 이 때, access token을 함께 보내서 인증을 처리한다. (F) The resource server validates the access token, and if valid, serves the request. resource server에서 access token을 확인해서 처리. The preferred method for the client to obtain an authorization grant from the resource owner (depicted in steps (A) and (B)) is to use the authorization server as an intermediary, which is illustrated in Figure 3 in Section 4.1. 위의 (A), (B)를 쓰는 방법보다 4.1에 나와있는 방법을 추천한다. * 위의 방법은 client에 계정정보가 노출됨.

OAuth2 Spec. – 1.1. Roles

https://tools.ietf.org/html/rfc6749#section-1.1

1.1. Roles

OAuth defines four roles:
OAuth에는 네가지 역할이 있다.

resource owner
리소스 주인님
An entity capable of granting access to a protected resource.
When the resource owner is a person, it is referred to as an
end-user.
protected resource로의 접근을 허가해 줄 수 있는 사람 또는 서비스. resource owner가 사람인 경우는 end-user(최종사용자,서비스사용자)

resource server
리소스 서버
The server hosting the protected resources, capable of accepting
and responding to protected resource requests using access tokens.
protected resource를 가지고있는 서버. access token을 이용한 요청을 받아들이고 응답해줌. 그냥 리소스 서버

client
손님(OAuth2로 인증하는 모바일앱, 웹사이트.. 예) 네이버 App은 Naver의 Client앱이다)
An application making protected resource requests on behalf of the
resource owner and with its authorization. The term “client” does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).
resource owner대신에 protected resource를 관리하는 응용프로그램.
‘client’는 특정 구현방식을 갖고있지 않다. server, desktop, 또는 다른 device에서 구현 가능하다.

authorization server
인증 서버
The server issuing access tokens to the client after successfully
authenticating the resource owner and obtaining authorization.
client가 resource owner임이 확인되었거나 허가를 받은 경우.
client에게 access token을 발행하는 서버

The interaction between the authorization server and resource server
is beyond the scope of this specification. The authorization server
may be the same server as the resource server or a separate entity.
A single authorization server may issue access tokens accepted by
multiple resource servers.
authorization server와 resource server 간의 통신은 이 규격에 포함되지 않는다.
이 부분은 맘대로하라구

OAuth2 Spec. – 1. Introduction

https://tools.ietf.org/html/rfc6749#page-4

1. Introduction 소개

In the traditional client-server authentication model, the client
requests an access-restricted resource (protected resource) on the
server by authenticating with the server using the resource owner’s
credentials. In order to provide third-party applications access to
restricted resources, the resource owner shares its credentials with
the third party. This creates several problems and limitations:
기존의 client-server 인증모델은, client가 resource owner의 credential을 가지고 protected resource에 접근하는 형태다. thrid-party application이 redtricted-resource에 접근하려면 resource owner의 credential을 가지고 있어야 한다. 위의 사항들은 아래의 문제와 제약을 갖는다 :

o Third-party applications are required to store the resource
owner’s credentials for future use, typically a password in
clear-text.
Third-party application은 앞으로 사용할 resource owner의 credential을 다 가지고 있어야한다. 보통 password를 텍스트로 보관한다.

o Servers are required to support password authentication, despite
the security weaknesses inherent in passwords.
Server는 취약한 패스워드 인증방식을 꼭 지원해야한다.

o Third-party applications gain overly broad access to the resource
owner’s protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of
resources.
Third-party application은 resource owner의 protected resource에 대한 광범위한 접근권한을 갖게된다. resource owner는 일부 resource에 대해 별도의 시간제한이나 접근제한을 걸 수 없다.

o Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by
changing the third party’s password.
(OAuth2를 쓰지 않는경우)Resource owner에서 third party 앱의 접근을 관리할 때는 일부 리소스에 접근을 제한할 수 없고 비밀번호를 바꿔서 전체 리소스의 접근을 모두 제한해야한다.

o Compromise of any third-party application results in compromise of
the end-user’s password and all of the data protected by that
password.
?? Third-party application의 결과는? end-user 비밀번호에 달려있다. 모든 데이터는 end-user 비밀번호에 의해 보호된다.

OAuth addresses these issues by introducing an authorization layer
and separating the role of the client from that of the resource
owner. In OAuth, the client requests access to resources controlled
by the resource owner and hosted by the resource server, and is
issued a different set of credentials than those of the resource
owner.
OAuth는 이 문제들을 authorization layer를 이용해서 그리고 resource owner의 client의 role을 이용해서 해결했다. OAuth에서 client의 접근은 resource owner에 의해 동작한다. resource server에서 서비스된다. 그리고 이것들은 resource owner고 다른 인증값을 사용한다.

Instead of using the resource owner’s credentials to access protected
resources, the client obtains an access token — a string denoting a
specific scope, lifetime, and other access attributes. Access tokens
are issued to third-party clients by an authorization server with the
approval of the resource owner. The client uses the access token to
access the protected resources hosted by the resource server.
protected resource에 접근할 때, resource owner의 credential을 사용하는 대신에 client는 access token을 받는다. (access token : 문자열로 되어있고, 접근범위와 사용가능시간제한, 그리고 접근 속성이 정의되어있다.) Access token은 authorization server가 third-party client에게 발급한다. third-party client는 이 access token 으로 resource owner에 접근할 수 있다.

For example, an end-user (resource owner) can grant a printing
service (client) access to her protected photos stored at a photo-
sharing service (resource server), without sharing her username and
password with the printing service. Instead, she authenticates
directly with a server trusted by the photo-sharing service
(authorization server), which issues the printing service delegation-
specific credentials (access token).
예) 사용자(resource owner)가 사진앱(client)을 다운받아서 인스타그램(resource server)의 비밀사진첩에 접근하는데 이 앱에 내 비밀번호를 넣지 않아도 된다.
그냥 인스타그램의 인증서버(authorization server)에 바로 접근해서 이 앱을 허가(trusted)시켜버리면 프린팅서비스앱(client)에 접근권한(delegation-specific credentials (access token))을 준다

This specification is designed for use with HTTP ([RFC2616]). The
use of OAuth over any protocol other than HTTP is out of scope.
이 스펙은 Http하에 사용하도록 설계되었고 http외의 프로토콜과 사용하는것은 알 바 아님.

The OAuth 1.0 protocol ([RFC5849]), published as an informational
document, was the result of a small ad hoc community effort. This
Standards Track specification builds on the OAuth 1.0 deployment
experience, as well as additional use cases and extensibility
requirements gathered from the wider IETF community. The OAuth 2.0
protocol is not backward compatible with OAuth 1.0. The two versions
may co-exist on the network, and implementations may choose to
support both. However, it is the intention of this specification
that new implementations support OAuth 2.0 as specified in this
document and that OAuth 1.0 is used only to support existing
deployments. The OAuth 2.0 protocol shares very few implementation
details with the OAuth 1.0 protocol. Implementers familiar with
OAuth 1.0 should approach this document without any assumptions as to
its structure and details.
OAuth1하고 뭐 어쩌고

OAuth2 Spec. – 개요

https://tools.ietf.org/html/rfc6749

Abstract

The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.

개요

OAuth 2.0 인증 프레임워크는 서드파티 어플리케이션이 HTTP service에 제한적으로 접근할 수 있게 해 준다. resource owner를 대신하여 resource owner와 HTTP service 사이의 인증을 조율해서 third-party application이 접근 권한을 갖게 된다. 이 스펙은 OAuth1을 대체한다.

OAuth1.0a spec 한글

http://oauth.net/core/1.0a/

필요한 부분만 발췌 해설(번역이 아닌것은 개인적인 해석이 들어갔기 때문)
다음에서 한글 문서를 제공했었는데 지네 서비스 2.0으로 올려다고 문서를 빼버려서 따로 정리.
OAuth1과 OAuth2의 뼈인간은 이름이 다르다.

3. Definitions용어 정의

  • Service Provider : 이름그대로 OAuth10a 인증을 제공하는 서비스 – Facebook, Twitter, Google, Daum, Naver 등이 Service Provider의 역할을 한다. 이 문서를 보는 사람들도 이 Service Provider에 접근하기 위해 OAuth를 찾고 있을겠지?
  • Consumer : OAuth10a인증을 통해 Service Provider에 접근하기를 원하는 웹사이트,앱 등
  • User : 말 그대로 일반 사용자… Service Provider에 가입하고 Consumer를 통해서 Service Provider에 접근하는 사람들
  • Protected Resource(s) : Service Provider에서 관리하는 리소스… Service Provider에서는 User의 권한에 따라 Protected Resources의 공개 여부를 결정한다
  • Consumer Developer : Consumer를 만드는 사람들
  • Consumer Key : Consumer의 로그인 ID같은 역할
  • Consumer Secret : Consumer의 로그인 비밀번호 역할
  • Request Token : Consumer에서 Service Provider에 근해 Request Token-Token Secret을 수신한다
  • Access Token : Request Token을 http://facebook.com?oauth_token?{request_token} 처럼 브라우저의 주소로 사용자를 넘겨준다. 사용자가 Service Provider에 로그인 후 사용허가를 해 주면 Service Provider에서 Consumer쪽으로 verifier값을 전달해주고 Request Token과 verifier을 이용해 ServiceProvider에서 AcceccToken과 AccessTokenSecret을 받을 수 있다. Access Token은 임시 사용자 ID와 비밀번호 역할을 하는 값으로 Access Token값이 만료되기 전까지 계속 사용 가능하다. 보통은 시간제한이 없다
  • Token Secret : Request Token, Access Token의 비밀번호..
  • OAuth Protocol Parameters : OAuth프로토콜 파라미터는 “oauth_”로 시작한다

4. Documentation and Registration
?????
OAuth includes a Consumer Key and matching Consumer Secret that together authenticate the Consumer (as opposed to the User) to the Service Provider. Consumer-specific identification allows the Service Provider to vary access levels to Consumers (such as un-throttled access to resources).

Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA).

4.1. Request URLs
Request Token URL :
User Authorization URL :
Access Token URL :

맥OS 용 개발언어 objective c…

맥 및 아이폰용 개발 언어로 객체지향 개념을 더욱 강하게 적용한 C++의 일종이라고 봐도 될 것 같다.

다양한 기능을 제공하지만… 델파이와 씨언어의 불편한 점을 모아놓은 듯한 언어의 문법에 기가 질릴 정도다

 

아이폰의 API는 안드로이드API에 비해 월등히 뛰어난 것으로 평가되고 있으며

이러한 강점을 무기로 애플진영은 스마트폰 시장의 우위를 점하고 있다.

 

안드로이드 OS자체는 프로요 이후 상당히 안정됐고 진저브레드 이후 상당히 쓸만한 수준으로 진화 하였지만….

SDK는 갈 길이 멀다.

이클립스 자체는 상당히 좋은 개발툴IDE?임은 분명하지만 화면을 디자인하는 XML문법의 오류는 어찌 할 수가 없다.

손으로 직접 코딩을 하면 되기는하지만… 생산성이 떨어진다.

전문 디자이나너 프로그래머에게는 어려운 일이 아니겠지만… 누구나 쉽게 만들 수 있어야 시장이 더 넓어질 수 있을 것 아닌가…

 

태블릿OS 허니콤 업그레이드 때문에 정신이 없겠지만… 이제 구글에서 SDK개발에도 박차를 가했으면 좋겠다는 생각이 든다.

Open Source Initiative OSI – The MIT License:Licensing

http://www.opensource.org/licenses/mit-license.php

Open Source Initiative OSI – The MIT License:Licensing

[OSI Approved License]The MIT License

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the “Software”), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

 

LGPL, GNU LESSER GENERAL PUBLIC LICENSE

http://www.gnu.org/copyleft/lesser.html

GNU LESSER GENERAL PUBLIC LICENSE

Version 3, 29 June 2007

Copyright © 2007 Free Software Foundation, Inc. <http://fsf.org/>

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below.

0. Additional Definitions.

As used herein, “this License” refers to version 3 of the GNU Lesser General Public License, and the “GNU GPL” refers to version 3 of the GNU General Public License.

“The Library” refers to a covered work governed by this License, other than an Application or a Combined Work as defined below.

An “Application” is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.

A “Combined Work” is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the “Linked Version”.

The “Minimal Corresponding Source” for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.

The “Corresponding Application Code” for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.

1. Exception to Section 3 of the GNU GPL.

You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL.

2. Conveying Modified Versions.

If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:

  • a) under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or
  • b) under the GNU GPL, with none of the additional permissions of this License applicable to that copy.

3. Object Code Incorporating Material from Library Header Files.

The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:

  • a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.
  • b) Accompany the object code with a copy of the GNU GPL and this license document.

4. Combined Works.

You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:

  • a) Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.
  • b) Accompany the Combined Work with a copy of the GNU GPL and this license document.
  • c) For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document.
  • d) Do one of the following:
    • 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
    • 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user’s computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.
  • e) Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)

5. Combined Libraries.

You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following:

  • a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License.
  • b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.

6. Revised Versions of the GNU Lesser General Public License.

The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation.

If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy’s public statement of acceptance of any version is permanent authorization for you to choose that version for the Library.