Re: [E-devel] FOSDEM 2017

[Philippe Caseiro]

Hi !!

What about a meet-up on Saturday morning 9am @ the central "bar" neer 
building K ?

Then we plan for the Diner ?

Or we chose a restaurant and a meet time here ?

See you !

Le lundi 22 janvier 2018 00:48:17 CET, Andrew Williams a écrit :

Hi,

I expect to be there too, though staying near the event rather than city
centre this time.

Andy

On Sat, 20 Jan 2018 at 16:21, Vincent Torri  wrote:


i'll be at fosdem but i go back home around 6PM

Vincent

On Sat, Jan 20, 2018 at 3:19 PM, Carsten Haitzler 
wrote: ...


--
Philippe Caseiro

Responsable Cadoles Services & Solutions
Ingénieur logiciels libres

https://www.cadoles.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL_UI_BG_WIDGET_DATA_GET_OR_RETURN

[cnook]

With great help of jpeg, I got that the efl_data_scope_get is checking if
the obj_id is NULL or not using EO_OBJ_POINTER_RETURN_VAL.
So, I would like to change CRI to ERR for this.
Thank you very much. (please do not go jpeg~ hehe)

Sincerely,
Shinwoo Kim.

2018. 2. 1. 오전 11:34에 "cnook" 님이 작성:

> Dear all, Hello!
>
> As you konw, we have macro EFL_UI_GB_WIDGET_DATA_GET_OR_RETURN and we can
> find similar MACROs.
> As you probably do not know, the Tizen is maintaing test suite including
> negative test cases.
> One of TCs is calling elm_bg_load_size_set with NULL obj parameter.
> In this case, CRI message occurs, and abort occurs. Then the result of TC
> is ERROR.
> In my opinion the api elm_bg_load_size_set should have to check if the
> parameter is NULL or  not.
> My question is that do I have to add a line checking NULL to the macro
> EFL_UI_WIDGET_DATA_GET_OR_RETURN? or add separated line?
> Which one is better? Please let me know. Thank you in advance.
>
> Sincerely,
> Shinwoo Kim.
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL_UI_BG_WIDGET_DATA_GET_OR_RETURN

[Jean-Philippe André]

Hi~

On Thu, Feb 1, 2018 at 11:34 AM, cnook  wrote:

> Dear all, Hello!
>
> As you konw, we have macro EFL_UI_GB_WIDGET_DATA_GET_OR_RETURN and we can
> find similar MACROs.
> As you probably do not know, the Tizen is maintaing test suite including
> negative test cases.
> One of TCs is calling elm_bg_load_size_set with NULL obj parameter.
> In this case, CRI message occurs, and abort occurs. Then the result of TC
> is ERROR.
> In my opinion the api elm_bg_load_size_set should have to check if the
> parameter is NULL or  not.
> My question is that do I have to add a line checking NULL to the macro
> EFL_UI_WIDGET_DATA_GET_OR_RETURN? or add separated line?
> Which one is better? Please let me know. Thank you in advance.
>

I think CRI here is a bit excessive, especially since this macro only
calls efl_data_scope_get() (not efl_data_scope_safe_get).
We might want to change this to ERR(), instead of CRI.

Best regards,

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] EFL_UI_BG_WIDGET_DATA_GET_OR_RETURN

[cnook]

Dear all, Hello!

As you konw, we have macro EFL_UI_GB_WIDGET_DATA_GET_OR_RETURN and we can
find similar MACROs.
As you probably do not know, the Tizen is maintaing test suite including
negative test cases.
One of TCs is calling elm_bg_load_size_set with NULL obj parameter.
In this case, CRI message occurs, and abort occurs. Then the result of TC
is ERROR.
In my opinion the api elm_bg_load_size_set should have to check if the
parameter is NULL or  not.
My question is that do I have to add a line checking NULL to the macro
EFL_UI_WIDGET_DATA_GET_OR_RETURN? or add separated line?
Which one is better? Please let me know. Thank you in advance.

Sincerely,
Shinwoo Kim.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Terminology support added on mdcat

[Cedric Bail]

>  Original Message 
> Subject: [E-devel] Terminology support added on mdcat
> Local Time: January 31, 2018 9:12 AM
> UTC Time: January 31, 2018 5:12 PM
> From: vini.ipsma...@gmail.com
> To: Enlightenment - dev 
>
> Just to let you guys know that support to Terminology extended escape
> sequences has been added to mdcat: https://github.com/lunaryorn/mdcat

That's great, especially with our new documentation being markdown. There is 
just one glitch, it can't find the absolute path being given as they are 
starting with '/'. So I was wondering if there is a way to set some environment 
variable or something to point to a base hierarchy for this image starting by 
'/'.

Cedric
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Terminology support added on mdcat

[Vinícius dos Santos Oliveira]

2018-01-31 19:37 GMT-03:00 Carsten Haitzler :

> tycat doesn't work because it needs to know size before emitting escapes
> thus
> has to load the file and tycat wont bother to download :) but yes - the
> basic media object can just download to a tmp file itself
>

In the code I've written, I just set it to occupy half of the terminal
height and I use ic escape sequence to not lose the aspect ratio.

I think the best solution would be to turn the tycat into a pager, but I
don't know what is the author opinion on this.

The second best solution I see is to keep doing what I do.


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Terminology support added on mdcat

[Carsten Haitzler]

On Wed, 31 Jan 2018 15:47:00 -0300 Vinícius dos Santos Oliveira
 said:

> I've tried to pipe the output to `less`, but it didn't work. I'll test it
> against tmux later.
> 
> 2018-01-31 15:21 GMT-03:00 Carsten Haitzler :
> 
> > On Wed, 31 Jan 2018 14:12:27 -0300 Vinícius dos Santos Oliveira
> >  said:
> >
> > > Just to let you guys know that support to Terminology extended escape
> > > sequences has been added to mdcat: https://github.com/lunaryorn/mdcat
> >
> > that's awesome man!
> >
> > is there anything we can help you with? i just quickly scrolled down
> > https://github.com/lunaryorn/mdcat/pull/16 ...
> >
> > i see 2 issues. 1 is remote references. they woth for popups but not inline
> > (tycat won't work, but typop will).
> 
> 
> They worked on my tests. Maybe new code landed and you missed, but the
> media is discarded as soon as you scroll down and re-downloaded again when
> you scroll up.

tycat doesn't work because it needs to know size before emitting escapes thus
has to load the file and tycat wont bother to download :) but yes - the
basic media object can just download to a tmp file itself

that's why it re-downloads. terminology will delete the media obj and re-create
as you scroll around (to save memory).

you suffer the same issues. needing to know when to keep files or not or
re-download, and to know their size without downloading them first so you know
how to flow text around them... :)

> Caching the media so I don't have to download it every time I scroll down
> or up again would be great.
> 
> even if we did download them... we'd have
> > to STORE them somewhere... because we're sure not going to keep them in
> > RAM. at
> > least stored they don't take precious ram all the time. so terminology will
> > also use tmp files too with references to remote url's anyway. if you do
> > it or
> > terminology does... it won't make much of a difference. :)
> 
> 
> There's one important difference.
> 
> If Terminology creates the files and cache them, then Terminology will keep
> an open fd to these files. If I clear my `/tmp` folder, Terminology will
> still work properly. mdcat can't do that as the application closes as soon
> as the file is printed.

