Hello,
Does anyone have a clear picture on the legalities of using the Ubuntu rootfs with a custom kernel, as RobertCNelson’s build system provides, in a commercial application (effectively a headless remote server)?
The Canonical site (http://www.canonical.com/intellectual-property-policy) has this to say:
“Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries. This does not affect your rights under any open source licence applicable to any of the components of Ubuntu.”
From this I take it that I cannot use the Ubuntu name anywhere on my product plain and simple. It also states that I have to ‘recompile the source code’ to create my own binaries. Does this mean I have to recompile every single package I have installed, or would this just apply to those specific to ubuntu, i.e. not those relating to projects undertaken outside of Canonical?
If anyone has a clearer picture of this I’d be grateful to hear it.
Regards,
Andrew Glen.
First, IANAL..
So you really asking the wrong group of people...
Looking around there is a few commercial projects that are shipping
devices with ubuntu on them. However MOST do not mention ANYWHERE they
are running ubuntu. Until you dig down into the provided gpl source,
then it becomes obvious. Of course obviously if you name your product
"ubuntu xyz" Canoncial is probably not going to be happy..
Anyways, talk to a lawyer..
Regards,
Thanks Robert,
I’m hoping to avoid lawyers if possible. Maybe you can help me with another causally related question: The reason I’m using you Ubuntu image is that it is more reliable for my application that the Debian rootfs (which has none of the legal constraints of ubuntu). The problem I get running Debian (using the new 3.12 kernel) is, using the CAN bus driver crashes about half the time the very first time it is opened after booting (one it has been opened successfully the first time, it can be brought up and down repeatedly with no issues). For reasons I am currently unable to understand, using the Ubuntu rootfs with exactly the same kernel, I get no such problem - perhaps there is something different with the scheduling or power management between these two systems?
Are there any settings or packages in the Debian rootfs you could suggest having a look at?
Regards,
Andrew Glen.
As a response to my own question, I have come up with a work-around to the CAN driver issue for anyone else who happens upon this problem:
The problem is caused by a call to ‘__pm_runtime_resume’ being made from within an interrupt routine - this occurs on random occasions when the CAN device is brought up immediately into a fault state (caused by starting the can received midway through a can tx by another device). the same call is made on other occasions, but seems to only cause an issue the very first time it is called.
Power management should not occur within an interrupt routine, so by making a special interrupt version of the routine calling ‘__pm_runtime_resume’, but with this call removed, I was able to get around the problem.
Further to this I found I could simply make a call to ‘void pm_runtime_irq_safe(struct device *dev);’ before opening the device to get around the problem.
In ‘/KERNEL/Documentation/power/runtime_pm.txt’ we have the following:
It is safe to execute the following helper functions from interrupt context:
pm_request_idle()
pm_request_autosuspend()
pm_schedule_suspend()
pm_request_resume()
pm_runtime_get_noresume()
pm_runtime_get()
pm_runtime_put_noidle()
pm_runtime_put()
pm_runtime_put_autosuspend()
pm_runtime_enable()
pm_suspend_ignore_children()
pm_runtime_set_active()
pm_runtime_set_suspended()
pm_runtime_suspended()
pm_runtime_mark_last_busy()
pm_runtime_autosuspend_expiration()
If pm_runtime_irq_safe() has been called for a device then the following helper
functions may also be used in interrupt context:
pm_runtime_idle()
pm_runtime_suspend()
pm_runtime_autosuspend()
pm_runtime_resume()
pm_runtime_get_sync()
pm_runtime_put_sync()
pm_runtime_put_sync_suspend()
pm_runtime_put_sync_autosuspend()
Calls to ‘pm_runtime_resume()’ were being made from the interrupt context without ‘pm_runtime_irq_safe’ having been called, so it makes sense that these problems were occurring, and that the problems went away after inserting this call.
I’ll post something to ‘linux-can’ to see what they think.
Regards,
Andrew Glen.