Source: Slashdot
Qualcomm has forced GitHub to remove over 100 repositories due to "unauthorized publication, disclosure, and copying of highly sensitive, confidential, trade secret, and copyright-protected documents." Among the repositories taken down were for CyanogenMod and Sony Xperia. The issue though is that these "highly sensitive" and "confidential" files are Linux kernel code and reference/sample code files that can be easily found elsewhere, including the Android kernel, but GitHub has complied with Qualcomm's DMCA request.
Click to expand...
Click to collapse
That's not good.
Umm... Wow
Then, there is this...http://www.androidpolice.com/2014/0...some-belonging-to-cyanogen-sony-and-qualcomm/
Related
The device database does not have an option to filter based on if the manufacture has release the source or not. Has anyone compiled this data????
I need a cheap device that I can customise for a customer at work but the first batch is a low number (field trials) so can't really justify commissioning our own device.
Failing that just have to keep trawling the forum for devices that have the source, rather hard going.
http://www.codon.org.uk/~mjg59/android_tablets/
here are for tablets.
the most manufacturers are really annoying me, they didn't release their sourcecode for the devices...
its a big violation against GPL (or is big G using apache licence?)
prepare for some kind of discussion.
First off, I didn't know where to put this. I was hoping for a generic Android forum, but General seems to be as close as I can get. This is a device independent question about Android, and of a more philosophical nature. Although there may be a practical solution in here. I've flagged this as a question, and I have a lot of them here (IANAL) but I'm hoping for some good discussion as well.
Bear with me as a say some very obvious things, I want people to follow my train of thought from the beginning. I'm also dead tired and don't want to take any of my presuppositions for granted.
It seems to me that locking bootloader is done by companies to prevent people from modifying the OS (DuH!). Yet is also seems to me that the purpose of having an open source OS is for that OS to be freely modifiable. So when a company locks the bootloader on the hardware they have violated the intent of the open source OS.
Now I know that the intent of a contract or license may not be enforceable in a court of law, and few will risk the money to attempt to resolve this through litigation.
Given the above, can or should the GPL be modified to take the unstated intent of allowing modification to code by anyone and "hard code" that intent directly into the GPL?
It is my assumption that such a change to the GPL would not be retroactive, but rather would apply to newer releases of the Linux kernel. So what would the fallout from a change of this nature be? Could it kill Android as Google is forced by the rest of the OHSA not to continue kernel development past a certain point to avoid having the revised GPL ruin their attempts to proprietize Android? Could the GPL be changed to be in effect from a certain date onward rather than from a certain revision on?
Col.Kernel said:
First off, I didn't know where to put this. I was hoping for a generic Android forum, but General seems to be as close as I can get. This is a device independent question about Android, and of a more philosophical nature. Although there may be a practical solution in here. I've flagged this as a question, and I have a lot of them here (IANAL) but I'm hoping for some good discussion as well.
Bear with me as a say some very obvious things, I want people to follow my train of thought from the beginning. I'm also dead tired and don't want to take any of my presuppositions for granted.
It seems to me that locking bootloader is done by companies to prevent people from modifying the OS (DuH!). Yet is also seems to me that the purpose of having an open source OS is for that OS to be freely modifiable. So when a company locks the bootloader on the hardware they have violated the intent of the open source OS.
Now I know that the intent of a contract or license may not be enforceable in a court of law, and few will risk the money to attempt to resolve this through litigation.
Given the above, can or should the GPL be modified to take the unstated intent of allowing modification to code by anyone and "hard code" that intent directly into the GPL?
It is my assumption that such a change to the GPL would not be retroactive, but rather would apply to newer releases of the Linux kernel. So what would the fallout from a change of this nature be? Could it kill Android as Google is forced by the rest of the OHSA not to continue kernel development past a certain point to avoid having the revised GPL ruin their attempts to proprietize Android? Could the GPL be changed to be in effect from a certain date onward rather than from a certain revision on?
Click to expand...
Click to collapse
Only the kernel is covered by gpl and that only states that you have to post the source code for the kernel if it has been modified. The rest of the OS is not covered by the GPL and neither is the hardware. As long as they give you the source code they do not have to allow the code to be changed on their device.
Col.Kernel said:
Given the above, can or should the GPL be modified to take the unstated intent of allowing modification to code by anyone and "hard code" that intent directly into the GPL?
Click to expand...
Click to collapse
This already happened. It's called GPLv3. However, the Linux kernel is GPLv2 and will stay that way. Not only would moving to GPLv3 be extremely difficult because of the large number of contributors to the kernel, the main developers don't want it. Linus Torvarlds consciously and deliberately made the kernel GPLv2-only in 2000 or so, a decision he still firmly stands by.
Also, the GPLv3 already has fallouts like what you state. For example, Apple did not go beyond GCC 4.2 (the last GPLv2 version, newer versions of GCC are GPLv3) and is instead financing the development of Clang.
The GPLv3 would not so much kill Android (Google would transition to a new kernel), it could kill Linux, as companies would potentially be moving away from it, similarly to how Apple is moving from GCC to Clang. Or, quite likely, there would be a fork of the kernel.
Please use the Q&A Forum for questions Thanks
Moving to Q&A
Hey devs, lawyers and people who know about GPL
I have a question about using GPL'ed source code in a closed source application.
Another question has been easily answered in the news comments, but as libav/ffmpeg is LGPL and has a nice legal.html it was solved quickly.
Here is what it's all about:
- I'm going to use Linux kernel drivers code (several (ten-)thousand lines of code across 10+ files) for several USB devices using JNI and the Android USB host interface
- I'm writing a wrapper / "glue" library so almost no changes have to be made to the GPL code (to keep compatibility with newer versions of the GPL code)
Now my question is: Can I link all the *.o in one shared library or do I have to separate GPL code and wrapper (may be closed source) code into different shared libraries (wrapper may still link to GPL code).
If this is illegal, does my wrapper code have to be GPL'ed as well, because it links against GPL code?
And how much / what of my application has to be GPL'ed since it uses GPL'ed code in any way?
As you can see I'm a bit confused about all the GPL stuff and don't want to get sued or blamed for violating the GPL.
PS: I'm still not sure if I may open source the app or not, but in case I don't want or can't to, I want to be legal at least.
I've done some more research and found out that it is not possible to link closed source directly to GPL'ed code, BUT it is possible to link against LGPL which itself is compatible with the GPL.
So in other words: The wrapper library itself will be open-sourced under the LGPL but the Android application, where most of the work will be done (UI, services, device handling, interfaces, etc.), may be still closed source.
Does this work?
chrulri said:
Does this work?
Click to expand...
Click to collapse
No, it doesn't. Read me. Unless one will pipe all the data flow through command line interface where the GPL'ed binary is running in a separated process (e.g. child process). Well even this is still a "slippery" path, concerning legal issues.
I guess I'll just GPL my app and hope for donations once it's published.
This particular kernel contains changes to the following:
- binder bugs, i.e. leaks, API misuse
- lowmem killer logic errors
- scheduler, i.e..spurious wakeups, "bouncing cow", fair scoring
- vm subsystem changes to oom killing, google lowmemkiller
- kswapd wasting CPU time no longer occurs
- cpufreq microoptimizations (wakeups, useless computation), interactive governor updated to latest version from msm-kernel for 3.10 Google Wear
Credits:
Kernel forked from work of another xda member. That's documented in github project itself, and revision history.
Changes come from Torvalds tree, msm and common. The kswapd fix comes from a google search. You can look for "contention_wait" yourself to note the source.
hxxps://github.com/sthalik/gcore_kernel
Pull requests and forks welcome. So are quality well-researched bug reports. Feature requests, only if sensible and educated.
-foo
foobie-bletch said:
This particular kernel contains changes to the following:
- binder bugs, i.e. leaks, API misuse
- lowmem killer logic errors
- scheduler, i.e..spurious wakeups, "bouncing cow", fair scoring
- vm subsystem changes to oom killing, google lowmemkiller
- kswapd wasting CPU time no longer occurs
- cpufreq microoptimizations (wakeups, useless computation), interactive governor updated to latest version from msm-kernel for 3.10 Google Wear
Credits:
Kernel forked from work of another xda member. That's documented in github project itself, and revision history.
Changes come from Torvalds tree, msm and common. The kswapd fix comes from a google search. You can look for "contention_wait" yourself to note the source.
hxxps://github.com/sthalik/gcore_kernel
Pull requests and forks welcome. So are quality well-researched bug reports. Feature requests, only if sensible and educated.
-foo
Click to expand...
Click to collapse
Hi there! I would love to try it, how could I?
First post includes a link to the sources. Given an ARM cross-compiler that can build the kernel, it's a matter of repacking initrd and flashing.
Unless you suffer from the kswapd issue, there's little point. Fixes included aren't something you'd notice after using the software briefly.
My intention is to make available the changes. Whether they're given attention or are reviewed at all, doesn't depend on me really.
-foo
foobie-bletch said:
First post includes a link to the sources. Given an ARM cross-compiler that can build the kernel, it's a matter of repacking initrd and flashing.
Unless you suffer from the kswapd issue, there's little point. Fixes included aren't something you'd notice after using the software briefly.
My intention is to make available the changes. Whether they're given attention or are reviewed at all, doesn't depend on me really.
-foo
Click to expand...
Click to collapse
Thanks a lot for your answer, I would love to try it, but i don´t know how to compile a kernel
Contact Ali filth may be he could help.
Sent from my GT-I8262 using XDA Premium 4 mobile app
Please note, you don't have to fork the repository on github to follow the changes.
If you in fact never compile kernels yourself you're not my intended audience.
Still, getting to know C is always the first step toward any serious Linux/Unix hacking.
Kernel stuff isn't any different than others. There are some rules to follow, but this is true of userland code, too. Documentation often says "don't do this and that". Just like with kernel API.
LineageOS (LOS, https://lineageos.org/) the successor to Cyanogenmod, is probably the most commonly used alternative Android operating system.
microG (https://microg.org/) is a free-as-in-freedom alternative to Google Play services. Unfortunately, Android ships in a state that allows only software from Google, Inc to provide play services. Users can override this by either including a signature spoofing patch when they compile their kernel or modifying their system after the fact (https://github.com/Lanchon/haystack & others).
Many users want microg installed in their kernel to avoid the hassle of modifying their system after installation. Unfortunately, the LOS team has decided not to allow the signature spoofing patch in mainline kernels. Thus, the microG team compiles its own kernels with microG and signature spoofing already installed. These are available at https://download.lineage.microg.org/.
Maintaining software is difficult and time consuming. The LineageOS team only supports devices for which someone has volunteered to be a maintainer. That is, someone has to volunteer to ensure that patches, security updates, and changes do not break the kernel. If the maintainer leaves (stops maintaining), the LOS team discontinues kernel builds for the device.
They also delete existing kernel builds from their website. Since microG follows the lead of LOS, they delete their "discontinued" builds too.
This has the effect that a user might not be able to access a ROM today that they could have downloaded last week.
I believe that people should be able to decide what ROM is best for them according to their own needs and at their own risk. Therefore, I am posting links to archived Samsung Galaxy Note II (t0lte) LineageOS for microG roms. These roms were archived by the Internet Archive (https://archive.org/).
Some disadvantages of these roms include that they are not updated and will likely receive no further updates (lack of security updates implies security vulnerabilities) and that there is no support for them.
On the other hand, they are cryptographically signed by the microG team and can be verified using the instructions on https://lineage.microg.org/. Some people want a plain ROM with minimal "extra features" and find that LineageOS provides this. Others disagree. You may decide that, on the whole, the security advantages of this ROM outweigh its disadvantages. Or not. As the user, its up to you.
All information and files — both in source and compiled form — are provided on an as is basis. No guarantees or warranties are given or implied. The user assumes all risks of any damages that may occur, including but not limited to loss of data, damages to hardware, or loss of business profits. Please use at your own risk. Note that unless explicitly allowed by the warranty covering your device, it should be assumed that any warranty accompanying your device will be voided if you tamper with either the system software or the hardware.
https://web.archive.org/web/20191215024949/https://download.lineage.microg.org/t0lte/lineage-14.1-20190303-microG-t0lte.zip
Wayback Machine
I am not a developer. I did not create, code, or compile this ROM. If you choose to use this ROM, you will need to figure out how to install it separately.