actually like the above scrolling... it won't do that. it just remembers the
uri/file path and re-fetches to tmp file... :) sure - while it's visible there
is an open file handle...

but you could do the same. you would have to not EXIT at the end of the cat,
but wait for a key press to exit. like less/more would do. an interactive pager
built-in...

> the other is
> > fr/fs/fx ... that literally is for file sending. it's zmodem for
> > terminology.
> > tysend is a quick handy tool to run to do this. sample code is really just
> > that
> > - sample code, but it will begin a file send transaction and send file
> > blocks.
> > the terminology side will see the request and pop up a file selector with
> > the
> > ability to abort, and then put up a progress bar. it's not what you want i
> > think.
> >
> 
> Thanks for the explanation.
> 
> -- 
> Vinícius dos Santos Oliveira
> https://vinipsmaker.github.io/


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Terminology support added on mdcat

[Vinícius dos Santos Oliveira]

I've tried to pipe the output to `less`, but it didn't work. I'll test it
against tmux later.

2018-01-31 15:21 GMT-03:00 Carsten Haitzler :

> On Wed, 31 Jan 2018 14:12:27 -0300 Vinícius dos Santos Oliveira
>  said:
>
> > Just to let you guys know that support to Terminology extended escape
> > sequences has been added to mdcat: https://github.com/lunaryorn/mdcat
>
> that's awesome man!
>
> is there anything we can help you with? i just quickly scrolled down
> https://github.com/lunaryorn/mdcat/pull/16 ...
>
> i see 2 issues. 1 is remote references. they woth for popups but not inline
> (tycat won't work, but typop will).


They worked on my tests. Maybe new code landed and you missed, but the
media is discarded as soon as you scroll down and re-downloaded again when
you scroll up.

Caching the media so I don't have to download it every time I scroll down
or up again would be great.

even if we did download them... we'd have
> to STORE them somewhere... because we're sure not going to keep them in
> RAM. at
> least stored they don't take precious ram all the time. so terminology will
> also use tmp files too with references to remote url's anyway. if you do
> it or
> terminology does... it won't make much of a difference. :)


There's one important difference.

If Terminology creates the files and cache them, then Terminology will keep
an open fd to these files. If I clear my `/tmp` folder, Terminology will
still work properly. mdcat can't do that as the application closes as soon
as the file is printed.

the other is
> fr/fs/fx ... that literally is for file sending. it's zmodem for
> terminology.
> tysend is a quick handy tool to run to do this. sample code is really just
> that
> - sample code, but it will begin a file send transaction and send file
> blocks.
> the terminology side will see the request and pop up a file selector with
> the
> ability to abort, and then put up a progress bar. it's not what you want i
> think.
>

Thanks for the explanation.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] GPL icons in theme

[Carsten Haitzler]

On Wed, 31 Jan 2018 19:15:28 +0100 Davide Andreoli 
said:

> 2018-01-31 10:52 GMT+01:00 Carsten Haitzler :
> 
> > On Wed, 31 Jan 2018 14:37:28 +1030 Simon Lees  said:
> >
> > >
> > >
> > > On 31/01/18 10:39, Davide Andreoli wrote:
> > > > The fdo icons in the efl theme are indeed GPL3,
> > > > as clearly staten in COPYING.images and data/elementary/themes/fdo
> > > >
> > > > I have no idea about the contamination and the resulting theme final
> > > > license.
> > > >
> > > > For sure I want (and we must) them to remain to that license.
> > > >
> > >
> > > I don't understand why you wouldn't want them licensed under an
> > > equivalent creative commons license rather then GPL-3, GPL-3 is designed
> > > for source code where as creative commons is designed for images, using
> > > the wrong sort of licenses leads to the ambiguities we are seeing here,
> > > if we can't convince the upstream developers to change there isn't much
> > > we can do but its worth trying.
> >
> > we need to probably replace them with icons that are not licensed like the
> > above.
> >
> > as for contamination, that is generally considered to be true with code if
> > they
> > share the same memory space. icons on the other hand do not. they are first
> > decoded/rendered then manipulated. code from the binary is mapped directly
> > into
> > memory as-is pretty much minus relocation.
> >
> > so while i don't think DATA files would leak their license to efl, gplv3
> > does
> > create requirements of its host system (to allow any gplv3 components to be
> > replaceable by the end user) and that requires any system that would ship
> > these
> > to not be locked down. that is generally disliked by commercial vendors.
> >
> 
> Well, I expect a commercial vendor with a locked down device to at least
> provide a
> theme of their own :)


the problem is they just read "gplv3" and run away without looking at the
details most likely... :) so just having it off the list is a good thing.

> > so my take is "replace them". i could replace them anyway if the theme
> > fundamentally changed (e.g. became flat).
> >
> > > >
> > > > 2018-01-30 14:05 GMT+01:00 Jean-Philippe André :
> > > >
> > > >> On Tue, Jan 30, 2018 at 9:30 PM, Simon Lees  wrote:
> > > >>
> > > >>>
> > > >>>
> > > >>> On 30/01/18 22:20, Jean-Philippe André wrote:
> > >  Hi,
> > > 
> > >  Sungtaek pointed out to me that we have GPLv3-licensed artworks
> > (unsual
> > > >>> for
> > >  images) in our theme, under data/elementary/theme/fdo. Those images
> > are
> > > >>> are
> > >  then included in the compiled theme default.edj. One source is
> > clearly
> > >  GPLv3:
> > >  https://tiheum.deviantart.com/art/Faenza-Icons-173323228
> > > 
> > >  Now I wonder what the implications of this are...
> > >  1. Does Elementary become GPL because we load the theme and it
> > contains
> > >  executable code (embryo & edje programs), so the theme is to be
> > > >>> considered
> > >  a library, contaminating everything??
> > >  2. Or only the theme itself is GPL, by contamination from those
> > images?
> > >  3. Or is the compiled theme file not GPL because we're not linking
> > or
> > >  derivating, merely archiving those images like in a Zip file, in
> > which
> > > >>> case
> > >  only what's in the tree is GPL? This would be same as HTML:
> > >  https://news.slashdot.org/story/13/06/26/2113242/when-
> > > >>> gpl-becomes-almost-gpl-the-css-images-and-javascript-
> > > >>> loophole/informative-comments#comments
> > > 
> > >  In the FAQ I only found a mention about fonts:
> > >  https://www.gnu.org/licenses/gpl-faq.en.html#FontException
> > >  We don't have such an exception.
> > > 
> > >  Pretty sure there is no problem (i.e. #3 is right), but IANAL so I'd
> > > >>> rather
> > >  ask away :)
> > > 
> > > >>>
> > > >>> Licence wise i've always considered themes to be separate, whether
> > that
> > > >>> is correct or not is another question. GPL with images is silly
> > anyway
> > > >>> and we really should be asking upstream to relicense with some form
> > of
> > > >>> creative commons anyway which makes far more sense, but I guess the
> > > >>> theme is probably technically GPL-3 as a binary.
> > > >>
> > > >>
> > > >> Not so sure. HTML seems to be a crazy exception: An HTML file
> > containing
> > > >> GPL licensed JS code is not GPL itself. Not consistent but makes
> > sense. EDJ
> > > >> probably also falls under the category of "container".
> > > >>
> > > >>
> > > >>> Probably the biggest actual real life issue is if the theme is being
> > > >>> used in consumer devices such as tizen you would need to provide
> > > >>> consumers a way to swap there stock theme for one of there choice.
> > > >>>
> > > >>
> > > >> Yeah that's partly why I'm asking. :)
> > > >>
> > > >> --
> > > >> Jean-Philippe 

