On Sat, Feb 5, 2011 at 12:05 PM, Lukas Fleischer wrote:

...

Greg, You have a valid point, personally I have always asked the

On Sat, Feb 05, 2011 at 11:45:20AM -0700, Thomas S Hatch wrote: maintainer

...

of a package for objections before moving a package into community. I also want to continue to express my deep gratitude for the packagers who contribute to the AUR. They are really the frontline in Arch development, the blood on the knife's edge.

We as trusted users need to show the devs in the AUR the utmost respect and appreciation. I would also like to point out: https://wiki.archlinux.org/index.php/TU_Person_Specification All TUs we should adhere to the first bullet under "At Least" on this wiki entry.

I hope that my fellow TUs agree that we should give AUR contributors the utmost respect, they deserve it.

A behavior of respect will help us, the TUs, improve Arch, it will allow us to bring more people onto the Arch development teams, and continue our march to making Arch greater.

I personally asked for objections using AUR comments in most cases and waited some days before moving stuff. Nevertheless, I don't see a huge problem with just moving stuff. Moving a package to the binary repos shouldn't be regarded as stealing but as an improvement for the community. The AUR ain't a place for competitions (like "Which package has the most votes?" or "Who maintains the coolest packages?") but a place to provide source packages until a TU/Dev steps up and maintains the package in [community]/[extra]/[core].

Still, I'd prefer to have some announcement before moving a package. And another one just before removing it (so that users being notified about a package become aware of the move). AUR comments seem to be the appropriate place for this.

Angel has many good and valid points, I am proud of my contributions to open source and to Arch. My willingness to give without the expectation of receiving anything back has given me, personally, much more than I could have expected. Also it is true, that what you submit to the AUR, Arch reserves rights to. But these points should not reduce the fact that a person contributed the package, and even when I have had to completely rewrite a PKGBUILD before moving the package to community I still think that it is important to recognize the maintainer who paved the road. I am going to maintain, that a TU is not to be required to contact the AUR maintainer, but it is the courteous thing to do, and that we should develop and maintain an atmosphere of respect. To reiterate Lukas, notifications should ALWAYS be placed before deleting AUR packages and moving AUR packages to community. Thats how I would draw the line, posting the comments about moves and deletions should be mandatory, and contacting the maintainer should be a strongly encouraged courtesy. -Thomas S Hatch

On Sat, Feb 5, 2011 at 1:13 PM, Thomas S Hatch wrote:

On Sat, Feb 5, 2011 at 12:05 PM, Lukas Fleischer wrote:

...

...

Greg, You have a valid point, personally I have always asked the

On Sat, Feb 05, 2011 at 11:45:20AM -0700, Thomas S Hatch wrote: maintainer

...

of a package for objections before moving a package into community. I also want to continue to express my deep gratitude for the packagers who contribute to the AUR. They are really the frontline in Arch development, the blood on the knife's edge.

We as trusted users need to show the devs in the AUR the utmost respect and appreciation. I would also like to point out: https://wiki.archlinux.org/index.php/TU_Person_Specification All TUs we should adhere to the first bullet under "At Least" on this wiki entry.

I hope that my fellow TUs agree that we should give AUR contributors the utmost respect, they deserve it.

A behavior of respect will help us, the TUs, improve Arch, it will allow us to bring more people onto the Arch development teams, and continue our march to making Arch greater.

I personally asked for objections using AUR comments in most cases and waited some days before moving stuff. Nevertheless, I don't see a huge problem with just moving stuff. Moving a package to the binary repos shouldn't be regarded as stealing but as an improvement for the community. The AUR ain't a place for competitions (like "Which package has the most votes?" or "Who maintains the coolest packages?") but a place to provide source packages until a TU/Dev steps up and maintains the package in [community]/[extra]/[core].

Still, I'd prefer to have some announcement before moving a package. And another one just before removing it (so that users being notified about a package become aware of the move). AUR comments seem to be the appropriate place for this.

