Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 30 19:38

    freemo on master

    Copied over attributions file f… (compare)

  • Sep 30 19:21
    Travis Syncleus/aparapi (changelog) errored (418)
  • Sep 30 19:12

    freemo on changelog

    Adding code quality reports for… Fixed codequality pipeline so i… Fixed stages key, produced erro… and 5 more (compare)

  • Sep 30 18:29
    Travis Syncleus/aparapi (master) errored (417)
  • Sep 30 18:22
    Travis Syncleus/aparapi@6af8d51 (gitlab-ci) errored (416)
  • Sep 30 18:17

    freemo on master

    Updated changelog to reflect re… Merge branch 'gitlab-ci' into '… (compare)

  • Sep 30 18:11

    freemo on gitlab-ci

    Updated changelog to reflect re… (compare)

  • Sep 30 16:22

    freemo on defensive-0

    (compare)

  • Sep 30 16:00
    Travis Syncleus/aparapi (master) errored (415)
  • Sep 30 15:42
    Travis Syncleus/aparapi (gitlab-ci) errored (414)
  • Sep 30 15:30
    Travis Syncleus/aparapi (master) errored (413)
  • Sep 30 15:28

    freemo on gitlab-ci

    (compare)

  • Sep 30 15:28

    freemo on master

    Updated dependencies. Merge branch 'master' into gitl… Merge branch 'gitlab-ci' into '… (compare)

  • Sep 30 15:14

    freemo on gitlab-ci

    Updated dependencies. Merge branch 'master' into gitl… (compare)

  • Sep 30 15:10
    Travis Syncleus/aparapi (gitlab-ci) errored (412)
  • Sep 30 15:07

    freemo on gitlab-ci

    (compare)

  • Sep 30 15:07

    freemo on master

    Adding code quality reports for… Fixed codequality pipeline so i… Fixed stages key, produced erro… and 1 more (compare)

  • Sep 30 14:56
    Travis Syncleus/aparapi@d1ca7f2 (gitlab-ci) errored (411)
  • Sep 30 14:54

    freemo on gitlab-ci

    Fixed codequality pipeline so i… Fixed stages key, produced erro… (compare)

  • Sep 30 14:47

    freemo on gitlab-ci

    Adding code quality reports for… (compare)

