Posts tagged ‘ACTA’

Raspberry Pi: Compute Module CubeSats

This post was syndicated from: Raspberry Pi and was written by: David Honess. Original post: at Raspberry Pi

CubeSats are a type of miniature satellite that’s around the size of a shoe box and made from easily available, non-aerospace, parts. Because CubeSats use widely supported technologies, you no longer have to be a government or a space corporation to send a satellite into orbit: building a CubeSat is within the reach of individuals, universities and other organisations. The small size of the Raspberry Pi Compute Module makes it suitable for this very exciting application, and today we have a guest blog post from the University of Surrey to tell us more.

The Surrey Space Centre, Chris Bridges and CubeSats

Dr Chris Bridges leads the spacecraft On-Board Data Handling group in the Surrey Space Centre at the University of Surrey. He researches and teaches computer hardware and software to provide reliable computer processing in the harsh radiation environment of space. Chris is also an amateur radio enthusiast, with a passion for hacking almost any electronics for space and telling everyone that the sky is most definitely not the limit. He was involved at the beginning of the Astro Pi project back in 2014, since he has been working on numerous space flight projects involving Raspberry Pi devices and has been doing thermal and vacuum tests on them with his students.

Dr Chris Bridges

Dr Chris Bridges

Together with Surrey Satellite Technology Ltd, he designed, built, programmed, launched, and operated the UK’s first CubeSat, called STRaND1. The STRaND1 mission aimed to train new researchers and students as well as to launch novel payloads aboard CubeSats, including a smartphone. The team is proud of the enthusiastic coverage that the BBC and New Scientist magazine gave to the world’s first ‘phone-sat’!

 STRaND-1 CubeSat

STRaND-1 flight ready February 2013 with Shaun Kenyon, Dr Peter Shaw, Dr Chris Bridges | Photo courtesy of Surrey Satellite Technology Ltd

Raspberry Pi in space: detecting other CubeSats

Space is a harsh environment where it’s difficult to ensure that a computer will operate reliably for an extended period of time. Cosmic radiation interferes with transistors and can bit-flip computer memory (change the state of a single binary bit from a 0 to a 1 or from a 1 to a 0) causing what’s known as a single event upset crash.

Solving this is traditionally highly expensive, but using commercial off-the-shelf technologies has been proven as an effective method in reducing these costs. Being small, powerful, and low-cost, with large community support, Raspberry Pis are an obvious candidate here, provided that they can operate reliably in space. Chris says,

CubeSats and nanosatellites are a great educational tool used around the world – for students, staff, and researchers to learn about the Earth, and explore further into our solar system. For me, the new tech I’d like to try out is towards better computing parts – the Raspberry Pi fits the bill here.

Led by Professor Craig Underwood at the Surrey Space Centre, Chris is working on the on-board computer for the STRaND2 and AAReST CubeSat missions, along with CalTech and the NASA Jet Propulsion Laboratory in the US. These CubeSat missions require the processing and detection of other CubeSats in flight for rendezvous and docking experiments, as well as for collision avoidance manoeuvres.

These kinds of CubeSats employ light detection and ranging technologies (LIDAR) as a way to measure distance to nearby objects in space. This works by illuminating the target with a laser beam and then analysing the reflected light to calculate how far away the target is.

Postgrad student Richard Duke achieved this with a Raspberry Pi, an ordinary Microsoft Kinect and some custom Linux drivers that he rewrote himself. He now works at Surrey Space Centre as a software engineer. Enthusiasts can find detailed information in Craig and Chris’ paper on AAReST published in Acta Astronautica and their paper on STRaND2 at the IEEE/AIAA Aerospace Conference.


AAReST concept demonstrating the launch of four CubeSats (left), initial configuration (middle) and secondary configuration (right) after successful in-flight docking manoeuvres.

Richard says,

The project allowed me to gain real-world technical knowledge into Linux hardware drivers and the building of a full LIDAR sensor package. Using low-cost but highly capable components such as the Raspberry Pi in spaceflight is a hugely exciting area of technology. It’s been fantastic to be a part of developing real space projects as part of my Masters degree.