Angel has many good and valid points, I am proud of my contributions to open source and to Arch. My willingness to give without the expectation of receiving anything back has given me, personally, much more than I could have expected. Also it is true, that what you submit to the AUR, Arch reserves rights to.

But these points should not reduce the fact that a person contributed the package, and even when I have had to completely rewrite a PKGBUILD before moving the package to community I still think that it is important to recognize the maintainer who paved the road.

I am going to maintain, that a TU is not to be required to contact the AUR maintainer, but it is the courteous thing to do, and that we should develop and maintain an atmosphere of respect.

To reiterate Lukas, notifications should ALWAYS be placed before deleting AUR packages and moving AUR packages to community. Thats how I would draw the line, posting the comments about moves and deletions should be mandatory, and contacting the maintainer should be a strongly encouraged courtesy.

-Thomas  S Hatch

I agree. Even if the packages are part of archlinux, the courteous thing to do would be to send an email before moving the packages to see if the original maintainer is onboard with it. Though he may not own it, he does have a sense of authorship, and that needs to be taken into account. We're still dealing with people here :) -Thomas

Le 5 février 2011 13:45:20, Thomas S Hatch a écrit :

On Sat, Feb 5, 2011 at 11:31 AM, Gergely Imreh wrote:

...

Hi,

Recently a couple of my packages have been moved to Community but the process feels a little uneasy to me.

