3:05 p.m.
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.
3:48 p.m.
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):
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
I think we're going to need the Fedora Board to decide this. Its a
little outside of our jurisdiction, unfortunately.
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.
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.
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.
This seems fine to me. I'll work on drafting a change for vote.
~spot
4:16 p.m.
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):
>
> 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
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.
[...]
> 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).
(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.
3:16 a.m.
On Mon, Aug 06, 2007 at 11:05:50PM +0300, Ville Skyttä wrote:
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.
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.
--
Axel.Thimm at ATrpms.net
4:33 a.m.
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):
>>
>> 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
> 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.
8:48 a.m.
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
8:51 a.m.
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 ?
9:01 a.m.
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
9:03 a.m.
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.
7:30 a.m.
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):
>>>
>>> 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
>> 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.
8:54 a.m.
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
9:32 a.m.
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.
6102
days inactive
6109
days old
packaging@lists.fedoraproject.org
11 comments
5 participants
participants (5)
-
Axel Thimm -
Matthias Clasen -
Paul Howarth -
Tom Callaway -
Ville Skyttä