Re: [E-devel] Terminology support added on mdcat

[Vinícius dos Santos Oliveira]

2018-01-31 15:13 GMT-03:00 Gustavo Sverzut Barbieri :

> hey, now you must add the jump marks so he can add those as well ;-)
>

Honestly, I don't think they are very useful, so I wouldn't bother with
them. But if support for these escape sequences is added, then I can code
the feature.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Terminology support added on mdcat

[Carsten Haitzler]

On Wed, 31 Jan 2018 14:12:27 -0300 Vinícius dos Santos Oliveira
 said:

> Just to let you guys know that support to Terminology extended escape
> sequences has been added to mdcat: https://github.com/lunaryorn/mdcat

that's awesome man!

is there anything we can help you with? i just quickly scrolled down
https://github.com/lunaryorn/mdcat/pull/16 ...

i see 2 issues. 1 is remote references. they woth for popups but not inline
(tycat won't work, but typop will). even if we did download them... we'd have
to STORE them somewhere... because we're sure not going to keep them in RAM. at
least stored they don't take precious ram all the time. so terminology will
also use tmp files too with references to remote url's anyway. if you do it or
terminology does... it won't make much of a difference. :) the other is
fr/fs/fx ... that literally is for file sending. it's zmodem for terminology.
tysend is a quick handy tool to run to do this. sample code is really just that
- sample code, but it will begin a file send transaction and send file blocks.
the terminology side will see the request and pop up a file selector with the
ability to abort, and then put up a progress bar. it's not what you want i
think.

> -- 
> Vinícius dos Santos Oliveira
> https://vinipsmaker.github.io/
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] GPL icons in theme

[Davide Andreoli]

2018-01-31 10:52 GMT+01:00 Carsten Haitzler :

> On Wed, 31 Jan 2018 14:37:28 +1030 Simon Lees  said:
>
> >
> >
> > On 31/01/18 10:39, Davide Andreoli wrote:
> > > The fdo icons in the efl theme are indeed GPL3,
> > > as clearly staten in COPYING.images and data/elementary/themes/fdo
> > >
> > > I have no idea about the contamination and the resulting theme final
> > > license.
> > >
> > > For sure I want (and we must) them to remain to that license.
> > >
> >
> > I don't understand why you wouldn't want them licensed under an
> > equivalent creative commons license rather then GPL-3, GPL-3 is designed
> > for source code where as creative commons is designed for images, using
> > the wrong sort of licenses leads to the ambiguities we are seeing here,
> > if we can't convince the upstream developers to change there isn't much
> > we can do but its worth trying.
>
> we need to probably replace them with icons that are not licensed like the
> above.
>
> as for contamination, that is generally considered to be true with code if
> they
> share the same memory space. icons on the other hand do not. they are first
> decoded/rendered then manipulated. code from the binary is mapped directly
> into
> memory as-is pretty much minus relocation.
>
> so while i don't think DATA files would leak their license to efl, gplv3
> does
> create requirements of its host system (to allow any gplv3 components to be
> replaceable by the end user) and that requires any system that would ship
> these
> to not be locked down. that is generally disliked by commercial vendors.
>

Well, I expect a commercial vendor with a locked down device to at least
provide a
theme of their own :)

>
>
> so my take is "replace them". i could replace them anyway if the theme
> fundamentally changed (e.g. became flat).
>
> > >
> > > 2018-01-30 14:05 GMT+01:00 Jean-Philippe André :
> > >
> > >> On Tue, Jan 30, 2018 at 9:30 PM, Simon Lees  wrote:
> > >>
> > >>>
> > >>>
> > >>> On 30/01/18 22:20, Jean-Philippe André wrote:
> >  Hi,
> > 
> >  Sungtaek pointed out to me that we have GPLv3-licensed artworks
> (unsual
> > >>> for
> >  images) in our theme, under data/elementary/theme/fdo. Those images
> are
> > >>> are
> >  then included in the compiled theme default.edj. One source is
> clearly
> >  GPLv3:
> >  https://tiheum.deviantart.com/art/Faenza-Icons-173323228
> > 
> >  Now I wonder what the implications of this are...
> >  1. Does Elementary become GPL because we load the theme and it
> contains
> >  executable code (embryo & edje programs), so the theme is to be
> > >>> considered
> >  a library, contaminating everything??
> >  2. Or only the theme itself is GPL, by contamination from those
> images?
> >  3. Or is the compiled theme file not GPL because we're not linking
> or
> >  derivating, merely archiving those images like in a Zip file, in
> which
> > >>> case
> >  only what's in the tree is GPL? This would be same as HTML:
> >  https://news.slashdot.org/story/13/06/26/2113242/when-
> > >>> gpl-becomes-almost-gpl-the-css-images-and-javascript-
> > >>> loophole/informative-comments#comments
> > 
> >  In the FAQ I only found a mention about fonts:
> >  https://www.gnu.org/licenses/gpl-faq.en.html#FontException
> >  We don't have such an exception.
> > 
> >  Pretty sure there is no problem (i.e. #3 is right), but IANAL so I'd
> > >>> rather
> >  ask away :)
> > 
> > >>>
> > >>> Licence wise i've always considered themes to be separate, whether
> that
> > >>> is correct or not is another question. GPL with images is silly
> anyway
> > >>> and we really should be asking upstream to relicense with some form
> of
> > >>> creative commons anyway which makes far more sense, but I guess the
> > >>> theme is probably technically GPL-3 as a binary.
> > >>
> > >>
> > >> Not so sure. HTML seems to be a crazy exception: An HTML file
> containing
> > >> GPL licensed JS code is not GPL itself. Not consistent but makes
> sense. EDJ
> > >> probably also falls under the category of "container".
> > >>
> > >>
> > >>> Probably the biggest actual real life issue is if the theme is being
> > >>> used in consumer devices such as tizen you would need to provide
> > >>> consumers a way to swap there stock theme for one of there choice.
> > >>>
> > >>
> > >> Yeah that's partly why I'm asking. :)
> > >>
> > >> --
> > >> Jean-Philippe André
> > >> 
> > >> --
> > >> Check out the vibrant tech community on one of the world's most
> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >> ___
> > >> enlightenment-devel mailing list
> > >> enlightenment-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >>
> > > 

Re: [E-devel] Terminology support added on mdcat

[Gustavo Sverzut Barbieri]

hey, now you must add the jump marks so he can add those as well ;-)

On Wed, Jan 31, 2018 at 4:08 PM, Vinícius dos Santos Oliveira
 wrote:
