www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Couchman (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LEGAL-299) Category-X Dependency in Incubator Project
Date Tue, 18 Apr 2017 14:07:41 GMT

    [ https://issues.apache.org/jira/browse/LEGAL-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972742#comment-15972742
] 

Nick Couchman commented on LEGAL-299:
-------------------------------------

Okay, to answer Shane's questions:
{quote}
Is this extension merely a shim or small layer of coordinating code handling the generic concept
of authenticating a user within Guacamole by using one of a number of well-known authentication
standards?
{quote}
Yes, this is correct.  The Guacamole client has several different authentication modules that
interact with the client in a standard way - the client provides an abstracted authentication
interface, and the modules then implement that model.  The RADIUS module is one of five or
six different authentication modules that all interface with the client in this way.

{quote}
In terms of the rest of the functionality of Guacamole, does it change how your core functionality
works when using this extension vs. when using another well-known authentication method or
extension?
{quote}
No, it does not change the core functionality of the Guacamole client - providing a clientless
remote desktop gateway that interfaces via the Guacamole protocol with the Guacamole server.
 It simply extends the ability for authentication to be done via another protocol (in addition
to LDAP, JDBC, simple file, HTTP headers, and Duo) before users can reach the actual remote
desktop gateway.

{quote}
As Marvin notes, by policy, we don't ship code that uses Cat X related code for core or major
functionality. So we'd only consider this kind of work in an extension, and only an optional
one.
...
{quote}
I believe that this extension meets these criteria - it is optional (you can use a different
form of authentication, if you like), and it is not core or major functionality - the Guacamole
Client still operates as a clientless remote desktop gateway without this extension - it simply
provides the interface between a RADIUS server and the Guacamole client for authenticating
users in a RADIUS system.

{quote}
...
Part of the question would be: is it ever likely that contributors or developers would want
to change the extension's code itself to add notable features or not?
{quote}
I guess this depends on the definition of "notable features" :-).  I'll flesh this out a little
more...currently, the RADIUS extension only does authentication against RADIUS servers, and
only provides confirmation that a user 1) is present in the RADIUS system, and 2) has supplied
the credentials necessary for authenticating to RADIUS.  There are two scenarios that I can
think of off the top of my head where this extension would be modified.  First, RADIUS supports
accounting in additional to authentication, and it's conceivable that, at some point in the
future, a developer would decide that the ability for the extension to report accounting information
back to the RADIUS server would be a useful feature.  In fact, it's something I've considered
adding myself, just haven't had the time.

Second, the way the module stands today, you'd have to have some other authentication module
present and configured in order to actually be able to connect to anything after authenticating
via RADIUS.  The Guacamole Client "stacks" authentication modules, so that you can have multiple
ones present and configured, and have users authenticated through different modules, and connection
information provided through different modules.  The actual connections themselves are part
of the authentication modules - that is, when you configure the JDBC authentication module,
you are supplying *both* username/password authentication *and* connections and permissions
to those connections.  If a user exists in multiple modules, that account will be authenticated
through whatever module succeeds, and then connections will be pulled from all available modules.
 Today, JDBC, File, and LDAP are the modules that supply connection and permission information
(in addition to user authentication) - the HTTP Header, Duo, and RADIUS modules only supply
user authentication information and basically provide "empty" connection lists because they
do not currently support returning connection data (HTTP Header and Duo will probably never
support this).  RADIUS is a very flexible protocol, and it's, again, conceivable that in the
future someone would decide that they wanted to implement the ability for connection information
to be passed through via RADIUS packets (believe this falls into the "authorization" component
of RADIUS), so it isn't out of the realm of possibility that a developer (again, perhaps me,
if I were to get some free time) would decide to add that bit of functionality.

All that said, the two things above are really just additional implementations to the RADIUS
authentication module itself, allowing it to support the full interface that *the Guacamole
client has already defined.*  I would maintain that they do not represent significant changes
to core/major functionality of the Guacamole Client itself.

Thanks, again, for the time hashing this out!

> Category-X Dependency in Incubator Project
> ------------------------------------------
>
>                 Key: LEGAL-299
>                 URL: https://issues.apache.org/jira/browse/LEGAL-299
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Nick Couchman
>
> I'm currently contributing code to the Guacamole project, which is in the Incubator phase
with ASF.  One of the items I'm contributing is an extension to the Guacamole Client that
supports RADIUS authentication.  The extension that I've written includes a binary dependency
on the JRadius library, which is licensed under LGPL-2.1, a license not compatible with the
Apache 2.0 license and listed in the Category-X section on the ASF legal page.
> We have been through several rounds of discussions in the project and on the Incubator
General list about the acceptability of including this extension in the project.  At this
point we have determined that it is definitely not acceptable to distribute a binary form
of this extension that would include the binary (JAR) of the JRadius library.  However, if
possible, we'd like to include the source code for this extension in the main repository,
with instructions to users on building the extension.  Based on the information provided on
the ASF legal page, we believe this is acceptable, but would like to have verification on
that.
> All of the source code in the extension is Apache 2.0 licensed.  There is no source code
included from the JRadius library, only calls to classes and methods provided by the library.
> Finally, the source code in question is for an optional extension to the Guacamole Client
project, and is not core to its functionality.  It allows a user to perform RADIUS authentication
with the Guacamole Client, if they so choose, and other authentication modules are also available.
> Given the above information, can we get some guidance on whether or not including the
source code for the extension (*not* the JRadius library) in this ASF Incubator project is
acceptable?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message