Power, Memory and Schematics


Nice update; I certainly feel the CPU clocking issues needs resolving, marketing wise, 1.2GHz = 1.0GHz and 1.5GHz = 2.0GHz (*), so the device is suddenly half powered and way behind other tech. I appreciate that the idea behind the project isn't to "trick" people during marketing, but realistically we just want to market the correct clock speed for the device (and let peoples brain do the magic of rounding)! With all the hurdles that have been overcome during Pandora and Pyra, I have faith this one will be resolved somehow!

*I'm not going to provide any emperical evidence here, I'm sure if you Google around you'll find a lot of studies about things like setting price points, and how peoples brains want to group things together, typically by rounding in some form.
 
Honestly, I'd rather have the issue fixed than rushed out the door with a potential hardware issue, it should run at designed speeds. I know people want it now, just I feel that people will enjoy the device more if it's running like intended.


Oh of course, I am just saying I would be happy with 1.2
 
It's only the non-commercial aspect that makes that license non-free as far as I can tell. Presumably if you wanted to relicense it from ED you can talk to him and agree a fee, so I don't mind that restriction personally.
1. schematics should come standard with any purchase - that most vendors abuse us doesn't mean Pyra should be the same
2. the Pyra's price certainly is more than double that of the other proprietary competitor; presumably part of the justification for this is it was going to be open hardware
3. open schematics were a selling point from the start
4. another part of Pyra's value proposition is that people will be able to make upgrades. if only ED can do so commercially, this drastically reduces the possibility of such upgrades ever existing (therefore this license restriction is harming not just people who can make modifications, but all of us users)

FWIW, I do not personally have any competence in hardware design, so I could not do anything with them myself. So I would need to pay someone to make anything for me in the first place, even without additional fees. Paying someone to make a derived work, would be them commercially using the schematics. But especially point #4 is important to me.

P.S. China doesn't typically care about copyright licenses in the first place. They will probably make and sell cheap clones (or not) regardless of what license ED uses...
 
Last edited:
That even contradicts the FSF's understanding of a derivative work: Using and copying the original or parts of it makes a derivative, simply applying knowledge learned by studying the original doesn't.
If I have to study a previous project of someone else to learn how to solve specific problems in my current project, then I'm obviously creating a derivative work of the studied project in my mind.
If I write down these thoughts then this document becomes a derivative work of the studied project.
The key is, that I wouldn't have been able to create my project without studying the other one.