My impression is that AUR is treated as a "second class" source of packages compared to the official repos. Not surprising, of course, so many packages have problems. This is also underlined by the fact that yaourt and other AUR managers are not allowed in the official repos, as "not to give the impression that AUR is official" (paraphrasing what I've read before).

If there is indeed this divide, it feels more than little weird, that popular packages are just taken in to Community without even asking the current managers. It gives me the message that "AUR has no value, except when we say it has, at which time thanks for your work but now bugger off". I beg your pardon, if it comes through too harsh. I wouldn't have objected to have those packages moved. I, however, object to unilateral decisions.

My proposition is: could it be a policy to check with the maintainer first before initiating a move? If someone wants to keep a package then they should be able to, especially since they could not have been doing such a a bad job if their package has become popular.

Cheers,

Greg

Greg, You have a valid point, personally I have always asked the maintainer of a package for objections before moving a package into community. I also want to continue to express my deep gratitude for the packagers who contribute to the AUR. They are really the frontline in Arch development, the blood on the knife's edge.

We as trusted users need to show the devs in the AUR the utmost respect and appreciation. I would also like to point out: https://wiki.archlinux.org/index.php/TU_Person_Specification All TUs we should adhere to the first bullet under "At Least" on this wiki entry.

I hope that my fellow TUs agree that we should give AUR contributors the utmost respect, they deserve it.

A behavior of respect will help us, the TUs, improve Arch, it will allow us to bring more people onto the Arch development teams, and continue our march to making Arch greater.

-Thomas S Hatch -Arch Linux Trusted User

It is important to recognize the work done by the AUR contributor. Also we should not forget that TUs and Jr Devs are frequently selected among them. I can give a personal example. I was contacted by Thomas Dziedzic some weeks after being accepted as a Jr dev. He asked me if he could add the openmpi package into [community]. My nomination was not well known at that time. This mail gives me the possibility to tell him that I wanted to continue to maintain it and that I planned to add it to [community] later. I maintain it in [community] now. I really appreciated that he asked me instead of just taking the package. Stéphane

2011/2/6 Ángel Velásquez :

2011/2/5 Gergely Imreh :

...

Hi,

Recently a couple of my packages have been moved to Community but the process feels a little uneasy to me.

First of all remove that "my" before packages, that's a problem, some maintainers thinks that they're owners of the PKGBUILD, and isn't like this, all PKGBUILDS belongs to the Arch Linux project, and you contribute with them if you want, isn't an obligation.

There are way too many comments to reply them all, but I do want to take an exception on this one. When I say "my", that is "packages that I have been maintaining". I'm not "owning" them, of course. There's a sense they do "belong" to someone: you don't delete or orphan a package on anyone's request until they made sufficient effort to contact the maintainer and fix any issues. The original issue I wanted to bring up: if delete/orphan needs some form of cooperation, then why moving does not?

...

My impression is that AUR is treated as a "second class" source of packages compared to the official repos. Not surprising, of course, so many packages have problems. This is also underlined by the fact that yaourt and other AUR managers are not allowed in the official repos, as "not to give the impression that AUR is official" (paraphrasing what I've read before).

Not at all, many of the packages on official repos belongs to AUR in sometime, AUR is a playground, where you can find scripts for install (PKGBUILD) experimental software.

...

If there is indeed this divide, it feels more than little weird, that popular packages are just taken in to Community without even asking the current managers. It gives me the message that "AUR has no value, except when we say it has, at which time thanks for your work but now bugger off". I beg your pardon, if it comes through too harsh. I wouldn't have objected to have those packages moved. I, however, object to unilateral decisions.

My proposition is: could it be a policy to check with the maintainer first before initiating a move? If someone wants to keep a package then they should be able to, especially since they could not have been doing such a a bad job if their package has become popular.

Absolutely no, as I said PKGBUILD doesn't belongs to anybody, just the project, if a Dev or TU take one of them and move it to any official repo is good to you, that means that the software that you were packaging by hand it will be on binary 'cause is pretty stable and not experimental at all.

I beg your pardon, but I don't think this is at all about what is "good" for me (and by "me" I mean maintainers). If it was really about the good of the maintainer, then instead of just moving, the TUs and Devs would offer continued maintaining rights in Community for the - apparently successful - care taker. I know that this is technically not feasible at the moment. I believe, though, that it would be the The Right Thing (and saying this as part of that "Arch Linux Community", whose good you want to above all), but that's for another time, I'm not pushing that agenda here at all.

I understand your point about, I'm giving my time and receive nothing, well dude, you should give without expecting anything, and you will be more happier. I also understand the point about TU/Devs didn't said anything to the PKGBUILD that you were maintaining will become a package, well, maybe a little courtesy from the TU or Dev who did this is good, but he doesn't have to ask your permission, remember you contribute with the project giving your effort on those PKGBUILD but that doesn't imply that you are owner of those PKGBUILD.

Thanks for contributing with the Arch Linux project, And I hope now you will contribute without hoping regalies or something.

I'm sorry again, but you don't seem to get it: I don't want anything more in return than what you expect from me -common courtesy. As for the comment that only very few people write back on the TUs notes of moving: I didn't either. Why? It's all settled already, what's there more to say? I don't think the number of replies have any relation to the number of people who cared. I'm very happy to contribute. I'm very happy to spend time fixing packages. I'm always checking whether there are orphan packages to fix up. I don't apply to be a TU because I never know how much time I have and don't want to do a shabby job. But this does not mean we all cannot work together. Everybody gets different thing from Arch, but it's arguably a fact that what's good for me, good for you too, and vice versa. Cheers, Greg

I have contributed a few PKGBUILDs to AUR. I do it because I enjoy it -- all I ask is for is recognition. Yes, this is an open source project and it is implicit that the work can and (hopefully) be adopted and improved. But recognition of each person who contributed should be maintained. I am not a lawyer and I generally tune out all license flame wars. That said, PKGBUILDS generally do not contain copyright or license declarations. Unless I am mistaken, that means someone who comes into possession of a PKGBUILD does not have the right to republish it. As a minimum, I think Arch should get a nod from the creator of a PKGBUILD prior to absorbing it into the colective -- It might help avoid any misunderstandings. Oh, and I would be honored to have one of my PKGBUILDs graduate to a more general release. Eric Waller

I'll just add here that I used to use moving packages to [community] as a TU recruitment ground. If the package I wanted to move to [community] was obviously well maintained, I usually offered to sponsor the maintainer to be a TU when I let them know I was going to move their package. I think there are still a couple of TUs here that got brought on that way. Allan

Le 06/02/2011 18:48, Xyne a écrit :

Eric Waller wrote:

...

I am not a lawyer and I generally tune out all license flame wars. That said, PKGBUILDS generally do not contain copyright or license declarations. Unless I am mistaken, that means someone who comes into possession of a PKGBUILD does not have the right to republish it.

As a minimum, I think Arch should get a nod from the creator of a PKGBUILD prior to absorbing it into the colective -- It might help avoid any misunderstandings. What is the legal status of files submitted to the AUR? I have always assumed that anything uploaded to the AUR is automatically licensed under the GPL or something similar, in the same way that content contributed to the wiki is.

I can't find anything that states this on the AUR site, which is a potentially calamitous legal oversight.

The legal issue should be cleared up. If we needed to obtain explicit permission from every contributor then the AUR would cease to be useful. You would not be able to adopt and update PKGBUILDs without permission, and you would need to enable users to delete their own PKGBUILDs when they decide to withdraw permission.

There is also the specific problem of patches. From developpers of another linux distribution, I heard that the empirical rule is that the patch is released under the software licence. (So, it could be used by upstream) -- François Boulogne. Membre de l'April - Promouvoir et défendre le logiciel libre http://www.april.org

On Sun, Feb 6, 2011 at 1:10 PM, Bernardo Barros wrote:

2011/2/6 Xyne :

...

What is the legal status of files submitted to the AUR? I have always assumed that anything uploaded to the AUR is automatically licensed under the GPL or something similar, in the same way that content contributed to the wiki is.

Ownership and authorship aren't the same. In the first place the GPL lisence requires the copyright notice to exist. It is actually based on authorship, the first line is a copyright notice. And there is nothing bad about it.

Anyway atributing the work is a good thing. Good people atributive the works of their friends. Of course, if you revise the code in a not superficial way you also have some authorship in that piece of code, then it's a team work.

Or... you can interpret that the buildscript are Public Domain, then Arch, TU, IBM, Apple etc., all can use it without atributing anything. But since it is only useful for Arch users in the end... it is the same thing in practice.

Realy I think that this is a simple thing, that we should just post some statement that says that anything uploaded to the AUR can be absorbed into the Arch Linux distribution. When PKGBUILDS are in the AUR I could care less who's they are, but they are Arch Linux's when they are moved to community/extra/core. So my initial thought would be that the submit page just needs to say - in effect - "Dude, we can move your package into the main distribution whenever we want to and it will be assimilated, this should be cool with you, because Arch is the best"

2011/2/6 Gaetan Bisson :

"By uploading content to the Arch User Repository, you irrevocably agree to release it in the public domain, to the extent permitted by law."

GPL would do no harm to Arch either. And pieces of code with less then 10 lines can't have any copyright. The difference in practice is minimal, since it is very unlikely that this piece of code would integrate a non-free software, even including big patches and tricky things. The pratical differente I can see is the need to keep the attribution when it makes sense. If you rewrite everything from scratch, you are the author anyway.

On 06/02/11 21:41, Gaetan Bisson wrote:

[2011-02-06 19:28:38 -0200] Bernardo Barros:

...

2011/2/6 Gaetan Bisson :

...

"By uploading content to the Arch User Repository, you irrevocably agree to release it in the public domain, to the extent permitted by law."

GPL would do no harm to Arch either. And pieces of code with less then 10 lines can't have any copyright. The difference in practice is minimal, since it is very unlikely that this piece of code would integrate a non-free software, even including big patches and tricky things.

Since there is little difference, why choose a complicated license such as the GPL over the (much simpler) public domain?

IANAL, but probably because the concept of an author releasing something to "public domain" doesn't exist in all jurisdictions. So it's arguably safer to pick a license, but I agree that the GPL might be too complicated, why not use BSD? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

On 2011-02-06 19:48 -0200 (05:7) Bernardo Barros wrote:

Yes, but since you can't change a licence (from BSD to GPL), then Apple can just download the entire Arch repository code to adapt and use in their AppStore code, for example. Very unlikely, but possible since you can use PKGBUILD on OSX.

I agree that the simpler, the better, Most PKGBUILDs are not worth copyrighting anyway. The key point is to make sure that all PKGBuILDs can be used freely by Arch. The other point is that all previously submitted PKGBUILDs are in a legal grey area if there has never been such a disclaimer. It bothers me that the project is apparently exposed to potential legal trolls, even if it is unlikely that anything will happen.

On Sun, Feb 6, 2011 at 5:36 PM, Xyne wrote:

I agree that the simpler, the better, Most PKGBUILDs are not worth copyrighting anyway. The key point is to make sure that all PKGBuILDs can be used freely by Arch.

I vote that future PKGBUILD's uploaded to the AUR simply include '# All rights relinquished' or something similar. One line to settle things once and for all. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

2011/2/7 Yaro Kasear :

Sure you can change licenses if you own (Hold copyright to.) all the relevant code involved.

That's way OT, but I'm curious now... :-). Then if I did a BSD code that a company used in their proprietary code, and then I change it to GPL, what happens then? The company will have to open their derivative code too? What I see is people releasing prior proprietary code unde GPL, but not from BSD to GPL.

On Monday, February 07, 2011 11:46:08 Bernardo Barros wrote:

2011/2/7 Yaro Kasear :

...

Sure you can change licenses if you own (Hold copyright to.) all the relevant code involved.

That's way OT, but I'm curious now... :-).

