What would make a design not open?

[mushon]

I recommend we start by describing what we think would make a design not open.
Discuss…

[mushon]

Most design works have some means of inspection and reproduction that can be made available. If a design work does not allow open access to these means, then it is probably not open.

Example:
An vector icon that is released in PNG format may be licensed under CC license but it is not open design since I have no way of inspecting or modifying it. For the work to be Open Design it would need to allow access to the vector source, for example in SVG format.

[Alexnoussias]

anything (for starters) with technical and legal restrictions..

[alex-kovac]

Hi Mushon,
A vector icon which is released in a PNG format would cease to be a vector icon and would, from then on, be a proud bitmap icon. We cannot go into the teleology of why would someone release a bitmap vs. vector icon if that icon is under a open license. If bitmap icon is under a open license, anyone is free to modify it, redistribute it, etc. and therefore it is "open" for all purposes.

To look at this from another perspective, if the icon is released openly, the preference of PNG vs SVG format is purely personal. (I agree that having a vector icon would sometimes be more convenient)

[mushon]

So why wouldn't a software binary file be considered open source as well?
I think sticking to the technicalities only beats the purpose entirely. It is one thing if the image is scanned and never had a malleable source. It is a different case when the source was simply not provided with the rendered "flat" version. If we stick to liberal licensing (as CC) as our cue, then why do we even need an open design definition? A I said before, I am not sure we actually need it, but I could be missing something. I asked this question to better understand what may I be missing. Not sure yet…

[bujatt]

I think the whole question is about being able to access the source
design code. In case of a vector icon, access the SVG not only the PNG. In
case of a 3D print, access the 3D file, not only the object itself. In case
of a wooden table, access the technical drawings. In case of a poster,
access the editable PSD and embedded fonts, not only the JPG.

Alexnoussias told not open means "Very general (for starters): anything
with legal, technical restrictions."

The question is whether any restriction of accessing the source code
disallows a design being open. And what makes the question more difficult,
that this restriction can be conscious (the designer of the vector icon
doesn't release the vector file just the raster image) or unconscious (the
designer did release the technical drawings of a table but I only have the
table itself).

For me real open design is when the source code is attached to or embedded
in the object itself. I don't know how this could be done practically -
like engraving a QR-code directly *into *the table body which points to a
never-expiring link of the technical drawing files of the table - but that
would be the real openness.

Maybe this is not part of the discussion about the definition but more the
licences, but thinking practically, I could imagine several levels of
openness:

• super-open: the source design code is hardcoded into the design
  object/output
• middle-open: the source design code was released by the designer but it
  is your job to find it (hopefully shared on thingiverse-like repositories)

Attila

Attila BUJDOSÓ : bujatt@gmail.com +36-70-2809137 http://bujatt.com

Kitchen Budapest http://kitchenbudapest.hu/ : Pecha Kucha Night
Budapesthttp://pechakucha.hu/
: Remix Architecture http://remixarchitecture.org/

On 7 September 2013 20:18, Mushon Zer-Aviv notifications@github.com wrote:

So why wouldn't a software binary file be considered open source as well?
I think sticking to the technicalities only beats the purpose entirely. It
is one thing if the image is scanned and never had a malleable source. It
is a different case when the source was simply not provided with the
rendered "flat" version. If we stick to liberal licensing (as CC) as our
cue, then why do we even need an open design definition? A I said before, I
am not sure we actually need it, but I could be missing something. I asked
this question to better understand what may I be missing. Not sure yet…

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-24006659
.

[alex-kovac]

You are completely right, in the case of flattened bitmap icon, a CC like license would probably suffice and an open design license might not be needed. (unless someone uses that icon data as a basis for another design process, but that is a different issue) So, please disregard my comment above.

In my opinion, we need the open design definition to define the open design process and the elements of that process, too (and not only the final product).

On 2013/09/08, at 3:18, Mushon Zer-Aviv notifications@github.com wrote:

So why wouldn't a software binary file be considered open source as well?
I think sticking to the technicalities only beats the purpose entirely. It is one thing if the image is scanned and never had a malleable source. It is a different case when the source was simply not provided with the rendered "flat" version. If we stick to liberal licensing (as CC) as our cue, then why do we even need an open design definition? A I said before, I am not sure we actually need it, but I could be missing something. I asked this question to better understand what may I be missing. Not sure yet�c

�
Reply to this email directly or view it on GitHub.

[eldelacajita]

I think the underlying question in the debate here is to properly define the "source" of a design, so we can check if we are having access to it or not. And usually, in design there are different levels of "source":

Built object > whose source is > specifications/plans in read-only format > whose source is > specifications/plans in editable format.

So maybe openness of the source is not a yes/no question but a variable degree: If you only share specifications of an object in PDF instead of original editable format, I think you're still half way into open design.

Using that other example of sharing a raster file of an graphic design instead of the original vector file, I think that applying a CC license on a finished ("compiled", rasterized, etc) design cannot be described as "open source".

[mushon]