To add a little more substance:
A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”.
(source: http://mollykleinman.com/2008/10/20/cc-howto-no-derivatives/)

I argue, that applying knowledge to my project, that I learned by studying ED's schematics constitutes a translation.
In linguistics a translation often doesn't contain a single word of the original text, yet the original text is essential for creating the translated text. I don't see why it should be any different with design schematics.
 
@LukeJr

Point 1 is a fair point; maybe ED could relicense these designs as standard to anyone who gets sent a Pyra (though resellers might complicate that).

How likely are you to pay for a mod to your Pyra, honestly? Repair is one thing, but creating a derived work is something I'd only consider doing if I could do it myself, and even then I can't think of anything I'd want to do to improve my Pyra beyond what it already is. Maybe a new CPU board could be made by a third party, as I think ED suggested back in the day, and a different license will be needed for that, as I understand it, but that can be settled at least after the Pyra's been released, and they wouldn't need all of these schematics, just the CPU board interface. For now, the NC clause sits fine with me for all circumstances I can think of.
 
Some clarification from me (because I am the author) about CC-NC licensing (note: there is no -ND clause!) of the schematics:
* this license applies only to these PDF documents which are sort of a book publication.
* NC prevents that somebody else places the documents on a server behind a paywall.
* modding the device is something completely different than modding the PDF documents.
* like you can read any book and write your comments into you can do it here. You can publish and license your comments as you like.
* you can also learn for example mathematics or algorithms from a completely copyright protected text book and then use freely what you have learned. You can read some fiction and have fun with the story and talk about it. This is the main purpose why we publish it at all.
* CC license in general does not stop anyone from taking some CAD system and create a new design (Pyra 3... other CPU boards) based on the ideas found here.
* this project is not like typical open source hardware where publication of all material is intended to flood the world with as many copies and clones of the design as possible (Ardunino, RasPi, BeagleBone to name some examples). This approach is typically done/supported by chip manufacturers because it is free marketing for them and they sell the chips in any case. In other words, we have no exchange of making the Pyra completely unrestricted.
* as long as you are doing it non-commercialy you can do anything (except claiming you have produced the PDFs...).
* and even if you have commercial ideas, don't think in worst case scenarios. Even with NC you can simply ask to get an individual license. It may even be for free (as in free beer) if you ask politely... We do not want to cut your freedom (of speech) and ideas. We only want to know if someone makes something interesting out of it and remain able to decide case by case.
* for details about the license please read: https://creativecommons.org/licenses/by-nc-sa/3.0/ https://creativecommons.org/licenses/by-nc-sa/3.0/legalcode
 
Last edited:
If I have to study a previous project of someone else to learn how to solve specific problems in my current project, then I'm obviously creating a derivative work of the studied project in my mind.
If I write down these thoughts then this document becomes a derivative work of the studied project.
The key is, that I wouldn't have been able to create my project without studying the other one.

No. IANAL, but your notion of derivative work is too broad. You'd make every work in the world a derivative of the rest.
In your world, Newton would have said "I could only write my derivative work because I've stood on the originals of giants".
You may also have to read electronics textbooks to come up with your design, and that does not make your design a derivative
work of the textbook. The point is whether you could have used a different work to learn the same and still produce the work you produced.
If you could then your work is not a derivative of the one you learned from. It is a derivative work when
you need the original to produce the derivative, like in the examples you cited. You can't translate or abridge a text
if you haven't seen it. But you can learn elsewhere what you write in a text or consider in a design. Notice that
your source does not include "summarise", just "abridge" or "condensate". This is because to abridge or condensate you
basically take the original, select parts and remove others, so the original is still recognizable in the derivative work.
When you summarise you can write the important notions with your own words, and therefore the work you create
is exactly the same as if you had read a different text or learn the notions in a different way.

Different kinds of work (and jurisdictions) have different standards for when something is a derivative work or not, you need
to ask a lawyer, or run through the courts.I think for music there's a number of seconds or notes above which it is considerd derivative work,
and below not. For scripts, theatre and cinema it is controversial whether something is plagiarism or "homage". In software
you'll find I believe the FSF and the Apache Software Foundation with diverging views on whether dynamic linking constitues
derivative work.

And even in one field, common wisdom sometimes fail. Remember Oracle vs Google for Java in Android? Oracle though using header files
was deriving works, and Google not, the first judge sided with Google but surprisingly to most of the field the appeals judge
said it was a derivative after all, but back in the original court it was considered fair use so a legit derivative work and
maybe it is still pending for appeal). I mean sometimes everybody works for years thinking some legal detail is obvious and
a judge comes around and changes all (like that decision in Germany from a judge that didn't understand how open revision control
works and considered source repository not enough of a proof of authorship, fortunately not seting precedent AFAIK).

What I mean is that take my explanation with a grain of salt, I'm no expert but even experts disagree sometimes on what is
a derivative work.

I argue, that applying knowledge to my project, that I learned by studying ED's schematics constitutes a translation.

A translation? From what language to what language?.
If you produce schematics that replicate parts of ED's (Nikolaus' in fact?) schematics then you may be making a derivative
work. If not you aren't. But I don't know eactly what's the standard for electronic designs, it seems some coincidence might
be implicit to the functionality (like pin names or some component values) and not constitue derivative work, but some other (like track layout or so)
might be derivative work. I don't know. And there might be sui generis rights besides copyright in electronic designs in Europe, I don't know.