> PS.: details about the support are commented in this PR:
> https://github.com/lunaryorn/mdcat/pull/16
>
> 2018-01-31 14:12 GMT-03:00 Vinícius dos Santos Oliveira <
> vini.ipsma...@gmail.com>:
>
>> Just to let you guys know that support to Terminology extended escape
>> sequences has been added to mdcat: https://github.com/lunaryorn/mdcat
>>
>> --
>> Vinícius dos Santos Oliveira
>> https://vinipsmaker.github.io/
>>
>
>
>
> --
> Vinícius dos Santos Oliveira
> https://vinipsmaker.github.io/
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] GPL icons in theme

[Davide Andreoli]

2018-01-31 16:32 GMT+01:00 Carsten Haitzler :

> On Wed, 31 Jan 2018 14:36:17 +0100 Davide Andreoli  >
> said:
>
> > 2018-01-31 10:52 GMT+01:00 Carsten Haitzler :
> >
> > > On Wed, 31 Jan 2018 14:37:28 +1030 Simon Lees  said:
> > >
> > > >
> > > >
> > > > On 31/01/18 10:39, Davide Andreoli wrote:
> > > > > The fdo icons in the efl theme are indeed GPL3,
> > > > > as clearly staten in COPYING.images and data/elementary/themes/fdo
> > > > >
> > > > > I have no idea about the contamination and the resulting theme
> final
> > > > > license.
> > > > >
> > > > > For sure I want (and we must) them to remain to that license.
> > > > >
> > > >
> > > > I don't understand why you wouldn't want them licensed under an
> > > > equivalent creative commons license rather then GPL-3, GPL-3 is
> designed
> > > > for source code where as creative commons is designed for images,
> using
> > > > the wrong sort of licenses leads to the ambiguities we are seeing
> here,
> > > > if we can't convince the upstream developers to change there isn't
> much
> > > > we can do but its worth trying.
> > >
> > > we need to probably replace them with icons that are not licensed like
> the
> > > above.
> > >
> > > as for contamination, that is generally considered to be true with
> code if
> > > they
> > > share the same memory space. icons on the other hand do not. they are
> first
> > > decoded/rendered then manipulated. code from the binary is mapped
> directly
> > > into
> > > memory as-is pretty much minus relocation.
> > >
> > > so while i don't think DATA files would leak their license to efl,
> gplv3
> > > does
> > > create requirements of its host system (to allow any gplv3 components
> to be
> > > replaceable by the end user) and that requires any system that would
> ship
> > > these
> > > to not be locked down. that is generally disliked by commercial
> vendors.
> > >
> > > so my take is "replace them". i could replace them anyway if the theme
> > > fundamentally changed (e.g. became flat).
> > >
> >
> > Did you see how many fdo icons are there? I don't think we have the
> manpower
> > to redesign all of them.
>
> replace may mean replacing with an icon set that has a better license... :)
>

The majority of the fdo icons we have now are not just a copy of another
theme,
I draw them one by one starting from the svg shapes of various themes. They
are recolored, flattened and some fully redrawn. All that took to me
something
like a month of nightly work and I'm not sure we can find a theme that match
the E theme so closely, but I'm open to suggestions :)


>
> > > > > 2018-01-30 14:05 GMT+01:00 Jean-Philippe André  >:
> > > > >
> > > > >> On Tue, Jan 30, 2018 at 9:30 PM, Simon Lees 
> wrote:
> > > > >>
> > > > >>>
> > > > >>>
> > > > >>> On 30/01/18 22:20, Jean-Philippe André wrote:
> > > >  Hi,
> > > > 
> > > >  Sungtaek pointed out to me that we have GPLv3-licensed artworks
> > > (unsual
> > > > >>> for
> > > >  images) in our theme, under data/elementary/theme/fdo. Those
> images
> > > are
> > > > >>> are
> > > >  then included in the compiled theme default.edj. One source is
> > > clearly
> > > >  GPLv3:
> > > >  https://tiheum.deviantart.com/art/Faenza-Icons-173323228
> > > > 
> > > >  Now I wonder what the implications of this are...
> > > >  1. Does Elementary become GPL because we load the theme and it
> > > contains
> > > >  executable code (embryo & edje programs), so the theme is to be
> > > > >>> considered
> > > >  a library, contaminating everything??
> > > >  2. Or only the theme itself is GPL, by contamination from those
> > > images?
> > > >  3. Or is the compiled theme file not GPL because we're not
> linking
> > > or
> > > >  derivating, merely archiving those images like in a Zip file, in
> > > which
> > > > >>> case
> > > >  only what's in the tree is GPL? This would be same as HTML:
> > > >  https://news.slashdot.org/story/13/06/26/2113242/when-
> > > > >>> gpl-becomes-almost-gpl-the-css-images-and-javascript-
> > > > >>> loophole/informative-comments#comments
> > > > 
> > > >  In the FAQ I only found a mention about fonts:
> > > >  https://www.gnu.org/licenses/gpl-faq.en.html#FontException
> > > >  We don't have such an exception.
> > > > 
> > > >  Pretty sure there is no problem (i.e. #3 is right), but IANAL
> so I'd
> > > > >>> rather
> > > >  ask away :)
> > > > 
> > > > >>>
> > > > >>> Licence wise i've always considered themes to be separate,
> whether
> > > that
> > > > >>> is correct or not is another question. GPL with images is silly
> > > anyway
> > > > >>> and we really should be asking upstream to relicense with some
> form
> > > of
> > > > >>> creative commons anyway which makes far more sense, but I guess
> the
> > > > >>> theme is probably technically GPL-3 as a binary.
> > > > 

Re: [E-devel] Terminology support added on mdcat

[Vinícius dos Santos Oliveira]

PS.: details about the support are commented in this PR:
https://github.com/lunaryorn/mdcat/pull/16

2018-01-31 14:12 GMT-03:00 Vinícius dos Santos Oliveira <
vini.ipsma...@gmail.com>:

> Just to let you guys know that support to Terminology extended escape
> sequences has been added to mdcat: https://github.com/lunaryorn/mdcat
>
> --
> Vinícius dos Santos Oliveira
> https://vinipsmaker.github.io/
>



-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Terminology support added on mdcat

[Boris Faure]

On 18-01-31 14:12, Vinícius dos Santos Oliveira wrote:
> Just to let you guys know that support to Terminology extended escape
> sequences has been added to mdcat: https://github.com/lunaryorn/mdcat

That's neat! Thanks for letting us know about it!
-- 
Boris Faure
Pointer Arithmetician


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Terminology support added on mdcat

[Vinícius dos Santos Oliveira]

Just to let you guys know that support to Terminology extended escape
sequences has been added to mdcat: https://github.com/lunaryorn/mdcat

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] GPL icons in theme

[William L. Thomson Jr.]

On Thu, 1 Feb 2018 00:33:01 +0900
Carsten Haitzler  wrote:

> On Wed, 31 Jan 2018 13:42:13 + Al Poole  said:
> 
> > Worst scenario we could pay the author???  
> 
> just choose a different icon theme with better licensing... :)

What about Oxygen from KDE, LGPL may work?
https://techbase.kde.org/Projects/Oxygen/Licensing#Use_in_Applications

Long as it is not bundled in a binary, edj file. Seems a fair amount
end up in /usr/share/icons/Enlightenment-X. Which would make them
separate PNG files loaded at runtime so would not taint or violate
license.

