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

Luis Villa luis.villa at gmail.com
Mon May 1 22:03:45 EDT 2006


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,

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



More information about the cc-devel mailing list