This request reports that the current list of licence types is ‘impossible to use to classify existing licences’. It is proposed that a different list be created.
Discussion:
The three terms that are proposed for the new list overlap partly with the current list: E.g. ‘Public domain’ is in both; the ‘Other/proprietary’ seems similar to ‘Other restrictive clauses’; OSI Approved includes a number of licences that may be classified with the available licence types – e.g. the Apache Licence and BSD 2-clause are of type ‘Attribution’; BSD 3-clause seems to be close to ‘Reserved names’ etc. It would be helpful to see the licences that are encountered in data to determine if there are terms missing from the current licence type vocabulary.
The resolution this CR is dependant on the resolution of CR30 (https://joinup.ec.europa.eu/asset/adms_revsion/issue/cr30-analyse-how-l…)
Comments
Proposed resolution: Add terms to the ADMS licence type vocabulary as necessary, based on further analysis of the actual data.
The problem is not that there are missing terms to the current vocabulary, but that the vocabulary is not understood by users. Metadata publishers have no idea whether their licence is of type “attribution”, “viral effect” or other. The result of this is that almost all licences have “unknown IPR” as type. Hence the proposal of having a dct:type composed of only 3 terms: OSI Approved; Other/Proprietary and Public Domain.
Comment from Szabolcs Szekacs
Again, agree with TK .
What is the added value of defining more and more attributes for licences?
It is more work for metadata publishers, which they will not do, resulting in an actually lower metadata quality than without the new attributes.
When someone looks for a solution, s/he needs a quick info, whether that solution is truly OSS or not.
All the rest of the info can (and should be) analysed later, after having downloaded the solution.
If the real distinction is between FOSS and commercial, would it be a solution to have a two-member vocabulary? There is no need to create a second URI for Public Domain, as there is already one: http://purl.org/adms/licencetype/PublicDomain.
The other two, OSI-compliant and Commercial could be added to the Licence Type vocabulary http://purl.org/adms/licencetype/. Why would creating a parallel controlled vocabulary be better? In the ADMS-AP you could add a recommendation to use only:
http://purl.org/adms/licencetype/PublicDomain
http://purl.org/adms/licencetype/OSI-compliant
http://purl.org/adms/licencetype/Commercial
Indeed Makx. I did not understand it like that, but we do not have to create a vocabulary. We can, as you propose, enforce the usage of the three terms through the usage note.
For the term "Commercial", is it really what we want? I'm far from an expert, but I guess you could find some type of licences that aren't commercial, but that are not public domain nor OSI-compliant. Furthermore, having the term "commercial" may not be really relevant for Joinup as the number of solutions with commercial licences is extremeley low (because the scoping criteria only allows commercial licences in very specific cases).
It is indeed not entirely clear what 'Commercial' means. Maybe you want to distinguish just 'OSI-compliant' and 'Non-OSI-compliant'?
Hi Makx,
Indeed that would be better. And we should also keep Public Domain. Shouldn't we also have a term "Unknown" ? It can happen I guess.
So,
We would have:
OSI compliant
Non-OSI-compliant
Unknown
Public Domain
*************************
This could work for us as far as ADMS goes. however for the Joinup end-user we may want to translate this categorisation to something more understandable. E.g. I knew what open source means for the last 20 years, but before I started to work on OSOR, I had no idea of FSF and OSI (I know...a shame).
Second, for the end user, at first glance, OSI compliant and public domain are quite similar in terms of possible reuse (as long as we do not go into the trouble of combining code under different licences). Non-OSI compliant can mean many things which are totally different from the user prespective. I.e. a new EUPL v1.2 may be non-OSI compliant for some months, while it is a true OSS licence, which should not be confused with royalty based (commercial) licences.
Third, there is again a danger, that repository owners would not go through the hassle of trying to categorise every licence associated with their solutions, but just choose one from the list. We we be sure, that they would not do this?
So question is, whether the categories should be built into the standard, or whether the standards should only include the licence name, leaving it to the individual repositories to categorise them in whatever way they want. (e.g. Joinup would have the resource and expertise to categorise the licences based on whatever category we think it is best for the users.
Even with the issues highlighted, I can support the above categorisation, as it is still much better than the current way.
Szabi,
In CR30, there is also the proposal of having a set of URI of very known licences (mostly OSI-compliant). Those would be described on Joinup by us BEFORE any user needs it. Then he would only need to select the licence in the list and that's it. But with this proposal, we would also leave the user to create a new licence if needed. And if he does (meaning its a particular licence), he should know the detail about it and specifying OSI-compliant, non-OSI compliant, or Public Domain should not be too difficult. Do you agree?
As mentioned in CR30, I would propose first to discuss and agree on CR30 then on this one, which is a subsequent decision from CR30.
Yes, sorry for trying to create confusion.
Szabi
Public Domain is already there (http://purl.org/adms/licencetype/PublicDomain) and so is Unknown (http://purl.org/adms/licencetype/UnknownIPR). Those don't have to be re-defined.
We will ask for the addition of two terms OSI compliant and non-OSI compliant to the ADMS licence type vocabulary.
We'll add the recommendation in the specification that only one of the following four terms should be used: