On Sun, 12 Apr 2015 16:25:04 +0200
Lukas Fleischer wrote:
> On Sun, 12 Apr 2015 at 01:47:10, Johannes Löthberg wrote:
> > [...]
> > To mitigate this I’d propose making a ToS for the AUR that for one says
> > that the user agrees to either license the PKGBUILD and accompanying
> > scripts under
On Mon 13 Apr 2015 12:46 -0230, David Manouchehri wrote:
> > I like this idea, but I don't think it's sound to consider something
> > GPL-licensed because the author checked a box or accepted the TOC. I doubt
> > that has any legal significance.
>
> I agree that accepting a one time ToS agreement
On 12/04/15 16:25, Lukas Fleischer wrote:
I like this idea. GPL3 is probably the best choice, given that we
already use the GPL for most projects.
Many PKGBUILDs won't even pass the threshold of originality (ie. not
copyrightable = Public Domain). And for patches, forcing (or encouraging)
a GPL
Besides GNOME handles extension the same way. The creater/maintainer just
ticks a box which states "I verify that my extension can be distributed
under the terms of the GPLv2+ ". Furthermore many big companies treat their
agreements similar. Accepting a license by a click of a button should be
fine
> I like this idea, but I don't think it's sound to consider something
> GPL-licensed because the author checked a box or accepted the TOC. I doubt
> that has any legal significance.
I agree that accepting a one time ToS agreement is hardly binding. That's
why I suggested printing out a message wi
If everything in the git-repo would be GPL licensed than forking should be
no problem since we could just place one copy in the main tree.
Nevertheless you idea is worth considering but it might be problematic
because this header must be in every patch, install-script etc.
On Mon, Apr 13, 2015 at
I like this idea, but I don't think it's sound to consider something
GPL-licensed because the author checked a box or accepted the TOC. I doubt
that has any legal significance.
Wouldn't it make more sense to use a mandatory two-line header like below?
The pre-receive hook could enforce that.
# Co
Lukas Fleischer wrote:
> In order to `git push` a package repository, you need to add your SSH
> public key to the AUR profile which means you need to log into the web
> interface and accept the ToS. No need for something complicated
> involving Git hooks and email address filters.
You're right,
I would approach similiar how Lukas has already explained:
In order to `git push` a package repository, you need to add your SSH
> public key to the AUR profile which means you need to log into the web
> interface and accept the ToS. No need for something complicated
involving Git hooks and email
On 13/04, Dan McGee wrote:
Alas I am not. For one, actually look at your second link where it says that
there are 3 server-side hooks and note how none of them are pre-commit.
He mentioned "and many more"; you're gravitating toward pre-commit.
I'm guessing no one here thinks you will be able to
On Mon, Apr 13, 2015 at 8:42 AM, Johannes Löthberg
wrote:
> On 13/04, Dan McGee wrote:
>>
>> On Mon, Apr 13, 2015 at 8:28 AM, Johannes Löthberg
>> wrote:
>>>
>>> On 13/04, Gordian Edenhofer wrote:
Git has a pre-commit hook which is triggered prior to a commit and
many more. Re
Sorry, the hook is probably called pre-receive not pre-commit. However
the procdeure stays more or less the same.
Github for examples reminds users if they push to a deprecated url,
which still works but was moved.
On Mon, Apr 13, 2015 at 3:42 PM, Johannes Löthberg
wrote:
> On 13/04, Dan McGee wr
On Mon, Apr 13, 2015 at 8:28 AM, Johannes Löthberg
wrote:
> On 13/04, Gordian Edenhofer wrote:
>>
>> Git has a pre-commit hook which is triggered prior to a commit and
>> many more. Read
>> https://www.kernel.org/pub/software/scm/git/docs/githooks.html for
>> more detail.
>>
>
> I'm aware of how g
On 13/04, Dan McGee wrote:
On Mon, Apr 13, 2015 at 8:28 AM, Johannes Löthberg
wrote:
On 13/04, Gordian Edenhofer wrote:
Git has a pre-commit hook which is triggered prior to a commit and
many more. Read
https://www.kernel.org/pub/software/scm/git/docs/githooks.html for
more detail.
I'm awa
On 13/04, Gordian Edenhofer wrote:
Git has a pre-commit hook which is triggered prior to a commit and
many more. Read
https://www.kernel.org/pub/software/scm/git/docs/githooks.html for
more detail.
I'm aware of how git’s hooks work. You do not seem to though. Git is a
DVCS, unlike SVN. You ca
Git has a pre-commit hook which is triggered prior to a commit and
many more. Read
https://www.kernel.org/pub/software/scm/git/docs/githooks.html for
more detail.
On Mon, Apr 13, 2015 at 2:57 PM, Johannes Löthberg
wrote:
> On 13/04, David Manouchehri wrote:
>>
>> A Git pre-commit hook on the serv
On 13/04, David Manouchehri wrote:
A Git pre-commit hook on the server side should be fine.
This is Git, not SVN.
--
Sincerely,
Johannes Löthberg
PGP Key ID: 0x50FB9B273A9D0BB5
https://theos.kyriasis.com/~kyrias/
signature.asc
Description: PGP signature
On Mon, 13 Apr 2015 at 14:26:08, David Manouchehri wrote:
> > Showing it during a push would be flawed because then it's too late for
> them not to agree to it.
>
> A Git pre-commit hook on the server side should be fine. On the web side of
> the AUR, a list of accepted ToS users should be kept, a
> Showing it during a push would be flawed because then it's too late for
them not to agree to it.
A Git pre-commit hook on the server side should be fine. On the web side of
the AUR, a list of accepted ToS users should be kept, and then on every
push check to see if they've been added. Reminding
19 matches
Mail list logo
