[EMBOSS] Files included in EMBOSS but licensed ...

[Chris Fields]

(Charles, not sure you have been following, but any idea on the next steps and whether other package like bioperl are affected?)

On Jul 30, 2011, at 2:34 PM, Adam Sjøgren wrote:

> On Sat, 30 Jul 2011 14:01:58 -0500, Chris wrote:
> 
>> I don't understand the logic behind why data would be considered
>> software, unless one is using a very fuzzy definition of 'software'.
>> Is this strictly a packaging issue, e.g. any data packaged with source
>> makes it 'software'? Or just the fact that such data is licensed?
>> Would a package of just data/docs (no code) be allowed?
> 
>  "The DFSG is focused on software, but the word itself is unclear -
>   some apply it to everything that can be expressed as a stream of
>   bits, while a minority considers it to refer to just computer
>   programs. Also, the existence of PostScript, executable scripts,
>   sourced documents, etc, greatly muddies the second definition. Thus,
>   to break the confusion, in June 2004 the Debian project decided to
>   explicitly apply the same principles to software documentation,
>   multimedia data and other content. The non-program content of Debian
>   began to comply with the DFSG more strictly in Debian 4.0 (released
>   in April 2007) and subsequent releases."
>    - http://en.wikipedia.org/wiki/DFSG#Non-.22software.22_content
> 
> So no.

Oh well; we'll leave that up to debian then.  I think Peter and I stated our concerns, and possible options were stated by Charles and myself, no need to protract this out.  I would rather find a solution.

>> I agree with Peter's point, Uniprot and other databases license data
>> this way for very good (and well-intentioned) reasons.
> 
> Several people have mentioned the existence of these good reasons for
> not allowing derived works when it comes to science/databases/biology; I
> wonder what those reasons are?
> 
> Just curious.

Those links I passed on mention some of the primary concerns from both the Science Commons and Uniprot side.  I believe it comes down to an issue of trusting the source of the data and the level of control the database wants (the latter was implied in Eric's blog post).  

> [...]
>> http://sciencecommons.org/resources/faq/database-protocol/
> 
>> Note there is now a 'Database Protocol' (last link) that recommends a
>> different license; that page nicely summarizes the history the whole
>> Creative Commons licensing affair and the issues of using a Creative
>> Commons license re: databases, mainly due to the issue Peter mentioned
>> above, that databases != software. Uniprot doesn't use this as of yet
>> (so it doesn't solve the problem at hand), but it's possible this may
>> change.
> 
> It sounds like Science Commons' Open Access Data Protocol means putting
> the data in the public domain, which would mean that derived works would
> very much be allowed?

Yes, if one adopts that protocol (Uniprot hasn't).  Eric's blog post indicates the CC-nonderivative was chose for a level of control both Uniprot users and curators felt comfortable with but wasn't overly restrictive.  That's also from 2006, so a lot has likely changed since then.

> This link explains the protocol:
> 
> * http://sciencecommons.org/projects/publishing/open-access-data-protocol/
> 
> 
>  Best regards,
> 
>    Adam

There is no mention of derived or modified works there, but the brief mention of derived works from the Database Protocol page indicates that it is possibly allowed, yes.  That may be an impediment to adoption by a database depending on what level of control they would like.  I'm curious to see who has adopted it.

chris