I personally like and use them. Mostly because they have a wide range
of icons, and good MIME support. You can see them in use with my theme
Eminence. I used them with the default theme as well. The main file icon
is blue so I think it goes along with the rest of the blue base of E.
https://user-images.githubusercontent.com/12835340/28030854-6c079512-6573-11e7-8851-8311662ec359.jpg

-- 
William L. Thomson Jr.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] GPL icons in theme

[Carsten Haitzler]

On Wed, 31 Jan 2018 13:42:13 + Al Poole  said:

> Worst scenario we could pay the author???

just choose a different icon theme with better licensing... :)

> On Wed, Jan 31, 2018 at 1:36 PM, Davide Andreoli 
> wrote:
> > 2018-01-31 10:52 GMT+01:00 Carsten Haitzler :
> >
> >> On Wed, 31 Jan 2018 14:37:28 +1030 Simon Lees  said:
> >>
> >> >
> >> >
> >> > On 31/01/18 10:39, Davide Andreoli wrote:
> >> > > The fdo icons in the efl theme are indeed GPL3,
> >> > > as clearly staten in COPYING.images and data/elementary/themes/fdo
> >> > >
> >> > > I have no idea about the contamination and the resulting theme final
> >> > > license.
> >> > >
> >> > > For sure I want (and we must) them to remain to that license.
> >> > >
> >> >
> >> > I don't understand why you wouldn't want them licensed under an
> >> > equivalent creative commons license rather then GPL-3, GPL-3 is designed
> >> > for source code where as creative commons is designed for images, using
> >> > the wrong sort of licenses leads to the ambiguities we are seeing here,
> >> > if we can't convince the upstream developers to change there isn't much
> >> > we can do but its worth trying.
> >>
> >> we need to probably replace them with icons that are not licensed like the
> >> above.
> >>
> >> as for contamination, that is generally considered to be true with code if
> >> they
> >> share the same memory space. icons on the other hand do not. they are first
> >> decoded/rendered then manipulated. code from the binary is mapped directly
> >> into
> >> memory as-is pretty much minus relocation.
> >>
> >> so while i don't think DATA files would leak their license to efl, gplv3
> >> does
> >> create requirements of its host system (to allow any gplv3 components to be
> >> replaceable by the end user) and that requires any system that would ship
> >> these
> >> to not be locked down. that is generally disliked by commercial vendors.
> >>
> >> so my take is "replace them". i could replace them anyway if the theme
> >> fundamentally changed (e.g. became flat).
> >>
> >
> > Did you see how many fdo icons are there? I don't think we have the manpower
> > to redesign all of them.
> >
> >
> >>
> >> > >
> >> > > 2018-01-30 14:05 GMT+01:00 Jean-Philippe André :
> >> > >
> >> > >> On Tue, Jan 30, 2018 at 9:30 PM, Simon Lees  wrote:
> >> > >>
> >> > >>>
> >> > >>>
> >> > >>> On 30/01/18 22:20, Jean-Philippe André wrote:
> >> >  Hi,
> >> > 
> >> >  Sungtaek pointed out to me that we have GPLv3-licensed artworks
> >> (unsual
> >> > >>> for
> >> >  images) in our theme, under data/elementary/theme/fdo. Those images
> >> are
> >> > >>> are
> >> >  then included in the compiled theme default.edj. One source is
> >> clearly
> >> >  GPLv3:
> >> >  https://tiheum.deviantart.com/art/Faenza-Icons-173323228
> >> > 
> >> >  Now I wonder what the implications of this are...
> >> >  1. Does Elementary become GPL because we load the theme and it
> >> contains
> >> >  executable code (embryo & edje programs), so the theme is to be
> >> > >>> considered
> >> >  a library, contaminating everything??
> >> >  2. Or only the theme itself is GPL, by contamination from those
> >> images?
> >> >  3. Or is the compiled theme file not GPL because we're not linking
> >> or
> >> >  derivating, merely archiving those images like in a Zip file, in
> >> which
> >> > >>> case
> >> >  only what's in the tree is GPL? This would be same as HTML:
> >> >  https://news.slashdot.org/story/13/06/26/2113242/when-
> >> > >>> gpl-becomes-almost-gpl-the-css-images-and-javascript-
> >> > >>> loophole/informative-comments#comments
> >> > 
> >> >  In the FAQ I only found a mention about fonts:
> >> >  https://www.gnu.org/licenses/gpl-faq.en.html#FontException
> >> >  We don't have such an exception.
> >> > 
> >> >  Pretty sure there is no problem (i.e. #3 is right), but IANAL so I'd
> >> > >>> rather
> >> >  ask away :)
> >> > 
> >> > >>>
> >> > >>> Licence wise i've always considered themes to be separate, whether
> >> that
> >> > >>> is correct or not is another question. GPL with images is silly
> >> anyway
> >> > >>> and we really should be asking upstream to relicense with some form
> >> of
> >> > >>> creative commons anyway which makes far more sense, but I guess the
> >> > >>> theme is probably technically GPL-3 as a binary.
> >> > >>
> >> > >>
> >> > >> Not so sure. HTML seems to be a crazy exception: An HTML file
> >> containing
> >> > >> GPL licensed JS code is not GPL itself. Not consistent but makes
> >> sense. EDJ
> >> > >> probably also falls under the category of "container".
> >> > >>
> >> > >>
> >> > >>> Probably the biggest actual real life issue is if the theme is being
> >> > >>> used in consumer devices such as tizen you would need to provide
> >> > >>> consumers a way to swap 

Re: [E-devel] GPL icons in theme

[Carsten Haitzler]

On Wed, 31 Jan 2018 14:36:17 +0100 Davide Andreoli 
said:

> 2018-01-31 10:52 GMT+01:00 Carsten Haitzler :
> 
> > On Wed, 31 Jan 2018 14:37:28 +1030 Simon Lees  said:
> >
> > >
> > >
> > > On 31/01/18 10:39, Davide Andreoli wrote:
> > > > The fdo icons in the efl theme are indeed GPL3,
> > > > as clearly staten in COPYING.images and data/elementary/themes/fdo
> > > >
> > > > I have no idea about the contamination and the resulting theme final
> > > > license.
> > > >
> > > > For sure I want (and we must) them to remain to that license.
> > > >
> > >
> > > I don't understand why you wouldn't want them licensed under an
> > > equivalent creative commons license rather then GPL-3, GPL-3 is designed
> > > for source code where as creative commons is designed for images, using
> > > the wrong sort of licenses leads to the ambiguities we are seeing here,
> > > if we can't convince the upstream developers to change there isn't much
> > > we can do but its worth trying.
> >
> > we need to probably replace them with icons that are not licensed like the
> > above.
> >
> > as for contamination, that is generally considered to be true with code if
> > they
> > share the same memory space. icons on the other hand do not. they are first
> > decoded/rendered then manipulated. code from the binary is mapped directly
> > into
> > memory as-is pretty much minus relocation.
> >
> > so while i don't think DATA files would leak their license to efl, gplv3
> > does
> > create requirements of its host system (to allow any gplv3 components to be
> > replaceable by the end user) and that requires any system that would ship
> > these
> > to not be locked down. that is generally disliked by commercial vendors.
> >
> > so my take is "replace them". i could replace them anyway if the theme
> > fundamentally changed (e.g. became flat).
> >
> 
> Did you see how many fdo icons are there? I don't think we have the manpower
> to redesign all of them.

