Hi,

> > From what you say, I understand you don't want
> >commercial compilers to be allowed to use your files. Is that right ?
>
> Yup. that's right. Long live open source!
>
> The flow would be like this.
> The dex code i produce could be keep secret from outside world, just
> for now. But not from you and other JALLIB developers.


Well, keeping things secret is not something I would call open source :)

What about other open source compilers ? Why couldn't they use your files ?


>
> I hope, myself, you and others will be maintain that dex information
> first.


OK. What is "dex" ? Is it a format of your own ? Is that what you posted, or
something "above" this ?


> We could release it in the future, after we gathered all the PIC
> details. Complete it first.


Why not, but another approach is to use this information little by little,
as soon as it's available. Integrate, use it early. This will make sure it
can be used as expected, and can give lots of ideas while using it to
improve our libs.

Can you give some details about work to be done before having this
information complete ? What should be done ?


>
> We could generate JALLIB files some information from this dex code,
> Then,  the released file, would be in license is either BSD or ZLIB.


OK.

I understand that:

  - you don't want your files/informations being used by commercial
compiler/lib/program/etc...
  - there's probably an open source license which would fit this need
  - but this information will also be the source for producing, generating
jal files
  - these jal files will be ZLIB licensed (BSD is for samples and projects),
thus allowed to be used in commercial applications.

And this is where we may have problems:

  - depending on the license used for your dex files, it could be
incompatible with ZLIB, or worst contaminate our jal files, which would not
be allowed to be used in commercial applications (this is not what we want)
  - even it's ok, the information containted in generated jal files could be
exploited by commercial applications. Parsing a jal file is not a big deal.
At the end, one could reconstitute your dex files from another source of
information.


Sorry to bother with this, but this is an important point, that must be
clarified. Just few more words: when I wrote my small scripts to parse PDF
in order to extract pin aliases (DIPPinDef in your dex), I first tried to
get this information from another project, website, etc, in a format that
could programmatically be used... I was quite surprised to found nothing...
even from Microchip itself ! This information is valuable, if others
(commercial or not) could use it, then it's good for them, it's good for us
and for jallib/jal.


>
> This dex will be not needed on jal compiler. We don't need to release
> it as part of JALLIB right?


This is up to you ! As an example, Rob develops dev2jal project, which
generate device files. While this project could live (and is living) on its
own, it's also part of jallib, because Rob wanted it and this makes sens.


This is my point of view, maybe other guys around there could give their own
point of view, advices.


Cheers,
Seb
-- 
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to