Hello,
Here's a few notes/questions that IMO need to be addressed in the new licensing guidelines in Wiki. IANAL, etc, but anyway, something for near future FPC meetings (which I still probably won't be able to attend to for a couple of weeks):
1) The licensing pages strongly imply that OSI-approved licenses are ok. However for example the original Artistic license is OSI-approved but listed in Wiki page as "bad". Something needs real fixing - "ask upstream to move to a "good" Artistic license" is IMO just a band aid. http://fedoraproject.org/wiki/Licensing http://www.opensource.org/licenses/artistic-license.php
2) The Wiki pages refer to "files" and "content" without specifying whether those refer to files/content in the source rpm, the resulting binary rpms, or both.
Example case: an upstream source tarball contains source files under let's say BSD, LGPLv2.1+ and GPLv2+ licenses. That would mean that let's say a binary built from all those would fall under GPLv2+. Specifying GPLv2+ as the License tag would be misrepresenting the copyrights of the files in the source rpm that carry BSD and LGPLv2.1+ notices. Specifying "BSD and LGPLv2.1+ and GPLv2+" would be misrepresenting the copyright of the combined work in the resulting binary.
3) Source licenses are not the only thing that affect the distributables' copyrights. For example when something is built from let's say LGPLv2+ sources but linked with a GPLv2+ library, the resulting binary will be GPLv2+, while the sources are still LGPLv2+ (unless their embedded copyright notices are changed to GPLv2+, but that can't be done for many *GPL licenses).
Suggested combined fix for 2) and 3) above: change the licensing guidelines to prominently note something like that the value of the License tag represents the copyright/license info of binary packages only, and only when built in the configuration specified by the Fedora build system, build dependencies/conflicts in the specfile, and no non-Fedora software installed that will affect the build in any way. Source rpms' copyrights are determined by the sources and other content included in them.
On Mon, 2007-08-06 at 23:05 +0300, Ville Skyttä wrote:
Hello,
Here's a few notes/questions that IMO need to be addressed in the new licensing guidelines in Wiki. IANAL, etc, but anyway, something for near future FPC meetings (which I still probably won't be able to attend to for a couple of weeks):
- The licensing pages strongly imply that OSI-approved licenses are ok.
However for example the original Artistic license is OSI-approved but listed in Wiki page as "bad". Something needs real fixing - "ask upstream to move to a "good" Artistic license" is IMO just a band aid. http://fedoraproject.org/wiki/Licensing http://www.opensource.org/licenses/artistic-license.php
I think we're going to need the Fedora Board to decide this. Its a little outside of our jurisdiction, unfortunately.
- The Wiki pages refer to "files" and "content" without specifying whether
those refer to files/content in the source rpm, the resulting binary rpms, or both.
Example case: an upstream source tarball contains source files under let's say BSD, LGPLv2.1+ and GPLv2+ licenses. That would mean that let's say a binary built from all those would fall under GPLv2+. Specifying GPLv2+ as the License tag would be misrepresenting the copyrights of the files in the source rpm that carry BSD and LGPLv2.1+ notices. Specifying "BSD and LGPLv2.1+ and GPLv2+" would be misrepresenting the copyright of the combined work in the resulting binary.
My interpretation is that the License: tag represents the license/copyright on the bits in the binary rpm.
Again, keep in mind that the License: tag is not legally binding, so its more of a helpful tool for initial auditing, and not much more.
- Source licenses are not the only thing that affect the distributables'
copyrights. For example when something is built from let's say LGPLv2+ sources but linked with a GPLv2+ library, the resulting binary will be GPLv2+, while the sources are still LGPLv2+ (unless their embedded copyright notices are changed to GPLv2+, but that can't be done for many *GPL licenses).
Suggested combined fix for 2) and 3) above: change the licensing guidelines to prominently note something like that the value of the License tag represents the copyright/license info of binary packages only, and only when built in the configuration specified by the Fedora build system, build dependencies/conflicts in the specfile, and no non-Fedora software installed that will affect the build in any way. Source rpms' copyrights are determined by the sources and other content included in them.
This seems fine to me. I'll work on drafting a change for vote.
~spot
On Monday 06 August 2007, Tom "spot" Callaway wrote:
On Mon, 2007-08-06 at 23:05 +0300, Ville Skyttä wrote:
Hello,
Here's a few notes/questions that IMO need to be addressed in the new licensing guidelines in Wiki. IANAL, etc, but anyway, something for near future FPC meetings (which I still probably won't be able to attend to for a couple of weeks):
- The licensing pages strongly imply that OSI-approved licenses are ok.
However for example the original Artistic license is OSI-approved but listed in Wiki page as "bad". Something needs real fixing - "ask upstream to move to a "good" Artistic license" is IMO just a band aid. http://fedoraproject.org/wiki/Licensing http://www.opensource.org/licenses/artistic-license.php
I think we're going to need the Fedora Board to decide this. Its a little outside of our jurisdiction, unfortunately.
Ok, I'll forward the question to fab-list, hopefully they'll pick this up.
[...]
- Source licenses are not the only thing that affect the distributables'
copyrights. For example when something is built from let's say LGPLv2+ sources but linked with a GPLv2+ library, the resulting binary will be GPLv2+, while the sources are still LGPLv2+ (unless their embedded copyright notices are changed to GPLv2+, but that can't be done for many *GPL licenses).
(Meant to say "... but that can't be done for many non-*GPL licenses.")
Suggested combined fix for 2) and 3) above: change the licensing guidelines to prominently note something like that the value of the License tag represents the copyright/license info of binary packages only, and only when built in the configuration specified by the Fedora build system, build dependencies/conflicts in the specfile, and no non-Fedora software installed that will affect the build in any way. Source rpms' copyrights are determined by the sources and other content included in them.
This seems fine to me. I'll work on drafting a change for vote.
Thanks. You can count me as +1 if the exact text to be voted on won't differ drastically from the above.
Ville Skyttä wrote:
On Monday 06 August 2007, Tom "spot" Callaway wrote:
On Mon, 2007-08-06 at 23:05 +0300, Ville Skyttä wrote:
Hello,
Here's a few notes/questions that IMO need to be addressed in the new licensing guidelines in Wiki. IANAL, etc, but anyway, something for near future FPC meetings (which I still probably won't be able to attend to for a couple of weeks):
- The licensing pages strongly imply that OSI-approved licenses are ok.
However for example the original Artistic license is OSI-approved but listed in Wiki page as "bad". Something needs real fixing - "ask upstream to move to a "good" Artistic license" is IMO just a band aid. http://fedoraproject.org/wiki/Licensing http://www.opensource.org/licenses/artistic-license.php
I think we're going to need the Fedora Board to decide this. Its a little outside of our jurisdiction, unfortunately.
Ok, I'll forward the question to fab-list, hopefully they'll pick this up.
I'll be waiting for a resolution of this before updating most of my perl module packages - depending on the result, the "same as perl" licensed modules may be "GPL+" or "GPL+ or Artistic". I favour the latter personally as that's what the upstream authors intended.
On a related issue, the short name "GPL+" is described as:
A GPL or LGPL licensed package that lacks any statement of what version that it's licensed under in the source code/program output/accompanying docs is technically licensed under *any* version of the GPL or LGPL, not just the version in whatever COPYING file they include.
I presume, though it's not explicitly stated, that GPL+ can also be used where the license is explicitly given as "GPL version 1 or later" (e.g. for perl and all same-as-perl licensed modules)?
Similarly, I take LGPL+ to be suitable for packages licensed as "LGPL v2 (not 2.1) or later" as well as for LGPL of unspecified version?
Paul.
On Wed, 2007-08-08 at 10:33 +0100, Paul Howarth wrote:
I presume, though it's not explicitly stated, that GPL+ can also be used where the license is explicitly given as "GPL version 1 or later" (e.g. for perl and all same-as-perl licensed modules)?
Yes, this correct.
Similarly, I take LGPL+ to be suitable for packages licensed as "LGPL v2 (not 2.1) or later" as well as for LGPL of unspecified version?
Not quite:
LGPL+ is only for unversioned LGPL (I've never seen this, but it's possible). LGPLv2+ is for LGPL 2/2.1 or later.
~spot
On Wed, 2007-08-08 at 09:48 -0400, Tom "spot" Callaway wrote:
On Wed, 2007-08-08 at 10:33 +0100, Paul Howarth wrote:
I presume, though it's not explicitly stated, that GPL+ can also be used where the license is explicitly given as "GPL version 1 or later" (e.g. for perl and all same-as-perl licensed modules)?
Yes, this correct.
Similarly, I take LGPL+ to be suitable for packages licensed as "LGPL v2 (not 2.1) or later" as well as for LGPL of unspecified version?
Not quite:
LGPL+ is only for unversioned LGPL (I've never seen this, but it's possible). LGPLv2+ is for LGPL 2/2.1 or later.
Can you explain the difference, considering there is no version 1 of the LGPL ?
On Wed, 2007-08-08 at 09:51 -0400, Matthias Clasen wrote:
On Wed, 2007-08-08 at 09:48 -0400, Tom "spot" Callaway wrote:
On Wed, 2007-08-08 at 10:33 +0100, Paul Howarth wrote:
I presume, though it's not explicitly stated, that GPL+ can also be used where the license is explicitly given as "GPL version 1 or later" (e.g. for perl and all same-as-perl licensed modules)?
Yes, this correct.
Similarly, I take LGPL+ to be suitable for packages licensed as "LGPL v2 (not 2.1) or later" as well as for LGPL of unspecified version?
Not quite:
LGPL+ is only for unversioned LGPL (I've never seen this, but it's possible). LGPLv2+ is for LGPL 2/2.1 or later.
Can you explain the difference, considering there is no version 1 of the LGPL ?
Eh, I suppose there is no difference. I'll nuke LGPL+ off the list.
~spot
Matthias Clasen wrote:
On Wed, 2007-08-08 at 09:48 -0400, Tom "spot" Callaway wrote:
On Wed, 2007-08-08 at 10:33 +0100, Paul Howarth wrote:
I presume, though it's not explicitly stated, that GPL+ can also be used where the license is explicitly given as "GPL version 1 or later" (e.g. for perl and all same-as-perl licensed modules)?
Yes, this correct.
Similarly, I take LGPL+ to be suitable for packages licensed as "LGPL v2 (not 2.1) or later" as well as for LGPL of unspecified version?
Not quite:
LGPL+ is only for unversioned LGPL (I've never seen this, but it's possible). LGPLv2+ is for LGPL 2/2.1 or later.
Can you explain the difference, considering there is no version 1 of the LGPL ?
Also considering that the "Full name" column of the licensing page on the wiki specifically refers to v2.1 onwards (and not v2 onwards) for the LGPL2 and LGPL2+ short names.
Paul.
Paul Howarth wrote:
Ville Skyttä wrote:
On Monday 06 August 2007, Tom "spot" Callaway wrote:
On Mon, 2007-08-06 at 23:05 +0300, Ville Skyttä wrote:
Hello,
Here's a few notes/questions that IMO need to be addressed in the new licensing guidelines in Wiki. IANAL, etc, but anyway, something for near future FPC meetings (which I still probably won't be able to attend to for a couple of weeks):
- The licensing pages strongly imply that OSI-approved licenses are
ok. However for example the original Artistic license is OSI-approved but listed in Wiki page as "bad". Something needs real fixing - "ask upstream to move to a "good" Artistic license" is IMO just a band aid. http://fedoraproject.org/wiki/Licensing http://www.opensource.org/licenses/artistic-license.php
I think we're going to need the Fedora Board to decide this. Its a little outside of our jurisdiction, unfortunately.
Ok, I'll forward the question to fab-list, hopefully they'll pick this up.
I'll be waiting for a resolution of this before updating most of my perl module packages - depending on the result, the "same as perl" licensed modules may be "GPL+" or "GPL+ or Artistic". I favour the latter personally as that's what the upstream authors intended.
I've been working my way through my packages, updating the license fields as appropriate. I just came across perl-Tie-EncryptedHash, which is under the Artistic license (only). If this is not an acceptable license, the package will have to go, and so will perl-Crypt-RSA (which depends on it) and anything else that depends on that.
Paul.
On Mon, 2007-08-13 at 13:30 +0100, Paul Howarth wrote:
I've been working my way through my packages, updating the license fields as appropriate. I just came across perl-Tie-EncryptedHash, which is under the Artistic license (only). If this is not an acceptable license, the package will have to go, and so will perl-Crypt-RSA (which depends on it) and anything else that depends on that.
Would you ask upstream if they'd be willing to relicense either under the same terms as perl or Artistic 2.0?
Thanks,
~spot
Tom "spot" Callaway wrote:
On Mon, 2007-08-13 at 13:30 +0100, Paul Howarth wrote:
I've been working my way through my packages, updating the license fields as appropriate. I just came across perl-Tie-EncryptedHash, which is under the Artistic license (only). If this is not an acceptable license, the package will have to go, and so will perl-Crypt-RSA (which depends on it) and anything else that depends on that.
Would you ask upstream if they'd be willing to relicense either under the same terms as perl or Artistic 2.0?
Done.
http://rt.cpan.org/Public/Bug/Display.html?id=28813
Paul.
On Mon, Aug 06, 2007 at 11:05:50PM +0300, Ville Skyttä wrote:
- Source licenses are not the only thing that affect the distributables'
copyrights. For example when something is built from let's say LGPLv2+ sources but linked with a GPLv2+ library, the resulting binary will be GPLv2+, while the sources are still LGPLv2+ (unless their embedded copyright notices are changed to GPLv2+, but that can't be done for many *GPL licenses).
Suggested combined fix for 2) and 3) above: change the licensing guidelines to prominently note something like that the value of the License tag represents the copyright/license info of binary packages only, and only when built in the configuration specified by the Fedora build system, build dependencies/conflicts in the specfile, and no non-Fedora software installed that will affect the build in any way. Source rpms' copyrights are determined by the sources and other content included in them.
Sometimes a src.rpm/specfile does not know what it will be built against, it doesn't even quite know whether it will be built against the glibc and whether that glibc is undert GPL2, 3, 1001 and so forth.
Since we massage specfiles and not the environment we can't know what this package will binary-wise end up like. It might be that gnutls acts as a drop in replacement to openssl or libedit to readline (actually the latter almost does) atlas to lapack (but the licenses don't differ). Point is the build environment defines the final license and the same specfile/src.rpm could end up with different licenses for the binaries depending on which distribution and which age of it we're looking at.
For example consider gnuplot BR'ing a readline librariy's headers w/o specifying GNU readline. If you use GNU readline the binary's license is "undistributable" (actually that's the kind of gnuplot we currently do ship ...), if you use libedit it's "distributable".
So the License: tag needs to be closer to the sources than the binaries. We can't have both unles we would introduce something like a BinaryLicense: tag.
packaging@lists.fedoraproject.org
-
Axel Thimm -
Matthias Clasen -
Paul Howarth -
Tom Callaway -
Ville Skyttä