In linguistics a translation often doesn't contain a single word of the original text, yet the original text is essential for creating the translated text. I don't see why it should be any different with design schematics.

The words in the translation are considered equivalent to words in the original for it to be a translation. Even if it is not literal translation, it'll have enough detail on the proper nouns, referents, concepts and order, and the semantic equivalence, that it is practically impossible to come up with a translation of a work without having seen/heard/read the original.
 
Honestly, I'd rather have the issue fixed than rushed out the door with a potential hardware issue, it should run at designed speeds. I know people want it now, just I feel that people will enjoy the device more if it's running like intended.

I agree that these issues should continue to be pursued, but I also see that there is value to getting the prototypes out to software developers as soon as possible - even if they aren't running at max rated speeds. I.e. the 1.2 Ghz prototype units would be compatible with, just not as fast as, the later production units.

Even choosing at boot between dual 1.2 Ghz cores and single 1.5 Ghz core could be useful - though not as simple and useful as dual 1.5 Ghz cores.

The Pandora had a pretty broad headroom on overclocking. Getting 20-50% more processing power by just leveraging a few commands was pretty unprecedented. I don't think we can expect anything like that kind of OC headroom on the Pyra - which is OK.

For what it's worth, the device probably runs a lot cooler if locked to 1.2 Ghz dual core. That is something I've wondered - how underclockable is the unit? Are there advantages to doing so?
 
For people wondering about Copyright law on hardware schematics, here's a good faq by the Open Source Hardware Association. http://www.oshwa.org/faq/
Specifically here is the part about issues with Non-Commercial provisions. http://www.oshwa.org/faq/#noncommercial

I'm happy that the schematics are at least available. Now things do get a little muddled in that ED has stated what his intent for the use of the schematics.
While it'd be nicer if the license explicitly stated the intent, limits, and permissions, the copyright holder ultimately has say on when they choose to enforce or not enforce their rights outside of a license.
I do think it's a shame that commercial is such a broad term. I think many people use non-commercial licenses with the idea that they are preventing a giant company from ripping them off, but are totally ok with, or even encourage, hobbyist level activity.

On that note, possibly the CERN Open Hardware License (Mentioned above as well) would be a good choice. http://www.ohwr.org/projects/cernohl/wiki From their brief overview it sounds similar to the GPL. Which means you could charge money for it, but would have to provide the schematics under the same terms.

The TAPR Open Hardware License also sounds similar to the CERN one. http://www.tapr.org/ohl.html

Looks at the Open Hardware Licenses, things do seem confusing in that a document license very well may not cover actual hardware produced from the document. What a pain.

I think a time-bomb license as mentioned above would probably work out nicely, that or modifying the provisions to specifically prevent the sale of the schematics, but grant the ability to use the documents to produce hardware.

Also, I am not a lawyer, and I could very well be wrong on some points.
 
Last edited:
How likely are you to pay for a mod to your Pyra, honestly? Repair is one thing, but creating a derived work is something I'd only consider doing if I could do it myself, and even then I can't think of anything I'd want to do to improve my Pyra beyond what it already is.
Pretty likely. The lack of a camera is a serious flaw IMO. Furthermore, I know someone who can likely produce Tegra-based CPU boards even in small quantities.

Some clarification from me (because I am the author) about CC-NC licensing (note: there is no -ND clause!) of the schematics:
So can you clarify that the actual hardware design (not PDF) is under a less restrictive license?
 
from what i understand, @Luke-Jr @Splintercat, the license covers only the PDF documentation of the hardware schematics, so you can't sell your own version of the schematics.

but you could sell hardware based on your new schematics, but it sounds like you have to keep your schematics SA (share alike). see here:

License is CC-BY-NC-SA which means you can use and distribute them - except asking for money for a copy of this document or parts of it.

This does not exclude that you study the ideas and make your own (commercial) designs, because that is not covered by a document licence. But please let us know if you do that... We might be interested in learning your ideas as well :)
 
