On the side of the person needing to comply, one need only make sure the
source code is carefully published. On the side of the person wishing to
access the source code, the only alternative is to turn on logging or use a
hacked client. I don't think it would be permissible to emit no notice
regard
On Tue, 24 Sep 2019, 13:50 Florian Weimer, wrote
> My impression is that AGPL has gained a reputation of a GPL version
> that enables “open core” business models, and this is why most people
> choose it. The FUD it creates for non-networked AGPL code appears to
> be a welcome side effect, one th
On Tue, Sep 24, 2019 at 11:34 AM Florian Weimer wrote:
> My impression is that AGPL has gained a reputation of a GPL version
> that enables “open core” business models, and this is why most people
> choose it. The FUD it creates for non-networked AGPL code appears to
> be a welcome side effect,
* Howard Chu:
> That sounds like a fair summary, yes. Also, simply adding a
> non-standard extension to our server to meet this license
> requirement doesn't solve anything, if all LDAP clients aren't also
> modified to recognize the extension, and that in particular seems an
> unrealistic task.
* Howard Chu:
> Clause #10 of the definition https://opensource.org/docs/osd
>
> 10. License Must Be Technology-Neutral
>
> No provision of the license may be predicated on any individual
> technology or style of interface.
>
> I note that the Affero GPL
> https://www.gnu.org/licenses/agpl-3.0.en.
In my previous job we had a similar discussion related to software
which provides connectivity to clients using SIP (Session Initiation
Protocol). Even though it would be possible to provide an indication
of the AGPL license and URL to obtain the source code during SIP
session negotiation, no SIP c
On 8/14/2019 1:41 PM, Howard Chu wrote:
Richard Fontana wrote:
The precise question here seems to be whether the server operator can
be said to be "prominently offer[ing]" the opportunity to receive the
source code in this sort of case (the hypothetical where existing LDAP
clients cannot recogni
No argument that the AGPL approach is awkward - both for non-GUI software
and also for a non-network library like BerkeleyDB. Then we get to the
question what if a user interacts with AGPL LDAP server through a non-AGPL
proxy?
To fulfill the letter of the requirement though, wouldn't it be possibl
Bruce Perens via License-discuss wrote:
> OpenLDAP does not provide an interactive user interface, so that provision of
> AGPL does not apply to it. It provides an interface meant to work only with
> programs, rather than a human being. In contrast, the first generation of
> internet servers wh
OpenLDAP does not provide an interactive user interface, so that provision
of AGPL does not apply to it. It provides an interface meant to work only
with programs, rather than a human being. In contrast, the first
generation of internet servers where intended to respond to connection from
the tel
Richard Fontana wrote:
> The precise question here seems to be whether the server operator can
> be said to be "prominently offer[ing]" the opportunity to receive the
> source code in this sort of case (the hypothetical where existing LDAP
> clients cannot recognize the extension). To the extent th
Richard Fontana wrote:
> On Wed, Aug 14, 2019 at 11:08 AM Howard Chu wrote:
>>
>> Richard Fontana wrote:
>>> On Wed, Aug 14, 2019 at 10:25 AM Howard Chu wrote:
>>> I think what you're saying is that, assuming your interpretation of
>>> AGPL (including but not limited to section 13) is correc
On Wed, Aug 14, 2019 at 11:08 AM Howard Chu wrote:
>
> Richard Fontana wrote:
> > On Wed, Aug 14, 2019 at 10:25 AM Howard Chu wrote:
> >>
> > I think what you're saying is that, assuming your interpretation of
> > AGPL (including but not limited to section 13) is correct, a would-be
> > LDAP impl
>>-Original Message-
>>From: License-discuss [mailto:license-discuss-boun...@lists.opensource.org]
>>On Behalf Of Howard Chu
>>Sent: Wednesday, August 14, 2019 8:09 AM
>>To: Richard Fontana
>>Cc: license-discuss@lists.opensource.org
>>Subject:
>>-Original Message-
>>From: License-discuss [mailto:license-discuss-boun...@lists.opensource.org]
>>On Behalf Of Richard Fontana
>>Sent: Wednesday, August 14, 2019 9:02 AM
>>To: license-discuss@lists.opensource.org
>>Subject: Re: [License-discu
On Wed, Aug 14, 2019 at 11:51 AM Smith, McCoy wrote:
> Interestingly, I didn’t see AGPLv3 in any of the License Committee reports of
> that era. And I couldn’t see, through the Wayback Machine, that AGPLv1 ever
> got on the OSI list (although I haven’t done a comprehensive search of those
> a
-discuss] Discussion: AGPL and Open Source Definition
conflict
I would also like to see some documentation of the thinking that went into
OSI's approval of the AGPL, to better understand the precedent that they were
setting (or even if the precedent setting nature of this approval was
under
Richard Fontana wrote:
> On Wed, Aug 14, 2019 at 10:25 AM Howard Chu wrote:
>>
>> Richard Fontana wrote:
>>> On Wed, Aug 14, 2019 at 9:27 AM Howard Chu wrote:
Clause #10 of the definition https://opensource.org/docs/osd
10. License Must Be Technology-Neutral
No provi
On Wed, Aug 14, 2019 at 10:25 AM Howard Chu wrote:
>
> Richard Fontana wrote:
> > On Wed, Aug 14, 2019 at 9:27 AM Howard Chu wrote:
> >>
> >> Clause #10 of the definition https://opensource.org/docs/osd
> >>
> >> 10. License Must Be Technology-Neutral
> >>
> >> No provision of the license may be
Since we're piling into the AGPL, I think it's instructive in the dangers
of "upgrade clauses." Clause 13 of the GPLv3 allows for linking AGPL, GPL
and (transitively) LGPL code. This allows AGPL developers to freeload on
GPL code without contributing back to the commons.
Brendan
On Wed, Aug 14, 2
Richard Fontana wrote:
> On Wed, Aug 14, 2019 at 9:27 AM Howard Chu wrote:
>>
>> Clause #10 of the definition https://opensource.org/docs/osd
>>
>> 10. License Must Be Technology-Neutral
>>
>> No provision of the license may be predicated on any individual technology
>> or style of interface.
>>
I would also like to see some documentation of the thinking that went into
OSI's approval of the AGPL, to better understand the precedent that they
were setting (or even if the precedent setting nature of this approval was
understood). While it is obvious that there is a serious conflict in the
ca
On Wed, Aug 14, 2019 at 9:27 AM Howard Chu wrote:
>
> Clause #10 of the definition https://opensource.org/docs/osd
>
> 10. License Must Be Technology-Neutral
>
> No provision of the license may be predicated on any individual technology or
> style of interface.
>
> I note that the Affero GPL http
Clause #10 of the definition https://opensource.org/docs/osd
10. License Must Be Technology-Neutral
No provision of the license may be predicated on any individual technology or
style of interface.
I note that the Affero GPL https://www.gnu.org/licenses/agpl-3.0.en.html clause
#13
13. Remote
24 matches
Mail list logo
