Re: [gentoo-dev] RFC: License problem

[Richard Yao]

On 03/21/12 11:14, Justin wrote:
> On 21.03.2012 15:48, Ian Stakenvicius wrote:
>> On 21/03/12 10:34 AM, Richard Yao wrote:
>>> On 03/21/12 10:18, Justin wrote:
 I will not extract part of the software, e.g. subroutines, for
 use in other contexts without permission of the author.
>>
>>> Portage could be considered to be one of these contexts.
>>
>>
>> If the entire package is installed (ie, it's not broken up into
>> separate libraries or sub-packages) this would be fine (ie having the
>> package in portage), wouldn't it?
>>
>> I guess the primary restriction here would be that nothing else would
>> be allowed to link against any embedded libraries; ie, the package
>> couldn't be a dep.
>>
> 
> It simply creates one binary which I am interested in. I don't see any
> problem if I use fetch restriction. The only remaining question would be
> the actual LICENSE?
> 
> justin
> 
> 
> 

Portage is a dramatic advance over the older model of distributing
tarballs that are then extracted by hand and it is something that the
author could both have failed to realize possible and also consider to
be a different context.

This is a possible ambiguity that I could see being exploited in a legal
setting, although I admit that it is incredibly unlikely that anyone
would to bother. One would have to be incredibly dense to consider
portage to be a separate context, although I could imagine lawyers and
judges considering it to be such.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: License problem

[Marc Schiffbauer]

* Justin schrieb am 21.03.12 um 16:14 Uhr:
> On 21.03.2012 15:48, Ian Stakenvicius wrote:
> > On 21/03/12 10:34 AM, Richard Yao wrote:
> >> On 03/21/12 10:18, Justin wrote:
> >>> I will not extract part of the software, e.g. subroutines, for
> >>> use in other contexts without permission of the author.
> > 
> >> Portage could be considered to be one of these contexts.
> > 
> > 
> > If the entire package is installed (ie, it's not broken up into
> > separate libraries or sub-packages) this would be fine (ie having the
> > package in portage), wouldn't it?
> > 
> > I guess the primary restriction here would be that nothing else would
> > be allowed to link against any embedded libraries; ie, the package
> > couldn't be a dep.
> > 
> 
> It simply creates one binary which I am interested in. I don't see any
> problem if I use fetch restriction. The only remaining question would be
> the actual LICENSE?

How about asking the authors? Maybe they are fine with mirroring too
if updates they publish will be mirrored too.

If you get the permission to do it, it might be fine.

-Marc
Disclaimer: IANAL

-- 
0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


pgpojGSSDhbuW.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: License problem

[Paweł Hajdan, Jr.]

On 3/21/12 3:18 PM, Justin wrote:
> http://fizz.cmp.uea.ac.uk/dyndom/dyndomDownload.do

Have you suggested the authors to use a more standard license? A good
article about that (and more) is


That could also address possible interpretation questions.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: License problem

[Chí-Thanh Christopher Nguyễn]

Justin schrieb:
> Hi,
>
> I need some comments on following License Agreement:
>
> http://fizz.cmp.uea.ac.uk/dyndom/dyndomDownload.do
>
> QUOTE
>
> In downloading this code you agree with the following:

This would maybe warrant fetch restriction or inclusion of the license
in the EULA group, as agreement to the license is necessary before the
user can even download the package.

> I will not redistribute the software to others outside of my immediate
> research group. I will suggest to other interested research groups to
> contact the authors directly.

RESTRICT="bindist mirror" should shield us from any claims of wrongdoing
here.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: License problem

[Rich Freeman]

On Wed, Mar 21, 2012 at 10:34 AM, Richard Yao  wrote:
> On 03/21/12 10:18, Justin wrote:
>> I will not extract part of the software, e.g. subroutines, for use in
>> other contexts without permission of the author.
>
> Portage could be considered to be one of these contexts.

Unless portage is just installing a small part of the application then
I don't really see an issue here.  If we keep it as a whole I don't
see the issue.

The first clause really suggests that we need RESTRICT=mirror.  I
don't see any clear need for RESTRICT=fetch.

Obviously the license needs to go into the tree/etc.

Rich

Re: [gentoo-dev] RFC: License problem

[Justin]

On 21.03.2012 15:48, Ian Stakenvicius wrote:
> On 21/03/12 10:34 AM, Richard Yao wrote:
>> On 03/21/12 10:18, Justin wrote:
>>> I will not extract part of the software, e.g. subroutines, for
>>> use in other contexts without permission of the author.
> 
>> Portage could be considered to be one of these contexts.
> 
> 
> If the entire package is installed (ie, it's not broken up into
> separate libraries or sub-packages) this would be fine (ie having the
> package in portage), wouldn't it?
> 
> I guess the primary restriction here would be that nothing else would
> be allowed to link against any embedded libraries; ie, the package
> couldn't be a dep.
> 

It simply creates one binary which I am interested in. I don't see any
problem if I use fetch restriction. The only remaining question would be
the actual LICENSE?

justin





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: License problem

[Alexandre Rostovtsev]

