포스팅을 하면서 고민되는 문제 중의 하나가 바로 저작권입니다. 내 포스트에 사진을 넣고 싶은 데, 아무데서나 퍼 왔는데, 그게 알고보니 유명 사진 작가의 사진이었다면? 간혹 그냥 인터넷에 떠도는 사진을 자기 홈페이지에 넣었다가 사진 작가들에게 소송을 걸렸다는 이야기가 들리기도하고, 그런것만 전문적으로 찾아서 소송을 걸어서 먹고 산다는 변호사들이 있다는 소문도 있고... 그렇다고 일일이 저작권자를 찾아서 허락을 받기도 힘들고..
이런 고민을 하시는 분들을 위해서.. Flickr를 이용해서 저작권에 위배되지 않고 사진을 이용할 수 있는 방법을 소개해 드립니다. Flickr 는 전 세계적인 사진공유/관리 사이트 입니다.
예를 들어 한우와 관련된 글을 쓴다고 가정합시다. 일단 플리커로 들어가서 'Korean Cow' 라고 검색을 합니다.
아쉽게도 국내의 자료는 많이 등록되어 있지도 않고, 등록된 자료들 중에서도 CCL 이 적용된 것은 매우 드뭅니다. 그래서 검색을 할 땐 영어로 검색을 해야 쓸만한 결과를 얻으실 수 있습니다.
결과들이 나옵니다. 그럼 이 사진들을 그냥 가져다가 쓸 수 있느냐? 그렇지 않습니다. 이 모든 사진들은 사진을 찍은 사람에게 저작권이 있습니다. 아래 사진에 보이는 All rights reserved 가 그것을 의미하고 있습니다. (사실 All rights reserved 라고 따로 명시를 해 주지 않아도 인터넷의 모든 저작물들은 저작권에 의해서 보호받을 수 있습니다.)
이런 표시가 있으면 그냥 퍼 오시면 안됩니다.
그럼 어떻게 해야 할까요? 여기서 우리의 구세주 Creative Commons License(이하 CCL)가 등장합니다. CCL 은 자신의 창작물에 대하여 일정한 조건하에 모든 이의 자유이용을 허락하는 내용의 라이선스 입니다.(http://www.creativecommons.or.kr/ 참고) 일정한 조건은 아래 쪽에서 다루기로 하죠.
고급 검색 하단에 있는 Creative Commons 관련 옵션을 체크 해 줍니다. 아래 체크박스 아래에 있는 항목도 해당사항이 있으면 체크해 줍시다.
이제 나오는 목록은 CCL이 적용된 목록입니다. 목록을 주욱 훑어보시다가 이거다 싶은 사진을 클릭해 봅시다.
맘에 드는 사진을 찾았내요. CCL 표시도 확실히 되어있구요. 그럼 왼쪽 위에 있는 돋보기 아이콘을 클릭해 봅시다.
(사진 7. 사진 다운로드 화면) 여기서 마음에 드는 크기를 클릭합니다. 그리고 드래그 후 복사 후 자신의 블로그에 붙여넣기 합니다. 복사할 때, CCL 마크와 라이선스 이용 허락 조건도 같이 복사합시다.
굳이 사진의 저작권자이신 donut2D 님께 사진을 가져가도 좋다는 허락을 받을 필요가 없이 위에 표기된 CCL 에 의해서 그냥 퍼 올 수 있습니다.
CCL 의 이용허락조건
CCL이 적용된 컨텐츠를 사용하는 데에는 일종의 대가(?)가 있습니다. CCL의 컨텐츠에는 작은 아이콘으로 이른바 이용허락조건이 표기되어 있는 데, 그 의미는 아래와 같습니다.
저작자 표시 (이미지를 찾지 못해서 넣지 못했는 데 위 한우 사진에 BY: 라고 써 있는 아이콘과 같은 뜻입니다. 주로 이 사람 아이콘을 쓰는 데, 플리커는 특이한 걸 쓰는 군요..)
저작자 표시 - 비영리 저작자 표시 - 변경금지 저작자 표시 - 동일조건변경허락 저작자 표시 - 비영리 - 변경금지 저작자 표시 - 비영리 - 동일조건변경허락
다른 것은 별 설명이 필요없을 것 같고.. '동일조건변경허락' 만 부가 설명을 하자면, 그 컨텐츠는 수정이 자유롭지만 변경 후에는 반드시 CCL을 적용하고 같은 원본과 같은 조건으로만 배포할 수 있습니다.
아쉬운 점
이렇게 자유롭게 손 쉽게 유용한 컨텐츠들을 공유할 수 있는 CCL이지만, 아쉬운 점이 있습니다. 아직은 CCL이 적용된 국내의 컨텐츠가 부족하다는 점과 국내 커뮤니티 등에서 CCL을 적용하고 있는 곳이 거의 없다는 점이지요. 또한 국내의 저작권에 대한 몰이해(불펌 블로그 등)와 공유 의식의 부재 역시 CCL의 확산을 가로막는 장애물이라고 할 수 있겠죠..
CCL을 통한 컨텐츠의 올바른 공유(P2P로 불법 자료 공유하면서 변명으로 내세우는 공유정신이 아닌)는 서로를 이롭게 합니다. 저작권자는 내 저작물이 많은 사람들에게 읽히거나 사용될 수 있어서, 이용자는 훌륭한 품질의 컨텐츠를 손쉽게 이용할 수 있어서 좋지요. 많은 사람들이 공유했으면 좋겠다고 생각하는 당신의 컨텐츠에도 CCL을 적용해 보는 것은 어떨까요?
주제를 정하고 글을 쓰고자 하는 것은 문제가 아니다. 하지만 그 주제에 맞는 사진이나 동영상 같은 자료는 구하기가 너무 어렵다. 주변에 널리고 널렸지만 모두 저작권이라는 덧이 있어 이용하기 두렵다. 물론 글을 쓰고자 한다면 사진과 동영상 같은 자료들도 자신이 만들어서 사용해야 하겠지만 시간이 많지 않은 직장인들은 그렇게 하기 쉽지 않다. 글을 열심히 써도 그림이나 동영상이 포함되어 있지 않으면 많은 메타블로그에서 글을 밀어주지 않는다. 글을 읽는 사..
희철은 무엇을 해도 어설픕니다. 그의 노래도, 그의 춤도.. 그의 인간관계 역시... 너무 어설퍼서 희철을 바라보는 민하의 마음 역시 눈치채지 못합니다. 비장한 모습으로 연주에게 필름을 건네지고 멋지게 돌아서서 스쿠터를 타고 가야하는 장면에서도.. 결국 기름이 바닥이 나서 스쿠터를 팽개치고 걸어갑니다. 실제 상황이었다면 아마 얼마 걸어가다가 다시 스쿠터를 끌고 갔을지도 모르겠군요.. :) 무엇을 해도 어설프기만한 '스무살'의 청년. 그게 바로 희철입니다.
자신이 하고 싶은 것이 무엇인지도, 자기가 할 수 있는 것이 무엇인지도 모른채, 그냥 되는대로 살아가고 있던 희철에게 영화의 꿈을 가지게 한 사람들. 연주와 상우 역시 어설픈 초짜 단편 영화 감독과 매우 어설픈 초짜 영화 촬영 감독입니다. 연주의 어설픈 열정은 주위 사람들을 상처입히기도 하고, 자신 역시 상처를 입습니다. 상우 역시 처음부터 모든 것이 올바르지 않다는 걸 알고 있었으면서도 말릴 수 없었습니다. 그들 역시 아직은 어설픈 스무살의 청년들이니까요.
저 역시 스무살에는 정말 지나고 나면 아무렇지도 않을 쓸데없는 것들로 고민했던 적이 많았습니다. 지금 생각해보면 얼굴이 화끈거릴 정도로 어설프고 부끄러운 순간들이었지만.. 그래도 고민하고 방황했던 그 순간만큼은 정말 진지했고 뜨거웠고 열정적이었던 것 같습니다.
그래도 희철은 많은 우여곡절 끝에 '영화'라는 꿈을 찾아냅니다. 그리고 그 '영화'라는 목표를 위해 꾾임없이 노력하는 스무살이라는 타이틀을 가지게 됩니다. 사실 꿈을 찾는 다는 것이 그렇게 쉬운 일이 아닙니다. 아직도 저도 너의 꿈이 뭐냐는 질문을 받으면 한참을 버벅이다 그냥 둘러대기만 하기 바쁘니까요.
이래저래 어설픈 스무살이라는 표현을 쓰고 있지만.. 그래봐야 저도 어설픈 20대 중반일 뿐입니다. :) 그것도 무려 극 중 희철이 보다 못한 그다지 제대로 된 꿈도 가지고 있지 않지요. 20대여 꿈을 가져라~ 하고 비장하게 글의 끝을 맺고 싶지만.. 우선 저부터 꿈을 가질 수 있도록 열심히 노력을 해야겠네요.. -_-
여기서 포인트는 두 개입니다. 대체 URL 과 sampleFunction() 앞의 ! 죠. 대체 URL 은 말 그대로 Javascript 가 동작하지 않을 때 이동해야할 페이지입니다. 물론 해당 동작에 대한 대체 페이지가 마련되어야 겠죠.
그러면 클릭할 때, onclick 이 실행되는게 아니라 대체 URL로 이동해버리는 것이 아니냐..라고 생각하시는 분들이 계실텐데.. !(느낌표) 는 그것을 막기 위해 고려된 것입니다. 여기서 조건은 sampleFuntion 은 xmlHTTPRequest 가 성공하면 True, 실패하면 False 를 리턴하도록 구현되어야합니다.
만약 sampleFunction 이 동작을 성공하면 True가 리턴되고, <a> 태그의 동작은 return false; 가 되어 실제로 페이지 이동을 하지않게 됩니다.
덧붙여서 윗글의 정보와는 달리 현재 Edgerails 에서는 :preload 옵션이 없고 :include 를 사용해도, preload 가 가능한 경우는 Eager Loading이 아니라 Preload 를 하도록 패치되어 있습니다.
#2. Find conditions 에 시간을 사용할 경우는 한 번 더 생각을... 얼마전 테스트를 하다가 우연히 발견했습니다.
어느 쪽이 더 빠를까요? 당연히 테이블 전체를 가져오는 1번보다 2번이라고 생각하기 쉽습니다. 그런데 실제로 해보면 예상치 못한 결과가 나오더군요.
첫번째 호출할 때는 2번이 빠른데.. 두번째 이상 호출을 하게 될 경우, 1번이 훨씬 빠릅니다. 답은 각자 생성하는 쿼리에 있었습니다.
1의 경우는
로 처음이나 두번째 호출 후나 일정한 반면에.. 2의 경우는
처럼 초단위가 변해서 쿼리가 날아갑니다.
한마디로 쿼리 캐시가 안되고 계속 새로운 쿼리를 보내는 것이죠. 아마 1초단위 까지 정확히 하루 전이라고 하고 싶으면 어쩔 수 없겠지만.. 초단위 혹은 분단위를 올림/내림 등을 하는 것만으로도 쿼리 캐시의 효과를 잘 이용할 수 있게 될 겁니다.
#3. Pagination 의 함정. 이번엔 페이지를 나누는 Pagination 에서 생기는 문제입니다. 레일스 2.0 에서는 Pagination이 레일스 코어에서 빠지고 플러그인 식으로 설치를 해야 하는데.. 제가 설치해 본 대부분의 Pagination 플러그인이 같은 문제를 가지고 있었습니다.
Pagination의 동작은 크게 두 부분으로 나눌 수 있습니다. 페이지 표시를 위해 전체 레코드 수를 가져오는 것과 페이지 번호를 이용해 :offset 과 :limit 으로 특정 부분의 레코드를 가져오는 부분입니다. Pagination 의 플러그인 중 하나인 will_paginate 같은 경우 다음과 같이 Paginate를 합니다.
find 의 옵션들을 그대로 쓸 수 있으므로 아주 편하게 paginate를 할 수 있습니다. 그런데 문제는 include 옵션이 들어가게 되면 문제가 발생합니다. 우선은 paginate 는 #1 에서 언급한 preload 가 구현이 되어 있지 않고.. 두번째 문제는 전체 레코드 수를 가져오는 부분에서 쓸 데없는 Join 이 일어납니다. 위의 경우는.
와 같은 쿼리가 생성됩니다. 그런데, 위의 경우는 굳이 comments와 join 할 필요가 없고, 만약 join을 해아할 테이블이 훨씬 많아지면 오버헤드는 상상할 수 없을 정도로 커집니다. 단순히 레코드가 몇 개인지 세는 것 뿐인데 말이죠.
외국의 글입니다. 이 paginate 문제 의 해결책을 제시하고 있습니다만 count 를 하는 쿼리와 선택을 하는 쿼리를 직접 SQL 로 만들어서 하는 방식은 가장 유연한 방식이지만 그다지 깔끔해 보이진 않네요.
데비안의 Debian Maintainer가 우분투의 SOMEBODY로 대체된 것을 제외하면 거의 비슷한 모습을 하고 있지만, 문제는 왼쪽에서 오른쪽으로 향하는 화살표는 있지만, 오른쪽에서 왼쪽으로 나가는 화살표가 없다는 점입니다. 우분투가 데비안 기반의 배포판인 만큼 데비안의 패키지를 가져와서 개발을 하게 되지만, 정작 개발 후에는 다시 데비안으로 피드백이 되지 않는다는 거죠. 데비안 메인테이너, 개발자 들이 보기엔 데비안의 단물만 쪽쪽 빨아가고 있는 듯한 느낌이 드는 것도 무리가 아니겠군요.
데비안은 FSF(Free Software Foundation)로 부터 지원받는 자원 봉사자들로 구성된 데비안 메인테이너들에 의해서 패키지가 관리되고 있고, 우분투는 백만장자인 마크 셔틀워스(Mark Shuttleworth)가 CEO로 있는 캐노니컬(Canonical)이라는 기업에서 관리되는 배포판입니다. 돈 많은 기업이 자원봉사자로 구성된 커뮤니티를 착취한다는 느낌마저 들기도 합니다.
위와 같은 불만이 데비안 개발자로부터 터져나왔다는 사실 자체가 데비안과 우분투 사이에 불화의 위협이 시작된 것이 아닌가 싶습니다. GPL에 위배되는 것은 아니지만, 캐노니컬의 데비안으로의 피드백을 하지 않는 정책(?)은 데비안 커뮤니티 사이에서 환영받을 일은 아니죠. 결국 같은 작업을 우분투에서 하고 다시 데비안에서 하는 이중적인 개발이 이루어질 테고, 그건 양쪽 모두에게 개발의 지체를 가져오게 되겠죠.
우분투가 가정 영향력 있는 리눅스 배포판이 된 지금 캐노니컬은 데비안 커뮤니티와의 '기생적 관계'가 아닌 쌍방향의 피드백이 오가는 '공생적 관계'로 나가야 할 필요가 있습니다. 상대가 MS나 레드햇, 노벨과 같은 기업이 아닌 데비안 커뮤니티인 만큼 굳이 경쟁적인 체제를 도입할 필요가 없고, 데비안이 잘 되면 결국 우분투도 잘 될 수 밖에 없는 구조에서 협력, 지원을 하는 것은 손해가 될 것이 전혀 없을텐데 개인적인 의견으로는 캐노니컬의 현재 모습이 잘 이해가 되지 않는군요. 캐노니컬에서 이 문제를 인지하고 긍정적인 방향으로의 정책을 펼쳤으면 합니다.
환경은 우분투 리눅스 6.10 Edgy eft 사용했습니다. 이 문서는 symfony 공식 문서에 기반하고 있습니다.
우
선 symfony를 php에서 cli를 사용할 수 있어야합니다. cli는 command line interpreter의 약자로
쉘에서 php 프로그램을 실행시킬 수 있게 하는 인터프리터입니다. cli 는 php 4.3.0 이후의 버젼에서 지원하기
시작했죠. python이나 perl 같이 php를 쉘 스크립트로 사용할 수 있게 됩니다.
1. symfony 설치하기
$ sudo apt-get install php5-cli
symfony 는 아직 우분투 저장소에 올라오지 않은 모양입니다. php-pear를 통해서 써드 파티 extension들을 구할 수 있으니 php-pear 패키지를 설치합니다.
어제 어떤 웹 서비스에 로그인을 하려 하는데, 오랜만에 접속을 하려 하니.. 갑자기 패스워드가 생각나지 않는 것이었습니다. 그래서 로그인 폼 옆에 친절하게 붙어있는 비밀번호 찾기를 눌러서 개인정보 몇개를 입력을 하니, 패스워드의 앞글자 두개와 *로 이루어진 몇 자리의 문자열이 나오더군요. 그래서 전 제가 쓰는 패스워드 중 그 두자로 시작하는 것을 생각해내서 무리없이 로그인을 할 수 있었는데... 갑자기 찜찜한 기분이 들더군요..
내 패스워드는 어떻게 알아서 알려준건데?
혹시나 제 패스워드가 암호화도 안 되어서 그 쪽 데이터베이스에 저장되어 있을지도 모른다는 생각에 등골이 오싹하더군요. 물론 회원 가입시 앞자리 2자와 패스워드의 길이를 저장하고 있었을지도 모르겠습니다만.. 패스워드 앞자리의 두자리와 길이 만으로도 패스워드 전체를 유추해낼 수 있는 경우도 있을지 모릅니다. 제 생일이 84년 11월 1일이고 만약에 패스워드가 841101 인데, 84**** 라고 튀어나오면 패스워드를 알 수 있겠죠. 뭐 저런 패스워드를 쓸 일은 없을테지만 생일/주민등록번호/전화번호 뒷자리 등으로 패스워드를 만드는 사람들도 적지않은 걸로 알고 있습니다.
게다가 생각을 해보니, 정~말 친절히도 패스워드 찾기 서비스로 자신의 패스워드 전체를 알려주는 경우도 있던 것으로 기억합니다만.. 이건 뭐 짤없이 DB에 암호화 안되어서 들어가 있는 거겠죠.
한 번 제가 사용하는 서비스들 중 비밀번호 찾기 서비스에서 패스워드가 툭 튀어나오는 서비스가 있다면, 한번 사용을 고려를 해봐야겠군요. 패스워드의 암호화 db에 저장할때 코드 상으로 몇 글자만 더 치면 가능한 건데, 그런 것조차 하지 않았다면 뭔가 꿍꿍이가 있어서 일부러 그랬다고 밖에 생각밖에 들지 않거든요.
이올린에 북마크하기
이올린에 추천하기
