| 1 |
On 18 April 2019 16:56:16 BST, Mike Gilbert <floppym@g.o> wrote: |
| 2 |
>On Wed, Apr 17, 2019 at 10:44 PM Georgy Yakovlev <gyakovlev@g.o> |
| 3 |
>wrote: |
| 4 |
>> |
| 5 |
>> On Wednesday, April 17, 2019 6:31:42 PM PDT Mike Gilbert wrote: |
| 6 |
>> > On Wed, Apr 17, 2019 at 3:35 PM Georgy Yakovlev |
| 7 |
><gyakovlev@g.o> |
| 8 |
>> wrote: |
| 9 |
>> > > # Georgy Yakovlev <gyakovlev@g.o> (17 Apr 2019) |
| 10 |
>> > > # The Oracle JDK License has changed for releases starting April |
| 11 |
>16, 2019 |
| 12 |
>> > > # While it may be fine to use for some usecases it's not |
| 13 |
>comepletely clear |
| 14 |
>> > > # what is considered "personal use" and if we can legally |
| 15 |
>distribute it. |
| 16 |
>> > > # License states: |
| 17 |
>> > > # "You may not: |
| 18 |
>> > > # make the Programs available in any manner to any third party" |
| 19 |
>> > |
| 20 |
>> > I don't agree with your rationale here. |
| 21 |
>> > |
| 22 |
>> > Gentoo does not distribute the JDK due to RESTRICT="fetch mirror" |
| 23 |
>in |
| 24 |
>> > the ebuild, so Oracle's license has no relevance. |
| 25 |
>> > |
| 26 |
>> > Oracle cannot prohibit us from distributing a shell script that |
| 27 |
>moves |
| 28 |
>> > some files around. That liability is on the user who runs it. |
| 29 |
>> > |
| 30 |
>> > We cannot force you to continue maintaining this package, but I |
| 31 |
>think |
| 32 |
>> > we should have a better reason for masking/removing it. If you |
| 33 |
>cannot |
| 34 |
>> > provide one, please just drop this to maintainer-needed. |
| 35 |
>> |
| 36 |
>> I've modified the mask for now, but I still believe we should drop |
| 37 |
>it. |
| 38 |
>> I do not maintain it at all, I only work on openjdk and a bit of |
| 39 |
>icedtea. |
| 40 |
>> |
| 41 |
>> For a while[1] we've been modifying provided jar: |
| 42 |
>> |
| 43 |
>> zip -d jre/lib/rt.jar sun/misc/PostVMInitHook.class || die |
| 44 |
>> |
| 45 |
>> but license[2] states that |
| 46 |
>> |
| 47 |
>> "You may not: |
| 48 |
>> ... |
| 49 |
>> make the Programs available in any manner to any third party |
| 50 |
>> ... |
| 51 |
>> create, modify, or change the behavior of, classes, interfaces, |
| 52 |
>or |
| 53 |
>> subpackages that are in any way identified as "java", "javax", "sun", |
| 54 |
>“oracle” |
| 55 |
>> or similar convention as specified by Oracle in any naming convention |
| 56 |
>> designation. |
| 57 |
>> |
| 58 |
>> " |
| 59 |
>> |
| 60 |
>> Is it even legal? |
| 61 |
> |
| 62 |
>That does seem like it might cause some legal problems for users. |
| 63 |
> |
| 64 |
>> Java usage tracker will fail due to sandbox during builds. |
| 65 |
>> |
| 66 |
>> while writing this email I found out it's probably possible to |
| 67 |
>disable it with |
| 68 |
>> com.oracle.usagetracker.track.last.usage=false |
| 69 |
>> in |
| 70 |
>> /etc/oracle/java/usagetracker.properties |
| 71 |
>> |
| 72 |
>> need to test it |
| 73 |
> |
| 74 |
>If that does not work, a possible alternative would be to install a |
| 75 |
>file in /etc/sandbox.d to add some path to SANDBOX_PREDICT. |
| 76 |
> |
| 77 |
>Anyway, this issue does seem like grounds for removal if it is not |
| 78 |
>addressed by somebody. |
| 79 |
|
| 80 |
IIRC, SANDBOX_PREDICT doesn't really help in this case because it triggers on any package using Java within the home directory of the build user and the HOME environment variable isn't respected. |
| 81 |
-- |
| 82 |
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
Archives