Here is a video of Richard’s work, showing a Raspberry Pi Model B controlling a CubeSat on a frictionless test platform. It’s sending the LIDAR information over WiFi back to a Windows laptop which is processing it. The detection algorithm autonomously obtains the range and pose of the target/obstacle (the cardboard Kinect box) sixteen times every second. You can even hear the compressed air propulsion from the CubeSat firing as it gets close to the target in order to avoid a collision.

Raspberry Pi + SoftKinectic + WiFi + Battery Pack = Satellite LIDAR

Towards the AAResT mission with CalTech and NASA JPL, MSc student Richard Duke shows us his developments for soft and hard real-time rendezvous and docking on the granite table for new close proximity operations. It shows the RPi B+ routing the LIDAR information over WiFi TCP back to be plotted.


A Model B Raspberry Pi sits at the top of this LIDAR CubeSat stack

The Raspberry Pi Compute Module and reliability through redundancy

One way of making sure that a Raspberry Pi can operate reliably in space is through redundancy: if multiple Raspberry Pis are used, then if one of them should fail, another can take over (the same system used on the space shuttle). Using this method, students at the Surrey Space Centre have developed several on-board computer systems.

The smallest size of the popular CubeSat format measures just 10x10x10cm (known as 1U), and the largest 10x10x34cm (3U). As physical space is at a premium inside a CubeSat, undergraduate Oliver Launchbury-Clark developed a new on-board computer specifically for the AAReST CubeSat mission. Designed in KiCad (an open source PCB design tool), Oliver’s board is PC/104-compliant and features two Raspberry Pi Compute Modules and an MSP430 microcontroller to provide some ultra-low power functionality.

Raspberry Pi Compute Module, as used in CubeSats

The Compute Module contains the guts of a Raspberry Pi (the BCM2835 processor and 512Mbyte of RAM) as well as a 4Gbyte eMMC Flash device (which is the equivalent of the SD card in the Pi). This is all integrated onto a small 67.6x30mm board which fits into a standard DDR2 SODIMM connector (the same type of connector as that used for laptop memory).

The Raspberry Pis kindle an interest in space, programming and engineering in general by providing an accessible method for students of any age to have their programs run in space.

CubeSat on-board computer, featuring two Raspberry Pi Compute Modules

CubeSat on-board computer, featuring two Raspberry Pi Compute Modules

CubeSats: widening access to space

Building CubeSats is just as hard as building a full satellite – but being able to use the latest technologies that are widely supported means that access is no longer restricted to government space programmes or large space corporations. Now, universities and private individuals can undertake these ambitious projects too.

Craig and Chris visited Caltech in Pasadena USA and got a chance to visit the NASA Jet Propulsion Laboratory in September 2015. Chris writes,

It’s a truly inspiring place – and we now need to build and work on the software to meet all the mission requirements.


Craig and Chris at NASA Jet Propulsion Laboratory

At the SmallSat Conference in Utah, it was announced that the AAReST mission is planned for launch in 2018 – just one of the many CubeSat missions NASA is working on.

The tweet below shows different CubeSat missions (rows) and when they were/are planned to fly (columns). For more information go here.

Chris Brunskill on Twitter

Cubesat business worth $100m to @NASAJPL. 17 missions planned through to 2018 #SpaceMissionUK #SmallSat15

Many thanks to the Raspberry Pi Foundation for donating Pis and a Compute Module to begin all this development. Chris will be looking for more Surrey students to get involved to create new software chains with US partners – so feel free to get in touch with him to help develop their line of CubeSats!

The post Compute Module CubeSats appeared first on Raspberry Pi.

TorrentFreak: There Aren’t More Horrible Backroom Deals, We’re Getting Better At Spotting Them

This post was syndicated from: TorrentFreak and was written by: Rick Falkvinge. Original post: at TorrentFreak

copyright-brandedHave you heard of WCT or WPPT? Or TRIPs?

Odds are you haven’t.

But you’ve probably heard of the DMCA, EUCD, and/or InfoSoc.

