Matthew G. Saroff | 1 Aug 16:29 2005
Picon

Looking for Public Domain/CC Rules of Order

 	I'm with a group that is going to adopt rules of order.

 	We'd prefer not to shell out $15 or so for a copies of Roberts 
Rulse.

 	Anyone know of any public domain or Creative Commons alternatives?

--

-- 
Matthew Saroff

"A modern conservative is engaged in one of man's oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness."  -- John Kenneth Galbraith
Nathan R. Yergler | 1 Aug 17:23 2005
Picon

Standardizing JPEG licensing

Creative Commons has long had standard methods for embedding license 
information in MP3 and OGG audio files.  As we begin to work on a 
"libcc" or similar library, we probably need to discuss best practices 
for embedding in other common formats.  The one that matters to me today 
is JPEG, so I wanted to outline a couple of options and get feedback or 
consensus. 

It seems there are two obvious possiblities for embedding CC license 
information in JPEG files.  First, EXIF contains a "copyright" tag which 
is intended to be populated with a statement such as "Copyright, John 
Smith, 20xx. All rights
reserved."  Following the example of embedding a license statement in 
the TCOP field of ID3v2 for MP3 files, we could embed a standard 
statement, such as "© 1995 Example Photographer. Licensed to the public 
under http://creativcommons.org/licenses/by/2.0/ verify at 
http://example.com/licenseinfo".  Work metadata and verification 
information would then be stored in an external file, in this case 
http://example.com/licenseinfo.  This approach has the advantages that 
EXIF manipulation is well understood and a common operation of image 
editting software and sites.  Additionally, other tools may be able to 
display CC license metadata (even if they do not validate or populate) 
simply because they display all available EXIF data.  However, the 
disadvantage is that it requires metadata to be stored in an external, 
secondary file.

