Maybe ask at https://www.amd.com/en/support/contact-email-form . To see if AMD would be willing to relicense?
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
@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.
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.
@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
@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?
@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.
@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
@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"
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
@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.
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?
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+.
Correct. Here is the sequence of msgs above which led to the posting of the headers from javah for java 8.
@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
@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!
@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!
@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
@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 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 ^^^
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.
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.
@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.
@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
@/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!
@/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
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 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.