This simple fact illustrates very quickly how much better we’ve become in just ten years. WCT is the WIPO Copyright Treaty, and WPPT is the WIPO Performances and Phonograms Treaty. They were the backroom deals from 1996 that forced the DMCA and the EUCD to happen in 1998 and 2001, respectively.

Once the international agreements were inked, they had to be ratified. It didn’t help too much to protest the DMCA’s rectocranialism at that point, because its principal contents had already been locked in.

So now that we’re spotting yet another one of these bullshit backroom deals, TISA (the Talking In Shades Agreement, which it doesn’t stand for but that’s how I like to read it), which is about curtailing the Internet and civil liberties in order to benefit big business, we know what it will lead to if we don’t kill it in time.

…Oh, who am I kidding? Specifying “the agreement is about curtailing the Internet and civil liberties to the benefit of big business” doesn’t clarify a bit. Every single shady backroom deal has been about that.

TISA – which is supposed to stand for Trade in Services Agreement – was brought to attention by the EFF about ten days ago, and its contents were leaked by WikiLeaks shortly thereafter. That’s not bad. That’s getting considerably better. If we had done that with WPPT and WCT in 1993 and 1994, we wouldn’t have had the abominations of DMCA and EUCD today.

Not to mention the TRIPs agreement. Have you heard of that? Odds are you haven’t. It was essentially the US locking in its position as king of the hill by redefining most economic metrics so the rest of the world would be forced to pay rent. (For the interested, there’s an excellent book about how that agreement came to be. It’s worse than you think. Much worse.) It was one of the first deals where the copyright industry realized just how much rent they could extort from the public by ganging up against everybody else.

However, we didn’t have a developed Internet when the WCT, WPPT, or TRIPs were being drafted in the early 1990s. We do now. That’s why we were able to stop SOPA, PIPA, and ACTA. And that’s why we will be able to stop the TTIP, TPP, and this TISA abomination as well.

Things aren’t getting worse. What’s happening is that we have taken ourselves the right and the ability to put spotlights and sunlight on all the dirt. And this particular kind of dirt doesn’t survive sunlight.

The lobbyists will keep trying, for sure. For a while. They’re paid to do so, after all. Until their sponsors start noticing the nonexistent return on a considerable investment.

We haven’t won yet, but even though we’re digging up more dirt every year, the fact that we’re now digging up this dirt and exposing it means that we’re winning the long term.

After all, we have the Web and they don’t. When the Internet gangs up on the bad guy, the bad guy loses. Every single time.

I don’t think the copyright maximalists know how to deal with that fact.

About The Author

Rick Falkvinge is a regular columnist on TorrentFreak, sharing his thoughts every other week. He is the founder of the Swedish and first Pirate Party, a whisky aficionado, and a low-altitude motorcycle pilot. His blog at focuses on information policy.

Book Falkvinge as speaker?

Source: TorrentFreak, for the latest info on copyright, file-sharing, torrent sites and anonymous VPN services.

Bradley M. Kuhn's Blog ( bkuhn ): Federal Appeals Court Decision in Oracle v. Google

This post was syndicated from: Bradley M. Kuhn's Blog ( bkuhn ) and was written by: Bradley M. Kuhn. Original post: at Bradley M. Kuhn's Blog ( bkuhn )

[ Update on 2014-05-13: If you’re more of a listening
rather than reading type, you might
enjoy the Free as
in Freedom
oggcast that
Karen Sandler and I recorded about this topic
. ]

I have a strange relationship with copyright law. Many copyright policies
of various jurisdictions, the USA in particular, are draconian at best and
downright vindictive at worst. For example, during the public comment
period on ACTA, I
commented that
I think it’s always wrong, as a policy matter, for
copyright infringement to carry criminal penalties.

That said, much of what I do in my work in the software freedom movement
is enforcement of copyleft: assuring that the primary legal tool, which
defends the freedom of the Free Software, functions properly, and actually
works — in the real world — the way it should.