Well, it was in response to a reply in this thread a coupe days ago. It was on topic them... sort of.

Then if I did a BSD code that a company used in their proprietary code, and then I change it to GPL, what happens then? The company will have to open their derivative code too?

Well, that depends. Assuming the company made no contributions to the code that they have copyright over, from what I understand, the upstream maintainer can still relicense it and the company using it is SOL for any NEW versions of the software. But, also, from what I understand, NOTHING legally bars the company from forking the last BSD version of the code and making that proprietary as the BSD license already allows such a thing so long as copyright notices remain intact. Now, whether this would be a GOOD thing is subjective. If a lot of people counted on my code being open source, but none of them made any copyright- worthy contributions to the code and it remains 100% mine, I could go from GPL to proprietary... but it would, frankly, be absolutely scummy. But again, they could fork the last GPL'd version. From what I understand, this is part of why open source is unstoppable. A company can't just buy out an open source project, relicense it as proprietary or shut down its development, and expect it to go away. (This is why I think people are overreacting to Oracle a bit.)

What I see is people releasing prior proprietary code unde GPL, but not from BSD to GPL.

Also, I'm not an expert, but I think a bit reason this transition is rare is because the general attitude of those who use the BSD license is that they have less of a care about what happens with their code so long as they are still the upstream people in charge of it. You can make proprietary software from BSD code, and most BSD-licensing authors don't mind. But, legally, nothing stops them from MAKING it GPL later so long as it is 100% their copyright. This is likely also aggravated by the fact that it's VERY hard to make an open source project WITHOUT at least two other people putting in their own code that, yes, they do own all by themselves. Thus, Linus PRRROBABLY won't ever be able to relicense the Linux kernel, ever, as there are just way too many different copyright holders to way too many different bits of the Linux kernel. Even more "frustrating" to this is that the GPL prohibits changing to an incompatible license if other parts of the code are GPL, so Linus can change what he has copyright over in the kernel ONLY to something GPL-compatible. It's complicated, and its messy, and its far from perfect. The GPL has some wonderful bits mixed with some not-so-great bits. Demanding "compatibility" in the GPL is one of its not-so-wonderful bits. Keep in mind, this is how I have managed to interpret copyright law under the Berne Convention. You automatically have copyright on any works of your own, but if more than one person has copyright in the end, it's no longer just your decision to make decisions on the general license of the work. The great thing aout open source licenses, though, is that you don't have to worry about making changes to other people's work and sending it out to the world. However, I did point out some time ago that just because you make changes and distribute doesn't mean the upstream maintainer will approve of them and use them. This is open source, an amalgam of different skills, tastes, personalities, and ugly code (And we all do have ugly code in some way or another.).