On Wed, 2012-03-21 at 15:18 +0100, Justin wrote:
> Hi,
>
> I need some comments on following License Agreement:
>
> http://fizz.cmp.uea.ac.uk/dyndom/dyndomDownload.do
>
> QUOTE
>
> In downloading this code you agree with the following:
>
> I will not redistribute the software to others outside of my immediate
> research group. I will suggest to other interested research groups to
> contact the authors directly.

RESTRICT="bindist fetch"

pkg_nofetch() {
einfo "Please download ${MY_P}.tar.gz from"
einfo "http://fizz.cmp.uea.ac.uk/dyndom/dyndomDownload.do";
einfo "and move it to ${DISTDIR} if you agree with"
einfo "the DynDom download license agreement."
}

> I will not alter or suppress the run-time copyright message.
>
> I will acknowledge the program authors on any publication of scientific
> results based in part on use of the program and cite the article in
> which the program was described.
>
> I will report evidence of program bugs to the author.

The author should be added to maintainers in metadata.xml so that he
is added to the CC list for any bugs.

> I will not extract part of the software, e.g. subroutines, for use in
> other contexts without permission of the author.

Avoid distributing patches that show greater-than-fair-use amount of
upstream code.

> /QUOTE
>
> The source file do not contain any further license statements.
>
> Thanks justin
>

Re: [gentoo-dev] RFC: License problem

[Richard Yao]

On 03/21/12 10:48, Ian Stakenvicius wrote:
> On 21/03/12 10:34 AM, Richard Yao wrote:
>> On 03/21/12 10:18, Justin wrote:
>>> I will not extract part of the software, e.g. subroutines, for
>>> use in other contexts without permission of the author.
> 
>> Portage could be considered to be one of these contexts.
> 
> 
> If the entire package is installed (ie, it's not broken up into
> separate libraries or sub-packages) this would be fine (ie having the
> package in portage), wouldn't it?
> 
> I guess the primary restriction here would be that nothing else would
> be allowed to link against any embedded libraries; ie, the package
> couldn't be a dep.
> 
> 

It could also include applying patches.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: License problem

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/03/12 10:34 AM, Richard Yao wrote:
> On 03/21/12 10:18, Justin wrote:
>> I will not extract part of the software, e.g. subroutines, for
>> use in other contexts without permission of the author.
> 
> Portage could be considered to be one of these contexts.
> 

If the entire package is installed (ie, it's not broken up into
separate libraries or sub-packages) this would be fine (ie having the
package in portage), wouldn't it?

I guess the primary restriction here would be that nothing else would
be allowed to link against any embedded libraries; ie, the package
couldn't be a dep.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9p6ksACgkQAJxUfCtlWe0IugEAmsr4z1EunK61OPu6d17hK551
zFI7KaSUPT4EtXnZxboBAIBnPFlybqvfjJ/qj1Xwftf+IR8lzdkkIhWrF9BulNLQ
=wtVz
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: License problem

[Richard Yao]

On 03/21/12 10:18, Justin wrote:
> I will not extract part of the software, e.g. subroutines, for use in
> other contexts without permission of the author.

Portage could be considered to be one of these contexts.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: License problem

[Kent Fredric]

On 22 March 2012 03:18, Justin  wrote:
> Hi,
>
> I need some comments on following License Agreement:
>
> http://fizz.cmp.uea.ac.uk/dyndom/dyndomDownload.do
>
> QUOTE
>
> In downloading this code you agree with the following:
>
> I will not redistribute the software to others outside of my immediate
> research group. I will suggest to other interested research groups to
> contact the authors directly.
>

I'd translate that as "Gentoo can't distribute this, and *definately*
not distribute a copy of this via gentoo's mirrors"


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

[gentoo-dev] RFC: License problem

[Justin]

Hi,

I need some comments on following License Agreement:

http://fizz.cmp.uea.ac.uk/dyndom/dyndomDownload.do

QUOTE

In downloading this code you agree with the following:

I will not redistribute the software to others outside of my immediate
research group. I will suggest to other interested research groups to
contact the authors directly.

I will not alter or suppress the run-time copyright message.

I will acknowledge the program authors on any publication of scientific
results based in part on use of the program and cite the article in
which the program was described.

I will report evidence of program bugs to the author.

I will not extract part of the software, e.g. subroutines, for use in
other contexts without permission of the author.

/QUOTE

The source file do not contain any further license statements.

Thanks justin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs due www-server herd removal

[Anthony G. Basile]

On 03/21/2012 07:26 AM, Pacho Ramos wrote:


www-servers/thttpd



I can take care of this one

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535

Re: [gentoo-dev] Packages up for grabs due www-server herd removal

[Alex Alexander]

On Wed, Mar 21, 2012 at 12:26:12PM +0100, Pacho Ramos wrote:
> As discussed in "[gentoo-dev] www-servers herd is empty" thread,
> we agreed with dropping this herd and let people get what they want
> to maintain. This is the list of orphan packages:
...
> www-servers/lighttpd

This is not an orphan :)

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

