[arch-dev-public] Definition of non-free for repo-reorg
If we do separate "non-free" and "free" in the new repo layout, what will be the definition of "non-free"? Will anything closed source be non-free (acroread, nvidia)? or only things that have license/patent/distribution issues, like codecs? Will we just follow debian's definition and tests? James
On Thu, Jul 12, 2007 at 11:25:49AM +1000, James Rayner wrote:
If we do separate "non-free" and "free" in the new repo layout, what will be the definition of "non-free"?
Will anything closed source be non-free (acroread, nvidia)? or only things that have license/patent/distribution issues, like codecs?
I still don't see the need. We've never bothered in the past and it's just making things more complicated, why bother now? -S
Thursday 12 July 2007, Simo Leone wrote: | I still don't see the need. We've never bothered in the past and | it's just making things more complicated, why bother now? i agree why making all this mess? to satisfy the fundamentalists, i would suggest, that you can specify in pacman.conf, what licences you agree to and what licences you do not agree to. then pacman will know what is "allowed" to be installed. whenever a new licence comes up (with a new pkg) pacman would ask: do you agree to licence XYZ? licence XYZ can be found under /path/to/licence if you want to read it. Y/N? and then pacman would add this result to pacman.conf do not separate repositories acording to licences... that would make it quite messy. - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On Thu, July 12, 2007 20:17, Damir Perisa wrote:
Thursday 12 July 2007, Simo Leone wrote: | I still don't see the need. We've never bothered in the past and | it's just making things more complicated, why bother now?
i agree
why making all this mess?
to satisfy the fundamentalists, i would suggest, that you can specify in pacman.conf, what licences you agree to and what licences you do not agree to. then pacman will know what is "allowed" to be installed. whenever a new licence comes up (with a new pkg) pacman would ask: do you agree to licence XYZ? licence XYZ can be found under /path/to/licence if you want to read it. Y/N? and then pacman would add this result to pacman.conf
do not separate repositories acording to licences... that would make it quite messy.
agreed. it'd make a mess when things depend on "non-free" stuff.
Damir Perisa wrote:
Thursday 12 July 2007, Simo Leone wrote: | I still don't see the need. We've never bothered in the past and | it's just making things more complicated, why bother now?
i agree
why making all this mess?
to satisfy the fundamentalists, i would suggest, that you can specify in pacman.conf, what licences you agree to and what licences you do not agree to. then pacman will know what is "allowed" to be installed. whenever a new licence comes up (with a new pkg) pacman would ask: do you agree to licence XYZ? licence XYZ can be found under /path/to/licence if you want to read it. Y/N? and then pacman would add this result to pacman.conf
You know, you're brilliant, man. Yes, this is clearly the place to do this, in my opinion. - P
On 7/12/07, Paul Mattal <paul@mattal.com> wrote:
Damir Perisa wrote:
Thursday 12 July 2007, Simo Leone wrote: | I still don't see the need. We've never bothered in the past and | it's just making things more complicated, why bother now?
i agree
why making all this mess?
to satisfy the fundamentalists, i would suggest, that you can specify in pacman.conf, what licences you agree to and what licences you do not agree to. then pacman will know what is "allowed" to be installed. whenever a new licence comes up (with a new pkg) pacman would ask: do you agree to licence XYZ? licence XYZ can be found under /path/to/licence if you want to read it. Y/N? and then pacman would add this result to pacman.conf
You know, you're brilliant, man.
Yes, this is clearly the place to do this, in my opinion.
Aaron Griffin wrote:
On 7/12/07, Paul Mattal <paul@mattal.com> wrote:
Damir Perisa wrote:
Thursday 12 July 2007, Simo Leone wrote: | I still don't see the need. We've never bothered in the past and | it's just making things more complicated, why bother now?
i agree
why making all this mess?
to satisfy the fundamentalists, i would suggest, that you can specify in pacman.conf, what licences you agree to and what licences you do not agree to. then pacman will know what is "allowed" to be installed. whenever a new licence comes up (with a new pkg) pacman would ask: do you agree to licence XYZ? licence XYZ can be found under /path/to/licence if you want to read it. Y/N? and then pacman would add this result to pacman.conf You know, you're brilliant, man.
Yes, this is clearly the place to do this, in my opinion.
Okay, so you're brilliant, too. :) Seriously though, this gives a good way to handle the licensing without burdening the package organization. Good separation. - P
On 7/12/07, Paul Mattal <paul@mattal.com> wrote:
Aaron Griffin wrote:
On 7/12/07, Paul Mattal <paul@mattal.com> wrote:
Damir Perisa wrote:
Thursday 12 July 2007, Simo Leone wrote: | I still don't see the need. We've never bothered in the past and | it's just making things more complicated, why bother now?
i agree
why making all this mess?
to satisfy the fundamentalists, i would suggest, that you can specify in pacman.conf, what licences you agree to and what licences you do not agree to. then pacman will know what is "allowed" to be installed. whenever a new licence comes up (with a new pkg) pacman would ask: do you agree to licence XYZ? licence XYZ can be found under /path/to/licence if you want to read it. Y/N? and then pacman would add this result to pacman.conf You know, you're brilliant, man.
Yes, this is clearly the place to do this, in my opinion.
Okay, so you're brilliant, too. :)
Seriously though, this gives a good way to handle the licensing without burdening the package organization. Good separation.
Except that...I thought the issue had nothing to do with package installation. It has to do with distribution, no? These are two separate issues for sure, and now we have managed to make this much more complicated by bringing pacman into it. -Dan
Dan McGee wrote:
Except that...I thought the issue had nothing to do with package installation. It has to do with distribution, no?
These are two separate issues for sure, and now we have managed to make this much more complicated by bringing pacman into it.
It's true that the issue has many aspects. Some of them have to do with distribution, others have to do with having the source, etc. Some can be solved by pacman (or something using libalpm), some cannot. I recommend that someone who is really fired up about the license separation issue propose something that scratches their itch and helps implement it. If nobody is that fired up about it, nothing will happen, which is fine with me. I would like to figure out what can/can't we distribute in what might be our shiny new [core] repo, since we will be distributing ISOs/CDs of that. What are the requirements? GPL or any less restrictive license is okay? We should probably make a list of acceptable licenses. - P
On Thu, Jul 12, 2007 at 12:17:08PM +0200, Damir Perisa wrote:
Thursday 12 July 2007, Simo Leone wrote: | I still don't see the need. We've never bothered in the past and | it's just making things more complicated, why bother now?
i agree
why making all this mess?
to satisfy the fundamentalists, i would suggest, that you can specify in pacman.conf, what licences you agree to and what licences you do not agree to. then pacman will know what is "allowed" to be installed. whenever a new licence comes up (with a new pkg) pacman would ask: do you agree to licence XYZ? licence XYZ can be found under /path/to/licence if you want to read it. Y/N? and then pacman would add this result to pacman.conf
Featuritis. Another pacman feature, that should not be part of a simple lightweight package manager. A user can query the database for non-free software and just remove it. He has all the tools to do this. Please don't loose track of archlinux/pacman's philosophy. Jürgen
Jürgen Hötzel wrote:
Featuritis. Another pacman feature, that should not be part of a simple lightweight package manager.
License issues do need to be handled somewhere. I think we've already chosen to handle them in pacman, by putting all that information into packages. We could separate this out into a separate binary that uses libalpm and acts as a wrapper around real pacman, I suppose, if that would make people feel better. That seems to me like even more complexity for a fairly lightweight feature. - P
On 7/12/07, Paul Mattal <paul@mattal.com> wrote:
Jürgen Hötzel wrote:
Featuritis. Another pacman feature, that should not be part of a simple lightweight package manager.
License issues do need to be handled somewhere. I think we've already chosen to handle them in pacman, by putting all that information into packages.
We could separate this out into a separate binary that uses libalpm and acts as a wrapper around real pacman, I suppose, if that would make people feel better. That seems to me like even more complexity for a fairly lightweight feature.
I have to agree with Paul here. I mean, if you want to play the featuritis game, I could go on and on about packaging - for instance, why don't we build binary packages with all DB info for that package already in the var/lib/pacman directory? That way we don't even need pacman, just untar it at the top level. That'd strip pacman code in half, who needs this "feature creep" of actually installing packages? If you didn't catch it, the above is me being snarky. I see too many people call "feature creep" on things which, really, aren't that complicated. Seriously, adding the license stuff into pacman would be FAR less code than say, colored output, which apparently everyone wants and no one is concerned about.
Aaron Griffin wrote:
On 7/12/07, Paul Mattal <paul@mattal.com> wrote:
Jürgen Hötzel wrote:
Featuritis. Another pacman feature, that should not be part of a simple lightweight package manager. License issues do need to be handled somewhere. I think we've already chosen to handle them in pacman, by putting all that information into packages.
We could separate this out into a separate binary that uses libalpm and acts as a wrapper around real pacman, I suppose, if that would make people feel better. That seems to me like even more complexity for a fairly lightweight feature.
I have to agree with Paul here. I mean, if you want to play the featuritis game, I could go on and on about packaging - for instance, why don't we build binary packages with all DB info for that package already in the var/lib/pacman directory? That way we don't even need pacman, just untar it at the top level. That'd strip pacman code in half, who needs this "feature creep" of actually installing packages?
If you didn't catch it, the above is me being snarky. I see too many people call "feature creep" on things which, really, aren't that complicated. Seriously, adding the license stuff into pacman would be FAR less code than say, colored output, which apparently everyone wants and no one is concerned about.
I just want to temper this by saying.. I think we should be wary of feature creep. But I don't think this is it, given that we've put license management squarely into pacman's domain in the first place. Regardless, I'm not planning to implement this pacman feature, so I can avoid the argument altogether. :) - P
On Thu, Jul 12, 2007 at 12:43:48PM -0400, Paul Mattal wrote:
Jürgen Hötzel wrote:
Featuritis. Another pacman feature, that should not be part of a simple lightweight package manager.
License issues do need to be handled somewhere. I think we've already chosen to handle them in pacman, by putting all that information into packages.
Having license meta-information in packages is fine. And it would also be fine to not only search for package description/name but also package license. This would allow users to search for all pdf packages distributed under GPL using "pacman -Ss" But who needs a child proof for free software devotees, like in this scenario: "I have to install a viewer for this proprietary PDF files. Lets try Adobes Acrobat Reader" # pacman -S acroread do :: you agree to accept Adobes Non Free Software License [Y/N] User: "WTF! Adobe did not release Adobes Acrobat Reader as GPL? Thank god pacman saved me from installing non-free software". Jürgen
On Thu, Jul 12, 2007 at 07:44:30PM +0200, Jürgen Hötzel wrote:
On Thu, Jul 12, 2007 at 12:43:48PM -0400, Paul Mattal wrote:
Jürgen Hötzel wrote:
Featuritis. Another pacman feature, that should not be part of a simple lightweight package manager.
License issues do need to be handled somewhere. I think we've already chosen to handle them in pacman, by putting all that information into packages.
Having license meta-information in packages is fine. And it would also be fine to not only search for package description/name but also package license. This would allow users to search for all pdf packages distributed under GPL using "pacman -Ss"
But who needs a child proof for free software devotees, like in this scenario:
"I have to install a viewer for this proprietary PDF files. Lets try Adobes Acrobat Reader"
# pacman -S acroread do :: you agree to accept Adobes Non Free Software License [Y/N]
User: "WTF! Adobe did not release Adobes Acrobat Reader as GPL? Thank god pacman saved me from installing non-free software".
Jürgen
Sadly, there are people out there who really do think like this. They're like RMS fan boys and will only install software that is GPL or BSD licensed. I think people are more afraid of pulling in non-free dependencies though. Some people are really anal that way. I think I agree with Paul though. Let them have the feature, but let them write it. Jason
Sadly, there are people out there who really do think like this. They're like RMS fan boys and will only install software that is GPL or BSD licensed.
Not sure why you seem to be speaking derogatorily about people who have strong feelings about which software they choose to use.
I think people are more afraid of pulling in non-free dependencies though. Some people are really anal that way.
Again. Why the derogatory edge?
On Thu, Jul 12, 2007 at 02:09:59PM -0700, eliott wrote:
Sadly, there are people out there who really do think like this. They're like RMS fan boys and will only install software that is GPL or BSD licensed.
Not sure why you seem to be speaking derogatorily about people who have strong feelings about which software they choose to use.
I suppose I didn't have to have an edge. I just disagree with the sentiment. To whom shall I apologize? Jason
On Thu, Jul 12, 2007 at 02:18:22PM -0700, Jason Chu wrote:
On Thu, Jul 12, 2007 at 02:09:59PM -0700, eliott wrote:
Sadly, there are people out there who really do think like this. They're like RMS fan boys and will only install software that is GPL or BSD licensed.
Not sure why you seem to be speaking derogatorily about people who have strong feelings about which software they choose to use.
I suppose I didn't have to have an edge. I just disagree with the sentiment.
To whom shall I apologize?
I think you have to pray to RMS three times a day and send him a rainbow colored gnu/pony. That should do for an apology. -S
On Thu, Jul 12, 2007 at 02:05:42PM -0700, Jason Chu wrote:
I think I agree with Paul though. Let them have the feature, but let them write it.
I agree as well. Why waste time yapping about it, if it's an issue to someone, let's see a patch. -S
On Thu, 2007-07-12 at 14:05 -0700, Jason Chu wrote:
Sadly, there are people out there who really do think like this. They're like RMS fan boys and will only install software that is GPL or BSD licensed.
I think people are more afraid of pulling in non-free dependencies though. Some people are really anal that way.
I refuse to support any software that doesn't come with source. Why? you would ask... Everytime we get bugreports about crashing X servers or locking kernels, it's those damn nvidia or ati modules which are non-free. Nvidia and ATI don't seem to do anything about it, the only option you have is to up or downgrade packages. We can't debug it, but we get the bugreports. It's not the first time an xorg release was pushed back because of these shitty modules (Xorg 7.1, anyone? it happens with xorg-server 1.3.0 again now) Then another thing. Some things have distribution restrictions. We're telling all the time that we can't ship it on DVD, but did you think about exporting it from FTP? That's also distributing, we're not called a linux DISTRIBUTION for nothing. These packages shouldn't even be in the repos. Then there's "ask permission for distribution" packages. So we ask permission, we get it with a bunch of exceptions, then someone forks arch, or starts a port to another architecture (archppc). We made a distribution deal, but the people who fork don't have permission to do so. Then there's also (un)official mirrors, does the distribution agreement validate on their mirror? Then we have the part where free packages can depend on non-free packages. Mplayer and xine depending on codecs, which is a binary blob without source and these DLLs are even illegal in many countries (the DLLs come from several commercial codecs without distribution license, and if they have, the license says we're not allowed to modify... guess what, these DLLs are modified to run on linux). So people who don't want these illegal codecs have to pacman -Rd it everytime and hope mplayer and xine don't break because they miss codecs that were there on compilation time. IMHO we should do something about the handling of non-free software in our distribution. If we keep doing things this way, sooner or later we'll run into legal problems.
On Thu, Jul 12, 2007 at 11:24:51PM +0200, Jan de Groot wrote:
IMHO we should do something about the handling of non-free software in our distribution. If we keep doing things this way, sooner or later we'll run into legal problems.
Thats a good point. We need to agree on something like the "The Debian Free Software Guidelines" (DFSG). Jürgen
participants (10)
-
Aaron Griffin
-
Damir Perisa
-
Dan McGee
-
eliott
-
James Rayner
-
Jan de Groot
-
Jason Chu
-
Jürgen Hötzel
-
Paul Mattal
-
Simo Leone