Bug 468287

Spot, I expect this is an OK license (please suggest license tag text), but would appreciate your review.


// Copyright 1998-2008 Distributed Management Task Force, Inc. (DMTF).
// All rights reserved.
// DMTF is a not-for-profit association of industry members dedicated
// to promoting enterprise and systems management and interoperability.
// DMTF specifications and documents may be reproduced for uses
// consistent with this purpose by members and non-members,
// provided that correct attribution is given.
// As DMTF specifications may be revised from time to time,
// the particular version and release date should always be noted.
//
// Implementation of certain elements of this standard or proposed
// standard may be subject to third party patent rights, including
// provisional patent rights (herein "patent rights"). DMTF makes
// no representations to users of the standard as to the existence
// of such rights, and is not responsible to recognize, disclose, or
// identify any or all such third party patent right, owners or
// claimants, nor for any incomplete or inaccurate identification or
// disclosure of such rights, owners or claimants. DMTF shall have no
// liability to any party, in any manner or circumstance, under any
// legal theory whatsoever, for failure to recognize, disclose, or
// identify any such third party patent rights, or for such party's
// reliance on the standard or incorporation thereof in its product,
// protocols or testing procedures. DMTF shall have no liability to
// any party implementing such standard, whether such implementation
// is foreseeable or not, nor to any patent owner or claimant, and shall
// have no liability or responsibility for costs or losses incurred if
// a standard is withdrawn or modified after publication, and shall be
// indemnified and held harmless by any party implementing the
// standard from any and all claims of infringement by a patent owner
// for such implementations.
//
// For information about patents held by third-parties which have
// notified the DMTF that, in their opinion, such patent may relate to
// or impact implementations of DMTF standards, visit
// http://www.dmtf.org/about/policies/disclosures.php.

***Unofficial Review***
This is a pretty easy review considering "- now meets Fedora packaging guidelines too" is a change in 2.19.1-1. :D  However, here are my comments.

* Output from rpmlint:
cim-schema.src: W: invalid-license Any permissive
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

Hopefully Spot can provide some insight into that for you.

* In your %install macro, you have MOFDIR=/usr/share/mof.  I don't think it's required but you can substitute %{_datadir} for /usr/share.  The list of these macros is here: https://fedoraproject.org/wiki/Packaging/RPMMacros.

* Builds without any problems on i386 32-bit.

Looks pretty good to me.

