Skip to Content.
Sympa Menu

cc-devel - Re: [cc-devel] continuing brainstorm - installing licenses by default into operating systems

cc-devel AT lists.ibiblio.org

Subject: Developer discussion for Creative Commons technology and tools

List archive

Chronological Thread  
  • From: "Luis Villa" <luis.villa AT gmail.com>
  • To: "Jon Phillips" <jon AT rejon.org>
  • Cc: "cc-devel AT lists.ibiblio.org" <cc-devel AT lists.ibiblio.org>, "Nathan R. Yergler" <nathan AT creativecommons.org>, "cc-metadata AT lists.ibiblio.org" <cc-metadata AT lists.ibiblio.org>, Alex Roberts <alex AT creativecommons.org>
  • Subject: Re: [cc-devel] continuing brainstorm - installing licenses by default into operating systems
  • Date: Wed, 3 May 2006 13:20:25 -0400

On 5/1/06, Luis Villa <luis.villa AT gmail.com> wrote:
Hey, Jon, others-
From reading the spec doc, it really feels like you need to flesh out
the goals and use cases a bit more before you consider the
requirements and implementation details. *Why* do you want licenses in
the OS? Is it to track the license of everything installed on the OS?
Give a list of licenses for users to choose from when creating
content? Do license validation? It seems like you need to think
through those issues a bit more before fleshing things out more. It is
possible you guys have had this discussion elsewhere and I've missed
it, but if so,

Doh! 'but if so, it would be good to document it in the wiki.'

On 5/1/06, Jon Phillips <jon AT rejon.org> wrote:
> http://wiki.creativecommons.org/Licenses_in_Operating_Systems_Specification
>
> Here are the associated challenges:
> http://wiki.creativecommons.org/Include_licenses_in_operating_systems

It is, by the way, completely unclear what the difference between
these pages are, at least from the URL ;)

Some more specific thoughts:
* "What licenses should be allowed?" Why would any valid licenses be
disallowed? If the licensor of the code/content/whatever thinks it is
a license, then it will need to be represented, no?

* "Should licenses be weighted?" You mean, should users (or the
system) be able to indicate that some licenses are preferred in
certain situations? Or do you mean something else?

* "How will they connect with mime-types and how will a system know
which filetypes connect with which licenses?" This seems like
overthinking to me- I'm trying hard to think of a situation where (1)
the user knows enough to meaningfully discern between license types
but (2) would be overwhelmed by the list of licenses. Seems unlikely.
[That and most licenses don't claim to be valid only for specific
mime-types.]

* LICENSE_PROVIDER-LICENSENAME-FORM-VERSION.OPTIONAL_FILE_ENDING

You might look to the java-style org.creativecommons or org.fsf for
the 'license provider' portion of this.

* 'Forms': This is probably obvious, but CC is the only license on
earth that provides for all three of these forms. So make sure the
system supports them, but make sure not to make them mandatory.

* "Provide an installation system for this that is cross-platform"
nononono! Very good minds, with more relevant motivations, have
foundered on this issue. Just provide simple tarballs, or zipfiles, or
whatever, that apps can install themselves if they need the licenses
and discover they aren't present on the system.

* "Is dealing with possible violation too DRM-like?"

(1) Validation is not part of a data spec. :) Solve the basic data
problem first; and give it a shot to make sure it is extensible if
people want to put in the bits that would be necessary for validation.
The fact that no one is even trying to do validation right now should
be a suggestion about its relative priority :)
(2) It is DRM-like, in the sense that both fair use and license
incompatibility are usually judgment calls. If lawyers can't agree
whether or not licenses are compatible (see: openssl license) then
software certainly can't. So you have the option of making licensing
decisions for the user (which is the path the DRM industries have
taken in the fair use case) or you can do the more limited (but
potentially still very useful) 'warn but don't prevent' approach-
'your code might not be legally acceptable- continue anyway? Y/N'

Anyway, this certainly seems like a very worthwhile effort, and there
are clearly some good thinking here, but I strongly encourage writing
down your goals and use cases some more before going further with the
details.

HTH-
Luis





Archive powered by MHonArc 2.6.24.

Top of Page