@ible. Yeah, I think so. Just did some more reading and this paper seems to lay things out pretty well. http://www.tapr.org/Ackermann_Open_Source_Hardware_Article_2009.pdf
Specifically the pages numbered 193 - 194 (Page 12 and 13 of the PDF)

What that paper says is that copyright does not restrict your ability to produce hardware based on a schematic.
Though may only be for US law.

Once again. Not a lawyer.
 
I agree that these issues should continue to be pursued, but I also see that there is value to getting the prototypes out to software developers as soon as possible - even if they aren't running at max rated speeds. I.e. the 1.2 Ghz prototype units would be compatible with, just not as fast as, the later production units.

Even choosing at boot between dual 1.2 Ghz cores and single 1.5 Ghz core could be useful - though not as simple and useful as dual 1.5 Ghz cores.

The Pandora had a pretty broad headroom on overclocking. Getting 20-50% more processing power by just leveraging a few commands was pretty unprecedented. I don't think we can expect anything like that kind of OC headroom on the Pyra - which is OK.

For what it's worth, the device probably runs a lot cooler if locked to 1.2 Ghz dual core. That is something I've wondered - how underclockable is the unit? Are there advantages to doing so?

That's exactly what I was thinking. Pyra won't be able in any case to overclock over 1.5Ghz?
 
The OMAP5 (and probably all new SoCs) are A LOT more picky when it comes to power supply and voltage stability than the OMAP3 or other SoCs.
We've spent nights figuring out whether it's purely hardware based or whether it can be fixed with software.
Shouldn't TI provide all these data to their Chips? It's their job, not yours, to fiddle out under which conditions these Chips do run. Almost every hardware comes with such information, power conditions are mandatory imho. What is TI for a "Saftladen"... :|
 
from what i understand, @Luke-Jr @Splintercat, the license covers only the PDF documentation of the hardware schematics, so you can't sell your own version of the schematics.

but you could sell hardware based on your new schematics, but it sounds like you have to keep your schematics SA (share alike).

Given the SA clause, though, anyone who did sell a derivative version would likely not get much money, as the buyer is free to distribute the document under the same licence, for free (gratis and libre), right? It seems to me that the NC clause would have only a small effect on selling copies. The SA clause on its own is pretty good at suppressing commercial exploitation, it seems to me -- with the GPL the primary ways to make money seem to be via technical support or via relicensing. How often do savvy people pay for SuperTuxKart or Xonotic, even modified versions of them?
[doublepost=1479759484,1479758919][/doublepost]@hns I note that the Neo900 schematics (http://neo900.org/stuff/kicad/proto_v2/2016-11-20/neo900__proto_v2__by_eeshow.pdf) are CC-BY-SA, not CC-BY-NC-SA. The Neo900 appears to be a similar project to the Pyra, so what does the NC provide the Pyra that the Neo900 does not have? Why NC for the Pyra and not for the Neo900? Have any of the Neo900 schematics been modified and paywalled, and is it a problem? Why do the Neo900 people not need to decide, case-by-case, on the validity of commercial ideas, yet it is important for the Pyra?
 
wouldn't it make sense to have someone with an actual grievance with NC (i.e., they have made important contributions to the document, wishing to make others pay for it) before we complain about it? i suppose ideological grievances can be just as upsetting...
 
wouldn't it make sense to have someone with an actual grievance with NC (i.e., they have made important contributions to the document, wishing to make others pay for it) before we complain about it? i suppose ideological grievances can be just as upsetting...

I assume that, since ED has been very busy, not much thought has been given to the licence. Therefore, there is a possibility that it would be changed without too much trouble. Also, there ARE some people for whom this really matters (even if only ideologically, as ideology is one of the attractions of the Pyra), so this matter, and others, is covered in the Comparison chart (https://www.pyra-handheld.com/wiki/index.php?title=Comparison_Chart) and, as I am biased in favour of the Pyra, I want it to look as good as possible, so it would please me to be able to give it a green colour in the chart for the "Hardware documentation" row, as for the Neo900.
 
Back
Top