(In reply to comment #1)
> Spot, I expect this is an OK license (please suggest license tag text), but
> would appreciate your review.
>

Matt, this isn't a software license... but this isn't exactly software, is it?
(If it were on software, it would be non-free.)

So, judging it as content, I have one big concern:

// DMTF specifications and documents may be reproduced for uses
// consistent with this purpose by members and non-members,
// provided that correct attribution is given.

The guidelines for content licensing are:

Content must be:
 * freely distributable without restriction
 * in a format which is not patent encumbered

The format is okay, but that content seems to apply a restriction to "freely redistributable". My translation is that it says that these files are "freely redistributable as long as you use them in a way that is involved with promoting enterprise and systems management and interoperability."

This is really a use-case restriction, just the same as if it said "you may redistribute these files as long as you do not sell them."

Is there any chance we can get the DMTF to permit unrestricted redistribution of these files?

I was afraid of the use-case restriction aspect.  I'll consult with DMTF, but unlikely this can be changed easily.  Note: existing tog-pegasus package includes these schemas with exactly this same text.

I'd consider the schemas to be code myself, much like C headers.

Example text from one of the files in here:

   uint32 VerifyOKToApplyToCollection (
         [IN, Description (
             "The Collection of ManagedSystemElements that is being "
             "verified.")]
      CIM_CollectionOfMSEs REF Collection,
         [IN, Description (
             "TimeToApply can be either a specific time or a time "
             "interval.")]
      datetime TimeToApply,
         [IN, Description (
             "The required completion time for the method.")]
      datetime MustBeCompletedBy,
         [IN ( false ), OUT, Description (
             "A string array that lists the keys of the "
             "ManagedSystemElements to which the Setting cannot be "
             "applied.")]
      string CanNotApply[]);

whihc looks like code to me. :-(

It looks like code, but does it get compiled or executed? If it is code, it is definitely non-free.

It could just be a disgusting syntax for the schema.

The DMTF Board passed a motion at the recent face to face meeting that removes part of the copyright statement going forward for all docs, including MOFs.
 
The phrase "for uses consistent with this purpose" is to be removed from published CIM Schema stating with 2.21 and all specifications going forward.  
This policy is effective immediately.


Tom, that should address this, yes?
-Matt

Where is this documented? Either we need a new tarball with the updated terms or some documentation to include in the package that reflects the new terms. Apart from that, it is acceptable as a content license. However, if we were to treat it as a code license, it lacks the permission to modify, thus is non-free.

Documented: The DMTF Technical Committee chair sent an email to members of the TC stating the Board's decision, and asking them to make this change in all future published documentation and specifications.  I would expect to see this change in a future posting of the CIM Schemas tarball.

As for the MOFs (which implement a form of the specification) as code vs content, I have asked that the MOFs themselves be licensed under an explicit license such as the BSD 3-clause that permits modification.  There is a "MOF Compiler".  I am awaiting the answer to this.

(In reply to comment #9)
> Documented: The DMTF Technical Committee chair sent an email to members of the
> TC stating the Board's decision, and asking them to make this change in all
> future published documentation and specifications.  I would expect to see this
> change in a future posting of the CIM Schemas tarball.

A copy of that email would suffice for content (not code) distributed under that license.

> As for the MOFs (which implement a form of the specification) as code vs
> content, I have asked that the MOFs themselves be licensed under an explicit
> license such as the BSD 3-clause that permits modification.  There is a "MOF
> Compiler".  I am awaiting the answer to this.

From the context of this, I will assume the bits in the cim-schema packages are considered code.

DMTF considers the MOFs to be content, not code.  As this license is acceptable for content, dropping legal blocker.  Tom agrees.

After talking with Matt some more, we've determined that these schema chunks are not code, but rather, content. Thus, we can include it under the existing (modified) content license.

Use: 

License: DMTF 

Lifting FE-Legal.

updated to latest schemas, and addressed the License: tag and %{_datadir} notes above.

Spec URL: http://domsch.com/linux/fedora/cim-schema/cim-schema.spec
SRPM URL: http://domsch.com/linux/fedora/cim-schema/cim-schema-2.21.0-1.src.rpm


$ rpmlint SPECS/cim-schema.spec SRPMS/cim-schema-2.21.0-1.src.rpm RPMS/noarch/cim-schema-*
3 packages and 1 specfiles checked; 0 errors, 0 warnings.

There's actually an interesting problem with this package that I don't see mentioned above.  The spec is under the same license as the package, which means you didn't have the right to make any of the changes you've been making.

Now, it's incredibly dumb to try to license a spec file like that, and far dumber to put it under a license that does not permit modification.  I would honestly argue that you can't even copyright the factual information present in a spec file.  However, I don't think we can just remove the license, and since we've looked at the spec I'm not sure if we can just recreate it.  What are we supposed to do now?

The DMTF didn't write the RPM .spec file originally, Novell OpenSUSE did.  If this is a case of the spec file needing to be licensed differently than the content it refers to, getting Novell to explicitly note a license on the spec file itself should be easy.

Novell clarified that the license on the spec is in fact MIT.

# Copyright (c) 2009 SUSE LINUX Products GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.


new packages with this text, and v2.22.0 schema, posted.
http://domsch.com/linux/fedora/cim-schema/cim-schema.spec
http://domsch.com/linux/fedora/cim-schema/cim-schema-2.22.0-1.src.rpm

The Version mentioned in the spec file doesn't match the names of the files in the source package.
The build fails with a message 
error: File /XXXXXXXXXX/SOURCES/cim_schema_2.21.0Experimental-Doc.zip: No such file or directory

fixed and reposted to the above URLs.

The above posted spec file still contains the old license (not MIT license) Please fix it repost the file. 

Also change the version of the package in spec file. This version difference is still causing a build failure.

Review:

1) The version in the spec file is wrong.

2) Change the license of the spec file.
 
3) No need to mention unzip with "BuildRequries". This tool is part of the buildroot.
https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2

4) ##rpmlint cim-schema.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

  ##rpmlint cim-schema-2.22.0-1.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

http://domsch.com/linux/fedora/cim-schema/

has the above all fixed.  I stuck the MIT license directly into the spec file as a comment.  I don't understand the comment about versions.  It's all 2.22.0.  I removed the BR: unzip.

Please don't forget to set the fedora-review  flag when you're reviewing a package.

This package is approved.
 Please request the CVS access and submit the package.

New Package CVS Request
=======================
Package Name: cim-schema
Short Description: Common Information Model (CIM) Schema
Owners: mdomsch vcrhonek srini
Branches: F-10 F-11 EL-4 EL-5
InitialCC: emilyr.com

cvs done, except for the InitialCC. We can't make that arbitrary addresses, it must be a Fedora Account System account.

Built in rawhide, EL-5 and F-11.  Closing.

cim-schema-2.22.0-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/cim-schema-2.22.0-1.fc11

cim-schema-2.22.0-1.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/cim-schema-2.22.0-1.el5

cim-schema-2.22.0-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

cim-schema-2.22.0-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

New Package CVS Request
=======================
Package Name: cim-schema
Short Description: Common Information Model (CIM) Schema
Owners: mdomsch vcrhonek srini praveenp
Branches: EPEL-4 EPEL-5
InitialCC: emilyr.com

There are already EL-5/EL-4 branches for this package. 
We also cannot add email addresses to initialcc, only fedora account system names. 
Feel free to add another request and set the flag if you need anything changed here.

New Package CVS Request
=======================
Package Name: cim-schema
Short Description: Common Information Model (CIM) Schema
Owners: mdomsch vcrhonek srini praveenp
Branches: F-12
InitialCC: mdomsch

cvs done.

> The phrase "for uses consistent with this purpose" is to be removed from published CIM Schema stating with 2.21 and all specifications going forward.  
This policy is effective immediately.

JFYI the DMTF copyright page still has this clause: https://www.dmtf.org/about/policies/copyright