Selected comments on Licence Type

Published on: 04/05/2012
Discussion

Comment by Patrice-Emmanuel Schmitz:

https://joinup.ec.europa.eu/asset/adms_foss/topic/public-comments-admsf/oss-v03#comment-11941

Hi Phil, I have some comments related to section 5.7 (Licence Type vocabulary):

  1. I suggest that the exact meaning of each category (or label) should be explained in a missing “description” field. i.e. what “Attribution” or “Known patent encumbrance” means (this may not be clear for everyone). Maybe it is the role of the “id” field containing a link (but I checked these links and it causes an error)...
  2. The proposed categories classify the “known legal regime” of the asset rather than the licence: if the asset is “public domain” (meaning works whose intellectual property rights have expired, been forfeited, or are inapplicable) or if it is “unknown IPR”, then – by assumption - no formal licence exists or is known.
  3. Some of the proposed categories may be convenient for describing the legal or licensing conditions of ADMS, but are clearly outside the F/OSS definition (which is indeed more specific to software than semantics). For example, the categories “Non-commercial use only” and “No derivative work” are in formal contradiction with the Open Source Definition (OSD). What is confusing is that the title of the project “ADMS.F/OSS” seems to inform recipients that all relevant ADMS are F/OSS compliant.
  4. I assume that a licence may be classified by “n” categories or attributes in this vocabulary: for example, a licence X can be “Attribution” and “Jurisdiction within the EU” and “Non-Commercial use only” etc. Right?
  5. The wording “Viral effect” is often perceived very negatively. The correct wording (popularised for software by the Free Software Foundation) could be “Copyleft”. But if you want a neutral wording, more convenient for semantic assets, I would suggest “Share alike” or “Share alike / copyleft”, meaning that the same licence must be used in the case or re-distribution. The wording “Viral effect” was coined by opponents to the GPL and is controversial because few legal certainties (case law) exist about it. If simple linking / interfacing at object code level ( = static linking) produces derivatives, then linking with a GPLed source could indeed produce a “viral” effect, but this is controversial (the opinion may be shared by a majority of F/OSS lawyers, but strongly contradicted by others and we are still missing case law to clarify such “virality” in the European legal context).
  6. I suggest that this “Share alike / copyleft” category should be at least divided in two parts:
  • Share alike / copyleft - not compatible/interoperable with other copyleft licences; (This is the case for the GPL or AGPL)
  • Share alike / copyleft with compatibility exceptions for larger work and interoperability (This is the case for the EUPL v1.1, MPL v2 and some other. It means that a larger derivative work can be licensed under another licence, if the exception conditions implemented for interoperability reasons are met).

Component

Miscellaneous

Category

Controlled Vocabularies

Comments

stijngoedertier (not verified)
Wed, 30/05/2012 - 22:49

Thanks for these valid comments, Patrice. 

  1. I had hoped that these terms would be self-explanatory. An appropriate description could only come from you ;-). Can you add descriptions to the below table?
  2. If I understand you correctly, "Public domain" is not a characteristic of a licence, there is no copyright so there are no rights to grant... However, could we allow "licence documents" such as "http://creativecommons.org/publicdomain/zero/1.0/" and "http://creativecommons.org/publicdomain/mark/1.0/"? In this case, it would make sense to keep this term and the property "licence type"
  3. We have received several comments that ADMS.F/OSS is ready for a name change. It should not be restricted to describing F/OSS-only software. The following issue has been raised for this: https://joinup.ec.europa.eu/discussion/name-admsfoss-too-restrictive-specification-can-also-be-used-describe-other-software
  4. That is corect, the arity of licence type is [0..*]
  5. I agree that "viral effect" has a negative connotation. The table below contains an appropriate change.
  6. The table below contains the propsed changes.

Fri, 08/06/2012 - 09:31

As agreed during the last Tuesday ADMS call (5. June), please find below the description field corresponding to the ADMS codes and labels that were created. I did not add any new "attribute" so far. Some of these attributes are "non-open source", but the description clarifies this, hopefully. Please check and report any observation from the group: descriptions may be questionable, as some attributes like "known patent encumbrance" are definitely more related to a specific product or software (uploaded on Joinup) than to the used licence.

Label

Code

Id

Definition

Attribution

Attribution

http://purl.org/adms/licencetype/Attribution

In general, most licences request to respect author’s credits.

Example: Article 5 EUPL: “the licensee shall keep intact all copyright notices.... in every distributed copy...”

For the most permissive licences, this “Attribution obligation” (combined with a warranty disclaimer) is the main or sole condition for using, copying, performing and (re)distributing the work.

Examples: CC by, MIT, BSD, ISA Open Metadata v1.1.

Public domain

PublicDomain

http://purl.org/adms/licencetype/PublicDomain

Unlike in the US, most EU Member State’s laws ignore volunteer dedication to Public domain (authors cannot resign their moral rights). Falling in public domain results only from copyright expiration. However, there are licences dedicating the work to the public domain by waiving all rights under copyright law, including all related and neighbouring rights, “to the extent allowed by law”.

Examples: CCO (Creative Commons Zero).

Share alike / copyleft - not compatible/interoperable with other copyleft licences;

ShareAlike-NotCompatible

http://purl.org/adms/licencetype/ShareAlike-NotCompatible

Share alike / copyleft means that, in case of redistribution of the work, this (same) licence must be reused.

