You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by "Sebb (JIRA)" <ji...@apache.org> on 2008/06/24 11:54:45 UTC
[jira] Commented: (LEGAL-30) Options for including bridge code to
prohibited works
[ https://issues.apache.org/jira/browse/LEGAL-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607541#action_12607541 ]
Sebb commented on LEGAL-30:
---------------------------
In the case of Maven projects, how can the POM refer to the prohibited work?
Must it be "provided" - i.e. the user is responsible for obtaining it, or can it be downloaded automatically?
> Options for including bridge code to prohibited works
> -----------------------------------------------------
>
> Key: LEGAL-30
> URL: https://issues.apache.org/jira/browse/LEGAL-30
> Project: Legal Discuss
> Issue Type: Question
> Reporter: Sebb
>
> The 3rd party policy says:
> "YOU MAY include code within the Apache product necessary to achieve compatibility with a prohibited work through the use of API calls, "bridge code", or protocols, provided that the compatibility code was contributed under a CLA."
> In the case of Java code, the easiest way to build bridge code is to include a copy of the prohibited work in the classpath when compiling the code.
> This means that the prohibited work is a requirement for building the Apache product, and would need to be provided somehow by the builder.
> Is the build process allowed to unconditionally depend on a prohibited work?
> If the build process can be modified to conditionally build the bridge code when the prohibited work is present, is that OK?
> Or must the bridge code be buildable without the presence of the prohibited work?
> [e.g. in Java this can be done with reflection]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only. Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF. See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org