grfrost
@grfrost
Maybe ask at https://www.amd.com/en/support/contact-email-form . To see if AMD would be willing to relicense?
Jeffrey Phillips Freeman
@freemo
grfrost: hey sorry i totally forgot to respond and read your email, im just remembering it now
grfrost: ive been going through some shit mentally.. nothing serious, but when i was bed ridden for a year it really messed with my head and motivations (as you probably saw).. but i think im finally over that and been pretty productive again like my old self past few weeks
Gruet
@pgt_gitlab
@barneypitt and @grfrost Thanks for your answers! You're right, if I have to discuss this with AMD, it will be hard even to reach someone. Thanks for the link to the AMD form, I will give it a try.
I think getting rid of those restrictions would be good for the whole aparapi community as well, as works derived from aparapi are currently prevented from being distributed widely.
If I get some news about it, I will let you know. Thanks again for your answers to my concern.
Jeffrey Phillips Freeman
@freemo
@grfrost Do you think that repo is worth integrating into aparapi codebase? or at least maybe as a branch?
@grfrost the next week ill be doing some more code work on aparapi, including updating the website. So anything like that i can dedicate some time to if you think its a good path and ready for prime time
Barney Pitt
@barneypitt
@pgt_gitlab I notice that AMD's latest big open source effort on the GPU side FidelityFX https://github.com/GPUOpen-Effects/FidelityFX/blob/master/ is under a straight-forward MIT license which to the best of my knowledge is widely compatible . Perhaps they might switch their legacy Aparapi code to MIT?
grfrost
@grfrost
@pgt_gitlab I forwarded this request to AMD (a senior Software Fellow). I have asked for the appropriate contact, so we can at least open a discussion.
@freemo You are referring to the repo that I requested a pull request from ? I am not sure there is much in there that you guys would want, and I dismantled the Maven build stuff ( Have I expressed how much I hate Maven this week ;) ) . When I have a graal frontend I will place it there as a branch. Then we can decide what to do.
Jeffrey Phillips Freeman
@freemo
@pgt_gitlab hey sorry i am so late to respond to this.. But i am the one who originally migrated the license of Aparapi after discussion and approval from our lawyer who reviewed. I am not a lawyer myself so I will only be doing my best to reiterate the advice my corperate lawyer had given me at the time (which (i discussed at length).. so considerate it as you will but know I am not giving legal advice just reiterating the legal advice I was given as best I can and as a non-lawyer... but i think i can address your concern
@pgt_gitlab As it was explained to me by our lawyer at the time time the original Aparapi license, while having some additional wording added to it and thus not a standard MIT license is in almost every functional way exactly equivelant to an MIT license and does not, in fact, restrict distribution in the sense that you imply.
@pgt_gitlab ill explain why, but it was mostly a CYA on the part of AMD and not an additional restriction
@pgt_gitlab it essentially took something that was implied in the MIT license but effectively still a part of it and made it explicit
Jeffrey Phillips Freeman
@freemo
@pgt_gitlab As you realize the last paragraph is the only part of the license that differs from the original, it starts off with the wording "If you use the software (in whole or in part), you shall adhere to all applicable U.S., European, and other export
laws", and then it goes on to give examples of some relevant laws... the whole paragraph basically boils down to saying everything the MIT license states but with additional explicit assertion of "You can not break any laws that apply to you when you distribute this license"
@pgt_gitlab it is already implied in the MIT license that it does not grant you any right to break the law, obviously. so it is functionally equivelant to the MIT license. The reason for the added clause is not that it in any way adds additional restrictions to distribution. The purpose is so if someone decided to break the law in the way they distribute the license AMD as the original grantor of the license would not hold any liability under the law.. It was purely a CYA for them andas i said is in all relevant ways indistinct from the MIT license. in that regard
Jeffrey Phillips Freeman
@freemo
@pgt_gitlab the use case it is trying to specifically address is if you take a technology which is restricted by export, and bundle it with Aparapi, that even though Aparapi is bundled with it you are still not allowed to export the bundled package, even though aparapi on its own can and is free to be exported itself. A prime example of this would be if you were to implement a strong cryptographic algorithm using Aparapi, and if you live in the USA, you would be unable to export it as strong cryptography can not be exported from the USA under USA law.
@pgt_gitlab the part about "you will not (1) export, re-export or release to a national of a country in Country Groups D:1, E:1 or E:2 any restricted technology, software, or source code" is implying this very bit.
@pgt_gitlab in fact it is the exact same restriction on GPG software for exactly this reason, yet despite being under this same restriction, and despite the fact taht the authors of GPG have announced the the export restriction, it is still licensed under GPL and does not have its distribtuion limited by the definition of the GPL (which itself limits distribution should such distribution be illegal).. and as such GPG is and can be bundled with ubuntu despite having the same restriction as aparapi in that sense
@pgt_gitlab so long story short, you are absolutely free to bundle Aparapi as part of Ubuntu exactly as you would be any other Apache licensed software. the additional clause does nothing to change the nature of the MIT license.
Jeffrey Phillips Freeman
@freemo
@grfrost let me figure out what repo i was refering to... I thought i was responding to something you linked here but now im not seeing it

I cloned the headers from a java8 build into this dedicated repo https://github.com/grfrost/aparapi-include-java8, I will leave it up to you figure how to get maven to include this dir. I don't use maven.

Ok found it, apparently I was refering to this comment you made sometime ago, not sure why i thought i was commenting to something recent

@grfrost the question still stands though, is that something I need to look at or is worth integrating?
grfrost
@grfrost
Oh yes. Someone asked for the output from javah, which I think is not available post java 8. I think you now pass the -h option to javac. So I just created a public repo and dropped them in. I suggest leaving this public, until we learn what changes are needed to Maven to support generating headers on Maven 8+.
Jeffrey Phillips Freeman
@freemo
@grfrost oh so that didnt represent any work on your part, you just generated headers from the existing aparapi code as-is?
grfrost
@grfrost
image.png
Correct. Here is the sequence of msgs above which led to the posting of the headers from javah for java 8.
Jeffrey Phillips Freeman
@freemo
@grfrost ahh thanks, today i have devoted some time to Aparapi business, ill read over it ands ee if there is anything i should take action on. Might take another stab at cleaning up the build process but honestly im not hopeful at automating windows builds still
Jeffrey Phillips Freeman
@freemo
@grfrost hey I noticed just now the PR you did was on github.. while I can move it over to gitlab for you can you submit it to gitlab instead, or if your too busy at least in the future make sure you commit it to the official repo there. Only reason its important (there is two way mirroring) is because tahts where all our CI is including GPU-enabled CI servers
Gruet
@pgt_gitlab
@freemo really, thanks a lot for those very complete explanations about the licensing issue. Things are far clearer now :) I must admit this clarifies a lot this famous paragraph in the Attributions.md file. I thus guess we can go on with the packaging on our side.
@grfrost and @barneypitt thanks to you too for the reference to FidelityFX and for contacting someone inside AMD!
From my side, I had some contacts with AMD which led me to post on their DevGurus community, the message has not got an answer yet.
Well, thanks again everyone, I will keep you informed if there is some new significant step on this!
Jeffrey Phillips Freeman
@freemo
@pgt_gitlab I try to handle most of the day-to-day busy work for the project, so if you have any more questions as you begin to package let me know and just tag me and I'll be sure to get back to you. I had the benefit of a lawyer reviewing this stuff so i kinda get the jist of the legal side even though I cant provide legal counsel
@pgt_gitlab by the way your question prompted me to contact the person who started the original ticket over at the old aparapi project, the guy who represnted debian. It seems debial will also be going ahead and repackaging Aparapi for debian under the new license as well. So it has been fruitful twice over
Gruet
@pgt_gitlab
@freemo Thanks for your help proposal!
Indeed I work quite closely with the person who opened this original ticket and I saw you also wrote a detailed email to him. This is great for all of us!
Jeffrey Phillips Freeman
@freemo
@pgt_gitlab happy to be of help. The lawyer wasnt cheap but I knew the investment would pay off (it was my own donated money).. so im really glad to see I could resolve this issue for the community as a whole.
grfrost
@grfrost
@pgt_gitlab could you send me your email address? I got a response from my contacts at AMD and they would like some more information. I would like to include you in the discussion/my response. frost<dot>gary<at>gmail.com.....
Jeffrey Phillips Freeman
@freemo
@pgt_gitlab If your willing, could you ask @grfrost to cc me in so I can follow the conversation. While I dont think there is much need for the licensing conversation given that the license already freely allows for relicensing (as per our earlier talk and mine without our lawyer), I'd still like to follow the conversation and see if anything develops. Particularly if you decide to pursue it.
@grfrost BTW I have been in touch with the debian lead and mentioned to @pgt_gitlab earlier that we already legally and within the bounds of the license licensed under the Apache license. Unless something has changed botht he debian guy and @pgt_gitlab seem to be moving forward with the project under the apache license. I have no objection to AMD getting their say, however considering we are already granted the legal right explicitly under the original license I'm not sure what benefit could come out of the AMD conversation since we dont need them to relicense to MIT. With that said I do think talking to the guys at AMD about them possibly endorsing or contributing to the project or even just having a voice or input is a good thing in general, but for that I think I should talk to them personally (though I dont mind in the least if @pgt_gitlab would like to speak with them as well).
grfrost
@grfrost
@freemo Ah. I had no idea that you had synced with @pgt_gitlab and they were good to go ;) In which case I am happy to withdraw the request for help from AMD. If I hear from @pgt_gitlab that he would still like an intro I will also cc you on the intro email.
Jeffrey Phillips Freeman
@freemo
@grfrost talk to @pgt_gitlab regarding withdrawing the request.. While I dont think the request is needed, if he finds it helpful then by all means feel free to continue. I obviously dont think it would hurt if they explicitly converted their license. I dont think its needed, but at the very least it might help prevent future confusion and questions so if they are willing it seems it might be a good thing. Just seems like a waste of energy in some ways as legally speaking it isnt needed as it isnt a copyleft license in the first place and the extra clause in no way changes the condition of the MIT license. In fact in a way the extra clause can be seen as separate from the license itself in my mind, its more of a liability statement than a licensing term. But ont quote me on this im not lawyer, just my interpretation of what I learned from when the lawyer reviewed it.
@grfrost I dont wish to speak for pgt though, when I say i synced upw ith him I mean in this room here on gitter, see the conversation up above. While my chat witht he debian guy was via email in private my talk with @pgt_gitlab is in the open a few lines up ^^^
Gruet
@pgt_gitlab
Hi @grfrost and @freemo , and thanks again for your help :-)
Reading you, I feel you clarified things enough so that we do not need further license changes, although this might help in the future to prevent confusion. From Debian side, we (as developers) consider it's fine, but we will have to convince our FTP masters if they have doubts about the wording, so that aparapi finally gets accepted into Debian and its derivatives.
So maybe we could stay as we are now and only speak with AMD if it appears, in the coming weeks, that the wording prevents the inclusion in Debian? I am yet writing to you, @grfrost, so that you have my email if we have to deepen our conversation with AMD.
To be exhaustive: before your great inputs of the last days, I wrote a post in the forum of the Devgurus community of AMD, asking about this licensing issue. Someone answered he/she would transfer to the appropriate team... it seems it is a bit late for me to withdraw this request, yet I will try to postpone things if it appears we don't need to lose time on new licensing terms.
Jeffrey Phillips Freeman
@freemo
@pgt_gitlab I cant imagine much harm would happen by talking tot he AMD guys. Like you said if they do change the license it might be a bit of a waste of energy but ultimately might be marginally useful in case others have similar concerns so I dont need to justify the license change. The only way I could see anything negative coming out of it is if the AMD guys act as large companies sometimes act and push their weight around not in regard to the law or rights under the license but rather some other purpose. I have no reason to think AMD would do this however as they have never given us any problem after I picked up the project when they abandoned it. But a scary scenario i could envision would be if they have some sort of as-of-yet unreleased product that Aparapi might compete with and they may feel it is in their best interest to squash Aparapi.. but again I have absolutely no reason to think that is either the case or what AMD would do as a company... its just the old adage of poking sleeping dragons I suppose.
Jeffrey Phillips Freeman
@freemo
@grfrost hey you around, i wanted to ask you about your merge request
Jeffrey Phillips Freeman
@freemo
@grfrost I wrote a minor comment about your edit, the if block on the outside you added does not appear to do anything, so i will remove it, but the rest of your edit looks good. Let me know, however if you have any objections to that. See my comments here: https://git.qoto.org/aparapi/aparapi/-/merge_requests/6
Jeffrey Phillips Freeman
@freemo
@/all I did some work on our repo/ci tonight for a few hours.. I got the CI working over at our official repo and specifically got it setup so it runs on a GPU enabled CI.. I thought we already had but apparently I was wrong. There wasnt even a CI file in the repo. Anyway its all setup now!
Jeffrey Phillips Freeman
@freemo
@/all Hey guys, I spent the last three days solid working on Aparapi stuff, mostly CI and containers so we could run more thorough unit tests. I wrote a new repo here with various docker containers (which are up on dockerhub) that contain various OpenCL backends, a java jdk environment, aparapi pre-installed, and instructions on how to run them on GPU enabled machines (they take full advantage of GPU acceleration). For now they include amdgpu and nvidia, I plan to add an intel, pocl, and maybe rocm images next. While they are generally useful for anyone who wants to test or run an aparapi app in docker, or as part of a CI I also needed them specifically for our own CI so I can test aparapi against several backends at once before doing a release. Here is the repo for the docker images if your interested with those instructions (I have tested them both on GPU enabled devices): https://git.qoto.org/aparapi/aparapi-docker
What I found, however, is that while all the unit tests pass and work just fine on CPU (non GPU enabled) setups for AMDGPU and NVIDIA, unfortunately 4 of our unit tests fail on NVIDIA GPU enabled systems, the rest pass though (so it mostly works).. I will be opening issues for this and looking into if I can fix them. But just letting everyone know about our new CI and the docker images I created
Jeffrey Phillips Freeman
@freemo
You can see examples of the newly running pipelines here and click the failing one to see the failed tests: https://git.qoto.org/aparapi/aparapi/-/pipelines/638
grfrost
@grfrost
Nice work. Like the pipeline output. The NVidia breaks seem to be barrier related.
Jeffrey Phillips Freeman
@freemo
@grfrost thanks.. it was getting critical since travis stopped working sometime back and well we have a new CI pipeline anyway...
@grfrost It also seemed critical just so people could use aparapi on systems where they may not want the hassle of installing opencl and getting it all working... most systems already have good drivers for their hardware that opencl can talk to but just lack opencl itself. so i think the docker containers will make it a lot easier to use Aparapi for others too. Not to mention useful in the CI of aparapi based applications in much the same way it is used in aparapi.