FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-21-2012, 01:32 PM
Kent Fredric
 
Default RFC: License problem

On 22 March 2012 03:18, Justin <jlec@gentoo.org> 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 );"
 
Old 03-21-2012, 01:34 PM
Richard Yao
 
Default RFC: License problem

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.
 
Old 03-21-2012, 01:48 PM
Ian Stakenvicius
 
Default RFC: License problem

-----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)

iF4EAREIAAYFAk9p6ksACgkQAJxUfCtlWe0IugEAmsr4z1EunK 61OPu6d17hK551
zFI7KaSUPT4EtXnZxboBAIBnPFlybqvfjJ/qj1Xwftf+IR8lzdkkIhWrF9BulNLQ
=wtVz
-----END PGP SIGNATURE-----
 
Old 03-21-2012, 01:56 PM
Richard Yao
 
Default RFC: License problem

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.
 
Old 03-21-2012, 02:12 PM
Alexandre Rostovtsev
 
Default RFC: License problem

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
>
 
Old 03-21-2012, 02:14 PM
Justin
 
Default RFC: License problem

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
 
Old 03-21-2012, 02:15 PM
Rich Freeman
 
Default RFC: License problem

On Wed, Mar 21, 2012 at 10:34 AM, Richard Yao <ryao@cs.stonybrook.edu> 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
 
Old 03-21-2012, 02:32 PM
"Paweł Hajdan, Jr."
 
Default RFC: License problem

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
<http://starplot.org/articles/physics-software-rant.html>

That could also address possible interpretation questions.
 
Old 03-21-2012, 03:09 PM
Marc Schiffbauer
 
Default RFC: License problem

* 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
 
Old 03-21-2012, 03:19 PM
Richard Yao
 
Default RFC: License problem

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.
 

Thread Tools




All times are GMT. The time now is 09:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ę2007 - 2008, www.linux-archive.org