Not compatible / not interoperable with other copyleft licences means that the licence is copyleft on both source code and binaries, and is “self centric”: the distribution of larger works integrating components covered by other licences must also be done under this licence only. This has been considered as invasive (sometimes “viral”). In the case of different copyleft provisions, licence conflict makes distribution legally impossible. Examples: GPL, AGPL, OSL.

Share alike / copyleft on source code or with compatibility exceptions for larger work and interoperability

ShareAlike-Compatible

http://purl.org/adms/licencetype/ShareAlike-Compatible

Share alike / copyleft means that, in case of redistribution of the work, this (same) licence must be reused.

Compatibility / interoperability exist in two cases:

1.     The scope of the copyleft applies to the source code, not on binaries (therefore if a larger work is derivative of sources covered by various licences, then combined, compiled and statically linked binaries could distributed under any convenient licence).
Examples: LGPL, EPL, APSL 2.0, CDDL, Ms-PL ...

2.     There is full copyleft on the work (code and binaries), but the licence has implemented interoperability conditions and exceptions for distributing larger works under a controlled set of “secondary licences”.
Examples: EUPL v1.1, MPLv2.

Non-commercial use only

NonCommercialUseOnly

http://purl.org/adms/licencetype/NonCommercialUseOnly

Licensees may copy, distribute, display and perform the work, and make derivative works based on it only for non-commercial purposes.

These licences could present some interest for public sector.

These licences are NOT Open Source /OSI approved: principle 6 of the Open Source Definition (OSD).

No derivative work

NoDerivativeWork

http://purl.org/adms/licencetype/NoDerivativeWork

Licensees may copy, distribute, display and perform only verbatim copies of the work, and not derivative works based on it.

These licences are more useful for art or literacy work than for software (except for specific security or warranty reasons).

These licences are NOT Open Source /OSI approved: principle 3 of the Open Source Definition (OSD).

Royalties required

RoyaltiesRequired

http://purl.org/adms/licencetype/RoyaltiesRequired

The management of royalties (price to pay per year, per user, per computer for using the software) is a frequent characteristic of proprietary licences (in large deals). Royalties are un-manageable in open source licensing, because re-distribution cannot be restricted: principle 1 of the Open Source Definition (OSD). Explicit exclusion of royalties (for example Article 2 EUPL) makes no obstacle for selling the software (i.e. a lump sum, n years contribution) or for cost sharing agreements (i.e. supporting a % of the development budget).

Reserved names / endorsement / official status

ReservedNames-Endorsement-OfficialStatus

http://purl.org/adms/licencetype/ReservedNames-Endorsement-OfficialStatus

Except for attribution in copyright notices, some licences reserve the use of the name (of the author, of its employer /institution) because licensees cannot take advantage of an endorsement of the licensor in case they produce their own derivative.

For example, an economic operator cannot promote its product as “official and based on the work of the European Commission”.

Example: Article 5 EUPL: “This Licence does not grant permission to use the trade names, trademarks, service marks, or names of the Licensor...”.

Nominal cost

NominalCost

http://purl.org/adms/licencetype/NominalCost

Requesting from licensees a nominal value or cost refers to a contribution (i.e. to the development costs of a software, or of a standard) expressed as a lump sum (that is, in units of a currency) paid in a given year or series of years by initial licensees.

This is generally compatible with open source licensing (at the contrary of managed royalties).

Grant back

GrantBack

http://purl.org/adms/licencetype/GrantBack

This is a licence under which licensor grants to recipient (or licensee) the right to use/improve/redistribute the work under the condition that the licensee grants back to the licensor a licence with respect to any improvements he/she made.

This condition is mostly used in patent portfolio exchanges. It is compatible with open source software licensing: copyleft is a form of grant back (only in case of re-distribution). Stronger grant back allows a licensor to retain control of and access to any later developments associated with its technology. It is often considered bureaucratic and less efficient than pure share-alike/copyleft provisions.

Jurisdiction within the EU

JurisdictionWithinTheEU

http://purl.org/adms/licencetype/JurisdictionWithinTheEU

Licence provision stating that the applicable law (and in some case also the competent court) must be (the law) of a EU member State. Judges have the facility to ask a prejudicial question to the unique European Court of Justice, as most relevant national provisions are derivative of EU Treaties and Directives).

Example: Article 15 of the EUPL v1.1.

Other restrictive clauses

OtherRestrictiveClauses

http://purl.org/adms/licencetype/OtherRestrictiveClauses

As the label states, this is to evaluate case by case. In open source licensing, additional agreements (i.e. a warranty, support services, jurisdiction/arbitration, applicable law, etc.) are valid if they do not restrict the rights granted by the licence (according to the principles of the Open Source Definition – OSD).

Known patent encumbrance

KnownPatentEncumbrance

http://purl.org/adms/licencetype/KnownPatentEncumbrance

Patent encumbrance is a characteristic of specific products (software or standards) that cannot be used, reproduced and redistributed freely under any copyright licence, because a patent licence is also needed.

Specific open source licences fight patent encumbrance (Art 11 GPL v3) or neutralise it to “the extent necessary to make use of the rights granted under this Licence” (Art 2 EUPL).

Unknown IPR

UnknownIPR

http://purl.org/adms/licencetype/UnknownIPR

As the label says, IPR is unknown.

Sole valid recommendation: Please do not use/reuse/redistribute such work, until clearly falling in public domain.

 

 

stijngoedertier (not verified)
Fri, 29/06/2012 - 17:22