[gentoo-dev] Re: Packages up for grabs due www-server herd removal

[Pacho Ramos]

El mié, 21-03-2012 a las 12:28 +0100, Pacho Ramos escribió:
> El mié, 21-03-2012 a las 12:26 +0100, Pacho Ramos escribió:
> > As discussed in "[gentoo-dev] www-servers herd is empty" thread,
> > we agreed with dropping this herd and let people get what they want
> > to maintain. This is the list of orphan packages:
> [...]
> > www-servers/bozohttpd
> [...]
> 
> This is a false positive: it already has a maintainer

The same for:
www-servers/lighttpd
www-servers/pshs


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Packages up for grabs due www-server herd removal

[Patrick Lauer]

On 03/21/12 19:26, Pacho Ramos wrote:
> As discussed in "[gentoo-dev] www-servers herd is empty" thread,
> we agreed with dropping this herd and let people get what they want
> to maintain. This is the list of orphan packages:

> www-servers/pound

> www-servers/varnish

I'm a gonna take those two if no one else wants them ...

[gentoo-dev] Re: Packages up for grabs due www-server herd removal

[Pacho Ramos]

El mié, 21-03-2012 a las 12:26 +0100, Pacho Ramos escribió:
> As discussed in "[gentoo-dev] www-servers herd is empty" thread,
> we agreed with dropping this herd and let people get what they want
> to maintain. This is the list of orphan packages:
[...]
> www-servers/bozohttpd
[...]

This is a false positive: it already has a maintainer


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Packages up for grabs due www-server herd removal

[Pacho Ramos]

As discussed in "[gentoo-dev] www-servers herd is empty" thread,
we agreed with dropping this herd and let people get what they want
to maintain. This is the list of orphan packages:
www-servers/boa
www-servers/bozohttpd
www-servers/cherokee
www-servers/fnord
www-servers/lighttpd
www-servers/mini_httpd
www-servers/monkeyd
www-servers/pound
www-servers/pshs
www-servers/publicfile
www-servers/spawn-fcgi
www-servers/thttpd
www-servers/varnish
www-servers/webfs



Thanks for taking them








signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] www-servers herd is empty

[Dirkjan Ochtman]

On Tue, Mar 20, 2012 at 10:47, Pacho Ramos  wrote:
>> I find the whole concept of www-servers herd flawed.
>> It's not very likely one person would be running many different servers,
>> and thus be able to contribute to them.
>>
>> Propably why the team has no members in the first place...
>
> Then, the way to go would be to move them to maintainer-needed and let
> people pick whatever they want. I agree and can do it myself just now if
> you let me do

Seems sensible.

Cheers,

Dirkjan

Re: [gentoo-dev] www-servers herd is empty

[Ultrabug]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/03/2012 10:47, Pacho Ramos wrote:
> El mar, 20-03-2012 a las 11:40 +0200, Samuli Suominen escribió:
>> On 03/20/2012 11:36 AM, Pacho Ramos wrote:
>>> El lun, 19-03-2012 a las 20:48 +, Markos Chandras
>>> escribió:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 On 03/19/2012 08:32 AM, Pacho Ramos wrote:
> El dom, 18-03-2012 a las 20:29 -0400, Chris Reffett
> escribió:
>> Hi, I'd be interested in helping with www-servers, but I
>> would have to help by proxy because I am not a dev yet.
>> Chris Reffett
>> 
>> On 03/18/12 15:27, Pacho Ramos wrote:
>>> With bass retirement (#391429) lcd has become empty, is
>>> anybody willing to join or should their packages be
>>> moved to maintainer-needed (CCing that empty herd to
>>> allow somebody joining in the future to easily
>>> resurrect the herd)?
>>> 
>>> Thanks
>>> 
> 
> Thanks for offering your help, will CC gentoo-dev mailing
> list and proxy-maint to see how we could handle this case
> 
 It is very unlikely for proxy-maintainers to proxy an entire
 herd. Sorry
 
 - -- Regards, Markos Chandras / Gentoo Linux Developer / Key
 ID: B4AFF2C2
>>> 
>>> We need to try to find a way to let him contribute, the problem
>>> is that I don't know much about Chris to know if he is ready to
>>> try to become a gentoo-dev in the near future :S
>> 
>> I find the whole concept of www-servers herd flawed. It's not
>> very likely one person would be running many different servers, 
>> and thus be able to contribute to them.
>> 

That's my case tbh, I co-maintain a www-servers package but don't feel
like being able to maintain the whole of them as I just don't use them
all.

>> Propably why the team has no members in the first place...
>> 
>> 
> 
> Then, the way to go would be to move them to maintainer-needed and
> let people pick whatever they want. I agree and can do it myself
> just now if you let me do

I think that's a good idea and reasonable way to go.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9pje8ACgkQKiQSS7ZY+hP2cAD/Wix5cEM6YuFMu4V/l3sTZTci
eBHwWjKVBHTb1+G/HmsA/3HPgxNSesEedPWLxgQ0f7Rk1W2QZTq2S99WVdIPNeyq
=lrz9
-END PGP SIGNATURE-