All sounds good, but I think best to channel these ideas onto the wiki and roadmap. Rafael, can your team help with some of these todos and give good feedback.
Cheers! Jon On Wed, 2007-08-29 at 22:46 -0700, Jason Kivlighn wrote: > We're looking at various different use-cases, all of which should be > handled separately. I want to be sure we're clear on which use-cases > we're dealing with and discussing here. All cases should be handled, > and handling one case shouldn't interfere with another. > > 1) Selecting a license for a file from within a file manager (i.e. > Dolphin or Nautilus). We could be dealing with any type of content -- > source code, content/media, etc -- so being able to select the right > class of license based on the file type makes sense. > > 2) Selecting a license from within a specific application, i.e. > KOffice. When KOffice offers the user a choice of licenses, we can > safely assume that we want to offer content licenses (like CC). We > don't need to offer the GPL or other source code license as a choice. > No automation based on file type is required. > > 3) In the case of using liblicense with KNewStuff, a license is > potentially selected for a collection of files. This is the case where > what is being fetched is a tarball or zip. We can't go by the file > type, since the tarball may be a collection of CC-licensed photos, or an > application licensed under the Artistic License. The user should > explicitly specify whether it's content, source code, or something else. > > I like the idea of extending the license metadata (the RDF) to include a > "class" element which specifies whether it's a license recommended for > source code, content, or some other class. This is the most generic > solution. An application could ask for licenses from a particular > class. Or if appropriate, it could determine for itself which license > class to choose from based on a mime-type. Liblicense could even > include a set of known file type to license class mappings to ease in > the frontend implementation. > > Given all of the above, I think liblicense should make it easy to create > two types of license choosers: 1) a frontend license chooser that is > content-based, like we currently ship. And 2) It should also make it > easy to create a general license chooser that covers source code > licensing and everything else. This could simply present a list of > licenses to choose from, while providing additional info describing each > license. One might consider an attribute-based license chooser, like > the current one for content, that would be used to license source code > -- but given the intricacies among source code licenses, it just doesn't > make sense and couldn't possibly be accurate. Choosing between the two > types would be up to the application to decide -- an application can do > what makes sense for the current context (i.e. the 3 contexts above). > > Okay, enough rambling. I'm just throwing out bottled-up, random, > thoughts. Maybe I'm over-complicating things. > > Cheers, > Jason > > > Hi all, > > > > > >> Possible, yes... I just want to point out that we'd first have to extend > >> the API and license RDF to specify "classes" of licenses. That way > >> liblicense knows which license is which class (content, source code, > >> documentation, etc.). > >> > > > > I suggest somehow that the allowed licenses are determined > > automatically by the system. Well, KDE knows what kind of file it is. > > Why put a radio button or a combo if it can be done automatically ? > > > > There should be a "database" that says for each filetype what licenses > > are supported. > > > > > > Bye, > > Rafael Fernández López. > > > > _______________________________________________ > cc-devel mailing list > cc-devel@lists.ibiblio.org > http://lists.ibiblio.org/mailman/listinfo/cc-devel -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] _______________________________________________ cc-devel mailing list cc-devel@lists.ibiblio.org http://lists.ibiblio.org/mailman/listinfo/cc-devel