replace may mean replacing with an icon set that has a better license... :)

> > > > 2018-01-30 14:05 GMT+01:00 Jean-Philippe André :
> > > >
> > > >> On Tue, Jan 30, 2018 at 9:30 PM, Simon Lees  wrote:
> > > >>
> > > >>>
> > > >>>
> > > >>> On 30/01/18 22:20, Jean-Philippe André wrote:
> > >  Hi,
> > > 
> > >  Sungtaek pointed out to me that we have GPLv3-licensed artworks
> > (unsual
> > > >>> for
> > >  images) in our theme, under data/elementary/theme/fdo. Those images
> > are
> > > >>> are
> > >  then included in the compiled theme default.edj. One source is
> > clearly
> > >  GPLv3:
> > >  https://tiheum.deviantart.com/art/Faenza-Icons-173323228
> > > 
> > >  Now I wonder what the implications of this are...
> > >  1. Does Elementary become GPL because we load the theme and it
> > contains
> > >  executable code (embryo & edje programs), so the theme is to be
> > > >>> considered
> > >  a library, contaminating everything??
> > >  2. Or only the theme itself is GPL, by contamination from those
> > images?
> > >  3. Or is the compiled theme file not GPL because we're not linking
> > or
> > >  derivating, merely archiving those images like in a Zip file, in
> > which
> > > >>> case
> > >  only what's in the tree is GPL? This would be same as HTML:
> > >  https://news.slashdot.org/story/13/06/26/2113242/when-
> > > >>> gpl-becomes-almost-gpl-the-css-images-and-javascript-
> > > >>> loophole/informative-comments#comments
> > > 
> > >  In the FAQ I only found a mention about fonts:
> > >  https://www.gnu.org/licenses/gpl-faq.en.html#FontException
> > >  We don't have such an exception.
> > > 
> > >  Pretty sure there is no problem (i.e. #3 is right), but IANAL so I'd
> > > >>> rather
> > >  ask away :)
> > > 
> > > >>>
> > > >>> Licence wise i've always considered themes to be separate, whether
> > that
> > > >>> is correct or not is another question. GPL with images is silly
> > anyway
> > > >>> and we really should be asking upstream to relicense with some form
> > of
> > > >>> creative commons anyway which makes far more sense, but I guess the
> > > >>> theme is probably technically GPL-3 as a binary.
> > > >>
> > > >>
> > > >> Not so sure. HTML seems to be a crazy exception: An HTML file
> > containing
> > > >> GPL licensed JS code is not GPL itself. Not consistent but makes
> > sense. EDJ
> > > >> probably also falls under the category of "container".
> > > >>
> > > >>
> > > >>> Probably the biggest actual real life issue is if the theme is being
> > > >>> used in consumer devices such as tizen you would need to provide
> > > >>> consumers a way to swap there stock theme for one of there choice.
> > > >>>
> > > >>
> > > >> Yeah that's partly why I'm asking. :)
> > > >>
> > > >> --
> > > >> Jean-Philippe André
> > > >> 
> > > >> 

Re: [E-devel] GPL icons in theme

[Al Poole]

Worst scenario we could pay the author???

On Wed, Jan 31, 2018 at 1:36 PM, Davide Andreoli  wrote:
> 2018-01-31 10:52 GMT+01:00 Carsten Haitzler :
>
>> On Wed, 31 Jan 2018 14:37:28 +1030 Simon Lees  said:
>>
>> >
>> >
>> > On 31/01/18 10:39, Davide Andreoli wrote:
>> > > The fdo icons in the efl theme are indeed GPL3,
>> > > as clearly staten in COPYING.images and data/elementary/themes/fdo
>> > >
>> > > I have no idea about the contamination and the resulting theme final
>> > > license.
>> > >
>> > > For sure I want (and we must) them to remain to that license.
>> > >
>> >
>> > I don't understand why you wouldn't want them licensed under an
>> > equivalent creative commons license rather then GPL-3, GPL-3 is designed
>> > for source code where as creative commons is designed for images, using
>> > the wrong sort of licenses leads to the ambiguities we are seeing here,
>> > if we can't convince the upstream developers to change there isn't much
>> > we can do but its worth trying.
>>
>> we need to probably replace them with icons that are not licensed like the
>> above.
>>
>> as for contamination, that is generally considered to be true with code if
>> they
>> share the same memory space. icons on the other hand do not. they are first
>> decoded/rendered then manipulated. code from the binary is mapped directly
>> into
>> memory as-is pretty much minus relocation.
>>
>> so while i don't think DATA files would leak their license to efl, gplv3
>> does
>> create requirements of its host system (to allow any gplv3 components to be
>> replaceable by the end user) and that requires any system that would ship
>> these
>> to not be locked down. that is generally disliked by commercial vendors.
>>
>> so my take is "replace them". i could replace them anyway if the theme
>> fundamentally changed (e.g. became flat).
>>
>
> Did you see how many fdo icons are there? I don't think we have the manpower
> to redesign all of them.
>
>
>>
>> > >
>> > > 2018-01-30 14:05 GMT+01:00 Jean-Philippe André :
>> > >
>> > >> On Tue, Jan 30, 2018 at 9:30 PM, Simon Lees  wrote:
>> > >>
>> > >>>
>> > >>>
>> > >>> On 30/01/18 22:20, Jean-Philippe André wrote:
>> >  Hi,
>> > 
>> >  Sungtaek pointed out to me that we have GPLv3-licensed artworks
>> (unsual
>> > >>> for
>> >  images) in our theme, under data/elementary/theme/fdo. Those images
>> are
>> > >>> are
>> >  then included in the compiled theme default.edj. One source is
>> clearly
>> >  GPLv3:
>> >  https://tiheum.deviantart.com/art/Faenza-Icons-173323228
>> > 
>> >  Now I wonder what the implications of this are...
>> >  1. Does Elementary become GPL because we load the theme and it
>> contains
>> >  executable code (embryo & edje programs), so the theme is to be
>> > >>> considered
>> >  a library, contaminating everything??
>> >  2. Or only the theme itself is GPL, by contamination from those
>> images?
>> >  3. Or is the compiled theme file not GPL because we're not linking
>> or
>> >  derivating, merely archiving those images like in a Zip file, in
>> which
>> > >>> case
>> >  only what's in the tree is GPL? This would be same as HTML:
>> >  https://news.slashdot.org/story/13/06/26/2113242/when-
>> > >>> gpl-becomes-almost-gpl-the-css-images-and-javascript-
>> > >>> loophole/informative-comments#comments
>> > 
>> >  In the FAQ I only found a mention about fonts:
>> >  https://www.gnu.org/licenses/gpl-faq.en.html#FontException
>> >  We don't have such an exception.
>> > 
>> >  Pretty sure there is no problem (i.e. #3 is right), but IANAL so I'd
>> > >>> rather
>> >  ask away :)
>> > 
>> > >>>
>> > >>> Licence wise i've always considered themes to be separate, whether
>> that
>> > >>> is correct or not is another question. GPL with images is silly
>> anyway
>> > >>> and we really should be asking upstream to relicense with some form
>> of
>> > >>> creative commons anyway which makes far more sense, but I guess the
>> > >>> theme is probably technically GPL-3 as a binary.
>> > >>
>> > >>
>> > >> Not so sure. HTML seems to be a crazy exception: An HTML file
>> containing
>> > >> GPL licensed JS code is not GPL itself. Not consistent but makes
>> sense. EDJ
>> > >> probably also falls under the category of "container".
>> > >>
>> > >>
>> > >>> Probably the biggest actual real life issue is if the theme is being
>> > >>> used in consumer devices such as tizen you would need to provide
>> > >>> consumers a way to swap there stock theme for one of there choice.
>> > >>>
>> > >>
>> > >> Yeah that's partly why I'm asking. :)
>> > >>
>> > >> --
>> > >> Jean-Philippe André
>> > >> 
>> > >> --
>> > >> Check out the vibrant tech community on one of the world's most
>> > >> engaging tech sites, Slashdot.org! 