The other semi-obvious choice that comes to mind is using Adobe XMP 
metadata (http://www.adobe.com/products/xmp/).  CC already provides a 
specification and instructions for using XMP metadata in Adobe 
applications such as Photoshop 
(http://creativecommons.org/technology/xmp-help) and Adobe provides an 
(Continue reading)

Nathan R. Yergler | 2 Aug 15:31 2005
Picon

Re: Standardizing JPEG licensing

Mike and I spoke about this yesterday afternoon and came to the 
conclusion that we really need to support both EXIF and XMP embedding.  
They both have interested audiences, and we can probably leverage them 
better by supporting both approaches independently or simultaneously.

The CC XMP specification (http://creativecommons.org/technology/xmp) 
already lays out two possible formats for the Copyright field, which are 
minor distinctions upon what Christopher suggested.  In particular they 
omit the copyright owner, presumably because XMP (and EXIF) provides 
other tags which are more appropriate for that information.  The two 
possibly formats for the copyright statement are:

This work is licensed to the public under the Creative Commons 
Attribution-ShareAlike license 
http://creativecommons.org/licenses/by-sa/2.0/

and

This work is licensed to the public under the Creative Commons 
Attribution-ShareAlike license 
http://creativecommons.org/licenses/by-sa/2.0/ verify at 
http://example.com/metadata.html

The difference being the "verify at [URL]" statement at the end of the 
statement.  The proposal is that either format will be considered 
valid.  This allows users to make statements about the license without 
having to use verification RDF.  Unless there are objections or further 
refinements people would like to see, I'll write up a specification page 
using this format.

(Continue reading)

Mike Linksvayer | 2 Aug 20:44 2005

Re: Standardizing JPEG licensing

Christopher Allen wrote:
> EXIF is very similar to TCOP in MP3, and ICOP in MP2/4, so I lean toward
> supporting in audio and video. I do recommend a slight modifier of how the
> text should read:
> 
> Instead of:
> 
> C 1995 Example Photographer. Licensed to the public under
> http://creativcommons.org/licenses/by/2.0/ verify at
> http://example.com/licenseinfo
> 
> C 2005 Example Photographer <email@...> -- This work is
licensed to
> the public under the Creative Commons Attribution-NonCommercial-ShareAlike
> License http://creativecommons.org/licenses/by-nc-sa/2.5/ verify at
> http://example.com/licenseinfo

Everything before "license-url [verify at metadata-url]" is for humans 
only and can be as verbose as you like.  We should be explicit about 
this.  Currently http://creativecommons.org/technology/mp3 only 
explicitly says

# If "verify at " exists in TCOP, everything after it must be the
# license claim URL, and if there is a license claim URL then it must be
# preceded by "verify at ".

The first formulation above was designed to keep the string as short as 
possible while still providing useful information to humans given 
programs that display the contents of TCOP and similar are obviously 
expecting something much shorter, rendering such fields in short single 
(Continue reading)

Christopher Allen | 2 Aug 21:01 2005

Re: Standardizing JPEG licensing

On Tuesday, August 02, 2005 11:45 AM Mike Linksvayer <> wrote:
>> Instead of:
>> 
>> C 1995 Example Photographer. Licensed to the public under
>> http://creativcommons.org/licenses/by/2.0/ verify at
>> http://example.com/licenseinfo
>> 
>> C 2005 Example Photographer <email@...> -- This work is
>> licensed to the public under the Creative Commons
>> Attribution-NonCommercial-ShareAlike
>> License http://creativecommons.org/licenses/by-nc-sa/2.5/ verify at
>> http://example.com/licenseinfo
> 
> Everything before "license-url [verify at metadata-url]" is for
> humans only and can be as verbose as you like.  We should be explicit
> about this.  Currently http://creativecommons.org/technology/mp3 only
> explicitly says   
> 
> # If "verify at " exists in TCOP, everything after it must be the #
> license claim URL, and if there is a license claim URL then it must
> be # preceded by "verify at ".  
> 
> The first formulation above was designed to keep the string as short
> as possible while still providing useful information to humans given
> programs that display the contents of TCOP and similar are obviously
> expecting something much shorter, rendering such fields in short
> single line widgets.  I see nothing wrong with being more verbose,
> nor any reason to require a specific format for that part of the
> string.      

(Continue reading)

Mike Linksvayer | 2 Aug 21:14 2005

Re: wiki redirects

Conrad Parker wrote:
> sorry if this is the wrong place to report this :)
> 
> just looking around the wiki, it appears the following pages are
> similar:
> 
> http://wiki.creativecommons.org/wiki/Share_Alike
> http://wiki.creativecommons.org/wiki/Sharealike
> 
> Both are listed on the Popular Pages special page. I guess it would
> make sense to merge the content and make one a redirect to the other.
> I'm new here so I'll leave that to whoever's appropriate to do it :)

Wrong place, but there isn't any established place.

Going forward, follow the example of 
http://en.wikipedia.org/wiki/Wikipedia:Duplicate_articles and use
http://wiki.creativecommons.org/wiki/CreativeCommons:Duplicate_articles

--

-- 
   Mike Linksvayer
   http://creativecommons.org/about/people#21
Lucas Gonze | 2 Aug 22:24 2005
Picon

Re: Standardizing JPEG licensing


>>>BTW, some of the logic on why the text:
>>>
>>>I explicitly wanted there to be some ability to contact the author of the
>>>work, either email or web page. The statement "This work is licensed to the
>>>public" is licensed to be clear that we are talking about what the item is
>>>(this work) and that this is the public license, not a private license (for
>>>instance, Magnatune has CC licensed music files and high-bitrate music files
>>>that are only licensed to individuals). I felt naming the license was
>>>important for human readibility. The rest kept compatibility with the
>>>existing examples.
>>>      
>>>
I like these improvements a lot.

I'd like to suggest one tweak --have the contact info be a URL instead 
of an email address.  Few people are willing to put an email address 
that they check regularly into a public document, and a URL allows for 
stuff like the phone number of your management.
Mike Linksvayer | 2 Aug 22:47 2005

Re: Standardizing JPEG licensing

Lucas Gonze wrote:
> I'd like to suggest one tweak --have the contact info be a URL instead 
> of an email address.  Few people are willing to put an email address 
> that they check regularly into a public document, and a URL allows for 
> stuff like the phone number of your management.

I agree regarding URL rather than email, but the "verify at" URL is 
intended to provide useful info for humans as well as metadata.  Put in 
the crassest possible manner: 
http://creativecommons.org/technology/embedding#3

--

-- 
   Mike Linksvayer
   http://creativecommons.org/about/people#21
Lucas Gonze | 2 Aug 23:20 2005
Picon

Re: Standardizing JPEG licensing

Mike Linksvayer wrote:

>Lucas Gonze wrote:
>  
>
>>I'd like to suggest one tweak --have the contact info be a URL instead 
>>of an email address.  Few people are willing to put an email address 
>>that they check regularly into a public document, and a URL allows for 
>>stuff like the phone number of your management.
>>    
>>
>
>I agree regarding URL rather than email, but the "verify at" URL is 
>intended to provide useful info for humans as well as metadata.  Put in 
>the crassest possible manner: 
>http://creativecommons.org/technology/embedding#3
>  
>
What's standard practice right now?  Are users pointing to the 
boilerplate page, or are they pointing to custom pages which contain 
contact info?  I'd bet they're pointing to the boilerplate page, which 
suggests to me that a web service to edit and maintain custom pages 
(with contact info) would be a win.

- Lucas
Nathan R. Yergler | 2 Aug 23:36 2005
Picon

Re: Standardizing JPEG licensing

>>
> What's standard practice right now?  Are users pointing to the
> boilerplate page, or are they pointing to custom pages which contain
> contact info?  I'd bet they're pointing to the boilerplate page, which
> suggests to me that a web service to edit and maintain custom pages
> (with contact info) would be a win.

What do you mean by "boilerplate page"?  Do you mean a page on their  
site that only includes the license information? Verify links by  
definition have to reside on a site the user has control of, since  
they contain SHA1 hashes of the specific file for verification purposes.

NRY

>
> - Lucas
>
> _______________________________________________
> cc-metadata mailing list
> metadata@...
> http://lists.ibiblio.org/mailman/listinfo/cc-metadata
>

Gmane