I'm beginning to like where this is going. Rather than a binary license I think what we're starting to define here is a scale of openness on what could be defined (!() as the Open Design Spectrum. That spectrum would not require a new (tedious / technical / boring / anal) license of its own, but a set of guidelines / best practices for pushing the dial on your design work from the closed towards the open. Legally-wise, I think we're quite covered by the pleura of CC and OSS licensing, but I do agree that when it comes to design there's one tool still missing, and that is for a methodology for going beyond licensing and towards a more explicit Open Design process where openness is not an afterthought (as in: "ok, I slapped an open license on it, and now it's open") but a way of designing that considers the openness and remix from early in the production of the piece.

[bujatt]

Yes, I also think open design can be defined better as a spectrum than a
binary yes/no thing. I would like to share two references for this:

I really liked that someone (sorry forgot who) was referring to the 5 star
model of rating Open Data http://5stardata.info/ at OKCon last year. For
those unfamiliar, I paste it below:

★ make your stuff available on the Web (whatever format) under an open

license1 example ...
★★ make it available as structured data (e.g., Excel instead of image
scan of a table)2 example ...
★★★ use non-proprietary formats (e.g., CSV instead of Excel)3 example ...
★★★★ use URIs to denote things, so that people can point at your stuff4 example
...
★★★★★ link your data to other data to provide context5 example ...

Actually, this revokes how *Creative Commons *license evolved in the
history. While there are many permutations of the different conditions
(allow/disallow commercial use, allow/disallow remix etc.) they ended up
simplifying the different options in a 6-step
scalehttp://jakfoto.com/wp-content/uploads/2011/06/creative-commons-license-types-pros-cons1.gifof
license strength.

I think both references are really helpful and inspiring for us.

Attila BUJDOSÓ : bujatt@gmail.com +36-70-2809137 http://bujatt.com

Kitchen Budapest http://kitchenbudapest.hu/ : Pecha Kucha Night
Budapesthttp://pechakucha.hu/
: Remix Architecture http://remixarchitecture.org/

On 22 September 2013 14:22, Mushon Zer-Aviv notifications@github.comwrote:

I'm beginning to like where this is going. Rather than a binary license I
think what we're starting to define here is a scale of openness on what
could be defined (!() as the Open Design Spectrum. That spectrum would not
require a new (tedious / technical / boring / anal) license of its own, but
a set of guidelines / best practices for pushing the dial on your design
work from the closed towards the open. Legally-wise, I think we're quite
covered by the pleura of CC and OSS licensing, but I do agree that when it
comes to design there's one tool still missing, and that is for a
methodology for going beyond licensing and towards a more explicit Open
Design process where openness is not an afterthought (as in: "ok, I slapped
an open license on it, and now it's open") but a way of designing that
considers the openness and remix from early in the production of the piece.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-24881077
.

[openp2pdesign]

We can find a similar spectrum or range in Open Hardware as well (and maybe this can be an inspiration):

Patrick McNamara defined 4 possible levels of Openness in Open Hardware projects, that can help us understand them better:

1. Closed: any hardware for which the creator of the hardware will not release any information.
2. Open Interface: all the documentation on how to make a piece of hardware perform the function for which it is designed is available (minimum level of openness).
3. Open Design: in which enough detailed documentation is provided that a functionally compatible device could be created by a third party.
4. Open Implementation: the complete bill of materials necessary to construct the device is available.

[trox]

I would like to agree and disagree with the previous arguments

(1) agreement with the "spectrum" idea, agreement with some sort of "maturity" indication (the 5star idea)
(2) agreement with extending the open design discussion beyond the product and into the process arena … that's where it gets really interesting, ihmo

(3) disagreement with doing away with a clear cut "gold" standard of what open design is … not in terms of a license (!!!), but in terms of a definition

my 3c / Peter

[trox]

Patrick McNamara defined 4 possible levels of Openness in Open Hardware projects,

interesting contribution … but very "factual".

• I'm missing the "why": why has the hardware been designed as is?
• I'm missing the openness in designing (although this might be implicit in the TAPR community with its purpose of advancing the radio art)

[openp2pdesign]

The spectrum/range is a good idea, but little reminder: we are not discussing a specific license but rather a framework for understanding/working with Open Design. So it is a good idea not to have a binary distinction, but it's not about a license. Please have a look at the Open Design and Intellectual Property section (it still needs further work, so any help would be appreciated!).

[openp2pdesign]

I've added a first version of 6 levels for the documentation of Open Design (our Open Design Spectrum) with commit bd7bfc4. I've started from the 5 stars rating of Open Data), you can have a look at it here

1. make your stuff available on the Web (whatever format) under an open license
2. make it available as source file (e.g., vector format instead of bitmap format)
3. make it available as a human-readable source file (e.g. ASCII .stl instead of binary .stl, this would work better with version control systems)
4. use non-proprietary formats (e.g., .svg instead of Adobe Illustrator .ai)
5. add a documentation about the design process (how it has been designed, by whom, where, ...)
6. link your data to other data to provide context (e.g. Open Data regarding the design process, supply chain, manufacturing, distribution, end of life, ...)