Re: [E-devel] GPL icons in theme

[Davide Andreoli]

2018-01-31 10:52 GMT+01:00 Carsten Haitzler :

> On Wed, 31 Jan 2018 14:37:28 +1030 Simon Lees  said:
>
> >
> >
> > On 31/01/18 10:39, Davide Andreoli wrote:
> > > The fdo icons in the efl theme are indeed GPL3,
> > > as clearly staten in COPYING.images and data/elementary/themes/fdo
> > >
> > > I have no idea about the contamination and the resulting theme final
> > > license.
> > >
> > > For sure I want (and we must) them to remain to that license.
> > >
> >
> > I don't understand why you wouldn't want them licensed under an
> > equivalent creative commons license rather then GPL-3, GPL-3 is designed
> > for source code where as creative commons is designed for images, using
> > the wrong sort of licenses leads to the ambiguities we are seeing here,
> > if we can't convince the upstream developers to change there isn't much
> > we can do but its worth trying.
>
> we need to probably replace them with icons that are not licensed like the
> above.
>
> as for contamination, that is generally considered to be true with code if
> they
> share the same memory space. icons on the other hand do not. they are first
> decoded/rendered then manipulated. code from the binary is mapped directly
> into
> memory as-is pretty much minus relocation.
>
> so while i don't think DATA files would leak their license to efl, gplv3
> does
> create requirements of its host system (to allow any gplv3 components to be
> replaceable by the end user) and that requires any system that would ship
> these
> to not be locked down. that is generally disliked by commercial vendors.
>
> so my take is "replace them". i could replace them anyway if the theme
> fundamentally changed (e.g. became flat).
>

Did you see how many fdo icons are there? I don't think we have the manpower
to redesign all of them.


>
> > >
> > > 2018-01-30 14:05 GMT+01:00 Jean-Philippe André :
> > >
> > >> On Tue, Jan 30, 2018 at 9:30 PM, Simon Lees  wrote:
> > >>
> > >>>
> > >>>
> > >>> On 30/01/18 22:20, Jean-Philippe André wrote:
> >  Hi,
> > 
> >  Sungtaek pointed out to me that we have GPLv3-licensed artworks
> (unsual
> > >>> for
> >  images) in our theme, under data/elementary/theme/fdo. Those images
> are
> > >>> are
> >  then included in the compiled theme default.edj. One source is
> clearly
> >  GPLv3:
> >  https://tiheum.deviantart.com/art/Faenza-Icons-173323228
> > 
> >  Now I wonder what the implications of this are...
> >  1. Does Elementary become GPL because we load the theme and it
> contains
> >  executable code (embryo & edje programs), so the theme is to be
> > >>> considered
> >  a library, contaminating everything??
> >  2. Or only the theme itself is GPL, by contamination from those
> images?
> >  3. Or is the compiled theme file not GPL because we're not linking
> or
> >  derivating, merely archiving those images like in a Zip file, in
> which
> > >>> case
> >  only what's in the tree is GPL? This would be same as HTML:
> >  https://news.slashdot.org/story/13/06/26/2113242/when-
> > >>> gpl-becomes-almost-gpl-the-css-images-and-javascript-
> > >>> loophole/informative-comments#comments
> > 
> >  In the FAQ I only found a mention about fonts:
> >  https://www.gnu.org/licenses/gpl-faq.en.html#FontException
> >  We don't have such an exception.
> > 
> >  Pretty sure there is no problem (i.e. #3 is right), but IANAL so I'd
> > >>> rather
> >  ask away :)
> > 
> > >>>
> > >>> Licence wise i've always considered themes to be separate, whether
> that
> > >>> is correct or not is another question. GPL with images is silly
> anyway
> > >>> and we really should be asking upstream to relicense with some form
> of
> > >>> creative commons anyway which makes far more sense, but I guess the
> > >>> theme is probably technically GPL-3 as a binary.
> > >>
> > >>
> > >> Not so sure. HTML seems to be a crazy exception: An HTML file
> containing
> > >> GPL licensed JS code is not GPL itself. Not consistent but makes
> sense. EDJ
> > >> probably also falls under the category of "container".
> > >>
> > >>
> > >>> Probably the biggest actual real life issue is if the theme is being
> > >>> used in consumer devices such as tizen you would need to provide
> > >>> consumers a way to swap there stock theme for one of there choice.
> > >>>
> > >>
> > >> Yeah that's partly why I'm asking. :)
> > >>
> > >> --
> > >> Jean-Philippe André
> > >> 
> > >> --
> > >> Check out the vibrant tech community on one of the world's most
> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >> ___
> > >> enlightenment-devel mailing list
> > >> enlightenment-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >>
> > > 

Re: [E-devel] GPL icons in theme

[Davide Andreoli]

2018-01-31 10:52 GMT+01:00 Carsten Haitzler :

> On Wed, 31 Jan 2018 14:37:28 +1030 Simon Lees  said:
>
> >
> >
> > On 31/01/18 10:39, Davide Andreoli wrote:
> > > The fdo icons in the efl theme are indeed GPL3,
> > > as clearly staten in COPYING.images and data/elementary/themes/fdo
> > >
> > > I have no idea about the contamination and the resulting theme final
> > > license.
> > >
> > > For sure I want (and we must) them to remain to that license.
> > >
> >
> > I don't understand why you wouldn't want them licensed under an
> > equivalent creative commons license rather then GPL-3, GPL-3 is designed
> > for source code where as creative commons is designed for images, using
> > the wrong sort of licenses leads to the ambiguities we are seeing here,
> > if we can't convince the upstream developers to change there isn't much
> > we can do but its worth trying.
>

Just because I don't know well the various CC licenses :) sorry, indeed my
reply was a bit too rough. My main concern was that It seems to me quite
impossible  to convince all the upstream licenser to change their licenses.


