Is it possible for one in a nation that doesn't permit dedication to
public domain to simply gift the work (and intellectual rights) to
someone personally, who can and will the reassign it to the public
domain (such as a member of the sqlite dev team)?

On Mon, Jul 22, 2013 at 9:30 AM, Dušan Paulovič <paulo...@gisoft.cz> wrote:
> 1. I am not citizen of Czech Republic (but citizen of Slovak Republic with
> similar law)
> 2. If I do not want apply my copyrights, I can public my code without it.
>
>
> 2013/7/22 Richard Hipp <d...@sqlite.org>
>
>> On Mon, Jul 22, 2013 at 8:10 AM, Dušan Paulovič <paulo...@gisoft.cz>
>> wrote:
>>
>> > Hello, I like to make a patch for SQLite so that function xBestIndex
>> gets a
>> > collation sequences as a part of  sqlite3_index_info structure. Patch
>> will
>> > be binary compatible with previous versions, so all existing virtual
>> table
>> > implementations will work with new version. I understand, that I must
>> > attach also public domain copyright statment to be SQLite team able to
>> > merge it.
>> >
>>
>> According to what I read in Wikipedia, citizens of the Czech Republic are
>> not allowed to dedicate their work to the public domain.  :-(
>>
>>
>>
>> >
>> > What I do not know is:
>> > Can I somehow contact anybody about internal rules?
>> >
>>
>> Probably the sqlite-...@sqlite.org mailing list.
>>
>>
>> > Can I create new empty typedef for CollSeq struct? (name:
>> sqlite3_coll_seq)
>> > Can I create new API functions? (sqlite3_coll_seq_strcmp,
>> > sqlite3_coll_seq_name, sqlite3_coll_seq_enc)
>> > What all documentation should I provide? (I am not english native
>> speaker)
>> > Should be such code in #ifndef SQLITE_OMIT_VIRTUALTABLE blocks?
>> > Is there any chance that such patch will be merged to SQLite?
>> >
>>
>> It is an up-hill battle.  New interfaces in SQLite must be supported
>> forever, which is a lot of work for the core team.  So in order to accept a
>> new interface, we need to be convinced that there is lasting value for a
>> large community of users and that this value is sufficient to justify the
>> long-term support costs.  Other obstacles include the copyright issue cited
>> above, and the necessity of having 100% branch test coverage and complete
>> documentation of the new features.
>>
>>
>> --
>> D. Richard Hipp
>> d...@sqlite.org
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users



-- 
VerifEye Technologies Inc.
905-948-0015x245
151 Whitehall Dr, Unit 2
Markham ON, L3R 9T1
Canada
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to