As I’ve written
about before at great length
, copyleft functions primarily because it
uses copyright law to stand up and
defend the four
. It’s commonly called a hack on copyright: turning the
copyright system which is canonically used to restrict users’ rights, into
a system of justice for the equality of users.

However, it’s this very activity that leaves me with a weird relationship
with copyright. Copyleft uses the restrictive force of copyright in the
other direction, but that means the greater the negative force, the more
powerful the positive force. So, as I read yesterday
the Federal
Circuit Appeals Court’s decision in Oracle v. Google
, I had that
strange feeling of simultaneous annoyance and contentment. In this blog
post, I attempt to state why I am both glad for and annoyed with the

I stated clearly
after Alsup’s decision NDCA decision in this case
that I never thought
APIs were copyrightable, nor does any developer really think so in
practice. But, when considering the appeal, note carefully that the
court of appeals wasn’t assigned the general job of considering whether
APIs are copyrightable. Their job is to figure out if the lower court
made an error in judgment in this particular case, and to
discern any issues that were missed previously. I think that’s what the
Federal Circuit Court attempted to do here, and while IMO they too erred
regarding a factual issue, I don’t think their decision is wholly useless
nor categorically incorrect.

Their decision is worth reading in full. I’d also urge anyone who wants
to opine on this decision to actually read the whole thing (which
so often rarely happens in these situations). I bet most pundits out there
opining already didn’t read the whole thing. I read the decision as soon
as it was announced, and I didn’t get this post up until early Saturday
morning, because it took that long to read the opinion in detail, go back
to other related texts and verify some details and then write down my
analysis. So, please, go ahead, read it now before reading this blog post
further. My post will still be here when you get back. (And, BTW, don’t
fall for that self-aggrandizing ballyhoo some lawyers will feed you that
only they can understand things like court decisions. In fact, I think
programmers are going to have an easier time reading decisions about this
topic than lawyers, as the technical facts are highly pertinent.)

you’ve read
the decision now
? Good. Now, I’ll tell you what I think in detail: (As
always, my opinions on this are my own,
TINLA and these are my
personal thoughts on the question.)