>
> we need to probably replace them with icons that are not licensed like the
> above.
>
> as for contamination, that is generally considered to be true with code if
> they
> share the same memory space. icons on the other hand do not. they are first
> decoded/rendered then manipulated. code from the binary is mapped directly
> into
> memory as-is pretty much minus relocation.
>
> so while i don't think DATA files would leak their license to efl, gplv3
> does
> create requirements of its host system (to allow any gplv3 components to be
> replaceable by the end user) and that requires any system that would ship
> these
> to not be locked down. that is generally disliked by commercial vendors.
>
> so my take is "replace them". i could replace them anyway if the theme
> fundamentally changed (e.g. became flat).
>
> > >
> > > 2018-01-30 14:05 GMT+01:00 Jean-Philippe André :
> > >
> > >> On Tue, Jan 30, 2018 at 9:30 PM, Simon Lees  wrote:
> > >>
> > >>>
> > >>>
> > >>> On 30/01/18 22:20, Jean-Philippe André wrote:
> >  Hi,
> > 
> >  Sungtaek pointed out to me that we have GPLv3-licensed artworks
> (unsual
> > >>> for
> >  images) in our theme, under data/elementary/theme/fdo. Those images
> are
> > >>> are
> >  then included in the compiled theme default.edj. One source is
> clearly
> >  GPLv3:
> >  https://tiheum.deviantart.com/art/Faenza-Icons-173323228
> > 
> >  Now I wonder what the implications of this are...
> >  1. Does Elementary become GPL because we load the theme and it
> contains
> >  executable code (embryo & edje programs), so the theme is to be
> > >>> considered
> >  a library, contaminating everything??
> >  2. Or only the theme itself is GPL, by contamination from those
> images?
> >  3. Or is the compiled theme file not GPL because we're not linking
> or
> >  derivating, merely archiving those images like in a Zip file, in
> which
> > >>> case
> >  only what's in the tree is GPL? This would be same as HTML:
> >  https://news.slashdot.org/story/13/06/26/2113242/when-
> > >>> gpl-becomes-almost-gpl-the-css-images-and-javascript-
> > >>> loophole/informative-comments#comments
> > 
> >  In the FAQ I only found a mention about fonts:
> >  https://www.gnu.org/licenses/gpl-faq.en.html#FontException
> >  We don't have such an exception.
> > 
> >  Pretty sure there is no problem (i.e. #3 is right), but IANAL so I'd
> > >>> rather
> >  ask away :)
> > 
> > >>>
> > >>> Licence wise i've always considered themes to be separate, whether
> that
> > >>> is correct or not is another question. GPL with images is silly
> anyway
> > >>> and we really should be asking upstream to relicense with some form
> of
> > >>> creative commons anyway which makes far more sense, but I guess the
> > >>> theme is probably technically GPL-3 as a binary.
> > >>
> > >>
> > >> Not so sure. HTML seems to be a crazy exception: An HTML file
> containing
> > >> GPL licensed JS code is not GPL itself. Not consistent but makes
> sense. EDJ
> > >> probably also falls under the category of "container".
> > >>
> > >>
> > >>> Probably the biggest actual real life issue is if the theme is being
> > >>> used in consumer devices such as tizen you would need to provide
> > >>> consumers a way to swap there stock theme for one of there choice.
> > >>>
> > >>
> > >> Yeah that's partly why I'm asking. :)
> > >>
> > >> --
> > >> Jean-Philippe André
> > >> 
> > >> --
> > >> Check out the vibrant tech community on one of the world's most
> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > >> ___
> > >> enlightenment-devel mailing list
> > >> 

Re: [E-devel] GPL icons in theme

[Carsten Haitzler]

On Wed, 31 Jan 2018 14:37:28 +1030 Simon Lees  said:

> 
> 
> On 31/01/18 10:39, Davide Andreoli wrote:
> > The fdo icons in the efl theme are indeed GPL3,
> > as clearly staten in COPYING.images and data/elementary/themes/fdo
> > 
> > I have no idea about the contamination and the resulting theme final
> > license.
> > 
> > For sure I want (and we must) them to remain to that license.
> > 
> 
> I don't understand why you wouldn't want them licensed under an
> equivalent creative commons license rather then GPL-3, GPL-3 is designed
> for source code where as creative commons is designed for images, using
> the wrong sort of licenses leads to the ambiguities we are seeing here,
> if we can't convince the upstream developers to change there isn't much
> we can do but its worth trying.

we need to probably replace them with icons that are not licensed like the
above.

as for contamination, that is generally considered to be true with code if they
share the same memory space. icons on the other hand do not. they are first
decoded/rendered then manipulated. code from the binary is mapped directly into
memory as-is pretty much minus relocation.

so while i don't think DATA files would leak their license to efl, gplv3 does
create requirements of its host system (to allow any gplv3 components to be
replaceable by the end user) and that requires any system that would ship these
to not be locked down. that is generally disliked by commercial vendors.

so my take is "replace them". i could replace them anyway if the theme
fundamentally changed (e.g. became flat).

> > 
> > 2018-01-30 14:05 GMT+01:00 Jean-Philippe André :
> > 
> >> On Tue, Jan 30, 2018 at 9:30 PM, Simon Lees  wrote:
> >>
> >>>
> >>>
> >>> On 30/01/18 22:20, Jean-Philippe André wrote:
>  Hi,
> 
>  Sungtaek pointed out to me that we have GPLv3-licensed artworks (unsual
> >>> for
>  images) in our theme, under data/elementary/theme/fdo. Those images are
> >>> are
>  then included in the compiled theme default.edj. One source is clearly
>  GPLv3:
>  https://tiheum.deviantart.com/art/Faenza-Icons-173323228
> 
>  Now I wonder what the implications of this are...
>  1. Does Elementary become GPL because we load the theme and it contains
>  executable code (embryo & edje programs), so the theme is to be
> >>> considered
>  a library, contaminating everything??
>  2. Or only the theme itself is GPL, by contamination from those images?
>  3. Or is the compiled theme file not GPL because we're not linking or
>  derivating, merely archiving those images like in a Zip file, in which
> >>> case
>  only what's in the tree is GPL? This would be same as HTML:
>  https://news.slashdot.org/story/13/06/26/2113242/when-
> >>> gpl-becomes-almost-gpl-the-css-images-and-javascript-
> >>> loophole/informative-comments#comments
> 
>  In the FAQ I only found a mention about fonts:
>  https://www.gnu.org/licenses/gpl-faq.en.html#FontException
>  We don't have such an exception.
> 
>  Pretty sure there is no problem (i.e. #3 is right), but IANAL so I'd
> >>> rather
>  ask away :)
> 
> >>>
> >>> Licence wise i've always considered themes to be separate, whether that
> >>> is correct or not is another question. GPL with images is silly anyway
> >>> and we really should be asking upstream to relicense with some form of
> >>> creative commons anyway which makes far more sense, but I guess the
> >>> theme is probably technically GPL-3 as a binary.
> >>
> >>
> >> Not so sure. HTML seems to be a crazy exception: An HTML file containing
> >> GPL licensed JS code is not GPL itself. Not consistent but makes sense. EDJ
> >> probably also falls under the category of "container".
> >>
> >>
> >>> Probably the biggest actual real life issue is if the theme is being
> >>> used in consumer devices such as tizen you would need to provide
> >>> consumers a way to swap there stock theme for one of there choice.
> >>>
> >>
> >> Yeah that's partly why I'm asking. :)
> >>
> >> --
> >> Jean-Philippe André
> >> 
> >> --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > 
> 
>