On Mon, 27 Aug 2007, Dag Wieers wrote:
On Mon, 27 Aug 2007, Kevin Fenzi wrote:
Since Enrico never intended to maintain clamav in EPEL, he has formally orphaned clamav in EL-4 and EL-5.
Is there anyone out there that would be willing to take it on?
Preferably someone who likes/understands Enrico's package setup so you can stay in sync with Fedora versions?
If no one steps up soon, I might be able to take it over, but I would be quite likely to radically change the packaging.
Before you do, let's discuss how we can make things compatible in order to help existing users :)
ok. Sorry for getting behind on this...
It doesn't look like anyone wants to step up and maintain the current package in EPEL.
Would you be interested in maintaining your package in EPEL?
Or failing that, would you be willing to let me use your package and just keep it in sync with your version upstream?
Obviously, there would need to be testing to confirm that it upgrades the old 0.88.x version currently in EPEL correctly, but I can work on that if you don't mind me basing on your package.
Any other thoughts or ideas?
kevin
On 9/17/07, Kevin Fenzi kevin@tummy.com wrote:
On Mon, 27 Aug 2007, Dag Wieers wrote:
On Mon, 27 Aug 2007, Kevin Fenzi wrote:
Since Enrico never intended to maintain clamav in EPEL, he has formally orphaned clamav in EL-4 and EL-5.
Is there anyone out there that would be willing to take it on?
Preferably someone who likes/understands Enrico's package setup so you can stay in sync with Fedora versions?
If no one steps up soon, I might be able to take it over, but I would be quite likely to radically change the packaging.
Before you do, let's discuss how we can make things compatible in order to help existing users :)
ok. Sorry for getting behind on this...
It doesn't look like anyone wants to step up and maintain the current package in EPEL.
Actually I would be interested in doing it in the form you mentioned below. I thought it was moving behind the scenes from the last email you quoted above. I could be a co-maintainer as I have not maintained anything to this date.
Would you be interested in maintaining your package in EPEL?
Or failing that, would you be willing to let me use your package and just keep it in sync with your version upstream?
Obviously, there would need to be testing to confirm that it upgrades the old 0.88.x version currently in EPEL correctly, but I can work on that if you don't mind me basing on your package.
Any other thoughts or ideas?
kevin
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Mon, 17 Sep 2007 16:00:44 -0600 smooge@gmail.com ("Stephen John Smoogen") wrote:
It doesn't look like anyone wants to step up and maintain the current package in EPEL.
Actually I would be interested in doing it in the form you mentioned below. I thought it was moving behind the scenes from the last email you quoted above. I could be a co-maintainer as I have not maintained anything to this date.
Excellent. I think with packages like clamav that have lots of security updates in their history it would be good to have a number of (co)maintainers of the package. That way someone would always be around to push security updates...
The more the better.
Let's see what Dag thinks of us being able to use his package and go from there.
Would you be interested in maintaining your package in EPEL?
Or failing that, would you be willing to let me use your package and just keep it in sync with your version upstream?
Obviously, there would need to be testing to confirm that it upgrades the old 0.88.x version currently in EPEL correctly, but I can work on that if you don't mind me basing on your package.
Any other thoughts or ideas?
kevin
kevin
On Tue, 18 Sep 2007, Kevin Fenzi wrote:
On Mon, 17 Sep 2007 16:00:44 -0600 smooge@gmail.com ("Stephen John Smoogen") wrote:
It doesn't look like anyone wants to step up and maintain the current package in EPEL.
Actually I would be interested in doing it in the form you mentioned below. I thought it was moving behind the scenes from the last email you quoted above. I could be a co-maintainer as I have not maintained anything to this date.
Excellent. I think with packages like clamav that have lots of security updates in their history it would be good to have a number of (co)maintainers of the package. That way someone would always be around to push security updates...
The more the better.
Let's see what Dag thinks of us being able to use his package and go from there.
I have no problem helping out or discussing the SPEC file. I am pretty sure that a lot of improvements can be made and flow back.
I also have no problem if the RPMforge SPEC files are to be used by other projects, and I know some people have done this. I do not feel that the SPEC files contain anything 'special'. In fact, I would not be surprised if people can come up with (almost) exactly the same SPEC file for a project. So I don't feel the need to add a license or copyright, you can think of the SPEC file as being in the public domain.
In fact, I prefer that people use existing SPEC files and improve on them so that at least different packages have the same basis (and naming). I welcome feedback and ideas, but can understand to need for control and authority within a seperate project.
CCing Fedora-Advisory Board
On 22.09.2007 03:01, Dag Wieers wrote:
[...] I also have no problem if the RPMforge SPEC files are to be used by other projects, and I know some people have done this. I do not feel that the SPEC files contain anything 'special'. In fact, I would not be surprised if people can come up with (almost) exactly the same SPEC file for a project. So I don't feel the need to add a license or copyright, you can think of the SPEC file as being in the public domain.
In fact, I prefer that people use existing SPEC files and improve on them so that at least different packages have the same basis (and naming). I welcome feedback and ideas, but can understand to need for control and authority within a seperate project.
+1 to this and I also have no problem if my spec files are used by other projects. I also would prefer if they are used that way and that improvements flow from one project to the other and vice versa. Using the pkgdb and the cvs-commits list it's easy for outsiders to already follow them -- I you want watchcommits access to some of my packages just let me know.
I cannot speak for other peoples spec files and I suspect some packagers won't agree with the "SPEC files are public domain" statement -- making the license of the spec files explicit (a Wiki page that says "All our Fedora RPM SPEC files are free software and public domain if not otherwise specified in the spec file" might be enough already) in Fedora-land (EPEL, Fedora) would be best for all, as external projects (RPMForge, RPMFusion, Linva, freshrpms, <insert others>) than would be on the safe side if they use them.
@FESCo,@Board, you have the power to do that -- are you willing to do something like that? Currently it's a bit a grey area IMHO and that sucks. tia!
Cu knurd
Seems I missed to CC Fedora-Advisory Board, thus sending this again. Sorry for the trouble epel-devel-list.
On 22.09.2007 13:00, Thorsten Leemhuis wrote:
CCing Fedora-Advisory Board
On 22.09.2007 03:01, Dag Wieers wrote:
[...] I also have no problem if the RPMforge SPEC files are to be used by other projects, and I know some people have done this. I do not feel that the SPEC files contain anything 'special'. In fact, I would not be surprised if people can come up with (almost) exactly the same SPEC file for a project. So I don't feel the need to add a license or copyright, you can think of the SPEC file as being in the public domain.
In fact, I prefer that people use existing SPEC files and improve on them so that at least different packages have the same basis (and naming). I welcome feedback and ideas, but can understand to need for control and authority within a seperate project.
+1 to this and I also have no problem if my spec files are used by other projects. I also would prefer if they are used that way and that improvements flow from one project to the other and vice versa. Using the pkgdb and the cvs-commits list it's easy for outsiders to already follow them -- I you want watchcommits access to some of my packages just let me know.
I cannot speak for other peoples spec files and I suspect some packagers won't agree with the "SPEC files are public domain" statement -- making the license of the spec files explicit (a Wiki page that says "All our Fedora RPM SPEC files are free software and public domain if not otherwise specified in the spec file" might be enough already) in Fedora-land (EPEL, Fedora) would be best for all, as external projects (RPMForge, RPMFusion, Linva, freshrpms, <insert others>) than would be on the safe side if they use them.
@FESCo,@Board, you have the power to do that -- are you willing to do something like that? Currently it's a bit a grey area IMHO and that sucks. tia!
Cu knurd
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
fedora-advisory-board mailing list fedora-advisory-board@redhat.com http://www.redhat.com/mailman/listinfo/fedora-advisory-board
"TL" == Thorsten Leemhuis fedora@leemhuis.info writes:
TL> I cannot speak for other peoples spec files and I suspect some TL> packagers won't agree with the "SPEC files are public domain" TL> statement
You can be certain of it; for whatever reason, jpackage specfiles carry a block of license text, and they've been incorporated verbatim into Fedora. Which I honestly don't think should have been allowed, but nobody seemed to care when I raised the issue.
I certainly agree that the issue begs clarification.
- J<
On 22 Sep 2007 11:12:56 -0500, Jason L Tibbitts III tibbs@math.uh.edu wrote:
"TL" == Thorsten Leemhuis fedora@leemhuis.info writes:
TL> I cannot speak for other peoples spec files and I suspect some TL> packagers won't agree with the "SPEC files are public domain" TL> statement
(disclaimer: IANALY)
At least under US copyright law, it isn't at all clear that spec files are copyrightable. When there are very few (or effectively one) way of expressing a particular idea, courts typically will find that there is no copyright protection for the expression(s) of the idea. This is known as 'merger doctrine', since the idea is said to be 'merged' with the expression of the idea.
I'd suggest that most specfiles probably are like this- there are only so many ways to list which files need to be packaged, what the deps are, etc., and they mostly derive from known facts rather than creative choice on the part of the specfile author. (Dag, who obviously knows a hell of a lot more about specfiles than I do, seems to agree with me, but YMMV.)
That said, it wouldn't hurt for Fedora to expressly note that they think that specfiles are not copyrighted/copyrightable, so that there is no confusion.
Luis (again, disclaimer: IANALY)
On Sat, 22 Sep 2007 13:00:41 +0200 Thorsten Leemhuis fedora@leemhuis.info wrote:
CCing Fedora-Advisory Board
On 22.09.2007 03:01, Dag Wieers wrote:
[...] I also have no problem if the RPMforge SPEC files are to be used by other projects, and I know some people have done this. I do not feel that the SPEC files contain anything 'special'. In fact, I would not be surprised if people can come up with (almost) exactly the same SPEC file for a project. So I don't feel the need to add a license or copyright, you can think of the SPEC file as being in the public domain.
In fact, I prefer that people use existing SPEC files and improve on them so that at least different packages have the same basis (and naming). I welcome feedback and ideas, but can understand to need for control and authority within a seperate project.
+1 to this and I also have no problem if my spec files are used by other projects. I also would prefer if they are used that way and that improvements flow from one project to the other and vice versa. Using the pkgdb and the cvs-commits list it's easy for outsiders to already follow them -- I you want watchcommits access to some of my packages just let me know.
I cannot speak for other peoples spec files and I suspect some packagers won't agree with the "SPEC files are public domain" statement -- making the license of the spec files explicit (a Wiki page that says "All our Fedora RPM SPEC files are free software and public domain if not otherwise specified in the spec file" might be enough already) in Fedora-land (EPEL, Fedora) would be best for all, as external projects (RPMForge, RPMFusion, Linva, freshrpms, <insert others>) than would be on the safe side if they use them.
@FESCo,@Board, you have the power to do that -- are you willing to do something like that? Currently it's a bit a grey area IMHO and that sucks. tia!
I don't think you really want them to be considered public domain. You actually have to expressly say "This spec file is public domain" before that becomes true, otherwise it still holds a copyright by default. That's a lot of spec files to edit for no real gain.
Personally, I consider spec files to be contributions to Fedora per the CLA. And since the Distribution as a whole is licensed under the GPLv2, the spec files are likely licensed under that too. (I AM NOT A LAWYER AND TAKING LEGAL ADVICE FROM ME WOULD BE VERY STUPID)
Overall, I think it's just fine for the spec files to be used in other projects. The Board would ultimately have the call here. It's above FESCo.
josh
On Sat, 2007-09-22 at 13:00 +0200, Thorsten Leemhuis wrote:
@FESCo,@Board, you have the power to do that -- are you willing to do something like that? Currently it's a bit a grey area IMHO and that sucks. tia!
The CLA covers this:
http://fedoraproject.org/wiki/Legal/Licenses/CLA
"2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on behalf of the Project, and to recipients of software distributed by the Project: * (a) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your Contribution and such derivative works; and, * (b) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable (subject to Section 3) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer your Contribution and derivative works thereof, where such license applies only to those patent claims licensable by you that are necessarily infringed by your Contribution alone or by combination of your Contribution with the work to which you submitted the Contribution. Except for the license granted in this section, you reserve all right, title and interest in and to your Contributions."
Short answer: All Fedora spec files get these rights. Anyone downloading them gets them too.
~spot
On 25.09.2007 22:59, Tom "spot" Callaway wrote:
On Sat, 2007-09-22 at 13:00 +0200, Thorsten Leemhuis wrote:
@FESCo,@Board, you have the power to do that -- are you willing to do something like that? Currently it's a bit a grey area IMHO and that sucks. tia!
The CLA covers this:
http://fedoraproject.org/wiki/Legal/Licenses/CLA
"2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on behalf of the Project, and to recipients of software distributed by the Project: * (a) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your Contribution and such derivative works; and, * (b) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable (subject to Section 3) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer your Contribution and derivative works thereof, where such license applies only to those patent claims licensable by you that are necessarily infringed by your Contribution alone or by combination of your Contribution with the work to which you submitted the Contribution. Except for the license granted in this section, you reserve all right, title and interest in and to your Contributions."
Short answer: All Fedora spec files get these rights. Anyone downloading them gets them too.
And the latter is not obvious to anyone downloading the software. He often will not even be aware of a "Contributor Grant of License" that contributors make with the software provider, as he just wants to use the software and don't contribute to it.
It's like a contract that one makes with the author of software "foo" that states that all contributions to foo are Free Software. But then foo get shipped without any license and the users of foo cannot be sure if it's free software (thus it would be unshippable in Fedora!).
Further: As IANAL I read stuff like "a perpetual, non-exclusive, worldwide, fully paid-up [...] sublicense, and distribute your Contribution and such derivative works [...]" and wonder "that gives RH a lot of rights -- even to distribute it as non-free software" (afaics an IANAL). So who says it's free software if I just download a SPEC file from CVS or a SRPM from the web?
IOW: We should obey our own guidelines that at http://fedoraproject.org/wiki/Packaging/ReviewGuidelines say: "If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it." I think we don't need to include it in the spec files, but clarifying it is IMHO really needed and not a big deal.
So could the Board please put it on its agenda?
Cu knurd
On Wed, 26 Sep 2007, Thorsten Leemhuis wrote:
On 25.09.2007 22:59, Tom "spot" Callaway wrote:
On Sat, 2007-09-22 at 13:00 +0200, Thorsten Leemhuis wrote:
@FESCo,@Board, you have the power to do that -- are you willing to do something like that? Currently it's a bit a grey area IMHO and that sucks. tia!
The CLA covers this:
http://fedoraproject.org/wiki/Legal/Licenses/CLA
"2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on behalf of the Project, and to recipients of software distributed by the Project: * (a) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your Contribution and such derivative works; and, * (b) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable (subject to Section 3) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer your Contribution and derivative works thereof, where such license applies only to those patent claims licensable by you that are necessarily infringed by your Contribution alone or by combination of your Contribution with the work to which you submitted the Contribution. Except for the license granted in this section, you reserve all right, title and interest in and to your Contributions."
Short answer: All Fedora spec files get these rights. Anyone downloading them gets them too.
And the latter is not obvious to anyone downloading the software. He often will not even be aware of a "Contributor Grant of License" that contributors make with the software provider, as he just wants to use the software and don't contribute to it.
It's like a contract that one makes with the author of software "foo" that states that all contributions to foo are Free Software. But then foo get shipped without any license and the users of foo cannot be sure if it's free software (thus it would be unshippable in Fedora!).
Further: As IANAL I read stuff like "a perpetual, non-exclusive, worldwide, fully paid-up [...] sublicense, and distribute your Contribution and such derivative works [...]" and wonder "that gives RH a lot of rights -- even to distribute it as non-free software" (afaics an IANAL). So who says it's free software if I just download a SPEC file from CVS or a SRPM from the web?
IOW: We should obey our own guidelines that at http://fedoraproject.org/wiki/Packaging/ReviewGuidelines say: "If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it." I think we don't need to include it in the spec files, but clarifying it is IMHO really needed and not a big deal.
So could the Board please put it on its agenda?
What is the decision that you are looking for here, Thorsten? A statement that the Fedora spec files are just as redistributable as all the rest of our source code (ie: that the spec files are GPL'd just like the source?)
I must confess I don't really understand the fundamental question of this thread. It would never even OCCUR to me to think that our spec files aren't as Free as everything else.
But if you can help me understand what you want, I will try to make that thing happen.
--Max
On Wed, 26 Sep 2007 10:05:44 -0400 (EDT) Max Spevack mspevack@redhat.com wrote:
On Wed, 26 Sep 2007, Thorsten Leemhuis wrote:
On 25.09.2007 22:59, Tom "spot" Callaway wrote:
On Sat, 2007-09-22 at 13:00 +0200, Thorsten Leemhuis wrote:
@FESCo,@Board, you have the power to do that -- are you willing to do something like that? Currently it's a bit a grey area IMHO and that sucks. tia!
The CLA covers this:
http://fedoraproject.org/wiki/Legal/Licenses/CLA
"2. Contributor Grant of License. You hereby grant to Red Hat, Inc., on behalf of the Project, and to recipients of software distributed by the Project: * (a) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your Contribution and such derivative works; and, * (b) a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable (subject to Section 3) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer your Contribution and derivative works thereof, where such license applies only to those patent claims licensable by you that are necessarily infringed by your Contribution alone or by combination of your Contribution with the work to which you submitted the Contribution. Except for the license granted in this section, you reserve all right, title and interest in and to your Contributions."
Short answer: All Fedora spec files get these rights. Anyone downloading them gets them too.
And the latter is not obvious to anyone downloading the software. He often will not even be aware of a "Contributor Grant of License" that contributors make with the software provider, as he just wants to use the software and don't contribute to it.
It's like a contract that one makes with the author of software "foo" that states that all contributions to foo are Free Software. But then foo get shipped without any license and the users of foo cannot be sure if it's free software (thus it would be unshippable in Fedora!).
Further: As IANAL I read stuff like "a perpetual, non-exclusive, worldwide, fully paid-up [...] sublicense, and distribute your Contribution and such derivative works [...]" and wonder "that gives RH a lot of rights -- even to distribute it as non-free software" (afaics an IANAL). So who says it's free software if I just download a SPEC file from CVS or a SRPM from the web?
IOW: We should obey our own guidelines that at http://fedoraproject.org/wiki/Packaging/ReviewGuidelines say: "If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it." I think we don't need to include it in the spec files, but clarifying it is IMHO really needed and not a big deal.
So could the Board please put it on its agenda?
What is the decision that you are looking for here, Thorsten? A statement that the Fedora spec files are just as redistributable as all the rest of our source code (ie: that the spec files are GPL'd just like the source?)
I must confess I don't really understand the fundamental question of this thread. It would never even OCCUR to me to think that our spec files aren't as Free as everything else.
But if you can help me understand what you want, I will try to make that thing happen.
A declaration of what license (if any) the spec files are under globally. Spot is right in that they are covered by the CLA, but I don't consider that to be straight forward for people consuming downstream. It's also complicated by the fact that nothing disallows people from adding their own license to the spec file.
The end goal is simply to allow others to take the Fedora spec files and use them in other projects.
josh
On Wed, 26 Sep 2007 09:14:45 -0500 Josh Boyer jwboyer@jdub.homelinux.org wrote:
A declaration of what license (if any) the spec files are under globally. Spot is right in that they are covered by the CLA, but I don't consider that to be straight forward for people consuming downstream. It's also complicated by the fact that nothing disallows people from adding their own license to the spec file.
The end goal is simply to allow others to take the Fedora spec files and use them in other projects.
Also we should probably make a decision project wise as to if allowing spec files in Fedora to be explicitly licensed (see jpp spec files) and if so how that interacts with the global license of all spec files.
On Wed, 26 Sep 2007 10:26:17 -0400 Jesse Keating jkeating@redhat.com wrote:
On Wed, 26 Sep 2007 09:14:45 -0500 Josh Boyer jwboyer@jdub.homelinux.org wrote:
A declaration of what license (if any) the spec files are under globally. Spot is right in that they are covered by the CLA, but I don't consider that to be straight forward for people consuming downstream. It's also complicated by the fact that nothing disallows people from adding their own license to the spec file.
The end goal is simply to allow others to take the Fedora spec files and use them in other projects.
Also we should probably make a decision project wise as to if allowing spec files in Fedora to be explicitly licensed (see jpp spec files) and if so how that interacts with the global license of all spec files.
Perhaps. Though you'll be opening yourself up for lots of interesting "you stole my licensed spec file!" debates if you disallow it. The jpp folks added the licensing explicitly because of Fedora contributors doing that.
josh
On Wed, 26 Sep 2007, Josh Boyer wrote:
A declaration of what license (if any) the spec files are under globally. Spot is right in that they are covered by the CLA, but I don't consider that to be straight forward for people consuming downstream. It's also complicated by the fact that nothing disallows people from adding their own license to the spec file.
The end goal is simply to allow others to take the Fedora spec files and use them in other projects.
Ok. I've asked Mark Webbink to clarify this for me explicitly, so that we can remove the confusion. I'll post back here when I hear from him.
thanks, Max
On 26.09.2007 16:34, Max Spevack wrote:
On Wed, 26 Sep 2007, Josh Boyer wrote:
A declaration of what license (if any) the spec files are under globally. Spot is right in that they are covered by the CLA, but I don't consider that to be straight forward for people consuming downstream. It's also complicated by the fact that nothing disallows people from adding their own license to the spec file.
The end goal is simply to allow others to take the Fedora spec files and use them in other projects.
Yeah, exactly that.
Ok. I've asked Mark Webbink to clarify this for me explicitly, so that we can remove the confusion. I'll post back here when I hear from him.
Thanks for your work Max.
CU knurd
On Wed, 2007-09-26 at 09:14 -0500, Josh Boyer wrote:
On Wed, 26 Sep 2007 10:05:44 -0400 (EDT)
A declaration of what license (if any) the spec files are under globally. Spot is right in that they are covered by the CLA,
1. The CLA is a bilateral contract. It is invisible to arbitrary users wanting to use these specs.
2. The CLA's applicability is controversial (compatibiltiy) wrt. some licenses, esp. GPL'ed packages. Fundamental question would be: Is an rpm a derivative work of the "original works"?
but I don't consider that to be straight forward for people consuming downstream. It's also complicated by the fact that nothing disallows people from adding their own license to the spec file.
Further questions arise from Fedora maintainers reusing/modifying upstream specs and/or specs from other origins (e.g. other distros). They can be covered by other copyrights/licenses (e.g. the GPL).
The end goal is simply to allow others to take the Fedora spec files and use them in other projects.
Ralf
On Wed, Sep 26, 2007 at 10:05:44AM -0400, Max Spevack wrote:
What is the decision that you are looking for here, Thorsten? A statement that the Fedora spec files are just as redistributable as all the rest of our source code (ie: that the spec files are GPL'd just like the source?)
I think the right thing to do is to make sure spec files are always such that they have no more restrictions than the upstream code that they build (even if the upstream license allows relicensing in a more strict way).
In fact, I'd really like to encourage spec-files-as-public-domain.
On Wed, 26 Sep 2007, Matthew Miller wrote:
On Wed, Sep 26, 2007 at 10:05:44AM -0400, Max Spevack wrote:
What is the decision that you are looking for here, Thorsten? A statement that the Fedora spec files are just as redistributable as all the rest of our source code (ie: that the spec files are GPL'd just like the source?)
I think the right thing to do is to make sure spec files are always such that they have no more restrictions than the upstream code that they build (even if the upstream license allows relicensing in a more strict way).
In fact, I'd really like to encourage spec-files-as-public-domain.
Me too. I cannot see much value in SPEC files and 2 persons can end up making the exact SPEC file.
What is required to make something public domain ? Is it sufficient to add a file in a directory, or do I need to add a line on top ?
If so, I have no problem to put that information in every SPEC file.
epel-devel@lists.fedoraproject.org
-
Dag Wieers -
Jason L Tibbitts III -
Jesse Keating -
Josh Boyer -
Kevin Fenzi -
Luis Villa -
Matthew Miller -
Max Spevack -
Ralf Corsepius -
Stephen John Smoogen -
Thorsten Leemhuis -
Tom Callaway