The most interesting thing, IMO,
about this decision is that the Court focused on a fact from trial that
clearly has more nuance than they realize. Specifically, the Court claims
many times in this decision that Google conceded that it copied the
declaring code used in the 37 packages verbatim
(pg 12 of the Appeals

I suspect the Court imagined the situation too simply: that there was a
huge body of source code text, and that Google engineers sat there, simply
cutting-and-pasting from Oracle’s code right into their own code for each of
the 7,000 lines or so of function declarations. However, I’ve chatted with
some people (including Mark
J. Wielaard
) who are much more deeply embedded in the Free Software Java
world than I am, and they pointed out it’s highly unlikely anyone did a
blatant cut-and-paste job to implement Java’s core library API, for various
reasons. I thus suspect that Google didn’t do it that way either.

So, how did the Appeals Court come to this erroneous conclusion? On page
27 of their decision, they write: Google conceded that it copied it
verbatim. Indeed, the district court specifically instructed the jury that
‘Google agrees that it uses the same names and declarations’ in
Charge to the Jury at 10. So, I reread
10 of the final charge to the jury
. It actually says something much
more verbose and nuanced. I’ve pasted together below all the parts where
the Alsup’s jury charge mentions this issue (emphasis mine):

Google denies infringing any such copyrighted material … Google agrees
that the structure, sequence and organization of the 37 accused API packages
in Android is substantially the same as the structure, sequence and
organization of the corresponding 37 API packages in Java. …
The copyrighted Java platform has more than 37 API packages and so
does the accused Android platform. As for the 37 API packages that overlap,
Google agrees that it uses the same names and declarations but contends that
its line-by-line implementations are different … Google agrees that
the structure, sequence and organization of the 37 accused API packages in
Android is substantially the same as the structure, sequence and
organization of the corresponding 37 API packages in Java. Google states,
however, that the elements it has used are not infringing …
With respect to the API documentation, Oracle contends Google copied
the English-language comments in the registered copyrighted work and moved
them over to the documentation for the 37 API packages in Android. Google
agrees that there are similarities in the wording but, pointing to differences as
well, denies that its documentation is a copy
. Google further asserts that the
similarities are largely the result of the fact that each API carries out the same
in both systems.

Thus, in the original trial, Google did not admit to
copying of any of Oracle’s text, documentation or code (other than the
rangeCheck thing, which is moot on the API copyrightability issue).
Rather, Google said two separate things: (a) they did not copy any material
(other than rangeCheck), and (b) admitted that the names and declarations
are the same, not because Google copied those names and
declarations from Oracle’s own work, but because they perform the same
functions. In other words, Google makes various arguments of why those
names and declarations look the same, but for reasons other than
“mundane cut-and-paste copying from Oracle’s copyrighted

For we programmers, this is of course a distinction without any
difference. Frankly, programmers, when we look at this situation, we’d
make many obvious logical leaps at once. Specifically, we all think APIs
in the abstract can’t possibly be copyrightable (since that’s absurd), and
we work backwards from there with some quick thinking, that goes something
like this: it doesn’t make sense for APIs to be copyrightable because if
you explain to me with enough detail what the API has to, such that I have
sufficient information to implement, my declarations of the functions of
that API are going to necessarily be quite similar to yours — so much
so that it’ll be nearly indistinguishable from what those function
declarations might look like if I cut-and-pasted them. So, the fact is, if
we both sit down separately to implement the same API, well, then we’re
likely going to have two works that look similar. However, it doesn’t mean
I copied your work. And, besides, it makes no sense for APIs, as a general
concept, to be copyrightable so why are we discussing this

But this is reasoning a programmer can love but the Courts hate. The
Courts want to take a set of laws the legislature passed, some precedents
that their system gave them, along with a specific set of facts, and then
see what happens when the law is applied to those facts. Juries, in turn,
have the job of finding which facts are accurate, which aren’t, and then
coming to a verdict, upon receiving instructions about the law from the

And that’s right where the confusion began in this case, IMO. The
original jury, to start with, likely had trouble distinguishing three
distinct things: the general concept of an API, the specification of the
API, and the implementation of an API. Plus, they were told by the judge
to assume API’s were copyrightable anyway. Then, it got more confusing
when they looked at two implementations of an API, parts of which looked
similar for purely mundane technical reasons, and assumed (incorrectly)
that textual copying from one file to another was the only way to get to
that same result. Meanwhile, the jury was likely further confused that
Google argued
various affirmative
against copyright
infringement in
the alternative

So, what happens with the Appeals Court? The Appeals court, of course,
has no reason to believe the finding of fact of the jury is wrong, and it’s
simply not the appeals court’s job to replace the original jury’s job, but to
analyze the matters of law decided by the lower court. That’s why I’m
admittedly troubled and downright confused that the ruling from the Appeals
court seems to conflate the issue of literal copying of text and
similarities in independently developed text. That is a factual issue in
any given case, but that question of fact is the central nuance to API
copyrightiable and it seems the Appeals Court glossed over it. The Appeals
Court simply fails to distinguish between literal cut-and-paste copying
from a given API’s implementation and serendipitous similarities that are
likely to happen when two API implementations support the same API.

But that error isn’t the interesting part. Of course, this error is a
fundamental incorrect assumption by the Appeals Court, and as such the
primary ruling are effectively conclusions based on a hypothetical fact
pattern and not the actual fact pattern in this case. However, after
poring over the decision for hours, it’s the only error that I found in
the appeals ruling. Thus, setting the fundamental error aside, their
ruling has some good parts. For example, I’m rather impressed and swayed
by their argument that the lower court misapplied the merger doctrine
because it analyzed the situation based on the decisions Google had with
regard to functionality, rather than the decisions of Sun/Oracle. To

We further find that the district court erred in focusing its merger analysis
on the options available to Google at the time of copying. It is
well-established that copyrightability and the scope of protectable activity
are to be evaluated at the time of creation, not at the time of infringement.
… The focus is, therefore, on the options that were available to
Sun/Oracle at the time it created the API packages.

Of course, cropping up again in that analysis is that same darned
confusion the Court had with regard to copying this declaration code. The
ruling goes on to say: But, as the court acknowledged, nothing prevented
Google from writing its own declaring code, along with its own implementing
code, to achieve the same result.

To go back to my earlier point, Google likely did write their own
declaring code, and the code ended up looking the same as the
other code, because there was no other way to implement the same API.

In the end, Mark J. Wielaard put it best when he read the decision,
pointing out to me that the Appeals Court seemed almost angry that the jury
hung on the fair use question. It reads to me, too, like Appeals Court is
slyly saying: the right affirmative defense for Google here is fair use,
and that a new jury really needs to sit and look at it

My conclusion is that this just isn’t a decision about the copyrightable
of APIs in the general sense. The question the Court would need to
consider to actually settle that question would be: “If we believe an
API itself isn’t copyrightable, but its implementation is, how do we figure
out when copyright infringement has occurred when there are multiple
implementations of the same API floating around, which of course have
declarations that look similar?” But the court did not consider that
fundamental question, because the Court assumed (incorrectly)
there was textual cut-and-paste copying. The decision here, in my
view, is about a more narrow, hypothetical question that the Court decided
to ask itself instead: “If someone textually copies parts of your API
implementation, are
, scènes
à faire
and de
affirmative defenses like to succeed?“ In this
hypothetical scenario, the Appeals Court claims “such defenses rarely help you, but
a fair use defense might help you”.

However, on this point, in my copyleft-defender role, I don’t mind this
decision very much. The one thing this decision clearly seems to declare
is: “if there is even a modicum of evidence that direct textual
copying occurred, then the alleged infringer must pass an extremely high
bar of affirmative defense to show infringement didn’t occur”. In most GPL violation cases,
the facts aren’t nuanced: there is always clearly an intention to
incorporate and distribute large textual parts of the GPL’d code (i.e., not
just a few function declarations). As such, this decision is probably good
for copyleft, since on its narrowest reading, this decision upholds the
idea that if you go mixing in other copyrighted stuff, via copying and
distribution, then it will be difficult to show no copyright infringement

OTOH, I suspect that most pundits are going to look at this in an overly
contrasted way: NDCA said API’s aren’t copyrightable, and the Appeals Court
said they are. That’s not what happened here, and if you look at the
situation that way, you’re making the same kinds of oversimplications that
the Appeals Court seems to have erroneously made.

The most positive outcome here is that a new jury can now narrowly
consider the question of fair use as it relates to serendipitous similarity
of multiple API function declaration code. I suspect a fresh jury focused
on that narrow question will do a much better job. The previous jury had
so many complex issues before them, I suspect that they were easily
conflated. (Recall that the previous
jury considered
patent questions as well
.) I’ve found that people who haven’t spent
their lives training (as programmers and lawyers have) to delineate complex
matters and separate truly unrelated issues do a poor job at such. Thus, I
suspect the jury won’t hang the second time if they’re just considering the
fair use question.

Finally, with regard to this ruling, I suspect this won’t become
immediate, frequently cited precedent. The case is remanded, so a new jury
will first sit down and consider the fair use question. If that jury finds
fair use and thus no infringement, Oracle’s next appeal will be quite weak,
and the Appeals Court likely won’t reexamine the question in any detail.
In that outcome, very little has changed overall: we’ll have certainty that
API’s aren’t copyrightable, as long as any textual copying that occurs
during reimplementation is easily called fair use. By contrast, if the new
jury rejects Google’s fair use defense, I suspect Google will have to
appeal all the way to SCOTUS. It’s thus going to be at least two years
before anything definitive is decided, and the big winners will be wealthy
litigation attorneys — as usual.

0This is of course true
for any sufficiently simple programming task. I used to be a high-school
computer science teacher. Frankly, while I was successful twice in detecting
student plagiarism, it was pretty easy to get false positives sometimes. And
certainly I had plenty of student programmers who wrote their function
declarations the same for the same job! And no, those weren’t the
students who plagiarized.