You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Niclas Hedhman <ni...@hedhman.org> on 2006/08/05 14:02:37 UTC
Using javax.microedition.io
Hi,
The CLDC profile of Java MicroEdition refers to the Sun Community Source
License (see below). Does this exclude ASF projects to have any;
import javax.microedition.io.*;
??
AFAICT, the SCSL doesn't discriminate between binary and source usages, and
hindered Jini adoption in some ways, and that many of the requirements are
incompatible with Apache licensing.
The OSGi specification requires javax.microedition.io usages, and we need to
get this sorted out in the Felix project.
Clarification is greatly appreciated.
Thanks
Niclas
SUN COMMUNITY SOURCE LICENSE Version 2.25 (Rev. Date Nov.
04, 2002)
RECITALS
Original Contributor has developed Specifications and Source
Code implementations of certain Technology; and
Original Contributor desires to license the Technology to a
large community to facilitate research, innovation and
product development while maintaining compatibility of such
products with the Technology as delivered by Original
Contributor; and
Original Contributor desires to license certain Sun
Trademarks for the purpose of branding products that are
compatible with the relevant Technology delivered by
Original Contributor; and
You desire to license the Technology and possibly certain
Sun Trademarks from Original Contributor on the terms and
conditions specified in this License.
In consideration for the mutual covenants contained herein,
You and Original Contributor agree as follows:
AGREEMENT
1. Introduction. The Sun Community Source License and
effective attachments (License) may include five distinct
licenses: Research Use, TCK, Internal Deployment Use,
Commercial Use and Trademark License. The Research Use
license is effective when You execute this License. The TCK
and Internal Deployment Use licenses are effective when You
execute this License, unless otherwise specified in the TCK
and Internal Deployment Use attachments. The Commercial Use
and Trademark licenses must be signed by You and Original
Contributor in order to become effective. Once effective,
these licenses and the associated requirements and
responsibilities are cumulative. Capitalized terms used in
this License are defined in the Glossary.
2. License Grants.
2.1 Original Contributor Grant. Subject to Your compliance
with Sections 3, 8.10 and Attachment A of this License,
Original Contributor grants to You a worldwide,
royalty-free, non-exclusive license, to the extent of
Original Contributor's Intellectual Property Rights covering
the Original Code, Upgraded Code and Specifications, to do
the following:
a) Research Use License: (i) use, reproduce and modify the
Original Code, Upgraded Code and Specifications to create
Modifications and Reformatted Specifications for Research
Use by You, (ii) publish and display Original Code, Upgraded
Code and Specifications with, or as part of Modifications,
as permitted under Section 3.1 b) below, (iii) reproduce and
distribute copies of Original Code and Upgraded Code to
Licensees and students for Research Use by You, (iv)
compile, reproduce and distribute Original Code and Upgraded
Code in Executable form, and Reformatted Specifications to
anyone for Research Use by You.
b) Other than the licenses expressly granted in this
License, Original Contributor retains all right, title, and
interest in Original Code and Upgraded Code and
Specifications.
2.2 Your Grants.
a) To Other Licensees. You hereby grant to each Licensee a
license to Your Error Corrections and Shared Modifications,
of the same scope and extent as Original Contributor's
licenses under Section 2.1 a) above relative to Research
Use, Attachment C relative to Internal Deployment Use, and
Attachment D relative to Commercial Use.
b) To Original Contributor. You hereby grant to Original
Contributor a worldwide, royalty-free, non-exclusive,
perpetual and irrevocable license, to the extent of Your
Intellectual Property Rights covering Your Error
Corrections, Shared Modifications and Reformatted
Specifications, to use, reproduce, modify, display and
distribute Your Error Corrections, Shared Modifications and
Reformatted Specifications, in any form, including the right
to sublicense such rights through multiple tiers of
distribution. c) Other than the licenses expressly granted
in Sections 2.2 a) and b) above, and the restriction set
forth in Section 3.1 d)(iv) below, You retain all right,
title, and interest in Your Error Corrections, Shared
Modifications and Reformatted Specifications.
2.3 Contributor Modifications. You may use, reproduce,
modify, display and distribute Contributor Error
Corrections, Shared Modifications and Reformatted
Specifications, obtained by You under this License, to the
same scope and extent as with Original Code, Upgraded Code
and Specifications.
2.4 Subcontracting. You may deliver the Source Code of
Covered Code to other Licensees having at least a Research
Use license, for the sole purpose of furnishing development
services to You in connection with Your rights granted in
this License. All such Licensees must execute appropriate
documents with respect to such work consistent with the
terms of this License, and acknowledging their
work-made-for-hire status or assigning exclusive right to
the work product and associated Intellectual Property Rights
to You.
3. Requirements and Responsibilities.
3.1 Research Use License. As a condition of exercising the
rights granted under Section 2.1 a) above, You agree to
comply with the following:
a) Your Contribution to the Community. All Error
Corrections and Shared Modifications which You create or
contribute to are automatically subject to the licenses
granted under Section 2.2 above. You are encouraged to
license all of Your other Modifications under Section 2.2 as
Shared Modifications, but are not required to do so. You
agree to notify Original Contributor of any errors in the
Specification.
b) Source Code Availability. You agree to provide all Your
Error Corrections to Original Contributor as soon as
reasonably practicable and, in any event, prior to Internal
Deployment Use or Commercial Use, if applicable. Original
Contributor may, at its discretion, post Source Code for
Your Error Corrections and Shared Modifications on the
Community Webserver. You may also post Error Corrections
and Shared Modifications on a web-server of Your choice;
provided, that You must take reasonable precautions to
ensure that only Licensees have access to such Error
Corrections and Shared Modifications. Such precautions
shall include, without limitation, a password protection
scheme limited to Licensees and a click-on, download
certification of Licensee status required of those
attempting to download from the server. An example of an
acceptable certification is attached as Attachment A-2.
c) Notices. All Error Corrections and Shared Modifications
You create or contribute to must include a file documenting
the additions and changes You made and the date of such
additions and changes. You must also include the notice set
forth in Attachment A-1 in the file header. If it is not
possible to put the notice in a particular Source Code file
due to its structure, then You must include the notice in a
location (such as a relevant directory file), where a
recipient would be most likely to look for such a notice.
d) Redistribution.
(i) Source. Covered Code may be distributed in Source Code
form only to another Licensee (except for students as
provided below). You may not offer or impose any terms on
any Covered Code that alter the rights, requirements, or
responsibilities of such Licensee. You may distribute
Covered Code to students for use in connection with their
course work and research projects undertaken at accredited
educational institutions. Such students need not be
Licensees, but must be given a copy of the notice set forth
in Attachment A-3 and such notice must also be included in a
file header or prominent location in the Source Code made
available to such students.
(ii) Executable. You may distribute Executable version(s)
of Covered Code to Licensees and other third parties only
for the purpose of evaluation and comment in connection with
Research Use by You and under a license of Your choice, but
which limits use of such Executable version(s) of Covered
Code only to that purpose.
(iii) Modified Class, Interface and Package Naming. In
connection with Research Use by You only, You may use
Original Contributor's class, interface and package names
only to accurately reference or invoke the Source Code files
You modify. Original Contributor grants to You a limited
license to the extent necessary for such purposes.
(iv) You expressly agree that any distribution, in whole or
in part, of Modifications developed by You shall only be
done pursuant to the term and conditions of this License.
e) Extensions.
(i) Covered Code. You may not include any Source Code of
Community Code in any Extensions;
(ii) Publication. No later than the date on which You first
distribute such Extension for Commercial Use, You must
publish to the industry, on a non-confidential basis and
free of all copyright restrictions with respect to
reproduction and use, an accurate and current specification
for any Extension. In addition, You must make available an
appropriate test suite, pursuant to the same rights as the
specification, sufficiently detailed to allow any third
party reasonably skilled in the technology to produce
implementations of the Extension compatible with the
specification. Such test suites must be made available as
soon as reasonably practicable but, in no event, later than
ninety (90) days after Your first Commercial Use of the
Extension. You must use reasonable efforts to promptly
clarify and correct the specification and the test suite
upon written request by Original Contributor.
(iii) Open. You agree to refrain from enforcing any
Intellectual Property Rights You may have covering any
interface(s) of Your Extension, which would prevent the
implementation of such interface(s) by Original Contributor
or any Licensee. This obligation does not prevent You from
enforcing any Intellectual Property Right You have that
would otherwise be infringed by an implementation of Your
Extension.
(iv) Class, Interface and Package Naming. You may not add
any packages, or any public or protected classes or
interfaces with names that originate or might appear to
originate from Original Contributor including, without
limitation, package or class names which begin with sun,
java, javax, jini, net.jini, com.sun or their equivalents in
any subsequent class, interface and/ or package naming
convention adopted by Original Contributor. It is
specifically suggested that You name any new packages using
the Unique Package Naming Convention as described in The
Java Language Specification by James Gosling, Bill Joy, and
Guy Steele, ISBN 0-201-63451-1, August 1996. Section 7.7
Unique Package Names, on page 125 of this specification
which states, in part:
You form a unique package name by first having (or belonging
to an organization that has) an Internet domain name, such
as sun.com. You then reverse the name, component by
component, to obtain, in this example, Com.sun, and use this
as a prefix for Your package names, using a convention
developed within Your organization to further administer
package names.
3.2 Additional Requirements and Responsibilities. Any
additional requirements and responsibilities relating to the
Technology are listed in Attachment F (Additional
Requirements and Responsibilities), if applicable, and are
hereby incorporated into this Section 3.
4. Versions of the License.
4.1 License Versions. Original Contributor may publish
revised versions of the License from time to time. Each
version will be given a distinguishing version number.
4.2 Effect. Once a particular version of Covered Code has
been provided under a version of the License, You may always
continue to use such Covered Code under the terms of that
version of the License. You may also choose to use such
Covered Code under the terms of any subsequent version of
the License. No one other than Original Contributor has the
right to promulgate License versions.
5. Disclaimer of Warranty.
5.1 COVERED CODE IS PROVIDED UNDER THIS LICENSE AS IS,
WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, WITHOUT LIMITATION, WARRANTIES THAT THE COVERED
CODE IS FREE OF DEFECTS, MERCHANTABLE, FIT FOR A PARTICULAR
PURPOSE OR NON-INFRINGING. YOU AGREE TO BEAR THE ENTIRE
RISK IN CONNECTION WITH YOUR USE AND DISTRIBUTION OF COVERED
CODE UNDER THIS LICENSE. THIS DISCLAIMER OF WARRANTY
CONSTITUTES AN ESSENTIAL PART OF THIS LICENSE. NO USE OF
ANY COVERED CODE IS AUTHORIZED HEREUNDER EXCEPT SUBJECT TO
THIS DISCLAIMER.
5.2 You acknowledge that Original Code, Upgraded Code and
Specifications are not designed or intended for use in (i)
on-line control of aircraft, air traffic, aircraft
navigation or aircraft communications; or (ii) in the
design, construction, operation or maintenance of any
nuclear facility. Original Contributor disclaims any
express or implied warranty of fitness for such uses.
6. Termination.
6.1 By You. You may terminate this Research Use license at
anytime by providing written notice to Original Contributor.
6.2 By Original Contributor. This License and the rights
granted hereunder will terminate:
(i) automatically if You fail to comply with the terms of
this License and fail to cure such breach within 30 days of
receipt of written notice of the breach;
(ii) immediately in the event of circumstances specified in
Sections 7.1 and 8.4; or
(iii) at Original Contributor's discretion upon any action
initiated in the first instance by You alleging that use or
distribution by Original Contributor or any Licensee, of
Original Code, Upgraded Code, Error Corrections or Shared
Modifications contributed by You, or Specifications,
infringe a patent owned or controlled by You.
6.3 Effect of Termination. Upon termination, You agree to
discontinue use and return or destroy all copies of Covered
Code in your possession. All sublicenses to the Covered
Code which you have properly granted shall survive any
termination of this License. Provisions which, by their
nature, should remain in effect beyond the termination of
this License shall survive including, without limitation,
Sections 2.2, 3, 5, 7 and 8.
6.4 Each party waives and releases the other from any claim
to compensation or indemnity for permitted or lawful
termination of the business relationship established by this
License.
7. Liability.
7.1 Infringement. Should any of the Original Code, Upgraded
Code, TCK or Specifications (Materials) become the subject
of a claim of infringement, Original Contributor may, at its
sole option, (i) attempt to procure the rights necessary for
You to continue using the Materials, (ii) modify the
Materials so that they are no longer infringing, or (iii)
terminate Your right to use the Materials, immediately upon
written notice, and refund to You the amount, if any, having
then actually been paid by You to Original Contributor for
the Original Code, Upgraded Code and TCK, depreciated on a
straight line, five year basis.
7.2 LIMITATION OF LIABILITY. TO THE FULL EXTENT ALLOWED BY
APPLICABLE LAW, ORIGINAL CONTRIBUTOR's LIABILITY TO YOU FOR
CLAIMS RELATING TO THIS LICENSE, WHETHER FOR BREACH OR IN
TORT, SHALL BE LIMITED TO ONE HUNDRED PERCENT (100%) OF THE
AMOUNT HAVING THEN ACTUALLY BEEN PAID BY YOU TO ORIGINAL
CONTRIBUTOR FOR ALL COPIES LICENSED HEREUNDER OF THE
PARTICULAR ITEMS GIVING RISE TO SUCH CLAIM, IF ANY. IN NO
EVENT WILL YOU (RELATIVE TO YOUR SHARED MODIFICATIONS OR
ERROR CORRECTIONS) OR SUN BE LIABLE FOR ANY INDIRECT,
PUNITIVE, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES IN
CONNECTION WITH OR ARISING OUT OF THIS LICENSE (INCLUDING,
WITHOUT LIMITATION, LOSS OF PROFITS, USE, DATA, OR OTHER
ECONOMIC ADVANTAGE), HOWEVER IT ARISES AND ON ANY THEORY OF
LIABILITY, WHETHER IN AN ACTION FOR CONTRACT, STRICT
LIABILITY OR TORT (INCLUDING NEGLIGENCE) OR OTHERWISE,
WHETHER OR NOT YOU OR ORIGINAL CONTRIBUTOR HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE AND NOTWITHSTANDING THE
FAILURE OF ESSENTIAL PURPOSE OF ANY REMEDY.
---------------------------------------------------------------------
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
Re: Using javax.microedition.io
Posted by BJ Hargrave <ha...@us.ibm.com>.
I don't think you should embed it. Just reference it via Import-Package.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
"Richard S. Hall" <he...@ungoverned.org>
08/17/2006 12:59 PM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: Using javax.microedition.io
Daniel John Debrunner wrote:
> Richard S. Hall wrote:
>
>> It seems like we could just remove the offending code with the
>> dependency until it is resolved if this were going to hold up
graduation.
>>
>
> What offending code though? Referencing the javax.microedition classes
> seems fine from the licence terms of the JSR 139 specification? It
includes:
>
I thought the issue was not that we were referencing it, but that we
were actually embedding it. Thus, we need to get rid of the code that
references it until it is resolved, so that we don't need to embed it.
-> richard
Re: Using javax.microedition.io
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Daniel John Debrunner wrote:
> Richard S. Hall wrote:
>
>> It seems like we could just remove the offending code with the
>> dependency until it is resolved if this were going to hold up graduation.
>>
>
> What offending code though? Referencing the javax.microedition classes
> seems fine from the licence terms of the JSR 139 specification? It includes:
>
I thought the issue was not that we were referencing it, but that we
were actually embedding it. Thus, we need to get rid of the code that
references it until it is resolved, so that we don't need to embed it.
-> richard
Re[2]: Using javax.microedition.io
Posted by Peter Kriens <Pe...@aQute.biz>.
Actually, you also need to include JSR 197 officially :-) This silliest
JSR of all was just done to make javax.microedition.io available
on J2SE ... That JSR was a weird experience ...
Kind regards,
Peter Kriens
DJD> Upayavira wrote:
>> Daniel John Debrunner wrote:
>>
>>>Richard S. Hall wrote:
>>>
>>>
>>>>It seems like we could just remove the offending code with the
>>>>dependency until it is resolved if this were going to hold up graduation.
>>>
>>>What offending code though? Referencing the javax.microedition classes
>>>seems fine from the licence terms of the JSR 139 specification? It includes:
>>>
>>> Sun Microsystems, Inc. ("Sun") hereby grants you a
>>> fully-paid, non-exclusive, non-transferable,
>>> worldwide, limited license (without the right to
>>> sublicense), under the Sun's applicable
>>> intellectual property rights to view, download,
>>> use and reproduce the Specification only for the
>>> purpose of internal evaluation, which shall be
>>> understood to include developing applications
>>> intended to run on an implementation of the
>>> Specification provided that such applications do
>>> not themselves implement any portion(s) of the
>>> Specification.
>>>
>>>JSR-000139 Connected Limited Device Configuration 1.1
>>>(Final Release)
>>>
>>>http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html
>>> follow the links to download the spec and then review licence.
>>
>>
>> "without the right to sublicense"
>>
>> Isn't that enough to scupper us?
DJD> Hmmm, ok, got me there. Doesn't that mean that writing any application
DJD> against J2ME CLDC is not allowed.
DJD> Dan.
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Using javax.microedition.io
Posted by BJ Hargrave <ha...@us.ibm.com>.
I think the issue is that some code in Felix needs to compile against
j.m.i classes. Since the build uses Java 1.4, there are no j.m.i classes
to compile against. So while Felix should not need to ship or distrbute
the j.m.i classes it does need the some j.m.i classes to compile certain
bundles. So j.m.i is needed the build env for Felix.
OSGi provides ee.foundation.jar which contains j.m.i class stubs from
CDC/Foundation 1.0 and is designed to compile against. OSGi uses
ee.foundation.jar duing compile time to resolve all j.m.i reference in the
OSGi code base.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Daniel John Debrunner <dj...@apache.org>
08/17/2006 11:46 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: Using javax.microedition.io
Upayavira wrote:
> Daniel John Debrunner wrote:
>
>>Richard S. Hall wrote:
>>
>>
>>>It seems like we could just remove the offending code with the
>>>dependency until it is resolved if this were going to hold up
graduation.
>>
>>What offending code though? Referencing the javax.microedition classes
>>seems fine from the licence terms of the JSR 139 specification? It
includes:
>>
>> Sun Microsystems, Inc. ("Sun") hereby grants you a
>> fully-paid, non-exclusive, non-transferable,
>> worldwide, limited license (without the right to
>> sublicense), under the Sun's applicable
>> intellectual property rights to view, download,
>> use and reproduce the Specification only for the
>> purpose of internal evaluation, which shall be
>> understood to include developing applications
>> intended to run on an implementation of the
>> Specification provided that such applications do
>> not themselves implement any portion(s) of the
>> Specification.
>>
>>JSR-000139 Connected Limited Device Configuration 1.1
>>(Final Release)
>>
>>http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html
>> follow the links to download the spec and then review licence.
>
>
> "without the right to sublicense"
>
> Isn't that enough to scupper us?
Hmmm, ok, got me there. Doesn't that mean that writing any application
against J2ME CLDC is not allowed.
Dan.
Re: Using javax.microedition.io
Posted by Daniel John Debrunner <dj...@apache.org>.
Upayavira wrote:
> Daniel John Debrunner wrote:
>
>>Richard S. Hall wrote:
>>
>>
>>>It seems like we could just remove the offending code with the
>>>dependency until it is resolved if this were going to hold up graduation.
>>
>>What offending code though? Referencing the javax.microedition classes
>>seems fine from the licence terms of the JSR 139 specification? It includes:
>>
>> Sun Microsystems, Inc. ("Sun") hereby grants you a
>> fully-paid, non-exclusive, non-transferable,
>> worldwide, limited license (without the right to
>> sublicense), under the Sun's applicable
>> intellectual property rights to view, download,
>> use and reproduce the Specification only for the
>> purpose of internal evaluation, which shall be
>> understood to include developing applications
>> intended to run on an implementation of the
>> Specification provided that such applications do
>> not themselves implement any portion(s) of the
>> Specification.
>>
>>JSR-000139 Connected Limited Device Configuration 1.1
>>(Final Release)
>>
>>http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html
>> follow the links to download the spec and then review licence.
>
>
> "without the right to sublicense"
>
> Isn't that enough to scupper us?
Hmmm, ok, got me there. Doesn't that mean that writing any application
against J2ME CLDC is not allowed.
Dan.
Re: Using javax.microedition.io
Posted by Upayavira <uv...@odoko.co.uk>.
Daniel John Debrunner wrote:
> Richard S. Hall wrote:
>
>> It seems like we could just remove the offending code with the
>> dependency until it is resolved if this were going to hold up graduation.
>
> What offending code though? Referencing the javax.microedition classes
> seems fine from the licence terms of the JSR 139 specification? It includes:
>
> Sun Microsystems, Inc. ("Sun") hereby grants you a
> fully-paid, non-exclusive, non-transferable,
> worldwide, limited license (without the right to
> sublicense), under the Sun's applicable
> intellectual property rights to view, download,
> use and reproduce the Specification only for the
> purpose of internal evaluation, which shall be
> understood to include developing applications
> intended to run on an implementation of the
> Specification provided that such applications do
> not themselves implement any portion(s) of the
> Specification.
>
> JSR-000139 Connected Limited Device Configuration 1.1
> (Final Release)
>
> http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html
> follow the links to download the spec and then review licence.
"without the right to sublicense"
Isn't that enough to scupper us?
Upayavira
Re: Using javax.microedition.io
Posted by Daniel John Debrunner <dj...@apache.org>.
Richard S. Hall wrote:
> It seems like we could just remove the offending code with the
> dependency until it is resolved if this were going to hold up graduation.
What offending code though? Referencing the javax.microedition classes
seems fine from the licence terms of the JSR 139 specification? It includes:
Sun Microsystems, Inc. ("Sun") hereby grants you a
fully-paid, non-exclusive, non-transferable,
worldwide, limited license (without the right to
sublicense), under the Sun's applicable
intellectual property rights to view, download,
use and reproduce the Specification only for the
purpose of internal evaluation, which shall be
understood to include developing applications
intended to run on an implementation of the
Specification provided that such applications do
not themselves implement any portion(s) of the
Specification.
JSR-000139 Connected Limited Device Configuration 1.1
(Final Release)
http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html
follow the links to download the spec and then review licence.
Dan.
Re: Using javax.microedition.io
Posted by "Richard S. Hall" <he...@ungoverned.org>.
It seems like we could just remove the offending code with the
dependency until it is resolved if this were going to hold up graduation.
-> richard
Upayavira wrote:
> Forwarded from legal-discuss:
>
> Niclas Hedhman wrote:
>
>> On Tuesday 15 August 2006 09:41, Daniel John Debrunner wrote:
>>
>>> http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html
>>> follow the links to download the spec and then review licence.
>>>
>>> Isn's the SCSL licence you quote just if you want to use the reference
>>> implementation?
>>>
>> Well, the issue has been resolved as Sun have donated the parts of interested
>> to the OSGi Alliance separately allowing OSGi Alliance to release (soon) the
>> javax.microedition jars under the Apache license.
>>
>> Problem solved.
>>
>
> Thanks Niclas, that is great news.
>
> Any idea as to when that'll happen? It'll be useful to know if we're
> planning to approach the board about graduation in September (I wouldn't
> feel happy approaching the board until we've resolved that dependency).
>
> Regards, Upayavira
>
Re: Graduation tasks (was Re: Using javax.microedition.io)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 31 August 2006 17:44, Upayavira wrote:
> I guess what I'm saying is that we shouldn't just do it in a sandbox, we
> should do it in trunk - remove the code now, and re-add it as soon as we
> have the required dependency available.
>
> WDYAT?
Sounds very reasonable to me.
Cheers
Niclas
Re: Graduation tasks (was Re: Using javax.microedition.io)
Posted by Marcel Offermans <ma...@luminis.nl>.
On Aug 31, 2006, at 16:20 , Richard S. Hall wrote:
> Upayavira wrote:
>> I guess what I'm saying is that we shouldn't just do it in a
>> sandbox, we
>> should do it in trunk - remove the code now, and re-add it as soon
>> as we
>> have the required dependency available.
>>
>> WDYAT?
>
> Sounds good to me too.
See FELIX-138, I've just committed a patch to remove the dependency.
Hopefully this solution won't break too much code.
It only affects the compendium bundle. Within that bundle, only the
IO service was modified. It did change some of the interfaces
slightly, so code depending on those interfaces might still break
(until we revert te patch).
Greetings, Marcel
Re: Graduation tasks (was Re: Using javax.microedition.io)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Upayavira wrote:
> I guess what I'm saying is that we shouldn't just do it in a sandbox, we
> should do it in trunk - remove the code now, and re-add it as soon as we
> have the required dependency available.
>
> WDYAT?
Sounds good to me too.
-> richard
Re: Graduation tasks (was Re: Using javax.microedition.io)
Posted by Upayavira <uv...@odoko.co.uk>.
Marcel Offermans wrote:
> On Aug 31, 2006, at 11:32 , Upayavira wrote:
>
>> Marcel Offermans wrote:
>>> If nobody else volunteers, I will attempt to
>>> remove the offending code. Perhaps it is a good idea if we start doing
>>> this now (maybe even in a branch or sandbox for now so we can easily
>>> apply this if necessary).
>>
>> That sounds like a good idea - to do a dry run in a sandbox. You willing
>> to give it a quick try?
>
> Sure, this weekend I can give it a try (earlier is impossible for me).
That's great.
Basically, we're taking a risk having votes with pending items.
Thinking about this, I'd like to change my proposal: we can vote
ourselves with a pending item outstanding, but, on reflection, it is
unreasonable to expect the incubator PMC to vote on graduation (which
implies the resolution of all outstanding issues) without us having
resolved all issues!
Therefore, lets get this fixed (this weekend should be fine) before we
consider asking the Incubator PMC to vote on graduation.
I guess what I'm saying is that we shouldn't just do it in a sandbox, we
should do it in trunk - remove the code now, and re-add it as soon as we
have the required dependency available.
WDYAT?
Regards, Upayavira
Re: Graduation tasks (was Re: Using javax.microedition.io)
Posted by Marcel Offermans <ma...@luminis.nl>.
On Aug 31, 2006, at 11:32 , Upayavira wrote:
> Marcel Offermans wrote:
>> If nobody else volunteers, I will attempt to
>> remove the offending code. Perhaps it is a good idea if we start
>> doing
>> this now (maybe even in a branch or sandbox for now so we can easily
>> apply this if necessary).
>
> That sounds like a good idea - to do a dry run in a sandbox. You
> willing
> to give it a quick try?
Sure, this weekend I can give it a try (earlier is impossible for me).
Greetings, Marcel
Re: Graduation tasks (was Re: Using javax.microedition.io)
Posted by Upayavira <uv...@odoko.co.uk>.
Marcel Offermans wrote:
> On Aug 31, 2006, at 11:03 , Upayavira wrote:
>
>> No comment anyone? We should be starting our vote any day now if we wish
>> to make the board meeting on the 16th.
>
> I'm ready to start the vote. As far as the licensing issue, I think the
> approach is a good one. If nobody else volunteers, I will attempt to
> remove the offending code. Perhaps it is a good idea if we start doing
> this now (maybe even in a branch or sandbox for now so we can easily
> apply this if necessary).
That sounds like a good idea - to do a dry run in a sandbox. You willing
to give it a quick try?
Regards, Upayavira
Re: Graduation tasks (was Re: Using javax.microedition.io)
Posted by Marcel Offermans <ma...@luminis.nl>.
On Aug 31, 2006, at 11:03 , Upayavira wrote:
> No comment anyone? We should be starting our vote any day now if we
> wish
> to make the board meeting on the 16th.
I'm ready to start the vote. As far as the licensing issue, I think
the approach is a good one. If nobody else volunteers, I will attempt
to remove the offending code. Perhaps it is a good idea if we start
doing this now (maybe even in a branch or sandbox for now so we can
easily apply this if necessary).
Greetings, Marcel
Re: Graduation tasks (was Re: Using javax.microedition.io)
Posted by Upayavira <uv...@odoko.co.uk>.
Upayavira wrote:
> So, we now have a website and a wiki. We have dealt with all licensing
> issues except for the javax.microedition one. I'm pretty close to
> calling for a vote. So, two questions to precede that:
>
> 1. As regarding the javax.microedition licensing, the approach we are
> proposing is to use the OSGi one, planned to be released week of 11
> sept. If, for whatever reason, this does not arrive in time, we will
> remove the related code from our SVN repo until such a time as we
> have the necessary dependency.
>
> So, do we have a volunteer to do the integration or removal, at short
> notice, just before the board meeting (16 Sept)?
>
> 2. Does anyone have any other concerns they wish to raise before we
> proceed to a vote?
No comment anyone? We should be starting our vote any day now if we wish
to make the board meeting on the 16th.
Regards, Upayavira
Graduation tasks (was Re: Using javax.microedition.io)
Posted by Upayavira <uv...@odoko.co.uk>.
So, we now have a website and a wiki. We have dealt with all licensing
issues except for the javax.microedition one. I'm pretty close to
calling for a vote. So, two questions to precede that:
1. As regarding the javax.microedition licensing, the approach we are
proposing is to use the OSGi one, planned to be released week of 11
sept. If, for whatever reason, this does not arrive in time, we will
remove the related code from our SVN repo until such a time as we
have the necessary dependency.
So, do we have a volunteer to do the integration or removal, at short
notice, just before the board meeting (16 Sept)?
2. Does anyone have any other concerns they wish to raise before we
proceed to a vote?
Regards, Upayavira
Upayavira wrote:
> On Fri, 18 Aug 2006 14:51:43 +0800, "Niclas Hedhman"
> <ni...@hedhman.org> said:
>> On Thursday 17 August 2006 22:27, Upayavira wrote:
>>> BJ Hargrave wrote:
>>>> I should be able to release the j.m.i code from OSGi to Felix under AL2
>>>> the week of September 11th.
>>> Okay. IIRC the board meeting is on 16th. So it is close. However, what
>>> I'd propose is we leave the code in place until the day before the board
>>> meeting, and if the OSGi code is not available, we remove the dependency
>>> then, and I'll attach a note to the agenda item making it clear that
>>> action has been taken one way or the other.
>> Yes, as long as the PMC is "on top" of the situation, knows it exists and
>> have
>> a plan for dealing with it, I can't see the Board would object.
>
> Well, I don't want to test it. Basically, dealing with licensing is a
> pre-graduation task. Until we've resolved the dependencies license or
> removed the dependent code, I'm not happy persuing graduation.
>
>> I have a question;
>> Is the Board voting for TLP before or after the Incubator PMC votes for
>> graduation?
>
> Actually, the Incubator PMC votes on accepting graduation. That is the
> most crucial vote. Once the incubator PMC has accepted the proposal to
> graduate, a motion would be put before the board, using all the legal
> "Hereby be it noted" language. The board would then do whatever they do
> during their meeting to decide whether they accept the Incubator PMCs
> recommendation. Likely they will.
>
> Regards, Upayavira
>
>> Reason for confusion;
>> The STATUS[1] page (which should be updated with the latest info on IP)
>> says
>> that "If graduating to a new PMC, has the board voted to accept it?".
>> OTOH, it sounds strange that the Board would approve TLP prior to the
>> Incubator is satisfied with exit criteria such as "healthy community".
>>
>>
>> Cheers
>> Niclas
>>
>> [1] http://incubator.apache.org/projects/felix.html)
>
Re: Using javax.microedition.io
Posted by Upayavira <uv...@odoko.co.uk>.
On Fri, 18 Aug 2006 14:51:43 +0800, "Niclas Hedhman"
<ni...@hedhman.org> said:
> On Thursday 17 August 2006 22:27, Upayavira wrote:
> > BJ Hargrave wrote:
> > > I should be able to release the j.m.i code from OSGi to Felix under AL2
> > > the week of September 11th.
> >
> > Okay. IIRC the board meeting is on 16th. So it is close. However, what
> > I'd propose is we leave the code in place until the day before the board
> > meeting, and if the OSGi code is not available, we remove the dependency
> > then, and I'll attach a note to the agenda item making it clear that
> > action has been taken one way or the other.
>
> Yes, as long as the PMC is "on top" of the situation, knows it exists and
> have
> a plan for dealing with it, I can't see the Board would object.
Well, I don't want to test it. Basically, dealing with licensing is a
pre-graduation task. Until we've resolved the dependencies license or
removed the dependent code, I'm not happy persuing graduation.
> I have a question;
> Is the Board voting for TLP before or after the Incubator PMC votes for
> graduation?
Actually, the Incubator PMC votes on accepting graduation. That is the
most crucial vote. Once the incubator PMC has accepted the proposal to
graduate, a motion would be put before the board, using all the legal
"Hereby be it noted" language. The board would then do whatever they do
during their meeting to decide whether they accept the Incubator PMCs
recommendation. Likely they will.
Regards, Upayavira
> Reason for confusion;
> The STATUS[1] page (which should be updated with the latest info on IP)
> says
> that "If graduating to a new PMC, has the board voted to accept it?".
> OTOH, it sounds strange that the Board would approve TLP prior to the
> Incubator is satisfied with exit criteria such as "healthy community".
>
>
> Cheers
> Niclas
>
> [1] http://incubator.apache.org/projects/felix.html)
Re: Using javax.microedition.io
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 17 August 2006 22:27, Upayavira wrote:
> BJ Hargrave wrote:
> > I should be able to release the j.m.i code from OSGi to Felix under AL2
> > the week of September 11th.
>
> Okay. IIRC the board meeting is on 16th. So it is close. However, what
> I'd propose is we leave the code in place until the day before the board
> meeting, and if the OSGi code is not available, we remove the dependency
> then, and I'll attach a note to the agenda item making it clear that
> action has been taken one way or the other.
Yes, as long as the PMC is "on top" of the situation, knows it exists and have
a plan for dealing with it, I can't see the Board would object.
I have a question;
Is the Board voting for TLP before or after the Incubator PMC votes for
graduation?
Reason for confusion;
The STATUS[1] page (which should be updated with the latest info on IP) says
that "If graduating to a new PMC, has the board voted to accept it?".
OTOH, it sounds strange that the Board would approve TLP prior to the
Incubator is satisfied with exit criteria such as "healthy community".
Cheers
Niclas
[1] http://incubator.apache.org/projects/felix.html)
Re: Using javax.microedition.io
Posted by Upayavira <uv...@odoko.co.uk>.
BJ Hargrave wrote:
> I should be able to release the j.m.i code from OSGi to Felix under AL2
> the week of September 11th.
Okay. IIRC the board meeting is on 16th. So it is close. However, what
I'd propose is we leave the code in place until the day before the board
meeting, and if the OSGi code is not available, we remove the dependency
then, and I'll attach a note to the agenda item making it clear that
action has been taken one way or the other.
Thanks all.
Now it is just the website :-)
Regards, Upayavira
Re: Using javax.microedition.io
Posted by BJ Hargrave <ha...@us.ibm.com>.
I should be able to release the j.m.i code from OSGi to Felix under AL2
the week of September 11th.
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788
Upayavira <uv...@odoko.co.uk>
08/17/2006 07:55 AM
Please respond to
felix-dev@incubator.apache.org
To
Niclas Hedhman <ni...@hedhman.org>, felix-dev@incubator.apache.org
cc
Subject
Re: Using javax.microedition.io
Forwarded from legal-discuss:
Niclas Hedhman wrote:
> On Tuesday 15 August 2006 09:41, Daniel John Debrunner wrote:
>> http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html
>> follow the links to download the spec and then review licence.
>>
>> Isn's the SCSL licence you quote just if you want to use the reference
>> implementation?
>
> Well, the issue has been resolved as Sun have donated the parts of
interested
> to the OSGi Alliance separately allowing OSGi Alliance to release (soon)
the
> javax.microedition jars under the Apache license.
>
> Problem solved.
Thanks Niclas, that is great news.
Any idea as to when that'll happen? It'll be useful to know if we're
planning to approach the board about graduation in September (I wouldn't
feel happy approaching the board until we've resolved that dependency).
Regards, Upayavira
Re: Using javax.microedition.io
Posted by Upayavira <uv...@odoko.co.uk>.
Forwarded from legal-discuss:
Niclas Hedhman wrote:
> On Tuesday 15 August 2006 09:41, Daniel John Debrunner wrote:
>> http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html
>> follow the links to download the spec and then review licence.
>>
>> Isn's the SCSL licence you quote just if you want to use the reference
>> implementation?
>
> Well, the issue has been resolved as Sun have donated the parts of interested
> to the OSGi Alliance separately allowing OSGi Alliance to release (soon) the
> javax.microedition jars under the Apache license.
>
> Problem solved.
Thanks Niclas, that is great news.
Any idea as to when that'll happen? It'll be useful to know if we're
planning to approach the board about graduation in September (I wouldn't
feel happy approaching the board until we've resolved that dependency).
Regards, Upayavira
Re: Using javax.microedition.io
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 15 August 2006 09:41, Daniel John Debrunner wrote:
> http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html
> follow the links to download the spec and then review licence.
>
> Isn's the SCSL licence you quote just if you want to use the reference
> implementation?
Well, the issue has been resolved as Sun have donated the parts of interested
to the OSGi Alliance separately allowing OSGi Alliance to release (soon) the
javax.microedition jars under the Apache license.
Problem solved.
Cheers
Niclas
---------------------------------------------------------------------
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
Re: Using javax.microedition.io
Posted by Daniel John Debrunner <dj...@apache.org>.
Niclas Hedhman wrote:
> Hi,
>
> The CLDC profile of Java MicroEdition refers to the Sun Community Source
> License (see below). Does this exclude ASF projects to have any;
>
> import javax.microedition.io.*;
>
> ??
>
> AFAICT, the SCSL doesn't discriminate between binary and source usages, and
> hindered Jini adoption in some ways, and that many of the requirements are
> incompatible with Apache licensing.
>
> The OSGi specification requires javax.microedition.io usages, and we need to
> get this sorted out in the Felix project.
>
> Clarification is greatly appreciated.
Would the 'import'ing of the class (as above) be covered by the licence
for the JSR 139 specification? It includes:
Sun Microsystems, Inc. ("Sun") hereby grants you a
fully-paid, non-exclusive, non-transferable,
worldwide, limited license (without the right to
sublicense), under the Sun's applicable
intellectual property rights to view, download,
use and reproduce the Specification only for the
purpose of internal evaluation, which shall be
understood to include developing applications
intended to run on an implementation of the
Specification provided that such applications do
not themselves implement any portion(s) of the
Specification.
JSR-000139 Connected Limited Device Configuration 1.1
(Final Release)
http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html
follow the links to download the spec and then review licence.
Isn's the SCSL licence you quote just if you want to use the reference
implementation?
Dan.
---------------------------------------------------------------------
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
Re: Using javax.microedition.io
Posted by Geir Magnusson Jr <ge...@apache.org>.
Justin Erenkrantz wrote:
> On 8/5/06, Niclas Hedhman <ni...@hedhman.org> wrote:
>> The CLDC profile of Java MicroEdition refers to the Sun Community Source
>> License (see below). Does this exclude ASF projects to have any;
>>
>> import javax.microedition.io.*;
>>
>> ??
>
> My interpretation is that I think this license falls under Category X
> as it places restrictions on what binaries can do:
>
>> (ii) Executable. You may distribute Executable version(s)
>> of Covered Code to Licensees and other third parties only
>> for the purpose of evaluation and comment in connection with
>> Research Use by You and under a license of Your choice, but
>> which limits use of such Executable version(s) of Covered
>> Code only to that purpose.
>
> If that's right, then we'd need to contact Sun to see if they'd be
> willing to relicense (they have in the past for some packages we've
> brought to their attention) or get OSGi to drop that usage. -- justin
What you want is a binary under CDDL or something, right? Until recenty
with CDDL, I can't recall any acceptable license from Sun...
geir
---------------------------------------------------------------------
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
Re: Using javax.microedition.io
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 8/5/06, Niclas Hedhman <ni...@hedhman.org> wrote:
> The CLDC profile of Java MicroEdition refers to the Sun Community Source
> License (see below). Does this exclude ASF projects to have any;
>
> import javax.microedition.io.*;
>
> ??
My interpretation is that I think this license falls under Category X
as it places restrictions on what binaries can do:
> (ii) Executable. You may distribute Executable version(s)
> of Covered Code to Licensees and other third parties only
> for the purpose of evaluation and comment in connection with
> Research Use by You and under a license of Your choice, but
> which limits use of such Executable version(s) of Covered
> Code only to that purpose.
If that's right, then we'd need to contact Sun to see if they'd be
willing to relicense (they have in the past for some packages we've
brought to their attention) or get OSGi to drop that usage. -- justin
---------------------------------------------------------------------
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